Living in a post-container world

Serverless has gained a lot of attention recently, possibly even more than containers. If you want to build a modern and future-proof architecture based on microservices, then serverless works just as well as containers as a solid building block. However, the question then arises of which technology to use, containers or serverless?

Building serverless applications

There are many different definitions for serverless. The best and most accurate definition is the “Serverless Compute Manifesto”, which consists of eight core tenets and was presented at AWS re:Invent 2016:

• Functions are the unit of deployment and scaling.
• No machines, VMs, or containers are visible in the programming model.
• Permanent storage lives elsewhere.
• Scales per request: users cannot over- or under-provision capacity.
• Users never pay for idle time: no cold servers/containers or their costs.
• Implicitly fault-tolerant because functions can run anywhere.
• BYOC – Bring Your Own Code.
• Metrics and logging are a universal right.

With serverless applications, you only pay for consumed resources, making it possible to focus on the business logic. If we want to compare serverless and containers, we should focus on the computing part of serverless application: functions. Typically functions let you run code without provisioning or managing servers. Your code is only executed when it is needed and the service is scaled automatically.

All the parts of a serverless application

AWS Lambda is a serverless compute service and figure1 shows the essential components of a serverless compute application. All functions need an event source; this could be changes in data state, requests to endpoints, or even changes in resource state. Functions can be implemented in different languages to process the events. An event source is the service or custom application that publishes events. Typically, functions run on high-availability computing infrastructure. The administration of the computing resources is entirely handled by the service, including server and operating system maintenance, capacity provisioning, and automatic scaling, monitoring, and logging. All you need to do is supply your code in one of the supported languages.

However, this support comes at the cost of flexibility. You can’t log in to compute instances or customize the operating system or language runtime. These constraints enable the underlying service of the function to perform operational and administrative activities on your behalf. AWS Lambda automatically takes care of things like provisioning capacity, monitoring fleet health, applying security patches, deploying your code, and monitoring and logging your functions.

Container workloads

Containers are basically a method of virtualization that allows you to run your applications in resource-isolated processes. In many cases, containers allow you to easily package an application’s code, configurations, and dependencies in an easy to use building block. This means you can use the same Docker images in all environments and implement the “immutable infrastructure” pattern. Containers give you a great amount of flexibility and control. With containers, you can typically choose the underlying operating system, but you are responsible for common administration tasks like patching. Unfortunately, containers add an additional layer of complexity, especially if you start building complex applications with a lot of inter-service communication. Additionally, containers still need a fair amount of administrative work like applying security fixes for the Docker images.

SEE ALSO: Containers: Big opportunity or big distraction?

AWS currently offers two different services for container orchestration: Amazon Elastic Container Service (Amazon ECS) and Amazon Elastic Container Service for Kubernetes (Amazon EKS). Amazon ECS eliminates the need for you to install and operate your own container orchestration software, manage and scale a cluster of virtual machines, or schedule containers on those virtual machines.  Amazon ECS supports AWS Fargate, so you can deploy and manage containers without having to provision or manage servers.

Amazon EKS runs the Kubernetes management infrastructure for you across multiple AWS availability zones to eliminate a single point of failure. You simply provision worker nodes and connect them to the provided Amazon EKS endpoint.

Combining containers and AWS Lambda

Let’s take a view from 10,000 feet: containers and functions are basic compute building blocks to implement business logic. Why not combine both? Serverless and containers can be used side by side to solve business problems. One typical approach is to start with serverless and move to containers if necessary.

How would a combined container and serverless architecture look? For example, let’s think of an application that collects data running in a Docker container. After validating the input data with information located in a cache, this application generates and emits messages with a streaming service. Functions consume those messages and write it into data storage. The application running in a Docker container has strict requirements in regards to response time. It uses an in-memory cache that is much easier to implement with a container-based approach.

Of course, it would be also possible to consume those messages using a Java application running on a server. The advantage of the combined container-serverless approach is having more control over the offset management. Major disadvantages include things like additional implementation complexity and management of the underlying computer infrastructure.

This small example demonstrates that choosing the right compute building block is not an either/or question. It is more important to fit your specific use case. With containers, you have the ability (and also the responsibility) to maintain your own infrastructure. However, this flexibility comes with a price. You need the right people in your organization that are capable to build and maintain a highly available cluster for your container workloads.

Conclusion

So, which approach is better, containers or AWS Lambda? The answer depends on your specific use-case and requirements! Probably the best approach is to start with a serverless approach and – if necessary – switch to containers.

The post Living in a post-container world appeared first on JAXenter.