Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

The CxO guide to microservices

Jim Highsmith, Executive Consultant; Neal Ford, Director, Software Architect, and Meme Wrangle, ThoughtWorks | Jan. 27, 2017
Experts from ThoughtWorks share why senior executives should pay attention to microservices.

If developers can build their own realistic environments, they have to coordinate less with operations, which reduces friction across organisational silos. The ability to spin up production-like environments programmatically removes problems with testing, integration, competition over shared environments, and a host of other problems.

21st Century Architectural Agility
In terms of governance, the microservices style of architecture has other benefits. Traditionally, enterprise architects defined the shared technology stacks of the organisation to maximise resource usage across projects while minimising support costs. For example, a large enterprise might standardise on Java and Oracle as their primary development platforms. If everyone is using Oracle, then everything can reside in one industrial strength database.

Prescriptive governance does have a downside-often, teams must use tools less than ideal for a certain purpose for the sake of standardisation. But a more subtle downside lurks as well. For example, consider a large enterprise that has chosen to standardise on a particular message queue. When evaluating all the projects that will need this shared infrastructure, the enterprise architects find the most complex use cases and pick a suitable tool to handle them.

However, many of the projects don't have the most complex use case. Yet, because each project must share the same infrastructure, every team takes on the maximum complexity of other teams. This occurs with databases as well. Many projects only need a simple data store for a few records, without sophisticated querying capabilities, yet end up using an industrial strength database server because it is the standard.

Containerisation solves this problem because it moves away from shared infrastructure-each project deploys in their own pristine, containerised environment. Because no impetus exists to choose tools because of sharing, each project picks more suitable tools.

Of course, serious downsides exist if enterprise architects allow each project to choose their own technology stack. We commonly see a practice we've named the "Goldilocks Governance" (where enterprise architects choose a few technology stacks-simple, medium, and complex-and assign new projects according to scale) used in highly decoupled environments. The company still benefits from portable knowledge but steps away from inadvertent over-complication.

Why did we get here?
The book "Domain-Driven Design" by Eric Evans was the other big influence on microservice architectures. This is ostensibly a technique to decompose a large problem space into domains, or the important entities (like customers and orders) and their relationships (customers place orders) and behavior. Part of the definition of the domain was the concept of a bounded context: each domain formed an encapsulation layer around the implementation details.

For example, if analysts identify a Customer domain, it resides within the its own bounded context. Within the Customer context, developers know all the implementation details: class structures, database schema, and so on.


Previous Page  1  2  3  4  5  Next Page 

Sign up for CIO Asia eNewsletters.