Summary
New research from the University of Sledgham-on-the-Wold has revealed that the correct number of microservices for any software system is 489. Given that, why have so many organizations used a different number of microservices? The panelists discuss the architecture of their various systems, what trade-offs they have made in the design of their systems, and how their system has evolved over time.
Bio
Suhail Patel is a Backend Engineer at Monzo focused on working on the core Platform. Jason Maude works at Starling Bank as one of their lead engineers and host of the Starling podcast. Nicky Wrightson works on the data platform at Skyscanner. Sarah Wells is the Technical Director for Operations and Reliability at the Financial Times.
Maude: This is a QCon exclusive here, where we can reveal some exciting, new research. Research from the University of Slechem on the world, has revealed that the correct number of microservices that you should be running is 489. This number was calculated, “By taking the total distinct code concepts that can be written in melted cheese on the number of pizzas a two-pizza team eats during an average Sprint, and dividing it by the mean average of your desired unit test coverage and the coefficient of the number you first thought of.” That obviously arrives at 489. I’ll let you work out the math for yourself. This would be of great and propitious import to the entire software engineering industry, if I hadn’t just made it up, which I did. That’s completely fake. Chucking that out of the window.
We can now start to ask the question, why 489? Why did we come up with this concept of stating a number of microservices that should be run in production? This came out from a tweet from Monzo about the number of microservices they run in production and what their software architecture looked like. They got a load of tweets saying, “That’s completely rubbish. You’re running far too many microservices in production. How can you possibly know what’s going on?” That raises the question, what do you mean? What is too many microservices? How do you know that you’re running too many microservices or too few?
What we wanted to do with this session was explore that concept from a number of different perspectives. I’m going to slowly invite up on stage, three guests from very different organizations who have taken very different approaches to the number of microservices in their systems landscape. How they’ve designed that landscape or how that landscape has evolved over time, whether by design or not. I’m going to call them up on stage. I’m going to quiz them about what they have in production. Then at the end, I’m going to turn the floor over to you to quiz them for me. I would like to invite the first one of my guests up, who is Sarah Wells, the Technical Director for Operations and Reliability at the “Financial Times.”
The Systems Landscape at the Financial Times
#panel #microservices #qcon london 2020 #transcripts #architecture & design #presentation
