In AWS, there are two important services that help with this: Amazon EC2 Auto Scaling and AWS Auto Scaling. Amazon EC2 Auto Scaling is specifically for managing your EC2 servers, while AWS Auto Scaling can also handle other things like DynamoDB tables and Amazon Aurora databases.

In this article, we'll dive deeper into how Amazon EC2 Auto Scaling works and how you can use it to keep your website running smoothly without overspending on servers.

Prerequisites

• Have an AWS account
• Basic understanding of EC2 instance

Table of Content

• Prerequisites
• Example Use case
• Advantages of Amazon EC2 Auto Scaling
• Components of EC2 Auto Scaling
• What is Launch Configurations vs Launch Templates
• How to create a launch template
• What are Auto Scaling Groups (ASGs)
• How to create an Auto Scaling Group
• What are Scaling Policies
• Conclusion

Example Use Case

Scenario:

Imagine running a website that sells trendy clothes. Sometimes, lots of people visit your site at once, especially during lunch breaks or evenings. Other times, it's pretty quiet.

Problem:

You need enough servers to handle busy times, but you don't want to waste money on too many servers when it's quiet.

Solution with Amazon EC2 Auto Scaling:

Traffic Analysis: Look at when people visit your site the most. This helps you understand when you need more servers.

Set Rules: Decide when to add or remove servers automatically. For example, you might say, "If more than 70% of our servers are busy for more than 5 minutes, add one more server."

Adjust Server Numbers: Tell Amazon the smallest and biggest number of servers you need. You can also say how many you'd like on average. For instance, you might say, "Keep at least 2 servers running all the time. But if it's busy, go up to 10 servers. And usually, we need around 4."

Load Balancing: Make sure all servers get some work. Use a load balancer to send visitors to the least busy server. This keeps everything running smoothly even if you have many servers.

Test and Watch: Before trusting everything, test to see if it works as planned. Keep an eye on it afterward to make sure it's doing its job right.

Save Money: With auto scaling, you don't pay for servers you're not using. When traffic is low, it reduces the number of servers, saving you money. When traffic picks up, it adds more servers, so your site stays fast.

Advantages of Using Amazon EC2 Auto Scaling

Cost Optimization: EC2 Auto Scaling helps optimize costs by automatically adjusting the number of EC2 instances based on demand. During periods of low traffic, it reduces the number of instances, saving on operational costs. Conversely, during high traffic, it scales up to ensure optimal performance without over-provisioning resources.

Improved Availability: By automatically distributing incoming traffic across multiple instances and fault tolerance of your application. If any instance fails/is unhealthy, the Auto Scaling group replaces it with a new one, ensuring minimal disruption to your services.

Scalability: EC2 Auto Scaling allows your application to handle sudden spikes in traffic or increased workload without manual intervention.

Enhanced Performance: With EC2 Auto Scaling, you can maintain consistent performance levels even during peak usage periods. By automatically adding more instances when traffic increases, it prevents performance degradation and ensures a smooth user experience.

Ease of Management: EC2 Auto Scaling simplifies the management of your EC2 fleet by automating instance provisioning, scaling, and monitoring.

Integration with AWS Services: EC2 Auto Scaling integrates seamlessly with other AWS services such as Elastic Load Balancing (ELB) and Amazon CloudWatch.

Highly Customizable: EC2 Auto Scaling offers flexibility and customization options to meet the specific needs of your application.

Components of EC2 Auto Scaling

Let's get a better understanding on how the Auto Scaling works through its different components.

There are two distinct steps to configuration. The first step is the creation of a launch configuration or launch template. The second is the creation of an Auto Scaling group.

Launch Configurations and Launch Templates

Launch configurations or launch templates define the configuration settings for the EC2 instances that will be launched by the Auto Scaling group.

These settings include the AMI (Amazon Machine Image), instance type, security groups, key pair, and user data.

Launch configurations are older and being phased out in favor of launch templates, which offer more features and flexibility.

How to Create a Launch Template

First, navigate to EC2 Instance page

AWS instance page

Select the Launch Templates under the instances and click the create button.

AWS launch templates

The following screen should show up, almost similar to launching an EC2 instance. You can fill the required information accordingly.

Create AWS launch templates

After configuration, click the "Create Launch" template button and allow it to create, then view your newly created launch template with default and latest version as 1. You can use this launch template to create another launch template and specify a different version for it.

View AWS launch templates

Auto scaling requires either a launch template or launch configuration to identify the instance it's launching and its configurations.

What are Auto Scaling Groups (ASGs)

Auto Scaling groups are the core component of EC2 Auto Scaling. They define the group of EC2 instances that are managed together and share the same scaling policies. ASGs ensure that your application can automatically scale out (add instances) or scale in (remove instances) based on demand.

How to create an Auto Scaling Group

First, navigate to EC2 Instance page and under the Auto Scaling group, select and click the create button.

creating an Auto Scaling group

On the create screen, the first step is to give your ASG a Name and then select your launch template created from the steps above.

creating a launch template

The next step requires you to select or override an instance launch template. You also select a VPC and subnet.

selecting instance launch template

The next step is to configure advanced options such as adding a load balancer and monitoring. You can attach or add a new load balancer but for this article we will skip this part.

configuring advanced options

Next, configure the group size and scaling. Here, we want to configure the scale between minimum of 2 and maximum of 5. Also, set the metrics type to track the CPU utilization (set to 50 – you can increase to 70 or more) for scaling.

configuring group size and scaling

Next two steps are for adding notifications (you will need to create an SNS service for this) and tags. In this article, we are going to skip these and create our ASG.

Create and view the ASG created. From its activity folder, you can see those two instances launched. Also, from the instances page, you should see two EC2 instances. This is because we set our desired state to 2.

Auto Scaling groups

Auto Scaling groups

What are Scaling Policies?

Scaling policies define the rules that govern how the Auto Scaling group scales in or out in response to changing demand. There are four types of scaling policies:

Let's break down each type of scaling with examples:

Manual Scaling

Manual scaling involves adjusting the number of EC2 instances in your Auto Scaling group manually, without relying on automated triggers or policies. This type of scaling is typically done in response to predictable events or planned changes in demand.

Example: Assuming you run an e-commerce website, and you know that there will be a flash sale event that will attract a large number of visitors. To handle the expected surge in traffic, you can manually increase the desired capacity of your Auto Scaling group before the event, adding more EC2 instances in advance of the anticipated demand spike. After the event is over, you can manually reduce the desired capacity back to its normal level.

Pros:

• Control: Offers direct control over the number of EC2 instances in the Auto Scaling group.
• Flexibility: Allows for immediate adjustments based on specific requirements or events.

Cons:

• Manual Intervention: Relies on human intervention, which can be time-consuming and prone to errors.
• Lack of Automation: Not suitable for handling dynamic or unpredictable fluctuations in demand efficiently.

Schedule Scaling

Schedule scaling involves defining predefined schedules to adjust the number of EC2 instances in your Auto Scaling group automatically. This type of scaling is useful for applications with predictable traffic patterns, such as daily or weekly fluctuations in demand.

Example: Consider a video streaming service that experiences peak traffic during evenings and weekends. You can set up a schedule scaling policy to increase the desired capacity of your Auto Scaling group every evening at 6 PM and decrease it every morning at 6 AM. This ensures that you have enough capacity to handle peak demand periods without overspending on resources during off-peak hours.

Pros:

• Predictability: Well-suited for applications with predictable traffic patterns, such as daily or weekly fluctuations.
• Cost Optimization: Helps optimize costs by aligning resources with expected demand patterns.

Cons:

• Limited Adaptability: May not be responsive to sudden changes in demand or unexpected traffic spikes.
• Requires Planning: Requires upfront planning and configuration of schedules based on historical data or business insights.

Dynamic Scaling

Dynamic scaling adjusts the number of EC2 instances in your Auto Scaling group automatically based on real-time metrics, such as CPU utilization, network traffic, or other application-specific metrics. This type of scaling is responsive to fluctuations in demand and helps ensure optimal performance and cost-effectiveness.

Types:

• Step Scaling: This policy scales the number of instances based on a series of scaling adjustments defined by step adjustments and associated metrics thresholds.
• Target Tracking: This policy automatically adjusts the number of instances to maintain a specified target metric, such as average CPU utilization or network traffic.

When adding instances to the ASG, it will take a few minutes for them to come online and handle load. This is why a cooldown policy has to be set.

Scaling Cooldowns: Scaling cooldowns help prevent rapid fluctuations in the number of instances by imposing a cooldown period after a scaling activity is triggered. During this cooldown period, EC2 Auto Scaling will not launch or terminate additional instances, allowing time for the newly launched instances to stabilize or for the impact of terminated instances to be observed.

Example: Let's say you operate a ride-sharing platform where demand can vary unpredictably throughout the day. With dynamic scaling, you can configure Auto Scaling policies to add more EC2 instances when the number of ride requests exceeds a certain threshold, and remove instances when demand decreases. This allows you to dynamically adapt to changing traffic patterns in real-time, ensuring a seamless experience for both drivers and passengers.

Pros:

• Real-Time Responsiveness: Adjusts resource allocation dynamically in response to actual demand, ensuring optimal performance.
• Cost Efficiency: Automatically scales resources up or down, helping to optimize costs by only using what is needed.

Cons:

• Potential Over-Provisioning: May lead to over-provisioning during sudden spikes in demand if scaling policies are not properly configured.
• Complexity: Requires careful configuration of scaling policies and monitoring of metrics to ensure effective scaling behavior.

Predictive Scaling

Predictive scaling uses machine learning algorithms and historical data to forecast future demand and proactively adjust the number of EC2 instances in your Auto Scaling group. This type of scaling helps prevent under-provisioning or over-provisioning of resources by anticipating changes in demand before they occur.

Example: Suppose you operate a weather forecasting application that experiences increased demand during severe weather events. By analyzing historical data on weather patterns and user behavior, predictive scaling can predict when a surge in traffic is likely to occur and automatically scale up the capacity of your Auto Scaling group ahead of time. This ensures that your application remains responsive and available during peak usage periods without unnecessary resource waste.

Pros:

• Proactive Optimization: Anticipates future demand based on historical data, ensuring resources are provisioned ahead of time.
• Improved Cost Management: Helps prevent under-provisioning and over-provisioning, optimizing resource usage and costs.

Cons:

• Data Dependence: Relies on accurate historical data and effective machine learning models for accurate predictions.
• Initial Setup: Requires initial setup and configuration of predictive scaling models, which can be complex and resource-intensive.

Conclusion

In conclusion, Amazon EC2 Auto Scaling offers a range of strategies to effectively manage and optimize the performance of applications running on EC2 instances.

Whether it's through manual adjustments, scheduled scaling, dynamic responses to real-time metrics, or proactive measures based on predictive analytics, EC2 Auto Scaling provides the flexibility and automation needed to ensure that resources are aligned with demand.

By leveraging these scaling capabilities, businesses can enhance availability, improve cost efficiency, and deliver a seamless user experience, ultimately driving better outcomes for their applications and customers on the AWS platform.

As always, I hope you enjoyed the article and learned something new. If you want, you can also follow me on LinkedIn or Twitter.

freeCodeCamp.org contributor David Jolliffe created a quiz game with questions on JavaScript, CSS, networking, and computer science.

If you have an Amazon Echo nearby, you can play the game right now by saying: "Alexa, start the free code camp quiz."

The entire project, along with it's ~100 questions, is open source and on GitHub. We would welcome additional questions. Open a pull request adding your new question to the codebase, or just open a GitHub issue with the question if you're in a hurry.

Here's a video of me and my 11-month-old son Quentin demonstrating the Alexa skill. You can watch the video on the freeCodeCamp.org YouTube channel (3 minute watch).‌

In the first part of this tutorial, we created an API which passed requests through to a Lambda which returned the top tv show or movie for that genre. Now we’re going to use DynamoDB to allow users to vote for their favourite genre.

If you’ve not read the first part of this series, then check it out here!

DynamoDB

DynamoDB is a non-relational database created by Amazon that we can use to store the users’ votes. It’s also great, because we can access it easily using the aws-sdk which Lambdas have preinstalled.

The first thing we need to do is to create a table to store the movie votes. Navigate to DynamoDB in AWS and click “Create table”.

On the next page, we will name our table and provide a primary key. The primary key needs to be unique so we don’t have two records with the same key. We can call the table “movie-api” and set the primary key to “movie-genre”, as each movie should only appear once in each genre.

We’ve now set up all that we need to set up in DynamoDB so we can go back into our code.

Adding a Dynamo handler

Getting and putting data into a Dynamo table is done using the documentClient on aws-sdk, but the structure of the requests is very specific. To make our lives easier, we can make a Dynamo handler to do all of the formatting.

Start by creating a new file called “dynamo.js” in the “movieAPI” Lambda. In this file we start by requiring aws-sdk and creating our documentClient.

const AWS = require('aws-sdk');

let documentClient = new AWS.DynamoDB.DocumentClient({    'region': 'eu-west-1'});

We now want to create and export a class that has three methods on it: a get, a write, and an update.

module.exports = class DB {    get(key, value, table) {}    write(ID, data, table) {}    async increment(ID, table) {}}

We’ll start by creating our get method. The first thing we need to do is to check that we have a valid key, value, and table.

if (!table) throw 'table needed';if (typeof key !== 'string') throw `key was not string and was ${JSON.stringify(key)} on table ${table}`;if (typeof value !== 'string') throw `value was not string and was ${JSON.stringify(value)} on table ${table}`;

Because we want this method to be promise-based, we need to return a new Promise.

return new Promise((resolve, reject) => {})

To get data from Dynamo, we need to pass a set of parameters to the document client. These params need to include TableName and Key.

let params = {    TableName: table,    Key: {[key]: value}};

We pass these params to documentClient and then reject if there is an error or resolve if there isn’t.

documentClient.get(params, function(err, data) {    if (err) {        console.log(`There was an error fetching the data for ${key} ${value} on table ${table}`, err);        return reject(err);    }    return resolve(data.Item);});

A similar process is done for the write method. We check that the parameters are valid, create the parameters, and pass them to documentClient.

return new Promise((resolve, reject) => {    if (typeof ID !== 'string') throw `the id must be a string and not ${ID}`;    if (!data) throw "data is needed";    if (!table) throw 'table name is needed';

    let params = {        TableName: table,        Item: { ...data, ID: ID }    };

    documentClient.put(params, function(err, result) {        if (err) {            console.log("Err in writeForCall writing messages to dynamo:", err);            console.log(params);            return reject(err);        }        console.log('wrote data to table ', table)        return resolve({ ...result.Attributes, ...params.Item });    });});

The increment method is a lot easier. To increment, we try getting the data for that key, increase the count by one, and then write it back to the database. If we can’t get the data, or if there is no count on the data, then we assume that we need to set the count to 0.

async increment(ID, table) {    if (!table) throw 'table needed';    if (!ID) throw 'ID needed';    let data;    try {        data = await this.get('movie-genre', ID, table);        if (!data.count) throw 'no count in data'    } catch (err) {            data = { "movie-genre": ID, count: 0 };    };    let newData = { ...data, count: data.count + 1 };    return this.write(ID, newData, table);}

Modifying our Lambda

Now we have an easy way to get, write, and update our Dynamo table. We can use this to allow our users to vote. Inside “index.js”, we first need to import our new Dynamo class and create an instance of it.

const DB = require('./dynamo');const Dynamo = new DB();

Now, inside of our putMovie we can add the logic to allow users to vote. The two things we need to get are movie from the body and genre from the path parameters. We then combine these to create our movie-genre ID. This then gets passed into Dynamo.increment with a table name of movie-api and our putMovie is complete.

const putMovie = async event => {    let { movie } = JSON.parse(event.body);    let genre = event.pathParameters.genre;    let ID = `${movie}-${genre}`;    return Dynamo.increment(ID, 'movie-api')}

To get this to work when we receive the Put request, we need to slightly modify our base handler function.

if (event.httpMethod === 'PUT') {    let response = await putMovie(event)    return done(response);}

Because we’ve added AWS to our Lambda, we need to run npm init and then npm install — save aws-sdk while in the Lambda folder. This can be done locally and uploaded, or done using Cloud9.

Adding the API Gateway method

With the new function, we can add a new method to our API. In API Gateway, we can select our “movieAPI” and then select “/movies/{genre}”. Click “Actions” -> “Create Meth_o_d” and choose to add a “PUT” method.

This “PUT” can be directed at our “movieAPI”, and tick “Use Lambda Proxy Integration”. Once saved we can test it out. On the method we can click “TEST” and enter a genre and a body containing a movie. When we click “TEST” we get a response containing the movie and new count. As this is the first vote, the count will be 1.

Running the test a second time will now increment the votes for this movie by one.

Modifying the GET method

Now that we have a new voting system, we can update our “GET” to use this new data. We need to get all of the movies that are in the requested genre and list them in order of votes.

We first need to make a new dynamo method. This method will scan each of the entries and pick out the ones that match our criteria.

scan(key, value, table) {    return new Promise((resolve, reject) => {        let params = {             TableName: table,             FilterExpression: `${key} = :value`,             ExpressionAttributeValues: { ':value': value }         };         documentClient.scan(params, function(err, data) {             if (err) reject(err);             resolve(data);         });    });}

We can now modify our getMovie function to use this new Dynamo method. We need to pass the genre, selected movie, and current count.

const getMovie = async event => {    let genre = event.pathParameters.genre;    let data = await Dynamo.scan('genre', genre, 'movie-api');    let result = data.Items.sort((a,b) => b.count - a.count);    result = result.map(({count, ID, genre})=> { return {count, ID, genre}});    return data;}

The last thing to do is to add an await before out getMovie function so that it handles the async database scan.

let response = await getMovie(event);

Testing

When we hit this new “GET” endpoint we receive an ordered list of all of the movies in the database.

[  {    "count": 2,    "ID": "Desperado (1995)-action",    "genre": "action"  },  {    "count": 1,    "ID": "Team America (2004)-action",    "genre": "action"  }]

Summary

We’ve now built an API that can handle “GET” and “PUT” requests, storing and retrieving data from a Dynamo database. You can also reuse a lot of the Dynamo class code for other APIs that work with Dynamo.

Want some practice?

If you’ve enjoyed this, then why not try to implement a similar setup for tv shows? If you do, then let me know how it goes!

You can also improve this API by making sure that Desperado (1995) and desperado (1995) both count towards the same movie, or only allow a certain format of movie title.

If you’ve liked this, then make sure to give it a clap and subscribe for more Amazon tutorials and guides. See you in the next article and Keep Coding!

I’m recognized as an Amazon Alexa Champion and have published more than twenty custom skills on the platform. I continue to look for new ways to stretch this technology, and one recent area I’ve been exploring is using Alexa to help organize everyday tasks. One of the underused features on the platform is the ability to create custom lists. Here is a brief review on how you can take advantage of this feature, and please feel free to test out the Workout Planner Skill — it’s free!

Alexa Workout Planner Skill

Background

Hands-free devices like an Alexa open up the possibilities of building handy digital assistants. One of the first features that was enabled with the native device was the ability to create shopping lists. Given the retail heritage of Amazon, it’s not surprising that this came early. Saying phrases like “add shampoo to my shopping list” adds it to the user’s Amazon account. It also renders the data on other applications that the user is signed in on.

Don’t Bring Alexa to the Gym, Bring a List

After using the shopping list feature for a while, I started to think of other types of lists that I could create. The device has the ability to create custom lists, and I thought it might be helpful in organizing my workouts. Rather than bring a handwritten workout list, I could make one using my voice.

I wrote a custom Alexa Skill called Workout Planner that asked questions about what types of exercises to do. It then created a list for me to track. Here’s a screenshot of what the skill creates on my phone.

Architecture to use the Alexa Lists

The core functionality around lists is enabled through an Alexa API that manages the entities that are rendered on the Alexa companion app.

In a typical Alexa skill architecture, the API gets invoked from the Lambda function that contains the functionality of the skill. Data passed into the API call indicates if a new list should be created, what item should be added, if an item can be crossed off the list, and so on. The companion app handles all of the user interaction with the data on the list, with no additional effort by the skill developer. The user then has the ability to manage this list through the companion app, including marking items off as complete.

The voice interface is the same as any Alexa skill. Authoring a custom skill includes setup of sample utterances, intents, and so on based on the functionality being provided to the user.

Enabling Permissions to use the Lists

When creating an advanced skill like this, the skill will need to request additional permissions. There are multiple levels of permissions and security, which all need to be in place for the skill to fully function.

First, the skill developer will need to acknowledge to the Alexa platform that the skill will make use of the lists. You can do this within the setup of the skill in the Developer console. The screenshot below is from the Permissions tab in the console. The sliders for both list attributes must be set.

Identifying additional permissions needed by this custom skill in the Alexa Developer console

As the skill goes through certification, Amazon validates that the permissions are required for the skill to work. This helps manage access to the user’s data that will be gained by the developer.

Second, when a user enables the skill on their device, they will need to grant consent for the skill to be able to read and write their data for their account. This is enabled through the companion app, and follows an “opt-in” model to access the escalated privileges. Below is a screenshot of the sliders that need to be adjusted in the settings.

Each user will need to grant permissions to access their list data.

Finally, at runtime, a consent token is created for each session that uses the skill. This token needs to be saved by the Lambda function, then passed in the header of the API call to Alexa.

Example API Call

As highlighted in the architecture, the household API contains the core functionality required to manage the lists. There are multiple operations available within the API, and here is the documentation from Amazon. Using Node.js, here is the code used to invoke the API using the POST operation that creates a new list called “Workout Tracker”.

var path = "/v2/householdlists/";     var postData = {        "name": "Workout Tracker", //item value, with a string description up to 256 characters         "state": "active" // item status (Enum: "active" only)    };            var consent_token = session.user.permissions.consentToken;

var options = {        host: api_url,        port: api_port,        path: path,        method: 'POST',        headers: {            'Authorization': 'Bearer ' + consent_token,            'Content-Type': 'application/json'        }    };

var req = https.request(options, (res) => {    console.log('statusCode:', res.statusCode);    console.log('headers:', res.headers);    var data = "";

    res.on('data', (d) => {         console.log("data received:" + d);         data += d;    });    res.on('error', (e) => {         console.log("error received");         console.error(e);    });    res.on('end', function() {         console.log("ending post request");        if (res.statusCode === 201) {             var responseMsg = eval('(' + data + ')');             console.log("new list id:" + responseMsg.listId);             callback(res.statusCode, responseMsg.listId);        } else {             callback(res.statusCode, 0);        }    });});    req.end(JSON.stringify(postData));

The API returns a JSON object that includes the ListIdentifier used in subsequent calls to add items to the list.

Conclusion

This is an easy way to leverage the voice user interface of Alexa with the ubiquity of the Alexa Companion App. Here is a link to the full repo of the skill, and if you have any ideas on how to improve — please let me know!

This article is a beginner’s high level look at Amazon ECS. We’ll cover core concepts, terms, simple architecture diagrams, and abstracted examples. So let’s get started!

Docker

To appreciate Amazon ECS, you first have to understand Docker.

Docker is a client-server application that can be installed on Linux, Windows, and MacOS and that allows you to run Docker containers. Containers are lightweight environments containing everything needed to run a specific application or part of an application. Multiple different containers can be run on one machine, so long as it has the Docker software installed.

If you’re interested in how they work, and how Docker is different from a virtual machine, then this intro to Docker is a great place to start.

_Adapted from Docker’s ‘[bins/libs](https://docs.docker.com/get-started/#container-diagram" rel="noopener" target="_blank" title="">get started’, see here for ‘<a href="https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard" rel="noopener" target="blank" title=")’

Using Docker containers allows teams to have a consistent development environment by abstracting away the software, operating system, and hardware configuration into a standard building block that can be run on any machine.

Each container has exactly what it needs — for example, certain versions of a language or library — and no more than it needs. Multiple containers can be used for different parts of your application if you want, and they can be set up to communicate with each other when needed.

By using specified Docker containers to run your production code, you can be sure that your development environment is exactly the same as your production environment.

As your application grows, managing the deployment, structure, scheduling, and scaling of these containers rapidly becomes very complicated. This is where a “container management service” comes in. It aims to allow simple configuration options and handles the heavy lifting while you go back to writing the app.

An intro to Amazon ECS

Amazon Elastic Container Service (ECS) is, according to Amazon,

…a highly scalable, fast, container management service that makes it easy to run, stop, and manage Docker containers on a cluster.

It is comparable to Kubernetes, Docker Swarm, and Azure Container Service.

ECS runs your containers on a cluster of Amazon EC2 (Elastic Compute Cloud) virtual machine instances pre-installed with Docker. It handles installing containers, scaling, monitoring, and managing these instances through both an API and the AWS Management Console. It allows you to simplify your view of EC2 instances to a pool of resources, such as CPU and memory. The specific instance a container runs on, and maintenance of all instances, is handled by the platform. You don’t have to think about it.

It’s worth noting that it is tied into the Amazon infrastructure, unlike some other providers that allow more flexibility. However, that means it comes with excellent integration with other AWS services.

Terms and architecture

Let’s give some imaginary context for the definitions we are about to look at. Say you are building an application that runs on two Docker containers, perhaps one for the main application, and one for managing metrics. Both are needed for the application to run as intended. If you had large amounts of traffic, you might need to run several pairs of containers.

Here we come to two sets of new terms:

• a Task Definition, Task, and Service, and
• a Cluster, ECS Container Instance, and ECS Container Agent.

Task Definition

This is the blueprint describing which Docker containers to run and represents your application. In our example, it would be two containers. would detail the images to use, the CPU and memory to allocate, environment variables, ports to expose, and how the containers interact.

Task

An instance of a Task Definition, running the containers detailed within it. Multiple Tasks can be created by one Task Definition, as demand requires.

One Task Definition creates several identical Tasks

Service

Defines the minimum and maximum Tasks from one Task Definition run at any given time, autoscaling, and load balancing. In our example, if the CPU was maxed out from the single task we had running, we may want it to add an additional Task.

We may, however, want to limit the maximum number of Tasks it can run, since we know that running extra Tasks uses additional resources that cost money.

Service definition defining alarms of when to scale capacity

Now that we have our Service, its Tasks need to be run somewhere in order to be accessible. It needs to be put on a Cluster, and the container management service will handle it running across one or more ECS Container Instance(s).

ECS Container Instances and ECS Container Agents

One ECS Container Instance running 8 Tasks from multiple different Services

This is an [EC2 instance](http://AWS EC2 for Beginners) that has Docker and an ECS Container Agent running on it. A Container Instance can run many Tasks, from the same or different Services.

The Agent takes care of the communication between ECS and the instance, providing the status of running containers and managing running new ones.

Cluster

An example ECS cluster, with one Service running four Tasks across two ECS Container Instances

As seen above, a Cluster is a group of ECS Container Instances. Amazon ECS handles the logic of scheduling, maintaining, and handling scaling requests to these instances. It also takes away the work of finding the optimal placement of each Task based on your CPU and memory needs.

A Cluster can run many Services. If you have multiple applications as part of your product, you may wish to put several of them on one Cluster. This makes more efficient use of the resources available and minimizes setup time.

Multiple Services allocated across multiple ECS Container Instances running on one Cluster

Conclusion

We have seen how a Dockerized application can be represented by a Task Definition that has a one-to-one relationship with a Service which in turn uses it to create many different Task instances.

This Service is deployed to a Cluster of ECS Container Instances that provide the pool of resources needed to run and scale your application. Additional Services can be deployed to the same Cluster.

Amazon ECS, or any container management service, aims to make this as simple as possible, abstracting away many complexities of running infrastructure at scale.

A Cluster running 3 Services, each running a different amount of Tasks, across two ECS Container Instances

As your needs become more complex, the container management service ensures this remains manageable. Using its API or Management Console, you can put definitions in place to add new Container Instances as you need them. This makes sure that there are always a healthy number of Tasks running, and intelligently allocates resources across Services.

Thanks for reading!

Resources

• Gentle Introduction to How AWS ECS Works with Example Tutorial
• Deploying Clustered Akka Applications on Amazon ECS
• Building Blocks of Amazon ECS
• Introduction to Amazon EC2 Container Service (ECS) — Docker Management on AWS
• Amazon ECS: Core Concepts
• AWS EC2 for Beginners
• A Better Dev/Test Experience: Docker and AWS
• Cluster-Based Architectures Using Docker and Amazon EC2 Container Service

I purchased my first mobile phone in the summer of 1999. I was 17 years old, growing up in a nondescript town in the Midlands of the United Kingdom. The population was less than 50,000.

For those of you wondering, it was a Sagem RC 922. It boasted enough memory for a whopping 100-contacts address book. It also had an external antenna. This phone would go on to be crushed by the juggernaut of Nokia.

My phone had no GPS. No colour screen. No WAP. No headphone jack.

It offered text messages, voice calls, and a calculator.

However, it came with a nice plastic card which promised £10 credit — if you scratched off the silver foil and input the numbers into the phone.

It cost me just shy of £100. I had saved this up by working part-time in a factory during evenings while I studied at college.

Beyond the nostalgia

My cousin Thomas, a few years older than me; and my father were with me when I purchased the phone. We sat down in a coffee shop and unwrapped my new purchase. I powered it on and started inputting the code for the free credit.

“What is that?” they asked.

“My new mobile phone,” I replied.

My Dad simply looked baffled. “But… why have you bought a mobile phone?”

I shrugged.

Then, quick as a flash, my cousin Thomas said: “I want one. Where did you get it?”

He marched off to the local store and came back two minutes later, triumphantly clutching his prize. My Dad, a blue-collar truck driver, was bewildered. Why had his son and nephew invested so much in something new?

What this means for Virtual Assistants

6 months ago my wife purchased me a gift. It was an Amazon Echo Dot. As someone who works all day in tech, she considered it a winner as a birthday gift.

However, it remained boxed for nearly six months. Two weeks ago she became exasperated, and set it up in the kitchen. It was a novelty at first.

• “Alexa, why is Siri better?” [snark]
• “Alexa, do you have a boyfriend?” [British taboo humour]

Eventually, it was used for the same purpose every Echo Dot is used for:

• “Alexa, set a reminder for 10 minutes when the oven fries are done”

Yesterday, I came downstairs and saw my four year-old son sitting in the kitchen. He often uses a stool to help himself to bowls of cereal from the cupboard.

This morning, he had served himself a bowl of chocolately goodness and milk, and was listening to a song on the radio. Or so I thought. The song was Way Out by Beau Black. You might otherwise know it as the Miles from Tomorrow theme tune.

“I’ m a hero to the core. And I’ m going to explore. Way out!”

I grabbed a bowl of cereal and sat next to him.

“How did you turn the radio on?”

He munched thoughtfully.

“I didn’t. It plays me songs.”

I looked over. Sure enough, the Echo dot was the source of the Disney pop extravaganza.

“It plays me songs”

Of course it plays songs. It is right there on the marketing literature. I knew it connects to dozens of services. It was supposed to work seamlessly.

However, as an adult I found it frustrating. Possibly because I was trying to frustrate it. For example:

“Alexa, turn on Spotify and play the Coding and Crushing It playlist and select Time by Hans Zimmer.”

Hah! Look. It can’t. First gen product. Pfft.

But to my son — who only started school 4 weeks ago — Alexa was his friend. Alexa played his songs. He continued to talk about Alexa glowingly over breakfast. I realised he had anthropomorphized it. Alexa was the equivalent of a pet. It was part of the home.

And no one had shown him how to use it. He just shouted commands.

Still eating, he said: “Alexa, please you play PJ Masks now!”

Sure enough, Alexa popped the PJ Masks theme tune onto Spotify. He was, in consumer terms, completely satisfied.

All of this complemented the behaviours I’d previously seen in my daughters, Darcey (7) and Holly (5).

Neither of them type search queries into Google. They default to voice-search for almost everything. Such as recently:

“Google, when is Descendants 2 released?”

Children don’t display the preconceptions that adults have when interacting with Virtual Digital Assistants or A.I. bots.

They rarely get mad or blame the technology. It is just there. They have adopted voice-control in the same casual manner that I adopted mobile phone technology in the 1999.

That is, they have no real sense of requirement. I never got mad that my phone was lacking features. I was just super-satisfied to be communicating. My use case for a phone was limited to calling and texting. My children have a similar limited use case for Alexa.

It is the norm. In their life, technology exists to serve content they request. That content may be a joke, or a song, a movie, a change in lighting, or the answer to a question.

Alexa and Google Assistant offer frictionless access to the content they want. They respond to an immediate thought — far quicker than typing.

As an adult, I am still conscious of saying “OK Google” in public to trigger the Assistant.

I own a pair of Bose QC-35 wireless headphones with the Google Assistant button, but I am loathe to use it. It does not feel normal in public. I feel like I am showing off.

However, my daughters have no problem shouting “OK Google, show me the nearest toy shop” into their phones anywhere they might be.

Why do my children get better responses from Alexa?

While adults may often attempt to trick the algorithm, children already speak in simple sentence structures. These lend themselves well to the user input required for an A.I.

It is frictionless because they are pure in their intentions and simple in their requests. The barrier to satisfaction is far lower for a child using voice activation. Their expectation of Alexa is zero — other than the exception that it is always available. Children are the best demographic for proving the voice-controlled home.

The true test of home automation is not: “Will the temperature go up 10 minutes before I get home?” That’s not too difficult to program using a combination of a smartphone, compatible hubs and IFTTT.

The true test is “Can a child dim their Hue lightbulbs to reflect bed time? Can a child request a Winnie the Pooh book-on-tape via a smart speaker?”

I believe we have passed that point in 2017. Children are the future consumers of this technology. For this reason, I believe the market valuations are pessimistic.

The target demographic for the widespread adoption of voice-control is not the Millennial generation. Instead, it is those born between 2010–2020. They are the ones growing up in a voice-controlled home, and will expect this technology as a standard.

Voice A.I. will be ubiquitous in the next two decades. I have no doubt.

What does the future hold?

I am all-in on Amazon winning this race. This is because vendor lock-in is crucial. If the barrier to switching is high, then once you have bought a home speaker or Hub, you are extremely unlikely to switch platforms.

At the beginning of 2016, there were just over 130 Alexa apps, or “skills”. By year-end, that number had grown to over 5,000. Today, there are over 7,000. Application growth was over 500% during the second half of 2016.

For anyone trailing Google, Apple and Amazon, the future looks bleak in terms of native adoption.

The best chance for rival voice assistant providers may be to provide a display/voice interface layer on top of a shared processing layer. However, the strength of an A.I. service lies in superior data processing ability. This means it is unlikely that such a collaborative development will happen.

Instead, we will see a fragmented marketplace emerge. It will be a market where you are forced into using default A.I. providers depending on the hardware purchase. This will lead to consumer friction and third party solutions to “remove” incumbent solutions.

Personally, I feel that Amazon benefit from being a commerce company while Google still suffers a ‘Big Brother’ reputation.

That branding hurdle is one that Google required Amazon to break down. If Google were first to market, I am certain voice-controlled home automation would have died on launch. Amazon were the route-provers, or the minesweepers.

Mobile reversal

Curiously, this branding issue is reversed on mobile devices. Google Assistant is crushing Android competitors such as Alexa and Bixby. According to Ovum Marketing Research:

Google Assistant will dominate the voice artificial intelligence (AI)-capable device market with 23.3% market share, followed by Samsung’s Bixby (at 14.5%), Apple’s Siri (13.1%), Amazon’s Alexa (3.9%) and Microsoft’s Cortana (2.3%)

TechCrunch recently reported on a VoiceLabs report:

“‘Therefore, while not a winner-take-all market, in 2017 VoiceLabs predicts it will be a winner-take-entire-household market,’ the report states. ‘This puts pressure on the hardware providers to distribute devices quickly.’”

Amazon is undoubtedly supported by its vast experience in selling consumer electronics. This gives it an edge in distribution channels.

Meanwhile, it has also made it easy for developers to build Alexa voice applications for its Echo family of devices. It has invested in tools for application development.

However, my last thought is that Amazon has made significant progress in capturing younger content consumers into the Amazon ecosystem. This is through the use of the Kindle Fire Kids, which seems ripe for an Alexa-inspired revolution.

“Alexa, help me understand long multiplication.”

“Opening Khan Academy, long multiplication, video playing in 3, 2, 1…”

As you may know, the last 11 months have been very difficult for me. As a self-taught web developer of 15 years, my computer science study plan took me months to get through, and the main motivator was to start a new career as a software engineer, tackling large problems at a large tech company.

Google was the company I had audaciously set my sights on, but in the end that turned into disappointment. If you haven’t read about my story, you’re missing out. Go ahead and read it first.

Well, I reached out to my network, and made a lot of new friends. I got connected with every tech giant in the Pacific northwest. Of all of them, Amazon had always stood out — even more than Google — as the most innovative company over the last 10 years. I applied via a referral, whom I had met at a startup event in 2013, and got the process rolling.

After so many months of non-stop effort, sacrifice, and worry, I’m pleased to announce that I finally made it!

Today I accepted an offer to be a Software Development Engineer at Amazon.com.

Working at Amazon is a dream come true, and I’ll be working on the Amazon Web Services Config team. I’ve wanted to work on AWS for years, but was never qualified, until now. I’ve been using AWS since 2012, when I got started using CloudFormation to automate infrastructure build-out and scaling.

AWS Config is a fully managed service that provides operations teams with AWS resource inventory, configuration history, and configuration change notifications to enable security and governance. Config Rules enables administrators to create rules that automatically check the configuration of AWS resources recorded by AWS Config, as well as define actions AWS can take to fix issues automatically.

Here’s a video with some cool automation tricks you can do with AWS Config Rules, CloudTrail, and Lambda:

Thanks to everyone for your support!

Where to Find Me

Since I won’t be posting on this “Googley” account any more, feel free to follow my adventures at Startup Next Door, LinkedIn, and Twitter.