the path to Serverless First

Apr 24, 2019 is one of the UK’s leading online electrical retailers, that is dedicated to giving its customers an exceptional experience, throughout the purchasing journey. From choosing the right item for their needs, ordering on its website to delivery of the item at a time that suits them, is passionate about creating happy customers..

One of their ways of achieving this was to spawn their Single Customer View (SCV) team. They play a key role in helping the company stay compliant with user privacy and GDPR legislation. Until recently, their tech stack was made up of everything you’d expect: containers, EC2, Kafka, SQL Server.

Upcoming GDPR legislation gave them the opportunity to try something new.

GDPR compliance pushes them toward serverless

At pace, the SCV team needed to build an entirely new feature to help make sure were compliant with new GDPR legislation due to come into force.

The SCV team thought about what this would mean for them. They’d have to set up the containers, provision the server resources, they needed to consider load balancing and security concerns (like patching), and ship a fail-proof feature in less than two weeks, with a relatively small team. The team knew they could have a far bigger impact by trying something new.

So they started looking at more time-efficient options. Some people on the team had already played around with AWS Lambda and the Serverless Framework, and it seemed promising.

So the team committed. They decided to build a new GDPR feature in a serverless way. It was the team’s first production serverless application—and such a resounding success, the team has never looked back.

They’ve gone all-in on serverless for every new feature since, truly adopting the Serverless First mindset.

The process: building the first serverless feature

Lambda + the Serverless Framework empowered the team to complete their new feature in only three days.

After the feature was launched, they did not have to think about constantly monitoring the feature to make sure it wouldn’t go down, since Lambda scales automatically with demand.

In 3 days, we had something running in production. This was so successful for the business that we started to build even more features with Serverless.

--Jon Vines, Software Development Team Lead

They kept building new API-based services with Serverless. They built a subject access request feature (another aspect of GDPR compliance), then right to be forgotten requests, and a whole suite of other user-facing features.

The architecture for these APIs is pretty straightforward: the Serverless Framework defines their Lambda functions, which then interfaces with SNS and S3 buckets.

They were able to ship each successive feature in only a few days as well. And their Lambda cost for all this?

Less than $15 a month.

From APIs to full serverless data pipelines

One of the team’s core competencies was building data pipelines and getting that data to the right teams. Their initial architecture used Kafka on EC2 instances, with services deployed in containers in ECS.

The team were happy with the robustness of this solution and they now had the opportunity to make it more efficient. The nature of the architecture meant that any time they wanted to deploy changes, they had to redeploy the entire functionality for the whole pipeline. It also meant scaling of functionality was across the whole service, and not the individual features.

Moving their data pipelines to Lambda with the Serverless Framework

The AO team decided to integrate Lambda into their data pipeline. This would give them the ability to easily make incremental deployments, and the pipeline would scale automatically as needed.

They kept Kafka in place, but now interface with Kafka using Lambda and S3 buckets. So their current serverless data pipeline architecture looks like this:

“We went from managing servers, containers and scaling policies, to pointing to Lambda using S3 buckets and triggers. No need to manage or scale, and it’s so much less of a burden. It’s been a massive win for us.”

-Jon Vines, Software Development Team Lead

Challenges along the way

The team was most familiar with .NET, and decided to continue developing in .NET even after moving to serverless and Lambda.

The serverless ecosystem is primarily focused on languages such as JavaScript, and Python. This meant it was more challenging to find .NET examples, however, the team contributed back with posts on their learnings. In other areas, the tooling for .NET in observability and monitoring weren’t as advanced, but this is improving all the time.

Most impactfully, when dealing with Lambda functions, developers will have to work around cold starts. Cold starts are fairly minor in languages like JavaScript or Python, but in .NET could be as much as 3-5 seconds. The team is working around this by tweaking their Lambda provisioning.

Overall, Jon Vines, Team Lead at, said he’d still choose .NET again. “We’re more familiar with it, and it’s just easier for us. The gains we see from Serverless are worth the trade-off.”

Company-wide change

The SCV team at is just one of many. After seeing the huge impact serverless has made in the SCV team, other teams at are beginning to experiment with and adopt serverless as well.

”We’re still pretty early in our Serverless journey here at AO. I can’t wait to see what things shape up like in the next year.”

-Jon Vines, Software Development Team Lead

Subscribe to our newsletter to get the latest product updates, tips, and best practices!

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.