I Believe in Serverless First and so Should You
Entering the world of Serverless Technology is a challenge. It’s also a very exciting world and could be a really important step for you and your product.
If you’re an Engineer or an Architect working on a SaaS product, the past 5 years has been an incredibly exciting time (even if you didn’t realise it 😉).
The rise and benefits of Cloud technologies have been well documented. What excites me about Cloud tech is its applications for a SaaS product.
Q: Why have the past 5 years been so exciting?
When AWS launched Lamba back in 2014 it introduced a new way of designing and delivering software to the mainstream. The introduction of Serverless brought benefits to many different applications, but SaaS and Serverless are perfect for each other.
What particularly surprises me is how slow the uptake has been. Even now the applications of Serverless technology which are being shared and talked about seem to me to be basic and, dare I say it, unambitious.
Serverless is not a silver bullet. It has plenty of scary “cons” to counter the exciting “pros”. Depending on your application, Serverless may not be the right solution, at all! But, Serverless is the right solution for a lot of problems, and some of those problems are complex, so why isn’t Serverless more widely used?
A Matter of Principle
Building using Serverless is different. To maximise the benefits, you must change your approach to design and architecture. There are architectural principles which you really should adopt, for instance:
- Data may arrive out of order, or multiple times.
- No State. You must code knowing your functions are ephemeral and will disappear and reappear.
- Functions are independent.
These changes are a problem. It makes it more difficult to make the transition. As an expert, a professional, it’s tough to realise that some of the foundations of your expertise are changing or are no longer relevant. Using Serverless effectively requires us to confront that fact.
Greenfield, as Far as the Eye Can See
Another hurdle to overcome is the “migration”. Migrating to the Cloud often means a relatively simple process of taking an existing virtual server and moving it onto someone else’s hardware.
This isn’t trivial if it was there wouldn’t be a $150 billion market for it! But, the mechanics of it are easy to understand. For the most part, you are exchanging like for like components, whether it’s servers, containers, networking etc.
“Migrating” to Serverless is more complicated. In almost all cases, “migrating” will mean “re-building”. Re-building immediately sounds more difficult, more expensive and slower. If you commit to adopting Serverless, you’re going to be building on greenfield, it’s unlikely you can efficiently repurpose your existing components.
Well if it’s so difficult, why would we bother! At the moment I think most people are saying “we shouldn’t”, hence the slow uptake and the noddy implementations when it is used.
ResponseTap Did Bother
When you are building and maintaining a SaaS product, you are intending to scale. You want your product to reach as many customers as possible and to serve those customers as efficiently and as effectively as possible. This means being able to scale, massively and with predictable, traceable costs.
This kind of model is perfectly suited to Serverless technology. Serverless allows you to:
- Achieve massive scale.
- Deploy in tiny, iterative increments to manage risk.
- Decouple your services and responsibilities.
- Simplify code to be truly single purpose.
- Manage your costs and only pay for what you use.
- Defer huge amounts of responsibility to your cloud provider, so you can focus all your efforts on your product.
- Put your code where your customers are, utilising you Cloud providers regions and Edge technology.
How Did We Do It?
My friend Ben Jones wrote a great story about our transition to Serverless. He explains how we’ve gone on an exciting journey from a monolithic Java app to a Serverless world, with a detour via Kubernetes and Docker on the way!
The turning point came midway through 2018. Our existing architecture had grown organically, following many of the same steps as other companies. We employed all of these tactics and more:
- Split the monolith into functional parts, so each can be scaled in isolation.
- Distribute the relational database to increase capacity.
- Buy bigger servers.
- Refine and improve code to make it more efficient.
- Build new functionality according to Service Oriented Architecture (SOA).
All these techniques helped. Our company was growing, we were scaling our product to keep up. But it was getting harder to keep up. Once the low hanging fruit had been claimed, we realised that further scaling was going to require a more fundamental and revolutionary strategy.
Being responsible for the delivery, architecture and maintenance of the ResponseTap product became increasingly stressful, agonisingly stressful at times 😰. Knowing that your product has a scaling limit — which is getting exponentially more and more difficult to increase — is not a happy place.
We also knew that to give all of our customers the same, great experience, wherever they are in the world, we had to do something big. Something risky. Something exciting. Something Brave.
As Ben Jones has mentioned, we had been experimenting with AWS, both server-based and Serverless services. I became convinced that the answer to our problem was to rebuild using Serverless technology. The benefits it offers were perfectly aligned with our SaaS product. Our first new architectural principle was born:
Our product is a complex data processing platform. The examples of Serverless architectures we’d seen were very simplistic. We’d need to build something far more complex and novel. We would be entering the unknown. A place that only thought-leader types like Yan Cui were talking about!
This was an ambitious plan, a massive investment to undertake. Thankfully at the time, I had great support from the whole ResponseTap Engineering team. Especially David Turner (VP Engineering) who mentored me through the process of making the audacious proposal and helping me to develop the new architecture designs. Andrew Haining and Ben Jones were also pivotal co-authors of the new designs.
12 months later.
In September 2018, we’d rolled the dice, seriously slowed down our product development and gambled on my firm belief that Serverless will allow us to make our company’s product best-in-class.
In September 2019, we’ve just put our Serverless solution into pre-Production. Testing and development continue. But now, for the first time, I can say with confidence, it works. It is capable of incredible scale, performance and agility.
I genuinely consider this to be a career-defining moment. Very few Architects and Engineers will have the opportunity to work on such ground-breaking or revolutionary projects, but we did 🙂.
Committing to a Serverless re-build is a huge undertaking, it is risky. If you consider the situation carefully and can see that Serverless characteristics and your requirements are matched, it is worth the risk.
I wanted to share this story because I think it is the best risk I ever took. We took a step into the unknown, using Serverless in a complex and novel way, with very few similar examples to refer to. It paid off and if more people can be brave too, we can start to learn what Serverless technology is really capable of.
Go for it.
In the coming weeks and months, I will dig deeper into how we achieved our Serverless transition, including some of the best-practises we’ve learned along the way.