Serverless computing – also sometimes referred to as utility computing – is a topic of growing interest in the field of cloud based solutions.
Key understandings
- Microservices architecture style – This is a software development approach that aims to build a single whole application as a suite of small services – each small service runs in its own process and communicates with other lightweight mechanisms. Each service is built around business capabilities and is independently deployable by automated deployment tools. Centralised management of such services can be maintained at a bare minimum, and services may be written in different programming languages, and may use different data storage technologies.
- Serverless and scalable – Serverless computing exploits the advantages offered by cloud providers such as AWS, Google or Microsoft to run solutions offsite, upon cloud computing infrastructure. Because serverless architectures are – by nature of technology – executed upon cloud infrastructures, serverless solutions also provide the benefits of instant scalability to solution owners. This means serverless microservices are able to scale process volumes up or down immediately in relation to demand of services.
- AWS Fargate – Fargate is a web service offered by internet giant – Amazon Web Services. Fargate allows solution owners and developers to run microservices styled as ‘containerised solutions’ without the added burden of having to manage solutions infrastructure. In other words, Fargate allows solution developers to focus on designing and building applications and not have to interact with or even think about servers or clusters.
The need for ‘Serverless’
To run containers – Virtual Machines are necessary – they act as the underlying layer of infrastructure. Having to manage a hosting technology or a Virtual Machine brings with it the burdens of maintenance costs and resolving of issues that could arise when run in the long term. Examples of problematic issues are version upgrading, patch applications, regular backing up of data and log clean ups to mention a few.
Instead, if we were to use a hollow placeholder – such as a runtime environment – that is capable of running a specific container function when the same is injected into the environment, and additionally, the lifetime of the placeholder exists only for the duration of the said function’s execution – we would not have to provision virtual machines or bother about managing them. To customise a runtime environment according to our needs, requires a config specification attached to the placeholder. This way we are only charged for that specification and the runtime of the placeholder. This benefits us by eliminating the hassle – and recurring charges of – running virtual machines contentiously.
AWS Fargate – Task Definition (to specify configurations)
AWS Fargate provides for specifying the technical configurations of placeholders. This feature is known as ‘task definition’ and is used to allocate the necessary CPUs and memory to run containers. CPUs in this case are – in reality – Virtual CPUs (vCPU).
The below image displays a task definition screen that specifies 0.5Gb of memory and 0.25 of vCPU.
(Image 1 – AWS Fargate ‘Task Definition’ to specify vCPUs and Memory
AWS Fargate – Container definitions (to specify functionality)
‘Container definitions’ are used to specify the task or function that a container is required to accomplish in AWS Fargate (see image 2 below). The previously mentioned ‘Task definition’ will create the environment in which a defined container will execute. The container definition also specifies the docker image that starts up as the function.
Currently AWS Fargate supports Docker containers only (even though Docker is not the only container implementation technology out there). For the purpose of a docker image – to run the container – we can specify a path in the Docker Hub repository or we could use an image hosted on AWS ECR (Elastic Container Registry).
(Image 2 – ‘Container Definition’ is used to specify Docker image)
Later, you may need to manually upload your preferred custom docker image to ECR prior to commencing usage. For example: an Apache Tomcat based docker container that is serving a web application that you ran once before.
AWS Fargate – Pricing
Pricing is based on the requested amount of vCPUs and memory resources for the defined task, and is billed per second. Price per vCPU is $0.00001406 per second ($0.0506 per hour) and per GB memory is $0.00000353 per second ($0.0127 per hour).
For an example if you run a single vCPU and 1GB sized container for 1 hour, your cost would only be $0.0506 + $0.0127 = $0.0633
*pricing is as at April, 2018 and is subject to change at the discretion of the respective service providers.
Below is the structural illustration of the different configuration definitions or layers that are used to build a AWS Fargate service
(Image 3 -Layers within a Fargate based service implementation)
A service definition instructs how may simultaneous docker instances are needed to run and how to load-balance incoming traffic. For example: a web service that needs to be served with multiple instances to handle the ingress load.
The below example screenshot shows only one task being assigned to the service.
(Image 4 -A Fargate Service definition that asks for how many task definitions to run)
A cluster is nothing but a logical grouping of a related set of services and hence a set of tasks. This can be done based on your requirements to grouping services.
Benefits of serverless container services
- Eliminates the need for EC2 management – Serverless microservice containers relieve system administrators of the headaches of managing an EC2 host. Infrastructure and system administrators won’t have to spend time and effort dealing with management activities such as restarting or stopping servers, upgrading resources manually, applying security patches and conducting health checks on the operating system.
- Focus on application – Serverless microservices containers allow solutions developers to focus on application building. Infrastructure management and heavy lifting is handled automatically by AWS Fargate.
- Flexible and affordable pricing model – Server Microservices containers accommodate a simple and low cost pricing model. Solutions developers need to worry only about three factors: CPU size, Memory size and the number of seconds of run-time.
- Scalable combinations of utilities – Serverless microservices containers can be adjusted to provide just the right amount of vCPU and memory for your application. Powerful scalability features allow to scale from allocating the smallest amount of computing resources to high power capabilities.
- Seamless auto scaling – Unlike manually adding ECS instances to handle spike loads, serverless microservices containers are designed to seamlessly auto-scale to match demand
- Ease of use – Central management capabilities via AWS web console or CLI deliver a much simpler user experience for solutions developers.
AWS Elastic Kubernetes Services
- Amazon Elastic Container Service for Kubernetes or Elastic Kubernetes Service (EKS) is a fully certified Kubernetes implementation in AWS cloud – and is also a fully managed service.EKS is currently (as at April, 2018) in preview mode for users (you have to register separately to get access to evaluate EKS which is subject to AWS approval based on your use cases). EKSis expected to be available with support for Kubernetes v1.10. This service will be released as a Fargate version in which you will not need to manage Kubernetes nodes and will be similar to the ECS version of Fargate with different vCPU and Memory configurations to choose from depending on the size of the workload for each Kubernetes pod.Benefits of implementing a serverless Kubernetes service:
- Replaces the use of hosts (VMs) with Kubernetes nodes and thus, management of hosts is not required
- the complexities of managing Kubernetes clusters are managed by AWS cloud for you
- highly available provisioned master nodes clusters handle the background work. This means there is no need to manage kubernetes masters
- serverless Kubernetes services are built upon vanilla Kubernetes and not on an AWS version of Kubernetes. therefore application working on standard plain Kubernetes is compatible with EKS
- significant cost reduction due to minimal infrastructure management requirements.
Summary
Serverless technologies are increasingly gaining the attention of solutions developers because of the immense conveniences it offers in managing applications along with cost savings. Maintenance costs too are at a minimal because developers do not have to engage in dealing with virtual hosts and serverless charging models adhere to resource usage parameters.
AWS offers two docker container based clustered environment capabilities known as ECS and EKS. ECS is Amazon’s proprietary implementation of cluster management and orchestration framework. EKS on the other hand is a Kubernetes based implementation.
Both ECS and EKS offer serverless versions (EKS is said to be made available sometime during the year 2018) where the underlying infrastructure is fully managed by AWS. All that the solution developer is required to do is prepare a relevant docker image that contains specific functionalities to deploy on AWS Fargate.
The best part is that both of these services seamlessly integrate with other AWS tools to allow you to make use of other robust AWS technologies such as IAM, S3, RDS, Cloudwatch and numerous other tools.
AWS Fargate is considered a forerunner technology and is still evolving as a product in the AWS cloud suite. Since we last checked, AWS Fargate is only available for ECS platforms and limited geographically to the Northern Virginia territory, and will soon be made available to other regions as well. We think it is beneficial for solution developers to be aware of such easy-to-work-with technologies as AWS Fargate is, and we expect to see a rise in solution developers migrating future workloads to serverless platforms – of which I think AWS Fargate is currently the most prominent and powerful of them all.
Thank you for reading this Tech Guide. We hope you will also read our next tutorial so that we can help you solve some more interesting problems. Also, don’t forget to subscribe to our newsletter to stay updated with the latest in technology.
