The idea of distributed, componentized applications goes back a long way. Most notoriously, it emerged in the form of the SOA (service-oriented architecture) trend that peaked eight yeas ago. Now, it's back -- as microservices architecture.
Microservices architecture and SOA aren't the same. But the high-level idea stems from the same frustration with monolithic applications, as Martin Fowler explains in a post much more comprehensive than this one. Create your application as a suite of services instead of one tightly coupled monolith of code, and it's easier to change and maintain -- particularly an Internet application that's supposed to be running 24/7. Just refactor and redeploy a couple of services rather than rejiggering and re-releasing the monolith.
[ Work smarter, not harder -- download the Developers' Survival Guide from InfoWorld for all the tips and trends programmers need to know. | Get a digest of the key stories each day in the InfoWorld Daily newsletter. ]
The real benefit shows itself when you consider an entire portfolio of applications: When services are shared, redundant work can be eliminated. Instead of a bunch of monolithic applications maintained by different teams, each duplicating the other's effort, you can compose your applications from existing services already built and deployed by others. Note that this isn't the same as reusing code -- you're actually including a live service as part of your application and tapping its functionality via API. When that service is improved, every application using that service can benefit.
SOA initiatives tended to be a top-down, driven by managers frustrated with multiple, siloed dev teams reinventing the same functionality. From what I can tell, microservices architecture appears to be more of a grassroots developer trend. Developers don't like duplication of effort, either, especially when they're under greater pressure than ever to build more and better apps -- many of them Web and mobile apps with different presentation layers but similar services behind the scenes.
You've probably heard that SOA failed. That's not entirely fair, since it succeeded in some cases -- famously, at Amazon -- but as a trend it pretty much tanked in 2008 or 2009. Why might microservices fare better? Here are a few reasons:
Greater simplicity. SOA grew out of Web services, which were defined by IBM and Microsoft as using SOAP (Simple Object Access Protocol) and XML. Today, SOAP has largely been replaced by the REST (Representational State Transfer) protocol, which is easier to learn and lighter weight. Also, SOAP required the use of XML, which is verbose and hard to work with; REST supports the simpler JSON (JavaScript Object Notation) data interchange standard, which Web developers in particular prefer.
The "micro" difference. In the old SOA days, services could be any size, including lumbering old enterprise apps retrofitted with APIs that too many other apps depended on. A few big software vendors even tried to make their big fat apps the center of "their brand" of SOA, which was nonsense. Although no one has developed a hard and fast size limit for the "micro" in microservices, the basic concept is that each service performs a single function.
Cloud infrastructure. A big problem bedeviled SOA's shared services. To implement SOA, enterprises were advised to find "best of breed" services within their organizations, which multiple applications would share. But when too many apps pinged the same service simultaneously, slowdowns and timeouts resulted. Now that problem has an answer: The auto-scaling functionality of cloud infrastructure.
New container technology. As it happens, everyone's favorite open source project, Docker, could well turn out to be a game changer in accelerating the adoption of microservices architecture. Decomposing monolithic apps into services incurs a lot of operations overhead. Docker and the ecosystem around it, including Mesos and Kubernates, seem well suited to deploying and managing microservices.
Faster, more reliable networks. A big objection to SOA was that distributed services were at the mercy of the network, potentially introducing latency and risk. The laws of physics still apply, but networks are faster and more available today than they were in the 2000s.
Less politics. Here's what really killed SOA: It required major organizational change. The idea was to slice up responsibility for services by business function, which met resistance all over the place. Microservices architecture, by contrast, appears to have sprung up organically as a common-sense way of speeding up application development and avoiding unnecessary work, using simple Internet-native technology rather than bloated big-vendor solutions.
Am I pitching microservices architecture for everything? Of course not. But as the latest iteration of an old idea, it shows promise, and in many ways simply describes the development patterns that Web developers have been employing for a while.