The idea of building applications using services has always had appeal. Why code from scratch when you can assemble multiple applications that tap the same services via standard APIs? As long as those services are properly provisioned, you should be able to enjoy tremendous economies of scale.
In the past, attempts at implementing this notion collapsed under the weight of overengineering (particularly the CORBA and SOA trends). But one of the most interesting aspects of microservices -- basically small, API-accessible, single-purpose programs -- is that their use has been a grassroots, developer-driven phenomenon. This time, the services approach has legs.
For a great example of microservices architecture in action, check out this 2014 blog post by Stefan Borsje, CTO and co-founder of Karma, which sells Wi-Fi hotspot devices to consumers. According to Borsje, his dev team "backed into" microservices as it developed its online store:
We started out with one big app in the back end and we split off pieces when it made sense. ... By just going ahead and building the app, we became familiar with the problem we were trying to solve, and the more familiar we were with the problem, the more obvious it was where we needed boundaries between aspects of the app. Every time we encountered something that clearly looked like it should be a separate piece, we turned it into a service.
At first, these pieces were relatively large, but as with other stories of microservices adoption, we've discovered those pieces can be smaller and smaller.
For example, the monolithic app originally had a "store" component, which Borsje's team broke down into order processing, fulfillment, and tracking services. Even the public-facing front end has been split apart into services. Isolating granular functions into independent services has resulted in a major productivity boost, says Borsje, in part because developers don't need to keep all the dependencies of a monolithic application in their heads as they work.
For Karma, the biggest problem with microservices has been testing. As Borsje puts it, "Actions and eventual results are so far from another that it's difficult to see exact cause and effect. A problem might bubble up from a chain, but where in the chain did it go wrong?"
Martin Fowler, the legendary co-author of the agile manifesto who co-authored everyone's favorite explanation of microservices last March with James Lewis, followed up in November by posting a presentation created by developer Toby Clemson that outlined a multilayered approach to microservices testing in considerable detail. Not surprising, Clemson advocates unit testing of individual services, but acknowledges this is inadequate to determine whether the entire system is functioning properly. He helpfully lays out a series of integration, component, contract, and end-to-end testing strategies that should help developers wrap their heads around one of microservices' toughest problems.
Another problem: You can't always predict which microservices may, under certain circumstances, be overwhelmed by demand. I'm sure that's one reason Karma deployed its e-commerce platform on AWS (Amazon Web Services), where autoscaling can help ensure no service becomes a bottleneck by adding horsepower where needed. Note that the microservices poster child, Netfilx, also uses AWS -- in other words, microservices and the cloud go hand in hand. Theoretically you could build your own autoscaling private cloud using VMware or OpenStack, but the difficulty of doing that is one reason the public cloud is winning.
Another more recent technology underlying microservices is Docker, a technology for packaging applications and deploying them in Linux containers. As is turns out, microservices and Docker are a perfect fit -- which is one reason why all the major public clouds now support Docker.
Obviously, no one is saying microservices can solve every problem. But microservices architecture may succeed where other service-based approaches have failed, because it's coming from the bottom up. Developers determine the types of services and their granularity, and as the trend spreads to larger enterprises, teams can decide which services are best of breed for the whole organization.
That sort of ad hoc build-out would have been impossible with the hardwired infrastructure of the past. Equally as important, developers have grown a lot better at collaborating, with a shift in culture that lends itself to creating software architecture organically rather than following edicts passed down from on high.
From what I'm hearing, in many organizations developers are already employing microservices architecture whether management knows it or not. With the right cloud infrastructure, either public or private, microservices architecture can not only boost developer productivity, but also enable the development of new applications that would have been impractical to build before.