What are containers?
Containers not only offer the possibility to overcome some limitations of traditional virtualization but lay the foundations for a radical change in the way of understanding the development and life cycle of services. The idea behind containers was not born in the Linux world but has its roots in a technology known as FreeBSD jail, which appeared in 2000, which allows partitioning of a FreeBSD system into subsystems (jail) isolated both from each other and from each other to the underlying system by extending the concept of chroot. This was brought into the Linux world with the Linux Vserver project and was integrated in the following years with new technologies, including cgroup, systemd, and Linux Kernel Namespace, thus outlining the Linux Container (LXC) project. In 2008, with the arrival of Docker, new tools and new ideas were added, such as the possibility of creating layered images (that is, resulting from the merger of multiple images) and the introduction of the image registry. Container projects in the Linux world have therefore received a new boost that led to the birth of the Open Container Initiative, whose members, including Docker and Red Hat, collaborate to define open and shared standards for container technologies. With these premises and these tools available, it is natural to question ourselves to understand if there are alternatives to traditional virtualization. Beyond the more strictly technical aspects, a Linux container is the set of one or more processes isolated from the rest of the system, which:
Have a standard management interface (for starting, stopping, environment variables) Optimize the use of resources with respect to virtual machines Simplify the management of larger applications (spread over multiple containers)
The presence of the standards proposed by standardization bodies also guarantees interoperability and the possibility of orchestrating containers even between different clouds. The concept of images and the way of constructing and aggregating them constitutes the most significant and innovative aspect, not so much from a technological point of view, as for the impact it has on development and operational management, with consequences that also affect the way of understanding business. The images are immutable, this means that each container executed from the same image is identical to the others, it does not contain any status information or persistent data. Persistence is entrusted to other tools such as external databases and filesystems. This determines, first of all, a clear distinction between the runtime environment of the application and the data on which it operates, introducing functional separation logics that bring benefits in terms of cleaning, process management, and safety. The real innovation in the development process and in the life cycle of the application lies in the fact that once a complete and consistent operating environment has been created on one or more images, separate from the data on which it operates, it will be able to go through all the phases from development to production without undergoing changes.
What is Serverless?
Containers, although they allow for improved resource allocation compared to virtual machines, do not really allow you to scale to zero and grow linearly: when a container does not deliver services, it still remains active as a process. An answer to this need can come from serverless approaches. Truly efficient resource allocation requires that all compute power be actually instantiated only on demand and released immediately after use. Serverless computing is one of the ways to distribute services in a cloud context that involves the execution of applications or, more correctly, functions, without requiring any visibility of the underlying infrastructure: provisioning, scaling and management take place automatically and linearly only in the face of real requests and needs. The term serverless is therefore not to be understood as the “absence” of servers but as transparency of the systems involved from the point of view of developers and users. This feature means that the DevOps paradigm, typical in the use of containerized technologies, is abandoned to return to a new, clearer distinction between the infrastructure and the application component, introducing two new concepts in the cloud world:
FaaS (Function as a Service) allows developers to have an execution environment for their applications (be they C #, Java, Node.js, Python, etc.) which is instantiated only in response to certain events. BaaS (Backend as a Service) allows delegating to third parties the typical functions of the applications without having to implement them in person (for example the case of services such as Auth0 which offers identity management and authentication functions).
There are many Serverless frameworks available in the market.
The main difference between serverless and containers
Containers are very important for the impetus that Serverless architecture has been taking overtime, mainly for incorporating concepts and the culture of no longer using the old virtual machines and classic servers. Everything can be hosted locally or in the cloud, without complications or complexity. The big difference between a Serverless architecture using FaaS and Containers is the lack of concern with the processes that run at the operating system level. Even with services like Docker offering similar abstraction capabilities to Containers technology, especially when used in conjunction with Kubernetes, Serverless architecture and FaaS allow an even greater degree of this type of abstraction in application development. In a Serverless architecture that uses FaaS, the scalability of the application is managed automatically and transparently, and it also has the capacity of a high granularity of the service for its best performance. Platforms that use containers need this provisioning to be managed manually, even with automated tools. In the end, the style of the application and the available infrastructure will determine which of the two forms of deployment will be the best used. Serverless architecture has a high level of operating system processing abstraction while containers are evolving and developing ways of automating scalability and availability.
How to choose between serverless and containers?
In this overview we have tried to highlight how radical the transformation that has been shaking the world of IT services in recent years, redefining infrastructures, development models, and even business models. However, what may seem an evolutionary process in which new technologies are destined to replace the previous ones, is actually a much less linear path: there are and probably will still exist for a long time scenarios in which each of the three technologies will be the only one applicable, others in which they will have to integrate and each one will find its own space. Not all workloads are portable in containers: in some cases, it would be necessary to redesign and rewrite the application. It is not certain that this is always possible, so there are still situations in which virtual machines allow for system control or flexibility that makes them indispensable.
Containers and Serverless Use Cases
Containers find their ideal use in complex applications, which require a high level of control of the operating environment, possibly with long processing times and which at the same time lend themselves to implementation in a containerized environment. Even if the use of resources is less efficient than a serverless approach, the performances are on average better as at least the first container is always active and does not have to be instantiated from scratch. Design, development, and management can be simpler since the presence of shared frameworks and standards allows orchestration between clouds of different vendors with much simpler scaling out than virtual servers. Conversely, in containers modifications to individual functions require the creation and deployment of a new image, with the expansion of release times and the possibility of error. The growth in the number of instances in response to the increase in load leads to difficulties in monitoring and possible performance problems as the growth capacity is always limited by the speed of the components that guarantee data persistence. A typical example of use can be a large e-commerce site consisting of numerous parts such as the price list, warehouse management, and payments, each of which can be packaged in a container for which execution time and memory limits do not constitute a problem. The serverless approach can be ideal in a microservices context and in scenarios, such as the IoT, where certain functions need to be invoked only when specific events occur and not be part of an always-on service. Being a strictly pay-per-use model, it allows cost optimization, especially in cases where it is difficult to proceed with a priori sizing or predict the load that will have to be faced. The design difficulty and the absence of standards, which in many cases determines the problem of vendor lock-in, still constitute a strong limitation of the field of use.
Final Words
In summary, no technology is better than the other in an absolute sense: each responds to specific needs. They can coexist and be integrated, as needed, in a single project. The best approach therefore is not to decide a prior path for the development of your applications, but to start with a careful analysis of the characteristics and requirements in order to choose the most suitable architecture.
