Optimizing your cloud ROI with serverless architecture

Only a few enterprises have currently deployed serverless architecture, but its adoption is set to ramp up over the next few years. This blog post discusses what it is, why it is important for both business and IT, its use cases, and how best to ensure a smooth adoption.

Capgemini TechnoVision 2020, our annual tech trend watch and guide, describes serverless architecture as: “The mix of virtualization, software-defined networking and data centers, cloud, APIs, and software containers” which “makes IT infrastructure a commodity that can be easily orchestrated and procured from a catalog of services,” it says.

It further states: “Serverless abstracts hardware from software, allowing the build and construction of server, storage and network landscapes without the need to access or manage anything.”

Run code – the easy way

In a nutshell, serverless architecture enables you to run your code without the need to provision or manage servers. From a business perspective, all of this adds up to three key outcomes:

Faster time to market: The ability to respond rapidly to change means that you can create applications without worrying about underlying infrastructure
Cost efficiency: A fully optimized public cloud cost model means you only pay for what is used, e.g. compute, storage, network, etc.
Inherent scalability and resilience: Applications (automatically) adapt to their workload, while replication ensures that if one app instance fails, those in other locations stay in place

This can be illustrated in a real example from independent investment advisor Financial Engines. By using serverless architecture with AWS Lambda instead of virtual machines (AWS EC2) for a key workload, Financial Engines saved 94% in hard costs, not including the cost savings in operational maintenance, which is taken care of automatically. Financial Engines has experienced near-zero downtime and near-zero performance degradation while serving 200–300 million requests per month at rates of 60,000 per minute during heaviest traffic, which can reach 10 times normal traffic. Another company, Homeway, a vacation rental marketplace, halved its development time and lowered its costs by 66% using Google Cloud Functions along with other Google serverless services.

The journey to serverless architecture will be familiar to IT leaders. From monoliths (1 app, 1 middleware, 1 hardware); to distributed apps (1 app with its associated containerized microservices relying on abstracted hardware); and now to serverless (1 app relying on abstracted middleware and hardware). Most organizations have yet to go fully (if at all) to serverless, but statistics show that of those companies using AWS, 75% regularly use its serverless Lambda compute service to run coding. Released in 2014, AWS Lambda was the first Function as a Service (a type of serverless) on the market but has since been joined by MS Azure Functions, Google Cloud Functions and others. And when the big guns come out, you know it’s getting serious.

Serverless Web Server high level architecture example based on AWS services. This architecture illustration could be replicable with any other Cloud provider.

A maturing technology

So, is it time to go serverless? If you want to stay ahead of the competition and maximize your cloud ROI, then the simple answer is yes.

Serverless is mostly hosted in public clouds for now but is already available for private clouds. Having said that, while it is currently easy to set up proof of concepts and/or production applications on mature public cloud platforms, it is way more difficult to do the same on-premises (private cloud) – at present. On-premises solutions such as Knative, Kubeless or OpenFaaS are emerging nonetheless. This remains an evolving and disruptive journey that will be a major change for the IT function over the next five years.

At this relatively early stage in the evolution of serverless, there are understandably a number of concerns being raised. Is vendor lock-in a risk? What new security threat does it pose? Testing and debugging appear more challenging. Is there a risk to performance? In addition, there is no (or limited) possibility to run long processes, such as video processing or long statistical computations. Thus, we can see that serverless is not applicable to every usage.

Adopt a hybrid strategy

While, in the main, serverless architecture is often a best practice for greenfield developments, the best approach is to go hybrid. By which we mean use elements of serverless alongside your existing cloud platform.

Use serverless for:

Lightweight, flexible applications, such as Internet of Things (IoT) data collection
Inconsistent application usage (when and how much), such as shopping websites front-end
Need for reduced latency (close to user), for example mobile apps

Do not use serverless for:

Large applications with constant workload – these might include monitoring tools and corporate websites with stable traffic

Recommendations for adopting serverless architecture

At Capgemini Invent, we urge our clients to ‘think cloud native’ and change the way they conceive their business applications by adopting architecture principles.

The following recommendations are built on our vision for a state-of-the-art architecture:

Build stateless functions
A stateless application does not store users’ data locally but rather in a centralized datastore. This ensures that, if the service fails, takeover from another instance keeps the service up and running.
Adopt event driven architecture
Event driven architecture relies on loose coupling/isolation of functions with their internal and external dependencies – in other words, they receive or transmit information asynchronously to other functions/applications. This is mandatory for serverless applications because it enables both elastic scalability and individual function updates with little to no impact on their ecosystem.
Address security and monitoring
Use specific tools and principles that will help monitor and protect your serverless services and functions individually, such as Dashbird, IOpipe and Protego.
Use the 12-factor app methodology
This is the historical reference for cloud native architecture principles.
Adhere to the following implementation principles
- “You build it, you run it”. This DevOps inherited pattern ensures that developers take operations into account ahead of time
- 1 function = 1 action. Building functions for more than one purpose will result in higher levels of complexity
- Only write business logic code. This is the purpose of serverless. Everything else is off-the-shelf

Start your serverless journey

Although still at early stages of adoption, serverless architecture will be a major disruptive force in enterprise computing in the coming years. Here’s how to get started on the journey:

Identify a relevant use case to be used as a pilot. A modernization use case allows for effective measurement of gains
Rely on a team with mixed expertise (Dev/Finance/Security/Ops), flexible on its operational model, for example, in a Cloud Center of Excellence or within a digital factory: serverless applications are better operated with NoOps practices which shift some of the operating complexity to the developer side.
Adapt/define the cloud architecture framework to the specifics of a serverless environment
Analyze serverless cost indicators from the beginning in order to anticipate the necessary budget and set up the appropriate FinOps policies

We recognize that serverless won’t solve everything because it isn’t suitable for all existing applications. That’s why we recommend a hybrid approach.

To learn more about Capgemini Invent’s approach to serverless architecture, please get in touch.

Financial Engines ROI source: https://aws.amazon.com/solutions/case-studies/financial-engines/

Homeaway ROI source: https://firebase.google.com/downloads/Firebase_HomeAway_Case_Study.pdf