Serverless — What’s all the fuss about?
There’s a lot of buzz around serverless solutions of late, but what’s it all about? Depending on who you talk to, it’s either the latest tech fad, or a major architectural shift in software delivery. Let’s take a look.
The Hosted Model
You may have a solution that looks similar to the figure below:
Cost savings can be made moving from bare metal servers to virtual machines (IaaS), removing the need to maintain physical hardware.
Further savings are made when moving to a Platform as a Service (PaaS) environment, where patching and maintaining infrastructure is no longer necessary. Surely this is as lean as it gets?
Uptime and Scale
No matter how popular our website is, there will always be quiet periods. In a hosted model, we’re paying to keep the lights on, even if there are no visitors. Some downtime we can expect and mandate for (shutting down servers outside business hours, for example), but we can’t get it right all of the time.
Conversely, we should also consider the busy periods — how will the application perform during peak business hours, and how will in perform as the user base grows over time?
In this scenario (even in a PaaS environment) we have to decide on server hardware specifications and load balancing rules — under what circumstances do we allocate additional capacity, and how much to allocate? Again, these estimations will never be a perfect fit; there will always be leftover capacity in a well performing system, and that has to be paid for.
Serverless Websites — Single Page Applications
Consider a single page application, written in an appropriate framework such as Angular, React or Vue. When a user visits such a site, their browser downloads all site assets (javascript files, images, css…etc). The important distinction here is that it is the user’s browser that is responsible for all page rendering rather than a hosted website — the website itself is merely static content, which can be uploaded to a cloud storage account.
There are two major advantages here, namely cost and scale. Firstly, we only pay for cloud storage, which is a fraction of what we would spend on hosting. Secondly, the number of concurrent users is irrelevant here, as all page rendering is done client side, and thus we have limitless horizontal scale.
There are a number of disadvantages to using SPAs though:
Accessibility — modern accessibility guidelines state that websites must work with javascript disabled. This would not be possible in this case.
Limited indexing — pages cannot be indexed by search engines in the typical manner, which may be a problem. Consider an eCommerce site, where customers may use Google to find the best price for an item — our site may lose business to a competitor if it can’t be found, no matter how keenly priced the product is.
User flows — tools like Google Analytics provide great feedback on most popular pages and user journeys with minimal configuration. Additional work is required to get such tools play nice with our serverless websites.
Serverless API — Functions in Azure
Functions are small blocks of user defined code hosted in Azure, designed to run for very short periods of time (with Lambdas being the equivalent in AWS).
Rather than the traditional hosted API where we pay for uptime, with Functions, payment is made based on execution and runtime.
If a function is never called, no cost in incurred, and the first million calls per month are free.
The same advantages apply — from a cost perspective, we aren’t being charged for absence of activity. Scale is automatically handled by the cloud provider, at no additional cost.
However, functions encourage the design of lean code from scratch, and may be difficult to retrofit to an existing solution. Furthermore, there can be a delay in execution if a function has not been run in a long time (aka “cold starts”), which may not suit applications dependent on high availability.
Serverless Storage — Table Storage and Cosmos DB
Azure SQL is the cloud hosted version of SQL Server, which we all know and love. However, relational databases require a lot of maintenance as they scale — indexes need to be created and recreated over time, data partitioned for optimal access times, and the underlying hardware needs to be considered, even in a PaaS environment.
Table Storage and Cosmos DB are two such serverless storage models provided by Azure, where hardware specifications are of no concern to the architect — costs are incurred separately for storage and retrieval.
Table storage is a cheap NoSQL data store that provides fast retrieval of data when searching in a single partition; Cosmos DB guarantees millisecond response times for all queries as indexes are automatically maintained and optimised by Azure, but is more expensive than table storage.
Again, cost and scale are the major advantages here, but careful consideration should be given as to the nature of the data stored — how it is to be queried; balance of read/write operations; what data is frequently used vs. what is archived. This is necessary to design and efficient, cost effective data model. Furthermore, if there are reporting needs, traditional database tooling will not work here; requiring the use of newer toolsets such as Power BI.
Opportunities for the Future
In this post, we’ve only looked at components we’re familiar with — a web front end, an API and a data store. It’s pretty easy to emphasise the cost and scale advantages here when talking about things we know well, but serverless architecture opportunities extend far beyond this.
Azure provides a wealth of intelligent consumption based services that work out of the box with minimal configuration, such as cognitive services for image, text and speech recognition; intelligent logging, monitoring and alerting with Application Insights; and secure authentication services for multiple identity providers.
Using these production ready services saves us the time and effort of creating our own solutions, and they are already designed to cater for scale.
Limitless opportunities with limitless scale at limited cost.
So yeah, that’s the fuss!
