A Guide To Building A Serverless Platform

Source- forbes.com

It’s cold and deafening as I scan my hand and walk through aisle after aisle of humming and whirring machinery. I used to love sitting on the floor to physically plugin and troubleshoot some mission-critical issue. Now I’m turning it all off.

Change in the technology space is seldom subtle. While I may have lost this experience to my memory, there is something incredibly liberating about a fresh start.

The last few years have felt frenzied as companies race to transform their legacy software and infrastructure into shiny, new digital platforms. The single biggest driver behind this trend is the need to go fast. As a technologist, I’ve come to view software, infrastructure, manual process and large teams all as risk and a drag on your ability to be agile.

Below, I’ve outlined proven technologies and approaches myself and others have adopted to build 100% serverless platforms, enabling you to transform your technology and go fast.

Adopt A Serverless Mindset

You’ll need to embrace a new mindset to move from “build to last” to “build to change.” I’ve worked with many organizations that still maintain the original systems that have powered their enterprise for decades. Most of these systems require hundreds of physical servers or VMs. As you can imagine, all that institutional knowledge requires large IT organizations just to keep the lights on.

Unfortunately, the same people who built these systems will usually be the first to admit that technology has become the single most limiting factor if not a complete roadblock to digital transformation. Below is the mindset you should adopt before contemplating evolving to a 100% serverless platform.

Get Started:

1. Commit to a continuous cycle of learning, testing and improving.

2. Commit to throwing away old code.

3. Commit to retiring as much physical infrastructure as possible.

4. Commit to rethinking your architecture and breaking it into simpler components.

5. Commit to automating everything.

Build Static Websites And Application UI

Since we’ve committed to change, let’s start the process top-down. As we simplify our stack, a natural place to start is the user interface. We’ll abandon servers completely and opt for static HTML, CSS and Javascript. Static websites optimize for rapid development and allow you to focus on user experience. This approach will allow you to build teams with skill sets that are web-native and, most importantly, unconstrained by server-side architecture.

Get Started:

1. Select a cloud provider that will allow you to host HTML, CSS and Javascript files and that will transparently scale along with your traffic patterns (AWS S3, Google Cloud Storage).

2. Select a Javascript framework or libraries that allow your static website to do URL routing and that can communicate with your backend services via REST or GraphQL endpoints (React.js, AngularJS).

3. Ensure your teams have above average skills in HTML, CSS and Javascript. Up-skill or fill resource gaps to get the most benefit from your new stack.

Ditch Your Application Servers

Your new static websites will use javascript to communicate with middle-tier and backend services. We will once again abandon servers and focus on writing single-purpose functions that do one thing and do it well.

The enabling technology to understand here is function as a service or FaaS. FaaS is a term given to a new category of container that allows you to build, manage and deploy functions independently without actively managing the underlying infrastructure. A key benefit with FaaS is that it’s easier to understand and maintain a single-purpose function/service.

Work can also be more easily distributed and released without impacting the broader platform. Another critical insight is that we only pay for function execution time and not servers sitting idle while they are not being used.

Get Started:

1. Select a cloud provider that supports FaaS services and can expose them as either GraphQL or REST endpoints (AWS AppSync, AWS API Gateway, Google Cloud Platform).

2. Select a framework to build and deploy vendor agnostic FaaS services (Serverless Framework).

3. Start with a continuous integration and delivery model (CI/CD). Your goal should be a zero-touch production environment where only your CI/CD process can deploy and promote your services (Jenkins, AWS Code Pipeline).

Move Your Data Into The Cloud

Managing, moving, transforming and storing data can be expensive. Infrastructure that’s prescaled and waiting until it’s needed will be a major drain on your budget. Your middle-tier and backend services will inevitably need to do all of the above. In organizations building business intelligence or data science programs, an inefficient design can kill the project before it’s off the ground.

A key enabler to adopting the serverless approach is embracing polyglot persistence. Polyglot persistence is a fancy way to say that the storage medium should be selected based on the way the data will be used and accessed.

Get Started:

1. Review your architecture to understand your data profiles and usage models and look for opportunities to move or refactor to a more appropriate data store.

2. Consider the relative ease of building a highly available architecture when making the case for moving your data to the public cloud.

3. Understand your data classification, best practices around data encryption and how to secure public cloud infrastructure.

Key Takeaways

In one word: simplify. Thick applications become thin websites. Services do one thing and do it well. Data is stored where and how it makes sense. Big IT and server maintenance becomes DevOps and automation.

With a serverless platform, you go fast by building systems that can not only survive but thrive in an environment of change.  One of my favourite quotes from economist Klaus Schwab sums it up well: “In the new world, it is not the big fish which eats the small fish, it’s the fast fish which eats the slow fish.”