Before I begin this, let me note I’ve broken another rule of blogging, which is that I promised to write a new entry soon… Anyway here is a new entry. I will not say anything about the next one 😉
In the world of microservices, the term “two pizza team” has a specific meaning – i.e. the right size of a dev team is one you can feed with two pizzas. The group structure and responsibilities of development teams is, if anything, more important than the technology they use.
In a previous blog post, I wrote about the influence of commodity server infrastructure on system software and application design, in particular how microservices evolved as the best way to design applications for deployment on modern IT infrastructure.
But the common misconceptions about microservices go beyond that. It’s not just about new technology and techniques. It’s also about changing the development culture. And of course the pizza that fuels it.
I couldn’t find Jeff Bezos’s original post anywhere, but I found this post that contains it, and describes a lot of the things the Amazon developers had to learn to implement SOA successfully. Of course Bezos’s 2002 memo is famous for mandating SOA or API-first development for the Amazon Web site, a course they have successfully followed in building a platform and creating a website that can be updated literally hundreds of times a day.
In Jeff Bezos’s world, the two-pizza team is a key principle of productivity. For the SOA and API first approach the two-pizza concept constrains the size of a development team. Larger teams are less productive. Marry this with the SOA and API first directive, and you end up with a lot of small teams building individual components of the application and deploying code without disturbing other teams, since everyone is adhering to the SOA principles of strongly governed interfaces (you don’t deploy incompatible changes to the interface, basically, without getting agreement from other teams dependent on those interfaces).
From talking with Amazon developers, I understand the dev teams take complete responsibility for the function (or functions) they deliver to the Website in the form of microservices. Including support – the dev team wears beepers in case a production problem occurs.
Part of this is because of the way the commodity computing works. It’s the “pets vs cattle” analogy, among other things. When you are dealing with servers as “cattle” you have to automate the system administration function. It’s simply not possible to manually administer hundreds of thousands of PC based computers. AWS has posted a good definition of DevOps as the merger of the dev and ops functions. This represents a significant culture change for traditional “scale up” IT environments, since there is no longer a separate Ops team and Dev has to provision all the infrastructure (data stores, messaging, networks, etc.) using APIs.
Even MORE APIs you say! Yes. So let’s conclude by revisiting a key part of this discussion – API governance. Why haven’t more companies followed Amazon’s lead? They have proven the API first SOA design approach to be very successful, if not essential in modern computing and digitization.
Mark Settle in Forbes argues it’s because of the governance, or lack thereof. Yes, it’s incredibly hard to change the development culture to two-pizza teams developing microservices with strongly managed interfaces. You need someone like Jeff Bezos to mandate it. Or at least have the organizational will to change the development culture.
The Amazon Web site Death Star from 2008! Showing the microservices landscape, essentially.