Serverless IT – Concepts & Considerations

Nov 9, 2016
Chess Board

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.

Serverless computing – what’s it about?

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.

Function as a Service

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:

  • No need to maintain a dedicated infrastructure team
  • No overhead or distractions from "infrastructure" issues
  • Only pay when your code is executing
  • The ability to scale your application without operating system constraints to accommodate

Ultimately, you are fully focussed on your application - your business' intellectual property, and its adoption.

Challenges & limitations

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.

Cost optimisation opportunities

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:

  • You maintain a clear focus on application delivery and customer outcomes
  • Operational costs can be reduced – if done right
  • Simplicity and speed of scale - remember all the capacity management headaches are for Amazon to manage
  • Release cycles are no longer constrained by the infrastructure design or expansion requirements – adopting a serverless architecture forces application decoupling by definition


As with most developments in technology, there will be some inevitable challenges along the way:

  • Your teams need to adopt a different mind-set and approach to application and architectural design choices
  • Your monitoring strategy and kit bag need to fundamentally change - the focus becomes response and transaction orientated. This is a good transition though, as it is much more closely aligned to your application consumers' experience
  • You could potentially be faced with Cloud Lock-In due to the provider specific implementation and any APIs being utilised, although code is platform/ vendor agnostic

AWS Lambda – SLAs & availability

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.

Serverless for everything?

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

Anthony Copson
Operational Pod Manager

comments powered by Disqus
Select service
Featured authors
Select tag
Call us on 0845 304 3044