Moving from a monolith to a distributed monolith - a cautionary tale on adopting microservices
This talk is a case study of our architectural evolution over the last 2 years.
Our start-up had licensed a customised warehouse management system in order to demonstrate our innovative new business model. The WMS had a traditional 3-tier architecture based on Java and SQL server, and was lightning fast with most of the business logic encapuslated in stored procedures.
Out our start-up we needed to be able to "test and learn" - ie rapidly develop and deploy new features and test them in the market with our customers. Based on the feedback we would identify tweaks to the business model, and fine-tune the functionality that our customers wanted.
We had a launch date 5 months in future, a need to scale rapidly, growing the team from 2 devs to 20 within 8 weeks. And we needed to be able to work in parallel on multiple features. Whilst ensuring that the application was secure, performant, and reliable.
The answer, according to a bunch of experts, was to adopt microservices.
Three years later, we have a suite of secure, scalable, and resilient applications running in AWS. We deploy to Production multiple times a day, and our MTTR is less than 30 minutes.
And we have Services. Some of them are "micro".
But reflecting on what we learned in that period, there are a lot of things that we wished we had done differently.
In this talk I'll walk you through the evolution of our architecture, explain some of the choices, and highlight what we learned, and discuss what we would do differently if faced with the same decisions today.
This case study talks about the last 9 months of our start-up where we went from “no team, and limited functionality” – to launching a successful and thriving business backed by completely custom trading platform and fulfilment engine.
Outline/Structure of the Talk
5 mins Introduction & scene setting
5 mins Describe how we decided to deal withe Monolith
5 mins Describe the challenges of having too many interdependent services
5 mins Discuss the shift in mindset between designing for the Cloud, and how we used some ideas from Domain Driven Design to simplify our architecture.
5 mins Summary and how to apply these ideas in their own context.
5 mins Questions
The audience should leave the talk with the following clear learning outcomes.
- Clarity in understanding how start-ups need a different mindset and approach to architecture and design
- Tips on how to apply DDD to their business architecture
- Ideas on how to map their business processes to the underlying applications and services
- And lastly, they'll have a clear understanding of some things NOT to do!
CTOs, senior technical leadership, and senior developers, and people interested in applying evolutionary architectures, in their own context, especially those from smaller companies or startups.
Prerequisites for Attendees
It is a very self-contained session. No jargon.
An awareness of AWS, and DDD would help, but the talk is pitched at an introductory/intermediate level.