Introduction

Serverless architecture, or sometimes known as just Serverless, is an important approach that is maturing rapidly in cloud computing. The approach blends well to DevOps and enables the roles within teams to be fully utilised while ensuring the delivery of applications onto an environment.

The AWS service for Serverless is known as AWS Lambda, this was launched in Nov 2014 (pre-release), it wasn’t until the start of April 2015 that it became generally available. As with all new AWS services, Lambda was built on the concept of an MVP (minimal viable product) and its feature set has been built from customer/community feedback to direct releases. As we’ll see later in the blog, the case studies are rich and varied now, as well as growing all the time.

What is Serverless Architecture

Serverless architecture enables further abstraction between the application and server that it is running it on. This is fulfilled by the cloud provider (AWS) managing the allocation of the server, availability, OS, and patching. Then the code is then run in isolation on the server only when it is invoked/triggered by another function or a service. This concept is often known as Function as a Service (FaaS).

AWS describes their Lambda service as a way to run code without provisioning or managing the servers. Find out more about AWS Lambda here.

Leveraging Serverless in your projects and workloads

When building an application or service to gain the benefits from serverless it is important to strip it of its functions, build up the common classes. In addition, it is important to understand how each function is going to be invoked and used to fulfil the requirements on the overall application or service. These basic concepts allow teams to write clear user stories and plan builds using sprints, enabling each team member to understand and concentrate on their tasks.

Our approach

This is slightly dependent on the point in the project that infrastructure concerns are considered. It is also dependent on the project methodology to some degree too. These dependencies aren’t blockers but do alter the effectiveness of an engagement.

Our preferred approach:

On the outset of a project a DevOps team member is included, which also means that this approach benefits DevSecOps too. By embedding a DevOps focused team member early into the project it enables the direction of the build, how to build each component, how that component could be split apart, and when to utilise AWS Lambda to deliver those functions. As a result, benefits of managed services can be adopted throughout.

We are keen to see the ongoing benefits from Lambda and promote the use of layers to provide libraries, custom runtimes, or other dependencies for the function. As well as this the AWS service called X-Ray to monitor the application or really the functions inside Lambda give vital insights for debugging and analysing for DevOps and developers.

Adoption of Serverless in project teams promotes the DevOps term of shifting left. The ability to split outputs into functions means that tangible deliveries can be made to development environments and testing can commence sooner. The benefits means that projects can be managed to a finer detail, functions can be signed off quicker, business leads can see and understand outputs and drive quality throughout the project. In order to increase deployment velocity we leverage Continuous Deployment as part of our DevOps Ethos, and AWS CodePipeline is a tool of choice. Our use of CodePipeline is illustrated in some of our case studies published here. In addition we either use AWS SAM (Serverless application model) to build our applications on AWS or the customers chosen 3rd party tool like serverless framework (within given constraints and integrations)

Please take a look at the case study section below to see our ongoing examples of how we are innovating and using serverless to fulfil customer requirements.

Benefits

There are many benefits of using serverless within your projects, as stated already, the ability to break apart the server provisioning and management with the code is paramount to its current success and adoption. The terms of ‘microservices’ and ‘FaaS’ allow developers to create concise reusable code and strongly aids in the reduction of bloat in services and products.

In addition it is worth highlighting the following areas as key benefits:

Costs

With AWS Lambda you only pay for what you use. This means that the costs only occur at the time the function is being invoked and executed. There are no costs associated with server provisioning, storage, or patching or maintenance of the infrastructure and runtimes of the Lambda itself.

This means that if you have services that only need to respond to events or triggers then this is the most cost effective way of running said solution. However, it is worth noting that if the solution is being constantly called and run then costs will escalate and at this point it may be worth looking at containers.

API

AWS Lambda service and the AWS managed service for API Gateway allow for many complex architectures and solutions to be realised. The benefits of APIs are well known, and being able to have API management tooling with serverless functions on AWS Lambda that seamlessly invoke a response to or from a target enables such flexibility in your services and operations.

Constraints

With any technology there are constraints but as these are known we have built up solutions to avoid them becoming an issue or blocker.

Going Cold / Cold starts

This happens when the server running the function hasn’t been used in a while, the first call to the function requires the instance backing the function to be started and the code to be deployed and then once that happens the instance stays alive for the subsequent requests.

In this circumstance the overall application/service may appear to be running slowly, low latency, however invocation times when observed through x-ray (a deep-tracing service) may appear fine. This discrepancy is due to the time taken to deploy the instance.

During testing we monitor for cold starts and build in known solutions like provisioned concurrency or use warmer functions to ping the target function to ensure that it hasn’t gone cold.

Size and execution

With any service there are limitations in place and using Lambda is no exception. Despite the server layer being ‘invisible’, it is important to know the constraints surfaced to the function running on it. The latest current set of limitations can be found here.

It is important to understand this constraint when building out functions, especially ones that could be invoked a lot (maybe via an API for example). The ‘shift left’ paradigm in DevOps allows for faster releases and therefore tests can be performed to help mitigate inadvertently hitting these limits. Developers need to be aware of sizing and execution to not get caught by these bottlenecks. Frequent deployments, good test cycles, will mitigate this constraint.

Case studies

The use cases for Serverless boardens all the time, at CirrusHQ we utilise Serverless to manage environments extensively from triggers/events that occur.

We recently worked with the development team at the University of Oxford to produce a pure serverless application involving API gateway backed by lambdas. This is a great example of how we built out a pipeline to enable continuous delivery of their service, this approach is a great pattern for serverless workloads. Please see how we did this here

We utilised lambda to help manage the inbound email traffic and notify our customers automatically on bounce notifications and status checks of the service. Find out more here

We utilised lambda to take data streamed from updates on an NoSQL solution to a reporting database in MSSQL. Find out more here

For CIPFA we built out their entire application layer (an API proxy) using Lambda. This enabled them to be able to create an abstraction layer between large systems in a changing landscape. Please read more here

Outcomes and best practices

At CirrusHQ we gain the advantages of serverless to help in every engagement and project, where appropriate. We utilise serverless to deliver best practices on AWS, these include:

• Automation of infrastructure from events to further extend our operations and services
• Help drive the right services and applications to benefit from microservice architecture
• We strive to promote the use of Lambda Layers
• Removal of code bloat
• Couple with CI/CD to gain the most from DevOps methodologies
• Ensure that teams are evangelised and skill sets within them can concentrate on their specialisms

I hope this overview of serverless and how we can help leverage it with you was insightful. If you like to know more on how CirrusHQ can assist you in your Serverless or DevOps journey, feel free to drop us a line at info@cirrushq.com or via our contact page.