Microservices explained - is this just tweaked SOA or something much bigger
It's an impressive list but in truth it could extend for several paragraphs. Indeed, it would be easier to say who is definitely not using microservices that who is, some without particularly seeing this as a special innovation. It's just programming in a world adjusted to the idea of constant conceptual innovation and change. People started doing this a while ago but now it has a name.
Every microservices FAQ states somewhere that it is an alternative to the monolithic approach to building applications that has until recently been the predominant development model. In this approach, applications are built as single entities, with the client (e.g. the browser) a server and a relational database cooperating using a flurry of HTTP requests output through HTML. This is still how the majority of applications are built today but it has issues. The linearity of monolithic applications scales quite well - just add more processes in parallel and then load balance. But such applications can be incredibly complex to change with small adjustments affecting the entire application in unexpected ways. Things break, development slows and expense rises.
Conceptually, microservices are a simply way of doing the job of a single application using a series of smaller specialised ones communicating over agreed interfaces. It's not an entirely new idea and is an evolution of mostly proprietary component models that have gained traction over the last 20 years including bearing a passing resemblance to the bare bones of Service Oriented Architecture (SOA). However, it is not an agreed architecture with a defined set of frameworks and it better thought of as a new conceptual approach to building and deploying applications to deliver specific advantages.
Despite sounding similar, a microservice is not a software component, a model in which a program is broken down into logical units performing functions and accessing shared libraries. Microservices are complete, autonomous, independent services that work as standalone units and can be programmed in any language and managed separately. Put these units together and you have a microservices application in which the different pieces communicate through APIs and REST interfaces such as HTTP.
Beyond the computing science jargon, the advantage of this approach is that it allows complex web applications to be developed by different teams without the danger that either will disrupt the other. Changes to a microservice never risk bringing down the others cooperating in the larger workflow. It also scales far more efficiently than simply firing up a new instance of a monolithic application because it allows the specific microservice needed to be scaled individually. In theory, this offers big efficiency gains for cloud applications based on virtualised infrastructure.
But is it really as simple as this A common criticism is that microservices ends up looking like a reheated form of Service Oriented Architecture (SOA), albeit more defined than SOA ever was. It is also not clear that applications built on microservices architectures are mature enough to make fine judgments about their strength over time. Further objections were made by ThoughtWorks in an influential article on the topic published in 2014:
"In any effort at componentization, success depends on how well the software fits into components. It's hard to figure out exactly where the component boundaries should lie," wrote Martin Fowler.
It's a valid point. Exactly which microservice should do what is not easy to state independent of a specific project. Put another way, microservices will vary from implementation to implementation.
"Another issue is If the components do not compose cleanly, then all you are doing is shifting complexity from inside a component to the connections between components. Not just does this just move complexity around, it moves it to a place that's less explicit and harder to control," continued Fowler, who went ton to fret about the possibility that microservices could also be implemented badly by weak teams lacking experience.
These are the words of a microservices fan and so it's not hard to imagine that there are also sceptics out there who believe the whole idea is just a reheating of established principles in a new guise. Software development architectures seem to be prone to these complex controversies. What microservices aren't is a simple in situ replacement for monolithic applications.
In the end, the best argument for microservices architectures are the companies using it in real applications, assuming one accepts that so many diverse implementations can be satisfactorily filed under one label. Poster kids for this include Netflix, which describes how it has used microservices to optimise performance. Another big fan has been music site SoundCloud, which migrated to a microservices way of looking at the world after starting in with monolithic applications.
A key feature many microservices-oriented firms have in common is that they are new, or the systems they have built using them are recent. Oddly, many seem to have been using them long before anyone called them microservices. This tells us that the term is like every other term to hit software development since the beginning of the modern era of business - it's always more evolution than revolution.