BT

Microservices and Evolutionary Architecture

| by Jan Stenberg Follow 34 Followers on Mar 05, 2015. Estimated reading time: 1 minute | NOTICE: The next QCon is in San Francisco Nov 5 - 9, 2018. Save an extra $100 with INFOQSF18!

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.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT