The Best of Both Worlds With AWS Fargate
If you haven't heard much about AWS Lambda's younger counterpart, take a look at what Fargate brings to the table.
Join the DZone community and get the full member experience.
Join For FreeWith the dawn of microservices and resource provisioning on the cloud, the world of software has been torn apart between two choices: containers or serverless. However, the choice may no longer have to be this binary as AWS introduced a shade of grey in late 2017 with AWS Fargate. Serverless orchestration of containers allowing you to run them directly in the cloud.
Unfortunately, since its release, AWS Fargate was pushed into the shadows as the community for the large part ignored it. The trend is changing, though, as the pitfalls of both serverless and containers are motivating developers and solution architects to explore the alternatives. Hence, it is imperative that we know how AWS Fargate works in comparison to containers and conventional serverless services to understand its benefits. That is the purpose of this article, to explain the scope of container services that Fargate brings, along with how much of a serverless benefit the service actually brings.
Drowning Containers and Floating Ships
In 2014, following the success of Kubernetes, AWS launched its own container management service called ECS, allowing you to manage the orchestration of your EC2 instances. Since then we have seen an increase in the interest of EC2 containers. So what was the big deal with ECS and EC2?
Firstly, ECS is simply a container orchestration service. It allows you to visualize EC2 containers in the form of tasks, where a single task is one or more EC2 instances that already have Docker installed in them. Each EC2 instance with Docker then communicates with the AWS backend. Several EC2 instances forming a cluster will run within the ECS’s auto-scaling groups with scaling rules that you define. That means the ECS Container Agent is continuously polling the ECS API to check which containers need to be stopped or run according to the task requirements. All this seems quite alluring, but the problem is that you still have to manage each EC2 instance, and this is where the difficulties begin.
EC2 orchestration, just like any other container orchestration is a daunting task, giving AWS Lambda the upper hand in this aspect. Even though ECS makes it easier to manage tasks, you still have to perform management on the container level. You would still have to manage scaling, monitoring, securing, networking and other operational issues of the EC2 instances. The management at the container level does not only make using containers an operational burden, but also vulnerable security wise and unreliable performance wise.
For example, even though you may have specified fitting rules for the ECS auto-scaling groups, automatically increasing or decreasing the tasks as per the needs, the EC2 instances themselves may not have enough memory or CPU provisioned to them. Additionally, there is no clear metric to scale EC2 clusters and also no proper solution regarding the scaling when task allotment fails due to lack of EC2 cluster resources. Another problem also is scaling down EC2 clusters without killing any tasks.
These operational burdens are not only seen with AWS EC2 but across all container services out there. With all this work, when would you have the actual time to concentrate on your business logic? This is where AWS introduced Fargate, bringing you to salvation by abstracting all these container orchestration responsibilities.
AWS Fargate presents Containers-as-a-Services (CaaS) as compared to Infrastructure-as-a-Service (IaaS) that EC2 is. That means the container has already been set up, including the networking, security, and most importantly, the scaling. These major operational burdens are abstracted away providing you with the ability to run containers directly on the cloud. With the service, you simply have to specify the resources for each container instance and let Fargate work it’s magic under the hood.
At the end of the day, each Fargate instance comes with its dedicated ENI to allow communication between inter-task clusters, whereas clusters of the same task are communicated via localhost. Moreover, the management of these tasks is again done by ECS. In fact, Fargate is defined as a compute engine of ECS, providing a different way of managing tasks, and this is the defining characteristic of Fargate linking it to container services. However, this is only one side of Fargate; there is an entire serverless side, too.
Tryst With Serverless
So AWS Fargate lets you run containers directly in the cloud, but how? Well, this is where the serverless part of the service comes into play. AWS Fargate can be considered a subset of AWS’s serverless compute services. That means instead of going to the other extreme end of the spectrum when it comes to which service you choose, you can now avail yourself the advantages of serverless without having to leave the flexibility of containers.
Terming Fargate as a serverless compute service also breaks one of the greatest misconceptions of the idea. Many believe that serverless is associated with Functions-as-a-Service (FaaS). The misconstrued association is due to the success of AWS Lambda, and hence, AWS Lambda functions becoming synonymous to the concept.
A service can be defined as serverless if it posses the following three features:
- Server management is abstracted to vendor
- Pay-as-you-go model where you only pay for what you use
- Automatically scalable and highly available
Considering these properties, AWS Fargate is truly serverless. This is because as already stated, with CaaS all underlying architecture till the container level is abstracted to the vendor. Furthermore, similar to AWS Lambda, Fargate also follows a pay-as-you-go model. The difference is that with the Lambda service, billing is calculated per invocation whereas, with Fargate you are charged according to the vCPU and memory you consume per second. Finally, the distinct and most crucial characteristic that Fargate posses, justifying its serverless tag, is the auto-scalability feature. Similar to AWS Lambda, Fargate is also scalable and highly available, and this is expected since both services have AWS Firecracker running under the hood.
Officially released at AWS re:Invent 2018, Firecracker is a greatly powerful virtualization tool that uses a Kernel-based Virtualization Machine (KVM). Designed to be secure and extremely lightweight, the technology has allowed AWS to enhance the serverless experience for both its Lambda and Fargate services. According to AWS Chief Evangelist Jeff Bar, Firecracker is "what a virtual machine would look like if it was designed for today's world of containers and functions."
Hence, with the support of Firecracker, AWS has brought CaaS into the fold of serverless computing services. The myth of serverless only meaning FaaS is now rightly being challenged, ushering in a new era of solutions in the domain. However, this was long overdue as the limitations of AWS Lambda has been acting as a deterrent for many to move their architectures towards serverless. This is where Fargate has some benefits over Lambda services.
The 15-minute runtime limitations, cold-starts, and upload memory restrictions all greatly restricts the use of the magnificent AWS Lambda function. AWS Fargate, on the other hand, lets you escape from these restrictions while still enjoying the benefits that serverless brings. One of them being most importantly that you now no longer have to worry about the scaling of your container. It is this flexibility in serverless services that vendors such as AWS had failed to provide, and Fargate is slowly being realized as the solution to the imposed limitations of conventional serverless services. Developers can now gain back the much-needed flexibility while still running serverless and staying away from the much-dreaded container orchestration.
Obviously, it’s not always sunny with Fargate, and the grass does look greener on the other side. By not abstracting all the underlying layers as far as FaaS does, Fargate does come with its fair share of complexity as compared to Lambda functions. For example, you still have to worry about scaling the number of containers in your load balancer. Additionally monitoring tools that Lambda users benefit from, such as Thundra.io, are not as available or comprehensive in regards to Fargate. Hence endangering users to fall into the "black-box" trap that serverless lays out, making it difficult to debug and test your code. At the end of the day, what matters is what you’re trying to attain. This is because, even though you retain flexibility and freedom from limitation with Fargate, you lose out on essential benefits of AWS Lambda, leaving you with only the core benefits of serverless in general.
Therefore, with the release of Fargate using a Firecracker base to ensure a serverless experience, AWS has eased container orchestration considerably. AWS Fargate truly does bring the best of both worlds of container service flexibility and operational ease. Nevertheless, that does not mean the community should run towards Fargate immediately. The higher costs compared to EC2 and the greater complexity compared to AWS Lambda functions calls for introspection of your business model and objectives. Only when considering the use case specific to your unique needs, can you make a well-informed decision regarding where on the spectrum you would like to sit. However, irrespective of the benefits and shortcomings, it’s safe to say that AWS Fargate is definitely a game changer in how future solutions will be implemented in the cloud. After all, it has only been a few years since we discarded our on-premise servers to the fate of coffee tables and coat hangers. Who knows what’s next in store for cloud-based development?
Published at DZone with permission of Sarjeel Yusuf. See the original article here.
Opinions expressed by DZone contributors are their own.
Trending
-
How To Create a Question-Answering Model From Scratch
-
Surviving SVB's Collapse and Outsmarting Uber with Kyte's Head of Product and Engineering, Nick Cobb
-
Agile Negotiations
-
Kubernetes Deployment Using Azure DevOps
Comments