Service-Oriented Architecture (SOA) made us think about breaking up large monolithic systems into individual services but also encouraged building producer driven monster services with centralised control and orchestration. With microservices we are going back to the underlying notions of why SOA made sense, Rebecca Parsons claimed in a presentation at the QCon London conference talking about how microservices can be an enabler for making systems more flexible in order to handle the speed and scale of changes business expects and why continuous delivery (CD) has been so important for the ability to adapt to microservices.
Parsons, CTO at Thoughtworks, also thinks that SOA has encouraged a greater acceptance of eventual consistency and replacing relational databases with other types of databases, but notes that there still exists a lot of resistance and hesitation leaving ACID transactions.
When moving to a microservice architecture, whether decomposing an existing monolith or starting without any legacy, Parsons emphasizes that granularity of services are crucial, suggesting using bounded context from Domain-Driven Design (DDD) for finding the boundaries that separates services, noting that this must be done from a business perspective thinking about business capabilities, not from a technological perspective. Cohesion and coupling as well as communication patterns and data architecture are other aspects of finding services. Parts that communicate a lot or that shares data may benefit from being in the same service.
Evolutionary architecture is for Parsons a series of principles, one important being how to deal with parts in a system that is most vulnerable to change. When working with monoliths we have often tried to predict how people would act 3-5 years in the future and built systems for that. Today we instead try to be as tolerant to change as possible, even for changes we haven’t anticipated. A focus on evolvability is a critical aspect and microservices are part of the foundation for supporting this.
Microservices places an additional burden on operations with more things to deploy, manage and monitor, activities that scale with number of services. Without a strong devops culture, with close communication between the developer and operations organizations, this is a recipe for disaster. Fortunately many of the features available in continuous delivery, (CD), are focused on simplifying for operations teams to manage a microservice architecture.
Parsons concluded by emphasizing that microservices are not a silver bullet, and that not all problems should be solved using microservices.