2 years ago (2018-08-23)  Technology |   First to comment  21 
post score 0 times, average 0.0

This article is translated from: Freecodecamp, original address: An intro to Amazon fargate:what It was, why it's awesome (and not), and when to use it, English original author for Em Manuel Marboeuf

When Amazon announced Fargate with Eks at the end of 2017 at the AWS Re:invent Conference, it was left out of the doghouse, when the blogs and the big guys I was focusing on were just mildly saying:

Oh, there's a new gadget that will allow ECS users to run containers directly in the cloud.

As a developer, it really surprised me.Let's see why.

Liberating productivity

I think there have been five major revolutions in the field of software development, greatly improving the productivity of developers and writing and deploying applications at the highest efficiency.They all solved a series of major problems:

  • The advent of cloud services (IaaS): Addressing the cost and scalability issues of infrastructure
  • Open source community, conferences, workshops, technical blogs, stackoverflow, etc.: let knowledge reach more people
  • Version control systems, collaboration tools, and continuous integration tools solve concurrent project development and integration issues
  • containerized architecture
  • Server and system management costs are reduced by server-less computing services (PaaS)

All of these revolutions have a common feature: they give software engineers more control, reduce reliance on server systems administrators, devops,it support staff, and so on. So, what kind of fargate?

Your "boat" is the problem.

Container as a service: AWS fargate
Life Jacket is advised

Docker's popularity of container technology quickly became a new standard widely used in development. Soon after, with the success of Kubernetes, AWS launched its own (more basic) Container Management Service: Amazon Elastic Container Service (ECS), which introduces the concept of task. A task can be any instance of a container that works together.It can be from a web app running a service, multiple microservices, a database and a reverse proxy, or it can be a batch shell script that runs periodically. As an "old driver" using ECS, I liked it and used it very well for a while, but in the end, I found that in managing EC2 instance, I had to manage some extra layers (tasks and containers), which made ECS more and more complex.(Please refer to the AWS "layer" concept) at the same time, I am not very satisfied with the security of ECS, the more layers, the more vigilance, and each layer brings more complexity, as well as the possibility of misconfiguration, vulnerability. When you use ECS to configure elastic scaling on an EC2 instance (Instance) running in a cluster, you can host multiple different tasks on each instance, and each task can run multiple containers. Because tasks are randomly deployed on the same type of EC2 instance with available resources (by default), you face the following issues:

  • A cluster must follow the same elastic scaling rules, and the EC2 instance type of the scaling must be the same.
  • Some containers require a completely different resource (the translator notes that AWS calls the network, virtual machines, and load balancer all as resources), but still needs to work together.
  • Some containers do not necessarily follow the same elastic scaling rules.
  • Sometimes multiple containers in the same task need to have their own load balancing and cannot set up multiple load balancers for the same task.

In the face of these problems, the preferred solution is:

  • Manually deploy some EC2 instances with different resources as required
  • Add these EC2 instances to your cluster
  • Run a container for a task
  • Manually linking to your EC2 instance
  • Configure complex task policies on ECS, and configure the EC2 on the appropriate set of tasks according to their needs

This requires a lot of tedious work and is not easy to maintain, which violates the original intention of using the container. Someone had to come up with a better idea.

Let them "drift".

It turns out that the AWS team has had the same problem in the past year, and they've considered and worked to address these issues:

How can we run containers without worrying about servers and clusters?

That's what AWS Fargate means.It completely abstracts the underlying infrastructure, and you can think of each container as a single machine. You only need to define the resources required for each container, and it will do complex tasks for you without having to manage the access rules between multiple layers, you can dispatch containers just as you would in a single EC2 instance.

Container as a service: AWS fargate
Containers on the Fargate

This allows your container to be like a ship on the surface of the water with its own sails, rudders, and crew, and can drift where it wants to go.

Container as a service (CaaS)

I've always believed that container-as-a-service (CaaS) is the real platform and Service (PaaS) that developers dream of.It allows developers to deploy their containers directly in the cloud without worrying about the underlying details. Of course, there are many technologies that allow you to run your code seamlessly on the cloud without worrying about scaling or server management (such as HEROKU,LAMBDA, or even using the Google App engine in your own way), but they all have limitations.

  • Must choose to lose a little flexibility
  • Must use the languages that they support
  • Projects cannot be completed using the languages that they support because it is possible that your project needs a lower version of the native library available on the specified OS system
  • Your project uses cutting-edge technology that will not be available to the public in the coming years
  • Some of these platforms are very, very expensive, especially when expanding

Fargate (or CaaS) offers you the solution for both worlds. The containerized architecture gives you the flexibility and control you need, allowing you to use any technology in any type of system.and container technology ensures that your app has the same behavior on every host, whether it's dev, test (TESTING/QA), pre-release (Staging), or production (Production) environments. I think this is crucial for many tech startups.In fact, sometimes one of your competitive advantages is that you are involved in the development of state-of-the-art technology, or the use of smart, original technology in new scenarios. A server-less deployment allows you to focus on writing good code, no configuration, and easy extensibility.


CaaS vs PaaS

You may indeed have given up some of the benefits of a real platform-as-a-service, such as you still need to manually update the container's image, and sometimes you have to write your own Docker image.If you don't understand the fundamentals of system administration, this is really a hassle. However, it also means that you can do whatever you want to do, and on the system you want to use, ensure flexibility and freedom in languages, tools, libraries, and versions.


Let's face it: cloud Services (IaaS) are more expensive than owning your own infrastructure (if you want to scale your infrastructure as needed).In the same vein, there is no need to worry about configuring, managing, and scaling servers at a cost.If your application is simple, the cloud service is not the optimal solution. Fargate is good, but its price is almost 4 times times the price of the EC2 instance (e.g. T2.medium), which makes it very difficult for us to choose, let's hope it can be reduced.

Container as a service: AWS fargate
Fargate and EC2 price comparison (USD)

Should I switch all ECS tasks to Fargate?

Of course not.As mentioned above, in some cases your costs will increase by more than three times times, so you might want to use standard EC2 instances before they reduce costs. However, fargate may be more beneficial to you in the following situations:

  • If you are unable to scale your ECS tasks well, it can result in a lot of idle CPU or memory, and with Fargate you only pay for the resources defined in the task.
  • For tasks that run on-demand or on a scheduled schedule, you do not need a EC2 instance that is running continuously.With Fargate, you only pay when the task runs.
  • For tasks that have memory and/or CPU usage spikes.This is only because using Fargate can save you time in configuring and managing in such cases.


For those who like kubernetes rather than ECS, Fargate will soon support Eks.


This article has been in the copyright printing record, protected by copyright law, without permission shall not be reproduced!If you think this article is useful for you, you can click on the "sponsor author" below to hit the author!

Reprint Annotated Original source:Baiyuan's Blog> >https://wangbaiyuan.cn/en/an-intro-to-amazon-fargate-when-and-why-use-it-2.html

Post comment


No Comment


Forget password?