Chief Strategist at Platform9 (www.platform9.com)
Serverless Computing has emerged in the past year as a compelling architectural alternative for building and running modern applications and services. Serverless applications allow developers to focus on their code, instead of on the infrastructure configuration and management. This speeds up development and release cycles, as well as allows for better, more efficient, scaling.
Serverless computing is closely tied to new architecture patterns and technologies such as Microservices and Containers. Greenfield, cloud-native applications are often microservices-based, which makes them ideal for running on containers (Docker). The further decoupling — and abstraction — that Serverless functions allow between the application and the infrastructure make them an ideal pattern for developing modern microservices that can run across different environments.
As Serverless applications become more used (with Lambda being the most popular cloud service offered by AWS), we increasingly see enterprises who want to enable a Serverless experience for their engineers on on-premises infrastructure as well-meaning Serverless are getting into hybrid cloud environments next!
While Serverless offers a lot of benefits, implementing it successfully, alongside containers, comes with quite a few challenges — particularly for IT Ops. While Serverless speeds up development, it needs a Kubernetes cluster in order to run, and Kubernetes is notoriously difficult to deploy and manage. Furthermore, these new technologies increase the complexity, scale, and sprawl of the IT environment, tooling, and applications that today’s enterprises need to support. Add the new Serverless to the mixed environments that already exist — of Cloud resources, traditional VMs and even bare metal — and things get even more complicated for IT.
In this series, I will cover some best practices and patterns to enable both developers and Ops teams to take advantage of Serverless computing in a way that supports their overall IT operations — and takes them to the next level!
I will discuss:
First, some definitions.
The most critical characteristic of a Cloud Native (CN) architecture is the ability to dynamically scale to support massive numbers of users, and large, distributed development and operations teams. This requirement is even more critical when we consider that cloud computing is inherently multi-tenant in nature.
Within this area, the typical requirements we need to address are:
Most enterprise (legacy) applications are Monolithic in nature, with tight coupling and interdependencies between application components, infrastructure, development teams, technologies, tooling, etc. This tight coupling poses challenges to the speed and agility of development, the adoption of new technologies or DevOps practices, as well as to the ease of scaling and operating these applications.
Microservices are a natural evolution of the Service Oriented Architecture (SOA) paradigm. In this approach, the application is decomposed into loosely coupled business functions, each mapped to one or more microservices. Each microservice is built for a specific, granular business function and can be worked on by an independent developer or team. By being a separate code artifact it is loosely coupled not just from a tooling or communication standpoint (typically communication using a RESTful API with data being passed around using a JSON/XML representation) but also from a build, deployment, upgrade and maintenance process perspective. Each microservice can optionally have its localized datastore. An important advantage of adopting this approach is that each microservice can be created using a separate technology stack from the other parts of the application.
Containers are an efficient, most optimal, way to run microservices, with Container orchestration solutions, such as the open source Kubernetes, required to handle the runtime operations of Container clusters. Microservices and containers are now an integral component of any digital transformation strategy, as they allow for easier build, independent development and deployment and better scaling.
Serverless Computing is a new paradigm in software development where the application developer is focused on coding the application functions and is freed from having to invest time and effort in configuring and managing the resources required to deploy and run these applications.
In this paradigm, the cloud or infrastructure provider needs to do all the required plumbing for the application to be instantiated once a request has been received for it. The developer focuses on the code of the application, and it is the responsibility of the underlying data center provider to manage all associated resources required to run it, reliably.
Functions as a Service (FaaS) is the most common type of serverless computing where the application is developed as a pure software function aimed at a granular use case (an extremely fine-grained microservice, if you will.) Multiple functions can then be composed together and optionally used in conjunction with a microservices application to perform business functionality. For the rest of this article series, I will use both terms — Serverless and FaaS — interchangeably.
Serverless and FaaS allow for fine-grained billing. Since FaaS gets idle functions to consume much lower CPU/memory, cluster resource usage becomes more proportional to real usage than deployment size. When the functions are idle, the server resources are not instantiated, and so cost is reduced. Keep in mind, however, that billing advantages depend, quite sensitively, on actual usage patterns. A function that runs for one second every 10 seconds is cheaper on Lambda, but if it runs for 2 seconds every 10 sec it’s cheaper on EC2. You have to model your usage accurately and evaluate whether Serverless will actually save you money.
Serverless Architectures, or Functions as a Service (FaaS), conform to the following broad principles:
Serverless computing solves the biggest challenge that developers face (even with a PaaS or a container orchestration platform such as Kubernetes) — the need to own, scale & manage infrastructure. The containers running these Serverless workloads are neither provisioned nor monitored or otherwise managed by the developer. They get to build applications that just run, without having to worry about servers.
Serverless frameworks are different from PaaS technology in four different ways:
Serverless frameworks run best on Kubernetes compared to running on PaaS. Most PaaS technologies have earned a reputation for being too rigid across several areas — developer workflow, architecture and pricing — that make them a bad fit to run serverless workloads. In the words of Brendan Burns, “the first generation of Platforms as a Service (PaaS) was squarely aimed at enabling developers to adopt “serverless” architectures. The trouble was, that as is the case in many first wave products, too many overlapping concepts were mixed into a single monolithic product. In the case of most first-generation PaaS, developer experience, serverless and pricing model (request-based) were all mixed together in an inseparable monolith. Thus, a user who might have wanted to adopt serverless, but perhaps not the developer experience (e.g. a specific programming language) or who wanted a more cost-efficient pricing model for large applications, was forced to give up serverless computing also.”
In the next post in this series, we’ll discuss some of the challenges and key considerations for choosing the right Serverless solution.