The serverless effect

The serverless movement is quickly gaining ground as it transforms businesses and the way we think about delivering value.

Serverless builds on many other practices before it, but one of the key benefits it brings is greater speed to market. These changes are encouraging businesses to evolve (or get left behind), and reframe how they function as an IT organisation. In this blog, I’ll take a look at some of the advantages a shift to serverless can bring, and share an example from a project I’ve been involved in.

A fundamental shift

Going serverless changes the way we think about delivering business value. It places a welcome focus on implementing core business logic over time spent on supporting tasks like maintaining and hosting third party IT infrastructure. A serverless approach is a simple one, since it encourages:

• Loosely coupled services
• Small code bases
• Automation
• Small changes, released often
• Effective monitoring with logs and metrics.

All of this makes serverless well suited to continuous delivery. It’s incredibly liberating for developers used to being chained to traditional enterprise programming paradigms.

Haven’t we been here before?

Serverless is hardly the first new phenomenon that promises to make all our lives easier. DevOps culture rode on the back of the agile movement, in an effort to bring traditional Operations and Developers together to deliver faster (a laudable motive; at Equal Experts we preferred to focus on what we felt was really important, which was operability).

DevOps may have fallen victim to the same buzzword jargon that agile has experienced, but it has brought a lot of good to the table. Many engineering teams have upped their game in terms of:

• Fostering a culture of collaboration with other business functions
• Automation (provisioning, testing, building, releasing)
• Supporting code all the way into production and beyond
• Better tooling
• Monitoring all the things!

The increasing automation DevOps brought with it allowed infrastructure to be described in code and provision served up on demand. All great in theory, but in practice it’s hard to execute if systems are deployed to data centres managed by teams less open to collaboration.

In contrast, creating serverless applications in the cloud pushes against the reliance on ops teams, since immediate infrastructure can be bundled with the application via serverless frameworks such as Serverless & Nuclio (ie. Platform as a Service, or PaaS capabilities).

The result: developers gain situational awareness of all aspects of the applications they are writing, and as such are able to get code into production much quicker.

Taking advantage of PaaS- like capabilities in the cloud

It’s only when businesses get over the ‘coupled to the platform’ mentality and start to allow developers to use PaaS-like services in the cloud that serverless becomes a real game changer.

With the desire to write code rather than support infrastructure, developers are more productive leaning on PaaS-like infrastructure. Most cloud platforms support the messaging systems, databases, file storage, load balancing and API management that are the building blocks for business applications. This frees developers to only concern themselves with the glue – the business behaviour in-between these building blocks.

There will always be edge cases where it makes sense for a business to run their own infrastructure, but in a lot of cases it will be far more cost-effective and productive to use services that the cloud provider offers.

Self-hosting infrastructure comes with a lot of baggage:

• Time spent on architecture, design, approval – plus actually building infrastructure;
• Time spent tuning and ironing out issues not anticipated at the design stage (it happens);
• Teams that manage the infrastructure often become siloed;
• There’s a tendency to manual configure infrastructure (rather than describe it with code);
• High training costs to on-board engineers;
• Support costs, with vendors of the technology used;
• Support problems, between teams using the technology;
• Keeping the infrastructure up-to-date with security patching & major updates;
• Aligning development code with API changes rolled out in product updates;
• Licensing costs;
• Hosting costs;
• Cost of engineers’ time to support and maintain the technology

With PaaS-like services in the cloud, you can cut all these factors out – leading to a dramatic improvement in business productivity. It frees up engineers that would otherwise be spending time becoming experts with a third party technology, and allows them to concentrate on contributing real business value.

Another notable and uncomfortable problem that is often overlooked is with teams that have a high turnover of engineers. Self-hosting infrastructure then becomes a constant time sink of re-training and learning. This is a big problem that, while not entirely eliminated with cloud infrastructure, is greatly reduced.

It’s not uncommon for enterprises with self-hosted infrastructure to eventually realise these costs and out-source it. This is the wrong response, as it results in even worse service for the teams building their applications on the top of the infrastructure.

Breaking down legacy with a serverless rewrite

Moving to serverless architecture is often labelled as something that should be left for greenfield development. The same mindset often sees legacy continuing to be maintained; perhaps left as is, or having its life extended via containers/kubernetes (we’ve been involved in initiatives like this ourselves).

However, in a world where serverless is an option, I’d argue it’s often a mistake to retain legacy applications. It’s merely extending the life of old code while increasing risk in the business. Over time, fewer engineers will have the specialist knowledge of how the application builds, runs and is deployed.

Ingenious use of containers and kubernetes is not a silver bullet either, as running container orchestration on-premises or in the cloud can be prone to the same long tail of issues as those I described above for self-hosted infrastructure.

Breaking down legacy applications and rewriting with serverless architecture can offer big wins in terms of maintainability and flexibility going forward. It provides a new generation of engineers a chance to deconstruct and break down small slices of functionality, and work with the business to document their behaviour.

Sure – the initial cost of moving from legacy to serverless requires an initial investment, but the money is being spent on a forward-looking initiative that will pay dividends over time, as teams gain the advantages I’ve touched on above.

Serverless makes on-boarding less of an issue

I’ve already touched on this, but seriously – the traditional cost of on-boarding new developers shouldn’t be underestimated. Serverless helps to counteract this phenomenon, since it naturally encourages ideal practices (eg. using a modern language that’s not too terse; maintaining a simple code base; using up-to-date tooling).

With this simplicity comes software that is easy to read, write and maintain. This also encourages diverse teams, since a simple code base can be understood by developers of various levels of experience. Conversely, where the product and code base is complex, it encourages the team to be composed solely of experienced, senior developers. This is not healthy in the long term.

An example from the field

Lots of theory above, so let’s take a look at the reality.

A client of Equal Experts has a team that focuses on customer messaging. This team has made the transition into serverless over the last couple of years, during which time the product owner kept track of how the team has evolved and delivered. The following chart shows the on-boarded business journeys, plotted against the size of the team:

The team embarked on their serverless journey in 2017, and by 2019 most of the legacy code base had been migrated. Looking at the change in more detail, it’s easy to see why the team is now far more productive:

2017
3 hours to deploy code to production;
1 ‘big bang’ deploy to production a day;
~1 week to get a development environment up and running;
Team naturally resistant to change;
Weighed down with manual BAU tasks that were hard to automate;
Only senior developers recruited to the team.

2019
20 minutes to deploy code to production;
10-20 changes deployed to production a day;
1 hour to get a development environment up and running;
Team naturally open to change;
Automation of BAU tasks;
Graduate developers welcomed with open arms.

So what made the team open to change, and able to take on more business journeys?

Well, it’s just as I’ve explained in this article. The move to serverless, cloud-based services (and away from on-premise infrastructure) enabled the developers to concentrate on what the business actually wants, rather than spending much of its time and focus just keeping applications running on on-prem infrastructure.

It could be argued that better architecture and a rewrite of the legacy system played a big factor and yes, of course it did. But the architecture chosen was serverless, giving the team all the advantages I’ve spoken about.

The changes have been dramatic for the product owner – and as other areas of the business have seen the delivery capabilities of the team in question, they are now seen as the go-to team for messaging requirements.

The serverless effect? It unleashed the team’s potential

As word spread and a trend started where instead of the business having ad-hoc messaging activity going on throughout the business, it started to coalesce around this team. Other entities in the business started to get in contact as they had heard that the team is the one to contact to resolve their messaging problems.

Marketing teams then got in touch, as their own team couldn’t turn round an email campaign as fast as the now-serverless team could. This was a great milestone for the inhouse team, and design teams were aligned to work collaboratively with them to ensure a consistent messaging narrative was delivered.

None of this would have happened so quickly if the team wasn’t able to deliver business value so quickly, and they couldn’t have done it on the old stack. Serverless was the enabler.

Only time will tell the full extent of the transformation unleashed by serverless, but we’ve already observed a number of remarkable changes that have benefited clients. For now, it’s the way to go.