The cloud is here to stay - that is no longer up for debate. If you are not one of the 88.5% businesses - already using the cloud or have cloud services on your roadmap, you soon will be!
As cloud adoption and trust grows, so do the breadth of services available for consumption - some obviously relevant (eg. Elastic Compute Cloud (EC2), managed database services, Route53 Domain Name Service), others with a more niche feel (eg. GameLift, Elastic Transcoder, Machine Learning). In this post, I’ll focus on ‘serverless’ capabilities and concepts offered by Amazon Web Services (AWS) and a growing number of cloud service providers, and what it means in practical terms.
Microsoft and Google are both entering the serverless/ Function as a Service (FaaS) space with their Azure Functions and Cloud Functions services respectively, although at time of writing, these services are in a preview/ alpha status so are not considered production ready yet.
My colleague and fellow Adapter, Mark Stancombe-Duhm, recently published a blog covering his thoughts on serverless computing, its place in the cloud services evolution and where the concept could ultimately take the industry. Amazon's first foray into serverless came with the introduction of Lambda in 2014, then only supporting Node.js as a runtime. Lambda now supports Python and Java runtimes in addition to Node.js, broadening its appeal significantly.
Contrary to the concept's name, serverless computing doesn't actually do away with servers - at the risk of defining YAaaS (Yet Another as a Service); think of this as Function as a Service (FaaS). You develop the function and your cloud service provider of choice takes care of the execution domain (capacity planning and management, infrastructure monitoring, patching, availability, etc.).
Rather than designing the infrastructure to scale and support your own code and functions, which can be seen as wasteful (especially with mode 2 deployments), your focus is solely delivering high quality, optimised, scalable code quickly and more efficiently.
There are other obvious benefits of a serverless approach as well:
Ultimately, you are fully focussed on your application - your business' intellectual property, and its adoption.
The obvious questions when going serverless are "what do I need to monitor? And how do I do it?" Those of you who have been in the industry for any length of time will be only too familiar with graphs showing CPU, RAM, network and hard drive utilisation, traffic light alerts for up/ down status of servers and services, etc.
No longer relevant!
You are running a function, so outputs, return codes and execution times are what you should be interested in.
Capturing outputs in log files stored in S3 is one option, nicely in keeping with the serverless philosophy, but isn't all that flexible. Consider storing outputs in DynamoDB or Redshift instead, which enables live alerting/ dashboards, along with historical analysis. These Amazon-managed database services remove the availability and instance management overhead, so complement a serverless approach well.
When working with compute instances, cost optimisation opportunities can be relatively easily identified - use down size instances and auto-scaling to accommodate spikes in demand, create schedules to stop and start instances based on workload profiles, etc.
Again though, not relevant to serverless.
Amazon bill for serverless code execution based on a combination of RAM your function is configured to use, and its total execution time (in 100ms increments). Based on this, decisions around selecting the most appropriate language for your function come in to play and every millisecond really does count, so code optimisation is crucial. Again, make maximum use of your logging data - left unchecked, a buggy function release could leave you with a surprising bill at the end of the month.
As your serverless strategy develops, you will come to realise a number of benefits:
As with most developments in technology, there will be some inevitable challenges along the way:
Lambda is a relatively new service in Amazon's portfolio and as such, there are currently no published SLAs to which the service can be held. This is something you need to include in any risk analysis work undertaken as part of the project initiation phase.
Two points of note from the AWS Lambda FAQs¹ are:
"Q: How does AWS Lambda secure my code?"
"AWS Lambda stores code in Amazon S3 and encrypts it at rest. AWS Lambda performs additional integrity checks while your code is in use".
"Q: How available are AWS Lambda functions?"
"AWS Lambda is designed to use replication and redundancy to provide high availability for both the service itself and for the Lambda functions it operates. There are no maintenance windows or scheduled downtimes for either".
There has obviously been a lot of thought around scalability and security put into the design of Lambda, so some sensible SLAs will undoubtedly follow.
Given the right use cases, a serverless approach can be a very cost effective way of operating. Combined with other managed services on offer from cloud providers (e.g. Relational Database Services, S3 Object Storage and Simple Email Services) you have a very powerful tool set at your disposal without having to touch or manage a single compute instance, operating system or database engine.
The industry has a long way to go before this becomes a practical reality, but cloud compute in its current form will become legacy - the only question now, is when...?
¹ - Source: AWS Lambda FAQs