Article Amazon Web Services April 4, 2017

Why Less Is More: Understanding Serverless Architecture

Think about your production environment: How many machines do you provision and maintain in the lab for backend services? Now, think about Netflix. Most likely, Netflix had more.

Last quarter, the popular streaming giant supplied more than 7 billion hours of videos to nearly 50 million customers in 60 different countries. Consider the infrastructure Netflix requires to support this size of media and stream, and the amount of unused resources when half the world is asleep and their servers are running for practically nothing.

Not so long ago, Netflix became wise to this as well, and sought out a solution that would reduce the huge cost of server management.

What they found was serverless architecture.

What’s serverless?

Serverless architecture is a method in which the application backend is run in a BaaS (Backend-as-a-Service), minimizing the need for IT infrastructure, including compute and storage. It allows for production teams to host the software’s code and features on machines supplied by third-party cloud vendors and execute the code on demand, thus easing the computing effort and more importantly, cutting the cost of production maintenance.

Serverless is a fast-growing trend. Frameworks like Amazon’s Lambda, Microsoft’s Azure Functions, and Google Cloud Functions, provide a pay-per-use solution, allowing applications to utilize their services at all times, but pay only when the service is actually required and used. Servers are no longer managed or monitored by the IT infra team, and storage need not be acquired or maintained. IT management aspects including scale, availability, and security are now the responsibility of the cloud provider.

Examples of serverless products

A good example of a serverless service is Lambda. A part of the AWS portfolio, Lambda promises swift integration, as well as tools to help with different requirements such as data analysis and real-time data or file processing.

Cloud Functions, Google’s serverless environment, provides a connective layer that lets you integrate with and extend other cloud services that Google offers. A file upload to the drive or a log change in Stackdriver can create an event that will trigger applications hosted on Google’s servers. This framework is a step towards agility and allows the user to manage small units of code—as small as one function—as a service. This helps minimize execution time and reduces the overall cost.

The Azure Functions platform offers solutions similar to the other leading platforms, but adds a couple of nice features. For instance, Azure Functions allows customization of bots, including behavior in real-time and timer-based code execution, as opposed to event-based execution only.

Serverless at Netflix

After understanding the benefits of the serverless approach, it makes sense that Netflix, a leader in new technology adaptations, went serverless for their media files delivery, backups, instance deployments, and monitoring solution. They chose Lambda as their tool of choice to help automate the encoding process of media files, the validation of backup completions and instance deployments at scale, and the monitoring of AWS resources used by the organization.

Deciding on a step-by-step approach, Netflix selected a feature which wouldn’t affect their production environment for a POC — disaster recovery. Using defined events on Lambda, every action that was done on production was synced to the DR site.

Next came efficiency improvements using better production monitoring and dashboards. This information was based on the events system that Netflix built for Lambda, through which events trigger validations to ensure that the configuration fit real-world needs.

The last step was to remove responsibility of the servers that manage all of Netflix’s media. When Lambda is responsible for the server deployment, compliance, and configuration, Netflix can be confident that provisioning processes and responding to new business needs is fully handled.

The bottom line: Go serverless, but go slow

Not all serverless platforms allow users to write code in all the common development languages. It is an important parameter to consider, when selecting which platform to work with. So, before starting to use serverless platforms, the application backend features must be written in a way that allow usage and execution to occur separately. The code must be modulated and contained, so the organization can truly benefit from the serverless solution.

As Martin Fowler’s serverless architecture article aptly explains, “Serverless is very unlikely to be the correct approach for every problem, so be wary of anyone who says it will replace all of our existing architectures. And be even more careful if you take the plunge into Serverless systems now… While there are riches (of scaling and saved deployment effort) to be plundered, there also be dragons (of debugging, monitoring) lurking right around the next corner.”

Also, as with cloud adoption in general, it’s important to remember that it’s not only about saving time and money, but also about reflecting efficiency to higher management. By implementing a tracking and analysis system to show how resources are provisioned and used before moving to serverless, you are better able to understand what your application demands. Serverless is certainly worth all the hype — but is not necessarily a simple solution to migrate to. Therefore, as with all transitions, consider this one carefully.

Related Resources