Introduction to Serverless

Cloud technology right now is in a state of constant transformation to create scalable, reliable, and robust environments. In order to create such an environment, every improvement in cloud technology aims to increase both the end user experience and the developer experience. End users demand fast and robust applications that are reachable from everywhere in the world. At the same time, developers demand a better development environment to design, deploy, and maintain their applications in. In the last decade, the journey of cloud technology has started with cloud computing, where servers are provisioned in cloud data centers and applications are deployed on the servers. The transition to cloud data centers decreased costs and removed the need for responsibility for data centers. However, as billions of people are accessing the internet and demanding more services, scalability has become a necessity. In order to scale applications, developers have created smaller microservices that can scale independently of each other. Microservices are packaged into containers as building blocks of software architectures to better both the developer and end user experience. Microservices enhance the developer experience by providing better maintainability while offering high scalability to end users. However, the flexibility and scalability of microservices cannot keep up with the enormous user demand. Today, for instance, millions of banking transactions take place daily, and millions of business-to-business requests are made to backend systems.

Finally, serverless started gaining attention for creating future-proof and ad hoc-scalable applications. Serverless designs focus on creating even smaller services than microservices and they are designed to last much longer into the future. These nanoservices, or functions, help developers to create more flexible and easier-to-maintain applications. On the other hand, serverless designs are ad hoc-scalable, which means if you adopt a serverless design, your services are naturally scaled up or down with the user requests. These characteristics of serverless have made it the latest big trend in the industry, and it is now shaping the cloud technology landscape. In this section, an introduction to serverless technology will be presented, looking at serverless's evolution, origin, and use cases.

Before diving deeper into serverless design, let's understand the evolution of cloud technology. In bygone days, the expected process of deploying applications started with the procurement and deployment of hardware, namely servers. Following that, operating systems were installed on the servers, and then application packages were deployed. Finally, the actual code in application packages was executed to implement business requirements. These four steps are shown in Figure 1.1:

Figure 1.1: Traditional software development

Organizations started to outsource their data center operations to cloud providers to improve the scalability and utilization of servers. For instance, if you were developing an online shopping application, you first needed to buy some servers, wait for their installation, and operate them daily and deal with their potential problems, caused by electricity, networking, and misconfiguration. It was difficult to predict the usage level of servers and not feasible to make huge investments in servers to run applications. Therefore, both start-ups and large enterprises started to outsource data center operations to cloud providers. This cleared away the problems related to the first step of hardware deployment, as shown in Figure 1.2:

Figure 1.2: Software development with cloud computing

With the start of virtualization in cloud computing, operating systems became virtualized so that multiple virtual machines (VMs) could run on the same bare-metal machine. This transition removed the second step, and service providers provision VMs as shown in Fig 1.3. With multiple VMs running on the same hardware, the costs of running servers decreases and the flexibility of operations increases. In other words, the low-level concerns of software developers are cleared since both the hardware and the operating system are now someone else's problem:

Figure 1.3: Software development with virtualization

VMs enable the running of multiple instances on the same hardware. However, using VMs requires installing a complete operating system for every application. Even for a basic frontend application, you need to install an operating system, which results in an overhead of operating system management, leading to limited scalability. Application developers and the high-level usage of modern applications requires faster and simpler solutions with better isolation than creating and managing VMs. Containerization technology solves this issue by running multiple instances of "containerized" applications on the same operating system. With this level of abstraction, problems related to operating systems are also removed, and containers are delivered as application packages, as illustrated in Figure 1.4. Containerization technology enables a microservices architecture where software is designed as small and scalable services that interact with each other.

This architectural approach makes it possible to run modern applications such as collaborative spreadsheets in Google Drive, live streams of sports events on YouTube, video conferences on Skype, and many more:

Figure 1.4: Software development with containerization

The next architectural phenomena, serverless, removes the burden of managing containers and focuses on running the actual code itself. The essential characteristic of serverless architecture is ad hoc scalability. Applications in serverless architecture are ad hoc-scalable, which means they are scaled up or down automatically when they are needed. They could also be scaled down to zero, which means no hardware, network, or operation costs. With serverless applications, all low-level concerns are outsourced and managed, and the focus is on the last step – Run the code – as shown in Figure 1.5. With the serverless design, the focus is on the last step of traditional software development. In the following section, we will focus on the origin and manifesto of serverless for a more in-depth introduction:

Figure 1.5: Software development with serverless

Serverless Origin and Manifesto

Serverless is a confusing term since there are various definitions used in conferences, books, and blogs. Although it theoretically means not having any servers, it practically means leaving the responsibility of servers to third-party organizations. In other words, it means not getting rid of servers but server operations. When you run serverless, someone else handles the procurement, shipping, and installation of your server operations. This decreases your costs because you do not need to operate servers or even data centers; furthermore, it lets you focus on the application logic, which implements your core business function.

The first uses of serverless were seen in articles related to continuous integration around 2010. When it was first discussed, serverless was considered for building and packaging applications on the servers of cloud providers. The dramatic increase in popularity came with the Amazon Web Services (AWS) Lambda launch in 2014. Furthermore, in 2015, AWS presented API Gateway for the management and triggering of Lambda functions as it's a single entry point for multiple functions. Therefore, serverless functions gained traction in 2014 and it became possible to create serverless architecture applications by using AWS API Gateway in 2015.

However, the most definitive and complete explanation of serverless was presented in 2016, at the AWS developer conference, as the Serverless Compute Manifesto. It consists of eight strict rules that define the core ideas behind serverless architecture:

Note

Although it was discussed in various talks at the AWS Summit 2016 conference, the Serverless Compute Manifesto has no official website or documentation. A complete list of what the manifesto details can be seen in a presentation by Dr. Tim Wagner: https://www.slideshare.net/AmazonWebServices/getting-started-with-aws-lambda-and-the-serverless-cloud.

• Functions as the building blocks: In serverless architecture, the building blocks of development, deployment, and scaling should be the functions. Each function should be deployed and scaled in isolation, independently of other functions.
• No servers, VMs, or containers: The service provider should operate all computation abstractions for serverless functions, including servers, VMs, and containers. Users of serverless architecture should not need any further information about the underlying infrastructure.
• No storage: Serverless applications should be designed as ephemeral workloads that have a fresh environment for every request. If they need to persist some data, they should use a remote service such as a Database as a Service (DbaaS).
• Implicitly fault-tolerant functions: Both the serverless infrastructure and the deployed applications should be fault-tolerant in order to create a robust, scalable, and reliable application environment.
• Scalability with the request: The underlying infrastructure, including the computation and network resources, should enable a high level of scalability. In other words, it is not an option for a serverless environment to fail to scale up when requests are rising.
• No cost for idle time: Serverless providers should only incur costs when serverless workloads are running. If your function has not received an HTTP request for a long period, you should not pay any money for the idleness.
• Bring Your Own Code (BYOC): Serverless architectures should enable the running of any code developed and packaged by end users. If you are a Node.Js should appear together or Go developer, it should be possible for you to deploy your function within your preferred language to the serverless infrastructure.
• Instrumentation: Logs of the functions and the metrics collected over the function calls should be available to the developers. This makes it possible to debug and solve problems related to functions. Since they are already running on remote servers, instrumentation should not create any further burden in terms of analyzing potential problems.

The original manifesto introduced some best practices and limitations; however, as cloud technology evolves, the world of serverless applications evolves. This evolution will make some rules from the manifesto obsolete and will add new rules. In the following section, use cases of serverless applications are discussed to explain how serverless is adopted in the industry.

Serverless Use Cases

Serverless applications and designs seem to be avant-garde technologies; however, they are highly adopted in the industry for reliable, robust, and scalable applications. Any traditional application that is running on VMs, Docker containers, or Kubernetes can be designed to run serverless if you want the benefits of serverless designs. Some of the well-known use cases of serverless architectures are listed here:

• Data processing: Interpreting, analyzing, cleansing, and formatting data are essential steps in big data applications. With the scalability of serverless architectures, you can quickly filter millions of photos and count the number of people in them, for instance, without buying any pricey servers. According to a case report (https://azure.microsoft.com/en-in/blog/a-fast-serverless-big-data-pipeline-powered-by-a-single-azure-function/), it is possible to create a serverless application to detect fraudulent transitions from multiple sources with Azure Functions. To handle 8 million data processing requests, serverless platforms would be the appropriate choice, with their ad hoc scalability.
• Webhooks: Webhooks are HTTP API calls to third-party services to deliver real-time data. Instead of having servers up and running for webhook backends, serverless infrastructures can be utilized with lower costs and less maintenance.
• Check-out and payment: It is possible to create shopping systems as serverless applications where each core functionality is designed as an isolated component. For instance, you can integrate the Stripe API as a remote payment service and use the Shopify service for cart management in your serverless backend.
• Real-time chat applications: Real-time chat applications integrated into Facebook Messenger, Telegram, or Slack, for instance, are very popular for handling customer operations, distributing news, tracking sports results, or just for entertainment. It is possible to create ephemeral serverless functions to respond to messages or take actions based on message content. The main advantage of serverless for real-time chat is that it can scale when many people are using it. It could also scale to zero and cost no money when there is no one using the chat application.

These use cases illustrate that serverless architectures can be used to design any modern application. It is also possible to move some parts of monolithic applications and convert them into serverless functions. If your current online shop is a single Java web application packaged as a JAR file, you can separate its business functions and convert them into serverless components. The dissolution of giant monoliths into small serverless functions helps to solve multiple problems at once. First of all, scalability will never be an issue for the serverless components of your application. For instance, if you cannot handle a high amount of payments during holidays, a serverless platform will automatically scale up the payment functions with the usage levels. Secondly, you do not need to limit yourself to the programming language of the monolith; you can develop your functions in any programming language. For instance, if your database clients are better implemented with Node.js, you can code the database operations of your online shop in Node.js.

Finally, you can reuse the logic implemented in your monolith since now it is a shared serverless service. For instance, if you separate the payment operations of your online shop and create serverless payment functions, you can reuse these payment functions in your next project. All these benefits make it appealing for start-ups as well as large enterprises to adopt serverless architectures. In the following section, serverless architectures will be discussed in more depth, looking specifically at some implementations.

Possible answers:

• Applications with high latency
• When observability and metrics are critical for business
• When vendor lock-in and ecosystem dependencies are an issue