Getting Started with Serverless in your Organisation

Contributors: James Dunn and Rafal Jankowicz

Serverless Architectures

©2018 Cloudreach

The concept of serverless architectures has garnered enormous interest from cloud pundits and industry bloggers, with many enterprises implementing serverless architectures as an effective alternative to deploying their workloads on traditional “always-on” servers. Serverless presents a change to the way in which we consume compute resources, placing any concern for virtual instances, middleware, software or processes back to the cloud provider themselves. This introduces both benefits and drawbacks, and it is the purpose of this whitepaper to help you understand how and why you might look at a serverless architecture to solve your requirements.

With Serverless, the user has the ability to deploy code without provisioning or running servers, with high availability and scalability catered for by the cloud provider. In this model, the user is not required to manage their servers or server applications which means that all a user has to do is upload code which is then executed by the platform.

AWS was the first cloud provider to offer this as a service and began providing this capability back in 2014 with the release of AWS Lambda which provides an event driven mechanism to executing code. There is no need to run persistent processes on servers, instead your code executes when certain events take place or when the function is called via HTTPS (for example, when using AWS API Gateway). As a consumer of AWS Lambda, a user has no idea of what server the function runs on. The cloud provider takes care of finding suitable servers to run the function on, and scaling the function if its called multiple times. This type of service has been called Function as a Service (FaaS) within the wider industry and is a service that many other Cloud Providers have replicated, for example - Microsoft Azure Functions and Google Cloud Functions.

Serverless is a term used to describe a software architecture concept where server-side logic is deployed on stateless compute containers that are ephemeral, and completely managed by a third-party such as a cloud provider.

Introduction to Serverless 2

©2018 Cloudreach

Benefits

Reduce Operational Overhead

Using a serverless architecture reduces the operational overhead associated with managing a server operating system, its middleware and any application components installed on it.

System administrator maintenance tasks such as patching, backups and upgrades are removed from concern as the cloud provider heavily abstracts any underlying infrastructure from the the user by providing compute containers to run your code in. And thus, the user is only responsible for their code artefacts, and how they are invoked.

Other components such as networking, monitoring, security and capacity planning are also abstracted. That’s not to say you don’t need to think and design carefully for these, but your operational overheads are significantly reduced by moving this responsibility to the cloud provider. In the same way that PaaS reduces TCO over IaaS, FaaS can reduce this even further.

Improved Time to Value

You can also greatly improve your time to value for new products and services you are looking to bring to the market using an architecture that does not depend on server procurement or provisioning, and does not require your application teams to rely on infrastructure teams to deliver an infrastructure stack so that you can begin deploying code. Any new ideas or innovation projects can be immediately tested and deployed simply by creating a function via the API or using the console, uploading code to it, and having it triggered by another service within the platform.

Many organisations have decided to adopt serverless components in their architecture, but what are the reasons?

3

©2018 Cloudreach

Reduced Scaling Costs

With serverless compute services, you are charged for the time it takes for your code to execute and the number of times your code is triggered. You don't pay anything when your code isn't running.

Using this approach you can be much more granular with the way in which compute meets traffic demand, rather than having to add entire virtual instances to meet spikes in traffic, you just trigger the same function again scaling precisely with the size of the workload. These savings are amplified if your application has been decomposed into micro-services allowing for granular scaling costs for each individual service.

To support experimentation with serverless architectures, AWS and Microsoft Azure both offer a free tier that includes 1M free requests per month and 400,000 GB-seconds of compute time per month.

4

©2018 Cloudreach

Challenges

Vendor Lock-in

When you make a decision to use abstracted cloud services such as FaaS, you may find it difficult moving your application to another FaaS provider. Each FaaS provider has native monitoring and deployment tools, and different interfaces that you may need to take into account in your function code. However, more importantly the cloud services that trigger these FaaS functions are going to differ which may force you to redesign your serverless architecture to take into account the nuances of the cloud provider you have chosen to move to.

For example, an AWS serverless big data pipeline may use AWS Kinesis to ingest a variety of data sources into AWS for the purposes of analytics. Lambda functions could be subscribed to automatically read batches of records from the Kinesis stream and process them if certain records are detected on the stream. Although similar products do exist within Microsoft Azure and Google Cloud Platform, this workflow is not directly portable, and will require a rebuild for both the services and the code to be redeveloped for the target cloud platform.

The vision of a serverless architecture is extremely attractive, however it is still a concept that requires maturity both from a cloud provider's point of view, and from third-party tooling vendors within the cloud ecosystem itself.

In addition, users of FaaS services must invest time in understanding the limits of using such services, and knowing when and when not to use such an approach.

5

©2018 Cloudreach

In contrast to AWS Lambda, Azure Functions is open-sourced to the community, so users can deploy the runtime on local servers or other cloud services allowing for true portability of the functions. To avoid true lock-in, it is advisable to design serverless components with simpler logic and fewer dependencies. For example, moving away from complex event driven workflows and using FaaS as a simple scheduler for backups, a report generator or for performing simple tasks or checks on resources.

Knowing the use case

It is important to identify the correct use case for using a serverless architecture. For example, if your workload traffic is predictable and uniform in nature then FaaS can become expensive, and there are execution duration limits on functions to consider too. As a result it may be more economic to run the process on an IaaS instance instead.

If you are building a trading application and you require a low start-up latency for your functions then FaaS may not suit your requirements as there are documented considerations to be aware of in how fast functions can start-up and begin executing your code, an effect known as a “cold start”. This is a key point as serverless does not translate to “no servers”. FaaS providers run your functions on compute containers which are hosted on virtual machines, which are hosted on physical servers. We still need to understand how we optimise our functions to run on this underlying infrastructure.

Service Limitations

Every cloud vendor imposes some kind of limitation on their services to prevent abuse, or to control the use and rollout of their products over time. FaaS services are no different. When moving your production application into a serverless architecture you must be aware of these limitations as they can have a large impact on how you run your workload.

6

©2018 Cloudreach

For example, AWS Lambda has an execution duration limit of 5 minutes and a total disk capacity of 512MB, meaning that the functions are aborted if they run after this time or require more disk than is available. Big Data Extract, Transform and Load (ETL) tasks, which are a common use case for serverless, may require you to review how these are engineered.

AWS also impose a limit on the number of invocations of Lambda functions per account per region. On exceeding this limit, AWS will throttle you and your service could be disrupted and become unresponsive. You are able to request an increase to this but this limitation is set across an entire AWS account.

Depending on your account setup strategy, you may have chosen to deploy Production, and Development environments into the same AWS Account. This means that both of these environments share the same limits on concurrent invocations so this requires careful consideration.

7

©2018 Cloudreach

Start Small

Public cloud presents a unique opportunity to test frequently and fail fast. We recommend testing FaaS functions in a sandbox to understand their limits and capabilities. Before deploying a FaaS function to a production environment, play around with functions of different sizes within your chosen cloud platform to find the right usage costs for your requirements as sometimes more expensive functions offering more Memory and CPU may save you money as they require less time to run.

Begin using FaaS for small and simple use cases to gain experience and learnings. Start with simple logic use cases such as using functions to schedule backups or by using FaaS functions to create automatic start and stop schedules for your Amazon EC2 instances (Serverless EC2 Scheduler).

As you develop experience you can look to other use cases such as creating a simple serverless web application that provides a business function, combining FaaS with abstracted storage and database services from your favourite cloud provider.

Use a Framework

In our experience, using a framework to manage deployment of FaaS functions at scale is necessary and can help address some of the challenges of operating FaaS natively. A popular framework that can help build serverless applications is the Serverless Framework.

Our advice on the best way to get into Serverless

How to get started 8

©2018 Cloudreach

It can be used to manage FaaS deployments as well as auxiliary services used to augment the logic in your application across AWS and Azure. It can provision PaaS databases and storage where state and application data can be kept - going serverless does not mean a necessity of going stateless or foregoing the benefits of accessing large data pools.

The framework takes care of packaging, deploying and versioning application code. It will set up permissions and interactions with an API gateway/HTTP endpoint and route web traffic to required handler functions. Serverless also provides command line tools which allow in terminal interaction and monitoring of FaaS deployment. It is convenient for the developer and enables interactions with CI/CD tooling, integrating with existing build/test/release processes and tools.

Participate in the community

We highly recommend attending the numerous Meetups and vendor events that surround the serverless industry. These events provide valuable insight into how other organisations have developed and implemented serverless architectures across multiple use cases, different cloud platforms and tools.

These often involve tips and advice on how to avoid the mistakes or overcome challenges that other users of serverless technologies have faced.

9

©2018 Cloudreach

Serverless at Cloudreach

Cloudreach initially recognised the usefulness of serverless for smaller use cases such as for auto-scheduling instances and for backups and quickly became accredited by AWS for their serverless technologies.

The use cases rapidly expanded to helping organisations remove technical debt by removing infrastructure and replacing with FaaS technologies. Cloudreach has helped customers who wish to focus on developing application code rather than infrastructure deployment and operational concerns. For one customer, Cloudreach built a website backend infrastructure that consisted of stateless microservices, with every microservice represented by a Lambda function. These services were called by internet users using API Gateway, with S3 being used for persistent storage. Cloudreach then built a deployment pipeline using a git repository and Jenkins server, to pull, package and deploy updated code to the Lambda functions.

Our engineering community has taken full advantage of the low barrier to experimentation with FaaS by creating serverless applications that simplify day to day tasks at work. Cloudreach hosted an internal event known as .create(), where Cloudreachers from across the globe get into teams of 2-3 to create something - with the theme: "Create something which improves someone else’s life at Cloudreach". One of the teams used AWS serverless technologies to automate the uploading of expenses using the Monzo banking app to the Cloudreach finance platform built on Financial Force. The team used AWS Lambda, API Gateway and DynamoDB, and were able to design and build the app in less than 12 hours.

Serverless is still a relatively young concept and many organisations have only just started using it for production business functions.

10

©2018 Cloudreach

The Future of ServerlessServerless has only been available to the market for around 2 years and the future is an exciting one. We have seen a vast improvement in the cloud vendor's implementation of FaaS technologies since release, and the creation of an impressive ecosystem of third-party tools and frameworks.

Looking forward, we are seeing interesting developments around the use of FaaS at the edge of content delivery networks (Lambda@Edge), improving user experience by executing functions as close to the user as possible and thus reducing network latency. AWS have taken this concept further by announcing AWS Greengrass, a service that allows IoT devices to run FaaS functions locally, reducing the need to send round trip requests to your nearest cloud region.

Despite Azure Functions only being announced in March 2016, Microsoft have produced a powerful competing product and we look forward to seeing how the cloud providers continue to compete and innovate in this space in the future. In the meantime, we see the third-party frameworks such as Serverless, Sparta, and Apex fill some of the feature gaps in the cloud vendor's implementation of serverless technology.

11

©2018 Cloudreach

For this reason, whoever can make the most of them will be tomorrow’s industry leaders. We have led the cloud industry since 2009, and bring deep expertise in enabling enterprises’ use of cloud technologies through intelligent and innovative adoption. Cloudreach’s customers always adopt cloud rapidly, efficiently and at scale.

We have empowered some of the largest and best known enterprises in the world to realise the benefits of cloud. In 2012, we were the first company in world to move a true enterprise data center to AWS, for Kempinski Hotels. Cloudreach is part of Blackstone’s portfolio of companies. Blackstone is one of the world’s leading investment firms with assets under management of over USD 360 billion.

Let us enable you to innovate and be tomorrow’s leader. Enable, integrate and operate your cloud with focus, governance and confidence.

We believe that successfully adopting cloud at scale requires brainpower, not just manpower. Cloud technologies eliminate the need for tedious, manual work and enable a large degree of automation. By taking an intelligent and innovative approach to cloud automation and tooling, you can streamline your processes and reduce human error.

For this reason, our first consideration will always be software (whether it’s ours or our partners’) and this, supported by cloud specialists, will drive repeatable, automatable processes within your organisation. Small, agile teams of innovative thinkers can deliver large outcomes. This is the cloud-native approach.

Not if. When

Intelligent Cloud Adoption

Cloud technologies have made it possible for everyone to innovate quickly, in completely new ways and at a far lower cost than ever before.

12

Cloudreach Customers Include

Nic Bellingham (Head of IT, The Met Office)Brendan McPartlan (VP of Ops, The Economist)Philip Wiser (CTO, Hearst Publications)

12