Where Are We Now?
Micro Services are all the rage right now.
Everywhere I go, every architectural discussion I’m taking part in, every conference I’m registering, is flooded with Micro Services.
“How to migrate your monolith (read: pathetically old and outdated) application to a Micro Services architecture?”
“Kubernetes vs Mesos vs Consul – Let the battle begin!”
“Organize by Dockerize”
You get the gist of it…
And that makes me a little bit itchy.
Now, don’t get me wrong. Micro Services is truly a great concept. It DOES make your application more modular. It DOES make updating the various components independently easier. It DOES allow you to use various technologies in your app.
We Were Here Before
But…
It’s not new.
Like, really really not new.
Actually, it was here since the nineties, but no one called it Micro Services. Back then, when Windows 95 was still considered the bleeding edge of technology and Netscape was the most-used browser, the term “Service Oriented Architecture” was born.
Let’s take a look at a typical SOA diagram, which was very common back in the day:
As you can see, this diagram shows all the basic elements of a SOA implementation in an organization:
- The various apps are exposed as a Service
- There is a Service Registry, which stores the location of the various services
- And there are, of course, the clients
When a client needed to access an app, it would access the Registry, get the desired service’s location, access the Service via SOAP or REST, and call it a day.
Over time many elements were added to the basic SOA concept, and we all remember the monstrosity that is ESB, but the basic gist stayed the same.
And We Failed
But…
SOA has failed. Badly.
It really had a great promise, and the benefits it brought to the table were substantial, but two factors pulled it down:
- High Up-Front Costs – Remember the ESB mentioned earlier? Those beasts where very expensive, required dedicated workforce, and positioned themselves as a Must-Have in any SOA-enabled organization.
- Organization Politics – For a SOA architecture to work, the organization’s applications will have to be exposed as a service. For this to happen, the project managers have to invest more in their project. And this is where the problem begins – the project manager needs to invest in HIS application, so that OTHER applications will have easy time accessing it. Am I the only one sees the conflict of interests here?
And from the ashes of SOA, took off the Micro Services era. Because, in reality, Micro Services is just an evolution of SOA, in an Application scope instead of Organization scope.
Take a look at a typical Micro Service diagram:
See the similarities to the previous diagram? Basically, I just changed the title from Organization to Application, and that did the trick.
Let’s Compare!
To finalize this topic, let’s take a look at the famous Martin Fowler’s article about Micro Services, and see which of the characteristics depicted there are relevant for SOA:
Characteristic | SOA? |
Componentization via Services | Yes, at the organization’s level. |
Organized around business capabilities | Sure! |
Products not projects | Sort of. It’s more a matter of the organizational’s terminology. |
Smart endpoints and dumb pipes | Definitely not. Remember the ESB mentioned above? This is where we get rid of it. |
Decentralized Governance | Yes. Although there were some tools aimed to centralize the services’ governance, it was never considered a best practice of SOA. |
Decentralized Data Management | Yes. Usually every service had its own data source. |
Infrastructure Automation | Not Applicable. The automation mechanisms back in the day were not nearly as advanced as we have today. |
Design For Failure | Yes. Clients were required to handle gracefully when services failed. |
Evolutionary Design | Yes. Organizations were encouraged to migrate to SOA gradually. |
So what’s my point?
Micro Services is not the second coming. We’ve been there, we’ve done that, we had our successes, we had our failures, and Micro Services is yet another step in the evolutionary process of software architecture.
Think otherwise? Let me know in the comments!