Microservice Architecture, but NOT microservice mindset?

Microservice Architecture, but NOT microservice mindset?
We are on the same team!
Let's say we as a company decide to implement the microservice architecture and we also decide to split the teams into domains for each team to own a domain (group of microservices). You may be a member of team A and I may be a member of team B and we are all on the same ship. There is a water leak in your area of the ship, but my side of the ship looks good.  What do we do? Let's help out each other because we are all members/passengers on the same ship. We are all going to the same destination :) Microservice teams were created to pave domain boundaries at the architectural level, but it does not mean that we should create boundaries among members of different domain team members. Yes, the API contracts are definitions for how our services communicate, but for the sake of final destination, we need to tear down those boundaries when it comes to approaching each other for help and proactive integration. It is beautiful to see ONE team in action especially in crunch time.


Almir Mustafic