The term “Serverless Architecture” refers to a setup where businesses develop and run applications without dealing with the underlying infrastructure. So, what does serverless mean to an end-user? There are no servers to provision or manage; it scales up as per increase in usage and scales down as usage decreases. Also, the end-user has to pay only for the time that the code is being executed. It has built-in high availability, fault tolerance, and auto-scalability. So, the service provider fully manages the provisioning, maintenance, and scaling of the infrastructure.
Monolithic vs. Microservices vs. Serverless
The legacy monolithic applications were built as a single unit. The enterprise applications that have been designed to date (before the advent of Microservices) were constructed in three parts: a client-side user interface, a server-side application, and a database. The server-side application had to handle the HTTP requests, retrieve and update data from the database, execute some server-side logic, and populate the HTML views to be sent to the browser.
The monolith is a single logical executable. To change anything in the system, the whole server-side application is to be built again and deployed. As monolithic applications are developed using a single development stack, the scaling up of the application becomes challenging.
The microservice architecture provides a different approach to software development. The monolith, if dismantled into a set of independent services that are developed, deployed, and maintained separately, becomes a Microservice.
- In a microservice, application architects can develop, manage, and scale these services independently as each service runs in its container. The services here are small and built by a handful of developers. They can be used and reused by other services and applications without direct coupling through language bindings or shared libraries.
- The monolithic applications are broken down into more minor services, each with its business logic.
Serverless takes it a step further by making an application more granular to the level of functions and events.
Evolution of Serverless
The use of computers for applications has evolved considerably since its inception. The need for greater agility and scalability has made the industry move from physical servers to virtual machines, containers, and finally to functions as a service. And, serverless is evolving faster than ever.
In the beginning, the OS was coupled to the hardware; however, with the evolution of the operating systems, it became possible to upgrade the OS without changing the hardware. As we progressed, applications were developed on/for a specific operating system (OS). As the operating systems became complex, the applications required a particular version of the OS, which increased the dependency of an application on a specific OS, leading to the development of virtual machines.
The system started to evolve as people began to find new ways to achieve more flexibility, agility, and productivity. This led to the development of service-oriented architecture. Eventually, container-based virtualization came into existence. Containers are packages that rely on virtual isolation to deploy and run applications that access a shared OS. Container images include the information executed at runtime on the OS via a container engine. The microservice architecture came into existence once we found ways to store the differences from image to image separately, with the common elements being drawn from an underlying container. This helped attain scalability in software development. There are still a lot of unnecessary libraries and supporting codes that are replicated across containers. This eventually led to the “Backend as a Service” and “Function as a Service (FaaS)” models. The FaaS model is basically about running a backend code without scaling up/down your servers.
As developers moved away from monolithic apps to microservices constructed as containers, it allowed the individual deployment of modules. This approach also enabled the developers to have the flexibility to use the framework and programming language of their choice.
The growth of Serverless as a culture
Serverless is an evolution of the trend towards a higher level of abstraction in cloud programming models. It is currently represented by “Function as a Service” (FaaS), where developers write small stateless code snippets and allow the platform to manage the complexities of executing the function.
Serverless is gaining traction in both enterprise and startup environments at a pace much faster than seen with containers, which was the last widespread industry adoption rollout. More and more backend developers are now using serverless platforms. Almost 1/5th (19%) of all backend developers currently use serverless platforms; this percentage has jumped 3 points in the last 6 months, indicating the fast growth rate in serverless architecture! It’s almost as famous as the use of virtual machines now, as per the quarterly survey from Developer Economics.
Moreover, Cloudability’s State of the Cloud 2018 report that analyzed the IT spending of 1,500 organizations in 2017 showed a serverless quarter-over-quarter growth rate of 667%. Not to be left behind, social media also shows the immense popularity of serverless technology, with Hundreds of tweets every hour being hash-tagged with “serverless.” Even Google Trends has reported a steady rise in the number of times this architecture is being looked up! This graphical representation can best understand the amount of traction that serverless is getting.
By adopting serverless architectures, customers have taken their products from ideation to production in no time compared to the traditional approach. Most cloud providers have released their serverless platforms, and there is a tremendous amount of investment and attention around this space in the industry.
Speeding up development with Serverless
Serverless Architecture is bringing about a paradigm shift in the organizational mindset. Serverless coupled with agile development culture drives organizations to fundamentally change how business applications are developed.
With the emergence of serverless functions, a more efficient pattern of event-driven computing is now available for developers. With serverless architecture, the app client creates an event that triggers an on-demand function. The developer is expected to code, without any infrastructure requirement, and pay for functions only when they call it. Pay as you go is the norm of the day with serverless computing.
The self-service based dynamic development environment dramatically speeds up the development team’s ability to respond to business needs and roll out new features. The development team now rolls out smaller and faster deployments reducing the downtime. Auto-scaling (based on traffic) provides a greater capacity, and the developers do not need to spend time testing or optimizing for spikes in the traffic as the surge response time is twice as fast. App server crashes because of surges in traffic or hardware/software failures have been reduced. Log access and system monitoring are also taken care of by the service provider, hence reducing overall development time, enabling the developer community or businesses to roll out the product faster than the traditional approach.
Instead of the long cycles of execution models and change management, Continuous Development and Deployment help the organization match pace with business agility. The developers gain by not creating critical services themselves. Most of the services are already available on the cloud; this enables faster development.
We design the prototype with too many detailed choices in traditional development, resulting in long decision cycles. The custom source code components that are a part of the design are generally fragile and are needed to be integrated, debugged, and tested at regular intervals for stability and compliance, which may require months of work. However, in the case of serverless, the development is rapid because scalable, standard and reliable components are readily available with model interfaces that can be used in our design by adjusting our design requirements accordingly. Since the source code components are standard (as good as a template), it speeds up decision-making, reducing the overall design time.
Leading players in the Serverless space
New players are entering this space rapidly, but as one would expect, the largest cloud providers have the most extensive set of geographical locations and supporting resources for hosting serverless applications.
AWS Lambda
AWS Lambda is the best-known vendor host for such a service in the current scenario. It is one of the first and most mature platforms with a stable serverless framework available in the market today. On AWS Lambda, one can deploy pure functions in Java, C#, Node.js, Python, and many more.
Over a dozen AWS cloud services are integrated with Lambda, and the list keeps growing! Amazon offers an interactive console and command-line tools for easy uploading and managing the snippets.
Microsoft Azure Functions
Microsoft’s Azure platform has been rapidly expanding in recent years. It is aggressively competing with AWS for a share of the serverless market. The list of supported resources largely parallels what AWS is offering, but Azure Functions also provides a few additional features specific to the .NET and Typescript audiences.
Google Cloud Functions
Google Cloud Functions largely follows Azure and AWS in feature parity, with few notable differences.
Summary
While serverless architecture may not be a solution to every IT problem, it indeed represents the future of many kinds of computing solutions in the coming years. Serverless has not gone mainstream yet, but it is bound to get a lot more traction in the years to come. However, the benefits of serverless architecture include easier operational management with reduced operating and development costs. But it might not be the correct approach for every problem, so one should be wary of anyone who claims that it will replace all our existing architectures.