The Microservices.com Practitioners Summit is a practitioner-driven microservices conference that focuses on real-world applications of adopting microservices at scale. The Summit will be held in San Francisco on January 31, 2017. Speakers include microservices practitioners from Uber, New Relic, Lyft, PayPal, and Google.
Susan Fowler is an engineer at Stripe , the author of Production-Ready Microservices , and will be speaking at the Summit. While at Uber , Fowler worked on microservices standardization, as well as embedded within various business-critical teams to help make their services more reliable.
Prior to the summit, InfoQ met with Fowler to discuss the technical, business and cultural challenges of successfully implementing a microservices architecture.
InfoQ: Where do you see the ideals of a microservices architecture intersecting, and possibly conflicting, with the real-world systems at most organizations?
Susan Fowler : With regard to intersecting, I think that adopting microservice architecture is a natural step in the evolution of many software applications. Monorepos (monoliths) are extremely difficult to scale, and many engineering organizations can and do find themselves at a place where they reach scalability limitations (no concurrency, no partitioning, etc.). They also find that development velocity grinds to a halt, because deployment and development on a monorepo becomes incredibly difficult (from an organizational standpoint) once the application is large and there is a large number of engineers working on it. Once you get to this point, the easiest and most scalable way forward is to adopt microservice architecture.
This is precisely where most of the conflicts come from, too. Since adopting microservices is usually a « next step » in the evolution of a software system, most systems weren’t designed with microservice architecture in mind, and this creates a lot of problems, some of which are organizational in nature and others technical.
For example, on the organizational side, you end up with a lot of isolated and disjointed teams who work on their own microservices but don’t know anything about the rest of the system unless you plan for a lot of cross-team collaboration beforehand. You also end up with an institutionalized lack of trust between microservice development teams, who don’t always know that the other microservices that their own service depends on are reliable, stable, scalable, etc.
