With microservices, then, a distributed architecture also means distribution of responsibilities. Basically, cloud infrastructure and devops tools have given developers the control they need to take that responsibility without depending much at all on operations. The division of labor also encourages domain specialization -- the pricing service developers really know how pricing works and have an open line of communication with the pricing folks on the business side.
Microservices architecture is no panacea, and determining the boundaries between services generally takes multiple iterations before you get it right. Plus, clear divisions of responsibility work well until key people leave -- and you discover documentation about how a given service works is lacking. Moreover, many teams struggle with determining the best practices for versioning hundreds of services. Last but not least, the service orchestration tools are today far from mature.
But the payoff is manifold: Services can be updated individually, new applications can be built quickly from existing services, and management actually has greater visibility into who is responsible for what. Practically speaking, it's still too early to tell whether microservices architecture will succeed where SOA and earlier, similar schemes failed. In the end, the greater authority and satisfaction enjoyed by developers may be the x-factor that ultimately drives its success.
Sign up for CIO Asia eNewsletters.