In this article, we will discuss about serverless architecture and serverless offerings from cloud platforms like Azure and AWS.
The cloud technology covers the whole gamut of IaaS to PaaS in terms of offerings. While the technology world evolves to scalable, flexible and modern cloud-based solutions; design & architecture of such applications is already in need of an overhaul. Serverless architecture paves the way for such an initiative. We'll explore this aspect more in this article.
This article is published from the DNC Magazine for Developers and Architects. Download this magazine from here [PDF] or Subscribe to this magazine for FREE and download all previous and current editions.
Serverless Architecture - Evolution of Apps & Architectures
Before we dive into the nuances of serverless architecture, let us first understand how the overall applications (or apps) landscape has evolved over the last few decades, and how it has had an impact on the architectures too.
Initially web only meant stateless, read-only web pages full of information. As the business requirements to put interactive data over the web grew rapidly, the stateless, read-only web pages got upgraded into web "applications".
The applications added life to the Web, and made it more interesting, interactive and obviously more complex. This eventually resulted into applications being categorized as thick client apps (desktop applications) and thin client apps (web applications).
The architectures for both these kinds of apps were still 3-tier or N-tier architectures, with server-client architecture as the base. The client would mostly be a thick or a thin client application. The server would be the gateway for data management, business logic and workflows, wherein data would flow from applications to various systems embedded and integrated, using server side components.
The architecture was very much dependent on the "server" for business data management. The server was indeed a core component of the architecture.
Then came in the mobile revolution.
The mobile-enablement of consumers and corporate workforce, and the possibility of having internet on the mobile, gave another impetus to applications, which got termed as "apps".
Apps are nothing but applications that are more modular, running on smaller & different form factors, and that perform specific tasks for an end user. Typical examples are expense management apps, ecommerce apps and of course, games. The app architecture is/was pretty much following the server-client model.
While the mobile revolution was happening, cloud-based offerings also started picking up. Initially the incentive for moving IT infra of an Enterprise, or even small business to the cloud, was to reduce costs. However, the rapid evolvement of cloud platforms like AWS and Azure added a new spin to the architecture.
In addition to being able to host applications and reduce IT costs, cloud based offerings could also reduce costs further by decomposing the tightly coupled "server" component of a typical client-server architecture. This is now achieved by AaaS (i.e. Anything As A Service). So instead of just looking at Infra as a service (IaaS), now you can also look at a possibility of Backend as a Service (BaaS) or Function as a Service (FaaS).
And this is how a serverless architecture started making more sense.
So what is a Serverless Architecture anyway?
A serverless architecture, by definition, would mean that there is no server in the architecture.
How is that possible, right?
Traditionally, any architecture (2 tier or 3 tier generally speaking) would follow a typical server/client model. Irrespective of the type of application ( thick client or thin client i.e. web), a client would be usually an interface to the end-users that would allow them to process some information, and the server would "serve" the requests coming from client - be it data or business logic etc.
This is how it has been so far with respect to the classic traditional architecture.
A Shift in Thinking Process?
Over the years, there is clearly a shift in thinking in terms of how an architecture is envisioned. This is made more interesting by adding cloud-based scalable deployment to the mix.
In traditional model, if you had to design a web application, you would think of UI, web services, business logic, database, and integration with third party systems. All of this would be sitting on the server. However, with AaaS, it is possible to further divide the server into more components that are reusable and consumable, and can also auto-scale up or down based on client needs.
This actually is the definition of serverless architecture.
So a serverless architecture would imply all of the following:
1) An architecture that does not necessarily follow a classic & traditional client-server model where everything is sitting on the server (i.e. tightly bound by server boundaries and not really on a single machine).
2) An architecture that can take advantage of "elasticity" of the underlying hosted model of the cloud. This is a big plus.
2) An architecture where some or all the components on the server-side would depend on some 3rd party applications or services, that would manage some part of server side logic or business data or workflows. This is basically Backend as a Service (BaaS).
3) An architecture where parts of the server side logic may still be in control of the team that owns the development apps consuming the logic (Single Page Apps, Mobile apps or Web apps or anything else), however the logic would run in cloud as a self-contained service which would be consumed or invoked by these clients. This is basically Function as a Service (FaaS). AWS Lambda is a good example and we will learn more about it in the coming sections.
To sum it up, a serverless architecture is basically a new design pattern that needs less effort in building your own server components. Although it is not entirely serverless per se, it is probably server-less (i.e. less server dependency).
Enough of theory; let's look at an example of Serverless
With the fancy definitions out of the way, let’s see how this information is relevant for your applications. Let us understand this by taking an example of a typical online shopping application as seen in Figure 1.
In this online shopping app, a user is interacting with a web-based client for viewing and ordering certain items. The client could also be a mobile app (not shown here for the sake of simplicity).
The user can first search through various items, and can choose specific ones for buying. The server will fetch relevant data from database and/or 3rd party systems, and then present product information to the user. The user would then be authenticated for ordering the items and an order will be placed. The application can also interact with any other third party components like payment gateway through a server to complete the transaction.
A few key points to note:
1) This is a classic 3-tier architecture hosted On-premise.
2) Server here in broader sense means all the server-side components including database, business logic etc.
3) The server is also responsible for calling any 3rd party components like payment gateway etc. Please note that the calls to such 3rd party components are routed through server and the control lies with the server only.
4) The client is mainly UX - most of the complex processing happens on the server-side - including authentication or payment. Please note that the server might be using some 3rd party services for this, but all of it is "hidden" from client.
5) This architecture design implies that the server is the entry-exit point for all interactions that are resulting from user interactions within the client itself. The server is also having all components tightly-bound within the boundaries of the infrastructure on premise.
Now let us look at how the same architecture would look like in the new serverless architecture world. It is obviously assumed that the online shopping application is on the cloud in the serverless architecture model.
In this architecture, the end user behavior and user-experience would not change at all.
It is the client application that would now be consuming various Functions or micro-services. Some functions or micro-services might be hosted on the cloud in a cluster, and would be developed by a specific organization that has created this online web application.
On the other hand, some of these functions would be 3rd party functions that are directly consumed by the client app. Please note the use of word "Function" here. This new terminology is an indication in the shift of thinking in terms of how server or server-side logic is now envisioned in the serverless architecture.
In this example, only a few functions are being consumed directly & outside the bounds of server in order to keep it simple, and compare it with our earlier example. However the number of 3rd party Functions that an application can use or consume will depend upon the nature of app, and also the kind of relevant 3rd party functions that can be used.
Some key points to note here are:
1) The end user experience does not change in both kinds of architectural patterns.
2) The business logic is now organized as Functions, which makes it all the more modular. So from Infra as a Service (IaaS since apps are hosted on cloud), to now Function as a Service (FaaS) is the logical transformation that is happening in serverless architectures.
3) Some functions or modules like authentication, payment gateways etc. are sitting "outside" the logical definition or boundary of server. These are basically self-contained micro-services that are being consumed by the client application.
4) Because of all of these alterations in the server-side logic, the client has got more responsibilities now and thereby controls certain business logic directly (like authentication or payment gateway). So the client in traditional architecture and this one, are not the same anymore. This is an important implication of serverless architecture.
5) Your application could be using many servers (or services) but you will not be worrying about managing any of them at all. This is the beauty of serverless architecture.
Serverless Architecture - Hype or Reality?
Now that we have got a good grip on the why and what of a Serverless architecture, let us dive deeper to find out if this architecture makes sense for various kinds of apps out there, or is it just a hype that would die down slowly. For us to know this well, we need to understand as to when and how a serverless architecture would be relevant.
But before that, let us understand its pros & cons.
Serverless Architecture - The Pros & Cons
Let us look at the specific advantages & disadvantages of serverless architecture.
Following are some advantages:
1) Lesser Total Cost of Ownership (TCO): Since you are going to move out certain functions from your servers and consume the relevant services accordingly, the ownership of maintenance and scalability of those functions would lie with the service, or the function provider. This means that you will end up spending less money/effort on the maintenance of this code. The total cost of ownership (TCO) would mainly include - maintenance, IT ops, development and testing, packaging & deployment costs.
2) Elasticity of Operation: Cloud based functions delivered as micro services offer an excellent ability to auto-scale up/down based on the work load. This is partly already fulfilled if your apps are on cloud. The same advantage is essentially now extended further.
3) Technology Agnostic: Servers are not bound to applications anymore, they are rather serving functions. This means that the functions could be developed in various technologies or languages, and yet can be consumed in applications hosted on other servers that are built on different technologies altogether.
4) Reduced time to market: This is more important or relevant for start-ups or organizations that want to launch the product in the market quickly - usually ahead of the competition. If you can reuse the functions that are provided as service, then it will reduce your overall calendar time for product launch.
5) More Granular Billing: Using FaaS also implies that it takes “pay as you use” methodology to a function call level.
Following are some disadvantages of limitations:
1) Dependency on 3rd party: If you are using a specific 3rd party or cloud provider Functions, then you are essentially locking yourself into a specific vendor - not at the infra level, but at the code level. This poses a serious risk to your product and it can be mitigated by choosing the right Function provider with good track record. Currently most cloud providers have FaaS, so this is mitigated up to a certain extent.
2) Code Reliability: Once you start using FaaS, then you are essentially dependent on the code written by others. So you need to be absolutely sure about how reliably the code is going to function even after periodic feature updates. This is very important when you are handling sensitive user information in your apps. You need to be very sure about the robustness and reliability of 3rd party apps in handling such data.
3) Data Security: When you end up using FaaS, your most precious data is going outside your control. For enterprises and specific ones like banks, this could be a serious cause of concern. However, this can be handled with having right checks and balances with Function providers, and also having appropriate SLAs.
4) Simplicity of Operation: Serverless might be about simplicity, but it does not always make your job simple. You have to take care of the plumbing code - session & state management, data flow between services etc. So it does not make things simple ‘just like that’.
5) Modular Design as Key Constraint: The basic premise of having your application follow a Serverless architecture is that you need to have your code modular enough at a function level. It means that the code has to be clean & separable at a level of modules being self-sustaining, and self-contained code functions.
Guidance on Using Serverless Architecture
Let us be absolutely clear that your current on-going apps may not have to be serverless right away. You don't need to rush to the drawing board immediately, and start thinking of redesigning your app that has been working so well for you.
Here are certain key driving factors or scenarios that would indicate the use of serverless architecture.
1) You are migrating your existing app to the cloud, and it is not just IaaS play, but more of an architectural revamp. Usually "move to cloud" initiatives are driven by infra cost-cutting & ROI calculations. So while doing so, if architectural revamp is not a priority, then serverless architecture at this point is not for you.
2) If you are going to deploy your application on cloud offerings like AWS, Azure, Google etc., then you can think of considering Serverless architecture based approach in your application design. However, you must know that this service is a very recent offering from most cloud providers (AWS Lambda is not more than 2-3 years old), so it means that the wide variety of things that you can achieve with such platforms, is limited to the extent of maturity of such offerings from cloud providers. Secondly, since these are pretty new and hence evolving, you may need to think through about the possibilities of being guinea pigs in the whole process. So tread water carefully here.
Cloud Based Serverless Offerings - What's on the menu?
Now let us look at specific offerings from leading cloud platforms that are based on serverless architecture concepts. As usual, some cloud platforms (viz. AWS) are ahead of the curve in terms of having an articulate offering for this, and some relatively newer cloud platforms (viz. Azure - no prizes for guessing that :) ) are moving towards that goal.
Here is a short list of various platforms that are having serverless offerings.
· AWS Lambda
· Azure Functions
· Google Cloud Functions
· IBM Open Whisk
This link gives a detailed run-down on various offerings if you would like to build a Serverless application end to end.
For this article, we will focus on AWS and Azure cloud platforms.
AWS has two key services that are based on the serverless architecture model.
1) AWS API Gateway: a service offered for creating and managing APIs.
2) AWS Lambda: a service that allows you to run specific code functions. This is on the lines of FaaS model as described earlier. Using this service, we can create user-defined code functions, and they can be triggered from your application using HTTPS, similar to a typical service oriented architecture.
Usually both these services are used together to create a multi-tier application. The best part is that both these services can scale, based on the volume of requests made. They allow you to create a tier in your application that essentially takes care of various aspects of multi-tier application overheads like high availability, server/OS infra management, and so on.
Here are some key points to note:
1) You can consume Lambda functions from mobile/web apps etc.
2) They are essentially request-driven functions. Requests could be event-driven or data-driven.
3) They follow the implicit scaling model i.e. you don’t have to worry about scaling up/down as it will happen based on workload.
4) Lambda functions can be invoked in the following ways:
a. Push Model: returns a response based on request made. Request could be event or a calling function.
b. Pull Model: happens when you subscribe to event source.
Here are some scenarios where you can use AWS Lambda (assuming you have your solution already deployed on AWS):
1) Document metadata processing or indexing
2) Image classification/indexing/processing
3) RSS feed content management
4) Media content validation/processing (audio/video)
5) Data cleansing/handling for imported/exported data
6) PDF watermarking
This is of course, not an exhaustive list. This list is to give you an idea about the kind of scenarios that can be considered for FaaS model. In addition to these scenarios, the following link provides more details about the reference architectures that can be used for AWS Lambda based solutions.
Azure Functions is similar to AWS Lambda. Here is a quick summary of all the features:
1) Develop them in languages of your choice – C#, Node.js, Python etc.
2) You can use as pay-per-use and rely on Azure to auto-scale them based on workload.
3) Runtime for functions is open-source and available on GitHub
4) Full integration with development tools like GitHub, Visual Studio
5) It is ensured that the security aspect is taken care of through authentication using OAuth and other various providers.
6) Integration with various Azure features like DocumentDB, Azure Event Hubs, Azure Notifications Hubs & Azure Storage etc.
Following are the basic templates provided in Azure Functions:
· EventHub Trigger
· HTTP Trigger
· Blob Trigger, Queue Trigger
· ServiceBusQueue Trigger, ServiceBusTopic Trigger
· Timer Trigger
· Generic Webhook, Github Webhook
In terms of various scenarios to be used, here are some scenarios for which Azure Functions are being used effectively:
1) Processing files in Azure Blob with large file size by making a compressed copy of it for use/reference later for digital media requirements. Here is a step by step process explained in this link.
2) Analyzing the product information logs generated for an ecommerce site by pushing this data in SQL Azure or Excel for further analysis. This can be done by Azure functions in an automated mode with auto-scale based on workload changes.
There could be many more scenarios. In fact, the scenarios explained earlier for AWS Lambda can also be the right ones where Azure Functions can be used to a certain extent.
We saw how Serverless architecture is picking up pace now, and how various cloud platforms are readying up their offerings to cater to these requirements.
The key driver for going Serverless still continues to be the cost. We are essentially moving from cloudification of IT (IaaS) to Apps (PaaS) to now code (FaaS). These are certainly exciting times for overall app development space. And it is evident that like all other offerings, Serverless Architecture will mature over a period of time and this has started in right direction.
The message is clear – focus on code; not the servers.