Cloud-based applications can be built on low-level infrastructure pieces or can use higher-level services that provide abstraction from the management, architecting, and scaling requirements of core infrastructure. In the following section, you will learn about the different cloud-computing models.

Cloud providers offer their services according to four main models: IaaS, PaaS, CaaS, and FaaS. All the aforementioned models are just thousands of servers, disks, routers, and cables under the hood. They just add layers of abstraction on top to make management easier and increase the development velocity.

Infrastructure as a Service (IaaS), sometimes abbreviated to IaaS, is the basic cloud-consumption model. It exposes an API built on top of a virtualized platform to access compute, storage, and network resources. It allows customers to scale out their application infinitely (no capacity planning).

In this model, the cloud provider abstracts the hardware and physical servers, and the cloud user is responsible for managing and maintaining the guest operating systems and applications on top of it.

AWS is the leader according to Gartner's Infrastructure as a Service Magic Quadrant. Irrespective of whether you're looking for content delivery, compute power, storage, or other service functionality, AWS is the most advantageous of the various available options when it comes to the IaaS cloud-computing model. It dominates the public cloud market, while Microsoft Azure is gradually catching up with to Amazon, followed by Google Cloud Platform and IBM Cloud.

Platform as a Service (PaaS) provides developers with a framework in which they can develop applications. It simplifies, speeds up, and lowers the costs associated with the process of developing, testing, and deploying applications while hiding all implementation details, such as server management, load balancers, and database configurations.

PaaS is built on top of IaaS and thus hides the underlying infrastructure and operating systems, to allow developers to focus on delivering business values and reduce operational overhead.

Among the first to launch PaaS was Heroku, in 2007; later, Google App Engine and AWS Elastic Beanstalk joined the fray.

Container as a Service (CaaS) became popular with the release of Docker in 2013. It made it easy to build and deploy containerized applications on on-premise data centers or over the cloud.

Containers changed the unit of scale for DevOps and site reliability engineers. Instead of one dedicated VM per application, multiple containers can run on a single virtual machine, which allows better server utilization and reduces costs. Also, it brings developer and operation teams closer together by eliminating the "worked on my machine" joke. This transition to containers has allowed multiple companies to modernize their legacy applications and move them to cloud.

To achieve fault-tolerance, high-availability, and scalability, an orchestrations tool, such as Docker Swarm, Kubernetes, or Apache Mesos, was needed to manage containers in a cluster of nodes. As a result, CaaS was introduced to build, ship, and run containers quickly and efficiently. It also handles heavy tasks, such as cluster management, scaling, blue/green deployment, canary updates, and rollbacks.

The most popular CaaS platform in the market today is AWS as 57% of the Kubernetes workload is running on Amazon Elastic Container Service (ECS), Elastic Kubernetes Service (EKS), and AWS Fargate, followed by Docker Cloud, CloudFoundry, and Google Container Engine.

This model, CaaS, enables you to split your virtual machines further to achieve higher utilization and orchestrate containers across a cluster of machines, but the cloud user still needs to manage the life cycle of containers; as a solution to this, Function as a Service (FaaS) was introduced.

The FaaS model allows developers to run code (called functions) without provisioning or maintaining a complex infrastructure. Cloud Providers deploy customer code to fully-managed, ephemeral, time-boxed containers that are live only during the invocation of the functions. Therefore, business can grow without customers having to worry about scaling or maintaining a complex infrastructure; this is called going serverless.

Amazon kicked off the serverless revolution with AWS Lambda in 2014, followed by Microsoft Azure Functions and Google Cloud Functions.

Serverless computing, or FaaS, is the fourth way to consume cloud computing. In this model, the responsibility for provisioning, maintaining, and patching servers is shifted from the customer to cloud providers. Developers can now focus on building new features and innovating, and pay only for the compute time that they consume.

There are a number of reasons why going serverless makes sense:

• NoOps: The server infrastructure is managed by the cloud provider, and this reduces the overhead and increases developer velocity. OS updates are taken care of and patching is done by the FaaS provider. This results in decreased time to market and faster software releases, and eliminates the need for a system administrator.
• Autoscaling and high-availability: Function as a unit of scale leads to small, loosely-coupled, and stateless components that, in the long run, lead to scalable applications. It is up to the service provider to decide how to use its infrastructure effectively to serve requests from the customers and horizontally scale functions-based on the load.
• Cost-optimization: You pay only for the compute time and resources (RAM, CPU, network, or invocation time) that you consume. You don't pay for idle resources. No work indicates no cost. If the billing period on a Lambda function, for example, is 100 milliseconds, then it could significantly reduce costs.
• Polygot: One benefit that the serverless approach brings to the table is that, as a programmer, you can choose between different language runtimes depending on your use case. One part of the application can be written in Java, another in Go, another in Python; it doesn't really matter as long as it gets the job done.

On the other hand, serverless computing is still in its infancy; hence, it is not suitable for all use cases and it does have its limitations:

• Transparency: The infrastructure is managed by the FaaS provider. This is in exchange for flexibility; you don't have full control of your application, you cannot access the underlying infrastructure, and you cannot switch between platform providers (vendor lock-in). In future, we expect increasing work toward the unification of FaaS; this will help avoid vendor lock-in and allow us to run serverless applications on different cloud providers or even on-premise.
• Debugging: Monitoring and debugging tools were built without serverless architecture in mind. Therefore, serverless functions are hard to debug and monitor. In addition, it's difficult to set up a local environment to test your functions before deployment (pre-integration testing). The good news is that tools will eventually arrive to improve observability in serverless environments, as serverless popularity is rising and multiple open source projects and frameworks have been created by the community and cloud providers (AWS X-Ray, Datadog, Dashbird, and Komiser).
• Cold starts: It takes some time to handle a first request by your function as the cloud provider needs to allocate proper resources (AWS Lambda needs to start a container) for your tasks. To avoid this situation, your function must remain in an active state.
• Stateless: Functions need to be stateless to provide the provisioning that enables serverless applications to be transparently scalable. Therefore, to persist data or manage sessions, you need to use an external database, such as DynamoDB or RDS, or an in-memory cache engine, such as Redis or Memcached.

Having stated all these limitations, these aspects will change in the future with an increasing number of vendors coming up with upgraded versions of their platforms.

There are multiple FaaS providers out there, but to keep it simple we'll compare only the biggest three:

• AWS Lambda
• Google Cloud Functions
• Microsoft Azure Functions

The following is a pictorial comparison:

As shown in the preceding diagram, AWS Lambda is the most used, best-known, and the most mature solution in the serverless space today, and that's why upcoming chapters will be fully dedicated to AWS Lambda.

AWS Lambda is the center of the AWS serverless platform:

AWS Lambda was launched at re:Invent 2014. It was the first implementation of serverless computing where users could upload their code to Lambda. It performs operational and administrative activities on their behalf, including provisioning capacity, monitoring fleet health, applying security patches, deploying their code, and publishing realtime logs and metrics to Amazon CloudWatch.

Lambda follows the event-driven architecture. Your code is triggered in response to events and runs in parallel. Every trigger is processed individually. Moreover, you are charged only per execution, while with EC2 you are billed by the hour. Therefore, you benefit from autoscaling and fault-tolerance for your application with low cost and zero upfront infrastructure investment.

AWS Lambda runs your code in response to events. Your function will be invoked when these event sources detect events:

AWS Lambda can be used for endless application scenarios:

• Web applications: Instead of a maintaining a dedicated instance with a web server to host your static website, you can combine S3 and Lambda to benefit from scalability at a cheaper cost. An example of a serverless website is described in the following diagram:

An alias record in Route 53 points to a CloudFront distribution. The CloudFront distribution is built on top of an S3 Bucket where a static website is hosted. CloudFront reduces the response time to static assets (JavaScripts, CSS, fonts, and images), improves webpage load times, and mitigates distributed denial of service (DDoS) attacks. HTTP requests coming from the website then go through API Gateway HTTP endpoints that trigger the right Lambda Function to handle the application logic and persist data to a fully managed database service, such as DynamoDB.

• Mobile and IoT: A schematic for building a sensor application, which measures the temperature from a realtime sensor-connected device and sends an SMS alert if the temperature is out of range, can be given as follows:

The Connected Device will ingest data to AWS IoT. AWS IoT rules will invoke a Lambda Function in order to analyze the data and publish a message to an SNS Topic in case of emergency. Once the message is published, Amazon SNS will attempt to deliver that message to every endpoint that is subscribed to the topic. In this case it will be an SMS.

• Data ingestion: Monitoring your logs and keeping an audit trail is mandatory, and you should be aware of any security breaches in your cloud infrastructure. The following diagram illustrates a realtime log-processing pipeline with Lambda:

The VPC Flow Logs feature captures information about the IP traffic going to and from network interfaces in your VPC and ships the logs to Amazon CloudWatch Logs. AWS CloudTrail maintains records of all AWS API calls on your account. All logs are aggregated and streamed to AWS Kinesis Data Streams.

Kinesis triggers Lambda Functions, which analyze logs for events or patterns and send a notification to Slack or PagerDuty in the event of abnormal activity. Finally, Lambda posts the dataset to Amazon Elasticsearch with a pre-installed Kibana to visualize and analyze network traffic and logs with dynamic and interactive dashboards. This is done for long-term retention and to archive the logs, especially for organizations with compliance programs. Kinesis will store logs in S3 bucket for backup. The bucket can be configured with a life cycle policy to archive unused logs to Glacier.

• Scheduling tasks: Scheduled tasks and events are a perfect fit for Lambda. Instead of keeping an instance up and running 24/7, you can use Lambda to create backups, generate reports, and execute cron-jobs. The following schematic diagram describes how to use AWS Lambda to perform a post-processing job:

When a video arrives at an S3 bucket, an event will trigger a Lambda Function, which will pass the video filename and path to an Elastic Transcoder pipeline to perform video transcoding, generate multiple video formats (.avi, .h264, .webm, .mp3, and so on), and store the results in an S3 bucket.

• Chatbots and voice assistants: You can use a Natural Language Understanding (NLU) or Automatic Speech Recognition (ASR) service, such as Amazon Lex, to build application bots that can trigger Lambda Functions for intent fulfillment in response to voice commands or text. The following diagram describes a use case for building a personal assistant with Lambda:

A user can ask Amazon Echo about its to-do list. Echo will intercept the user's voice command and pass it to a custom Alexa Skill, which will carry out speech recognition and transform the user's voice commands into intents, which will trigger a Lambda Function that in turn will query Trello API to fetch a list of tasks for today.

AWS announced its support for Go as the language for AWS Lambda in January 2018. There were already some open source frameworks and libraries with which to shim Go applications that used Node.js (Apex serverless Framework), but now Go is officially supported and added to list of programming languages that you can use to write your Lambda Functions:

• Go
• Node.js
• Java
• Python
• .NET

But which language should we use to write efficient Lambda Functions? One of the reasons to go serverless is being a polygot. Regardless of the language you choose, there is a common pattern to writing code for a Lambda Function. Meanwhile, you need to pay extra attention to performance and cold starts. That's where Go comes into play. The following diagram highlights the main advantages of using Go for serverless applications in AWS Lambda:

• Cloud-oriented: It was designed by Google primarily for the cloud with scalability in mind, and to reduce the amount of build time. Go is a solid language for distributed systems and infrastructure tools. Docker, Kubernetes, Terraform, etcd, Prometheus, and many orchestration, provisioning, and monitoring tools are built using Go.
• Fast: Go complies into a single binary. Therefore, you provide a precompiled Go binary to AWS Lambda. AWS does not compile the Go source files for you and this has certain consequences, such as Fast cold-boot time. Lambda doesn't need to set up a runtime environment; Java, on the other hand, requires spinning up a JVM instance to make your function hot. Go has a clean syntax and clear language specifications. This delivers an easy language for developers to learn and shows good results quickly while producing maintainable code.
• Scalable: Go has built-in concurrency with goroutines instead of threads. They consume almost 2 Kb memory from the heap and work faster than threads; hence, you can spin up millions of goroutine at any time. For software development, there is no need for a framework; the Golang community has built many tools that are natively supported by Go's language core:
  • Go's error-handling is elegant.
  • Lightweight framework for unit testing.
  • Solid standard library—HTTP protocol support out of the box.
  • Common data type and structure supported—maps, array, structs, and so on.
• Efficient: It involves efficient execution and compilation. Go is a compiled language; it compiles into a single binary. It uses static linking to combine all dependencies and modules into one single binary file. Also, its faster compilation speed allows for rapid feedback. Speedy development saves time and money; thus, this is certainly the most significant advantage for someone with a tight budget. Moreover, it provides efficient memory utilization with garbage collector.

• Growing community: The following screenshot shows the rising popularity and usage (as observed in the StackOverflow Survey 2017) for the most loved, dreaded, and wanted programming languages:

In addition, Go is backed by Google and has a large, growing ecosystem and numerous contributors to the language on GitHub, and great IDE support (IntelliJ, VSCode, Atom, GoGland) and debugging.

AWS Lambda is the first successful implementation of serverless computing or FaaS. It gives users freedom from managing servers, increases development velocity, decreases system complexity, and enables small business to go big with zero upfront infrastructure investment.

Go support for AWS Lambda provides significant cost-saving and performance benefits for those running their business on Lambda. So If you are looking for a modern, fast, safe, and easy language, Go is the one for you.

In the next chapter, you will get started with AWS Lambda Console and set up your Golang development environment.

1. What are the advantages of using the serverless approach?
2. What makes Lambda a time-saving approach?
3. How does serverless architecture enable microservices?
4. What is the maximum time limit for an AWS Lambda function
5. Which of the following are supported event-sources for AWS Lambda?
   • Amazon Kinesis Data Streams
   • Amazon RDS
   • AWS CodeCommit
   • AWS CloudFormation
6. Explain what a goroutine is in Go. How can you stop goroutines?
7. What's Lambda@Edge in AWS?
8. What's the difference between Function as a Service and Platform as a Service?
9. What's an AWS Lambda cold start?
10. Can AWS Lambda functions be stateless or stateful?