IntroductionBefore by the cloud providers like AWS. One way

IntroductionBefore we start creating Serverless applications to run in AWS, Microsoft Azure and Google Cloud Platfrom, let’s learn about What is Serverless Computing, learn how it is being used, learn about what is Function as a Service (FaaS) and the benefits that Serverless Computing provides. Readers will also learn about What’s not Serverless Computing.Learning outcomesIn this chapter we will learn the following topics:What is Serverless Computing?Use cases of Serverless ComputingUnpacking what is `Function as a Service` (FaaS)What’s not Serverless Computing?Benefits of Serverless ComputingBest practices to get maximum benefits out of Serverless ComputingWhat is Serverless Computing?Serverless applications still require servers to run, hence it’s a misnomer. Serverless computing merely adds another layer of abstraction atop cloud infrastructure, so developers no longer need to worry about servers, including virtual ones in the cloud. Serverless computing allows you to build and run applications and services without thinking about servers. Serverless applications don’t require you to provision, scale, and manage any servers, they are automatically provisioned for you to run and scale your application with high availability is handled for you.In most cases, when people think of Serverless computing, they are likely to think of applications with backends that run on cloud providers like AWS that are fully managed, are event triggered and are ephemeral that last only for that invocation that run within a stateless container. While Serverless applications are fully managed and hosted by the cloud providers like AWS, it is a misinterpretation the applications are completely running Serverless, servers are still involved in the execution of these Serverless applications, it is just that these are managed by the cloud providers like AWS. One way to think about these Serverless applications is as FaaS – Functions as a Service. The most popular implementation of FaaS at the moment is AWS Lambda, however there are other FaaS implementations from Microsoft Azure and Google Cloud Platform. Serverless computing is all about the modern developer’s evolving frame of reference:What we’ve seen is that the atomic unit of scale has been changing from the virtual machine to the container, and if you take this one step further, we’re starting to see something called a function – a single-purpose block of code. It’s something you can conceptualize very easily: Process an image, Transform a piece of data, Encode a piece of video.Fig 1-1. Monolithic vs Microservice vs FaaSBuilding serverless applications means that your developers can focus on their core product instead of worrying about managing and operating servers or runtimes, either in the cloud or on-premises. This reduced overhead lets developers reclaim time and energy that can be spent on developing great products which scale and that are reliable.The Serverless movement is not entirely about trying to do compute without servers, which would be a neat trick indeed, but in creating such a high level of abstraction for compute, at such a fine granularity, that customers don’t have to care what the underlying server is. It just is not their problem anymore.Serverless and Event-Driven collisionEvent-driven computation is an architecture pattern that emphasizes action in response to or based on the receptions of events. This pattern promotes loosely coupled services and ensures that a function executes only when it is triggered. It also encourages developers to think about the types of events and responses a function needs in order to handle these events before programming the functions. Fig 1-2. Event Driven Architecture exampleWith event-driven computing, people are being taken out of the workflow because, to put it bluntly, they are too slow. For the longest time, transaction processing meant humans talking to humans, who keyed in the transactions that ran the business using homegrown or third party applications coded in high level languages. Eventually some of the people at the backend – those who were the literal transaction processors – were replaced by Web front ends, and customers talked directly to systems. Various message queueing middleware was used to link disparate and often incompatible systems to each other so they could trade data and do more sophisticated data sharing and transaction processing. In datacenter operations itself, system administrators combed through alerts and other data to keep things humming along. All of this still takes too much coding and too much human intervention, and a new generation of applications that react to vast amounts of telemetry, often with in-memory processing techniques shaped by statistical analysis and machine learning algorithms, is emerging. And Serverless computing is meeting event-driven computing on what amounts to a single platform, where algorithms are the only thing coders write and the data store and compute is handled by the backend supplier, such as Amazon Web Services, Microsoft Azure, or Google Cloud Platform.”It really is an evolution in development and platforms from on-premises to infrastructure as a services to platform as a service to serverless platforms”. There are three things that I think define a Serverless platform. The first is certainly the abstraction of servers, and not having to manage the underlying server instance, but we also think it has to include micro-billing, which is pay for use down to the exact second of usage and the exact amount of CPU and memory capacity used. Many of these applications will run for very short periods of time. And the third thing is that a Serverless platform is event driven, when it is an IoT device or a user click on a mobile app or initiating a business process from some customer request.”By the way, no one is suggesting that serverless applications will replace everything out there in the tens of millions of corporations, governments, and other organizations in the world.I think Serverless will be a part of an overall application strategy and I don’t believe that Serverless will replace every part of an application, but I think that almost every application – modern or otherwise – is going to see integration points where Serverless components dramatically simplify the application and improve the customer experience. Certainly IoT is an obvious place where Serverless makes a lot of sense, but even simple things like bots built into help desk websites to engage with customers are a great place to start with Serverless. I think Serverless will integrate into almost all applications in some form or another.Serverless has another interesting effect, and it is both good for the public cloud providers and their private cloud emulators as well as for the customers. With traditional bare metal servers, CPU utilization was probably on average somewhere between 5 and 10 percent across all data centers in the world, which is pitiful but it is good business if you can sell on the resource spikes, as so many server makers and their parts suppliers did for so long. Server virtualization came along and maybe average utilization was driven up to maybe 15 percent to 20 percent – a big improvement that saved lots of money once customers shed big bucks on shiny new virtualization-assisted servers and hypervisors. These days, maybe the best of breed is doing 20 percent to 30 percent utilization, and maybe the big public clouds are doing on the order of 40 percent because they don’t just interleave workloads across a company, but across many companies. With microservices, provided there are enough of them and provided their utilization doesn’t come as one big spike, there is a change to get the server virtualization hypervisor overhead out of the equation on the underlying platform, perhaps by moving to Docker or some other container, and really bin packing the event-driven code. Let’s say average utilization can be driven to 65 to 75 percent.In this event-driven architecture, the functions are event consumers because they are expected to come alive when an event occurs and are responsible for processing it. Some examples of events that trigger Serverless functions include these:API RequestsScheduled eventsEvents in object storageEvents in databasesNotification EventsWhat is ‘Function as a Service’ (FaaS)I’ve mentioned about FaaS few times already, let’s dig into what it really means.  Serverless computing in which code runs as a service on an infrastructure that is fully managed by the cloud provider which is automatically provisioned based on an event and is automatically scaled to ensure high availability. You think this as “Functions as a Service” (FaaS) in which run on stateless, ephemeral containers created and maintained by the cloud provider. You might have already come across terms like Software as a Service (SaaS), Infrastructure as a Service (IaaS) and Platform as a Service (PaaS). Let’s look at what they mean; SaaS is a form of cloud computing is in which software is licensed based on a subscription, hosted centrally and is delivered remotely by the provider over the internet. Examples of SaaS are Google Apps, Citrix GoToMeeting and Concur. IaaS is a form of cloud computing where provision and management of compute infrastructure resources occur over the internet which scale up quickly and you pay for what you use. Examples of IaaS are Azure Virtual Machines and AWS EC2. PaaS is a form of cloud computing where software and infrastructure that is needed for application development are provided over the internet by the provider. Examples of PaaS are AWS Beanstalk and Azure App Services. Let’s also look at the description for AWS Lambda product to learn more about Function as a service.AWS Lambda lets you run code without provisioning or managing servers. You pay only for the compute time you consume – there is no charge when your code is not running.With Lambda, you can run code for virtually any type of application or backend service – all with zero administration. Just upload your code and Lambda takes care of everything required to run and scale your code with high availability. You can set up your code to automatically trigger from other AWS services or call it directly from any web or mobile app.Essentially FaaS is running code without having to provision, manage servers on your own and is executed based on an event rather than running all the time. With traditional architectures which involves Containers or Physical/Virtual Servers you would need the servers be running all the time. As the infrastructure is used only based on the need, you achieve 100% server utilization and cost savings are also huge as you pay only for the compute time you consume when the Function/Lambda runs.With FaaS solutions you can run any type of application, which means there isn’t restriction on what languages you need to write the code in and restriction on a particular frameworks to be use.  For example. AWS Lambda functions can be written in Javascript, Python, Go, C# programming languages and any JVM language (Java, Clojure, Scala, etc.). The deployment architecture for your code is also different than traditional systems as there is no server to update yourself rather you just upload your latest code to the cloud provider – AWS and they take care of making sure the new version of the code is used for subsequent executions.AWS handles scaling of your function automatically based on the requests in needs to process without any further configuration from us. If your function needs to be executed 10000 times in parallel, AWS handles scaling up the infrastructure that is required to run your function 10000 times in parallel. The containers that are executing your code are stateless, ephemeral with AWS provisioning and destroying them only for the duration that is driven by the runtime need.In AWS, Functions are triggered by different event types like S3 (file) updates, time (scheduled tasks) and messages sent to Kinesis Stream, messages sent to SNS topics and many more event type triggers. AWS also allows functions to be triggered as a response to http requests through Amazon API gateway.StateFunctions as they run in ephemeral containers have significant restrictions when it comes to management of state. You need to design your functions in such a way that the subsequent run of your function will not be able to access state from a previous run. In short you would develop your Functions with point of view that they are stateless.This does affect how you would design the architecture for your application. Considering that Functions are stateless, you would use external resources to manage the state of your application so that state can be shared between runs of the Functions. Some of the popular external resources that are widely using in FaaS architecture are Amazon s3 which provides a simple web services interface that you can use to store and retrieve any amount of data, at any time, from anywhere on the web, caching solutions like Memcached or Redis and database solutions like Amazon DynamoDB which is a fast and flexible NoSQL database service for any scale.Execution DurationFunctions are limited in how long each invocation is allowed to run. Each cloud provider has different time limit at the moment for their FaaS offering after which the function execution will be terminated. Let’s look at the different timeouts provided by each cloud provider for functions:AWS (Lambda): 5 minutesAzure Functions: 10 minutesGoogle Functions: 9 minutesAs the execution of the Functions are limited by the time limit set by the providers, certain architectures with long running processes are not suited for FaaS architecture. If you still want to fit those long running processes into a FaaS architecture then you would need to design the architecture in which several Functions are co-ordinated to accomplish a long running task where as in a traditional architecture everything would have been handled within the same application.Understanding Cold Start What is Cold Start? Cold start = time it takes to boot a compute systemWhat is Cold Start in FaaS? When you execute an inactive (cold) function for the first time a cold start occurs. The cold start time is when the cloud provider provisions the required runtime containers, downloads your code for the Functions and then runs your functions. This increases the execution time of the function considerably as it may take more time to provision certain runtimes before your Function gets executed. The converse of this is when your Function is hot (active), which means that the container with your code required to execute the Function stays alive, ready and awaiting for execution. If your Function is running it is considered active and if there is certain period of inactivity then the cloud provider will drop the runtime container with your code in it to keep the operating costs low and at that point your Function is considered cold again.The time it takes for Cold Start varies between different runtimes. If your Function utilizes runtimes like Node.js or Python, then the cold start time isn’t significantly huge, it may add  < 100 ms overhead to your Function execution.If your Function utilizes runtimes like JVM, then you will see cold start times greater than few seconds while the JVM runtime container is being spun up. The cold start latency has significant impacts in the following scenarios:Your Functions are not invoked frequently and are invoked once every 15 minutes, this will add noticeable overhead to your Function execution.Sudden spikes in your Function execution; for example your Function may be typically executed once per second, but it suddenly ramps up to 50 executions per second. In this case as well you will see noticeable overhead to your Function execution.Understanding and knowing this performance bottleneck is essential when you are architecting your FaaS application so that you can take this into account to understand how your Functions operate.Some analysis has been done to understand the container initialization times for AWS Lambda:Containers are not reused after 15 minutes of inactivityLambda within a private VPC increases container initialization timePeople overcome this by pinging there Lambda once every 5 or 10 minutes to keep the runtime container for your Function alive and also preventing it from going into a cold state. Is Cold Start an issue of concern? Whether your Function will have a problem like this or not is something that you need to test with production like load and understand the overhead that cold start adds to your FaaS application.