Two pizza team!

Came across this terminology while reading about APIs based on microservices architecture. So, what are two pizza teams? Yes, they are small enough to be fed by 2 large pizzas! But how are they related to microservices?! We will find out.

Amazon, being a popular online store, wanted to be able to innovate in IT space quickly. But their monolith architecture was not allowing them to make software changes quickly. Monolith architectures are the old school enterprise architectures where all the components of the software are tightly coupled. These APIs are powerful and perform lot of disparate functions. Even a small change in such systems needs a lot of planning, impact analysis, availability from other teams. This definitely slows down the software release cycle. Typically in such environments there are different teams like test team, deployment team, UI team, backend development team etc who work in silos. Any small or big change goes through a long process of build, test, deploy, integration test. In case of issues people often don’t know whose responsibility it is to fix it. 

Let’s see how microservices architecture is different. Microservices architecture is a shared nothing architecture. All the services, modules are independent of each other. e.g. on the amazon website, the widget displaying your 'Cart' and the widget displaying 'Similar products', though they appear in same screen to the end user, are independent services. So, any change or a bug fix can go seamlessly without disturbing other services. 

There is a single API gateway which is handling communication between different microservices APIs. The APIs are well documented. Whenever a new client wants to use these APIs, expected calls to the API, latency needs to be discussed with the API owner team to avoid issues. As we focus here on creating multiple micro APIs, instead of creating a self contained fully functional API, this communication becomes very important.

Along with this technical architectural change, microservices bring cultural change as well. Change in the way of working. Moving away from siloed teams to cross functional teams. There won’t be a DBA team or UI team anymore. The teams will be formed as per the functionality or the module. And not based on the skillset. Each team will have a mix of people having different skills. If we have 5 DBAs, they will work in different teams. These 2 pizza teams are autonomous, independent. They are given all the freedom for the services they are responsible for. This creates the right environment for innovation. It brings in a sense of belonging within the team. The DevOps culture is a famous term now. This is a result of the same thinking.  One team will have all the experts in it. Data management, Analytics, UI, all will work towards the same goal. This automatically provides a platform for cross training as well. Every member of the team would be across all the aspects of their service. The teams remain focussed on the piece of software and all have independent release cycles. 

I have experienced this change in the organization structure myself. 7 years back while working on a large CRM implementation we had teams based on the skill set. Now when I look back, I do feel a cross functional team focused on one functionality would have been more efficient. After a few years when I started working in an agile team, the difference was obvious. Teams were formed as per the module, having a mix of people working on different technologies.

In todays’ IT world we don’t want to spend much time on planning. ‘Fail fast’ is the new mantra! And leading IT companies who are ahead in innovation have proved this with their experience. Software development is a continuous improvement process. There is no full stop. The developers should have freedom to innovate and to make new functionalities available for customers in no time. This architecture (technical and cultural!) offers fast deployments, continuous delivery and within hours deployment of new features.

Now when we have talked so much about organization structure,  can't stop sharing this brilliantly conceptualized image by Tanmay Vora