This year's QCon 2015 conference in London was abuzz with talk of microservices, and if you, like me, have seen protocols and standards like CORBA, RMI, J(2)EE and SOAP come (and go), you would be forgiven for sighing and thinking "what's new"? However, it seems that Google, Amazon, eBay and others would beg to differ.
In a nutshell, microservices:
- Are small (they fit in your head)
- Run in their own process
- Are independently replaceable, upgradeable and deployable via automated/test deployment mechanisms
- Are backwardly (and forwardly) compatible
- Communicate with each other via lightweight mechanisms, typically an HTTP resource API
- Are organised around business capabilities. "Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure." -- Melvyn Conway, 1967
- Involve products, not projects
- Require decentralised governance
- Require decentralised data management (independent persistence)
- Automate their infrastructure (e.g. AWS)
- Are designed for failure of dependent services
- Prefer asynchronous calls to synchronous ones
- Involve evolutionary design
- Are fully developed, owned and supported by single teams
- Compete with each other in a market-place
Much of this will be familiar, but what is new and very interesting is the degree to which microservices apply the familiar principles of loosely-coupled, encapsulated software components to the organisation developing and managing those components.
Traditionally structured companies will balk at all of this, and perhaps dismiss this as yet another architectural fad, but I'm not so sure. Check out these two excellent videos on Spotify's Engineering Culture.
Further reading:
Traditionally structured companies will balk at all of this, and perhaps dismiss this as yet another architectural fad, but I'm not so sure. Check out these two excellent videos on Spotify's Engineering Culture.
Further reading: