There's a never-ending tug of war taking place within enterprises. On one side is the constant urge to centralize, and thus better control, applications and services. On the other, the move to free up applications into truly loosely coupled, independent services that can be rapidly called and mapped to whatever business process is required at the moment.
Perhaps it's time to revisit the idea of a business built on highly distributed services that aren't anchored to particular platforms, departments, or fiefdoms. This is especially urgent as enterprise teams find they are running into roadblocks as they attempt to move parts of monolithic applications to the cloud.
Enter the "microservice" architectural approach. In a recent post, James Lewis and Marton Fowler, both of ThoughtWorks, take a close look at this emerging style of IT architecture, and how it may help deliver on the promise of highly independent services.
A microservice architecture tends to be based on RESTful services that are built and operated by cross-functional teams and are intended to be completely independent of underlying platforms and applications. It is a style of software systems "that we are finding more and more appealing," Lewis and Fowler write. It describes "a particular way of designing software applications as suites of independently deployable services," with a strong emphasis on decentralization.
The ThoughtWorks leaders explored what distinguishes microservices from more traditional centralized enterprise applications -- here is a brief summary of some of their key points: (A more detailed examination is available on Martin Fowler's website.)
Componentized via services: Many applications tend to have multiple libraries within a single process, and thus changes in components mean having to redeploy the entire application, Lewis and Fowler write. A microservice architecture employs out-of-process services to communicate requests, versus libraries "that are linked into a program and called using in-memory function calls." Service calls are entirely independent of the application being called.
Organized around business capabilities: Lewis and Fowler observe that changes to services often occur along functional lines -- for example, a UI team, database team or server-side team will tend to "just force the logic into whichever application they have access to." A microservice approach is based on services built by cross-functional teams to support the business's products and services, not the other way around.
Products not projects: Taking the business capability discussion a step further, Lewis and Fowler note that these cross-functional service teams should "own" specific products over their full lifetimes. "A common inspiration for this is Amazon's notion of 'you build, you run it,' where a development team takes full responsibility for the software in production," they observe. Software and service development doesn't end once deployed; teams maintain on ongoing relationship with the business side to manage and keep improving the software.
Smart endpoints and dumb pipes: The microservice approach is highly decentralized, eschewing the developed middleware approach -- such as enterprise service buses that support centralized message routing, choreography, transformation, and applying business rules, Lewis and Fowler explain. Alternatively, the approach favors a lightweight message bus. The bottom line, they say, is that "applications built from microservices aim to be as decoupled and as cohesive as possible -- they own their own domain logic and act more as filters -- receiving a request, applying logic as appropriate and producing a response."