The Arc-E-Tect's Predictions for 2017 - Microservices and SOA [1/10]

The Arc-E-Tect's Prediction on Microservices

It's 2017, meaning 2016 is a done deal, and most of my predictions for 2016 (I predicted them about a year ago, but never got around documenting them in any form) have proven to be absolutely bogus. Which leads me to come up with my predictions for 2017 and properly document them. So continue your effort reading this post and hopefully you'll enjoy reading them. Unfortunately we'll have to wait for about a year to find out to what extent I got it all right, but for now, ... Microservices!

Why Microservices? Because they're not just a hype anymore, but are moving into the realm where people are applying them because they're useful and not just cool. So my prediction is:

Microservice in, SOA out

That's right. In 2017 people will start looking at Microservices as something that is useful and way better to have in your architecture than services. So a Microservices Architecture will replace Service Oriented Architectures in 2017.

What does this mean?

Well not that much at first, until one realizes that an important reason for SOA, the DRY principle is no longer valid. DRY, Don't Repeat Yourself, is an important aspect of procedural programming that got more attention in object oriented programming and became one of the even more important aspects of SOA.

In procedural programming developers introduce procedures to have a single implementation of an algorithm or procedure. By calling that procedure over and over again instead of programming it over and over again, the developer reduces the chance for errors in the code.

Then came object oriented programming and procedures, methods, were clustered together in classes to ensure that concepts and their behaviour only had to be programmed once and used often. It's a flaky definition, but covers my intention. So re-use was immensely important for object oriented programming and this is where DRY became an important architecture principle, even a pattern.

After some time, developers started moving towards services, web services that is. In OO, Object Oriented, there's a great practice to separate the interface to a class' methods from their implementation. Depending on the programming language you use, you'll use a variety of techniques to accomplish this. In an SOA, and yes, I'm a bit short on the elaboration here, we separate the implementation of a service from the interface to access it. But the whole idea is that you implement certain functionality only once, the service, and use it from around the world. By sticking with the interface you can change the implementation without affecting the callers of the service.

So in SOA, Service Oriented Architectures, re-use is huge and DRY is a pattern.

Here come the Microservices. Microservices are not tiny services, instead they are completely self contained pieces of business concepts. They're independent of each other. They can use each other, they can rely on one another, but they don't depend on each other. That's a key principle of Microservices. It also means that if both use the same algorithm or other functionality, they both implement it. Meaning that the code is not reused! Because if one would reuse parts of the other, it would depend on it. So, in a Microservices architecture, DRY is an anti-pattern.

In 2016 everybody started doing Microservices, but actually they implemented an SOA and called it a Microservices architecture because SOA was, well, old school. An SOA has become something tainted because for one most enterprises confuse an SOA with an architecture build around an ESB and they're strengthened in their belief this is correct by the ESB vendors. Which is of course just marketing horse dung as you can read here. In addition, SOA's have hardly ever delivered what vendors and architects promised: Agility, lower costs of change and independence of clients (consumers) and servers (producers). Why? Because ESB's and by association SOA's make architectures more complex and harder to change although they hide their complexity inside the products, making them look less complex. But ask yourself: Did you ever try to migrate from one ESB (version) to another? 

So we drop the SOA and brought in the Microservice to attract new developers.

Fortunately, Microservices are hard and costly to develop and maintain. From day one. Therefore all adopters of this new and shiny architecture had to reconsider their choice to move to this new architecture at a very early stage. Realising that understanding is more important than knowing and none of the vendors had a ready out-of-the-box Microservices solutions that they could sell, the level of knowledge and understanding is already in 2017 such that Microservices will start to replace SOA's.

In 2017, companies will drop service oriented architectures in favour of Microservices architectures instead of implementing SOA's with Microservice look-a-likes.

Thanks once again for reading my blog. Please don't be reluctant to Tweet about it, put a link on Facebook or recommend this blog to your network on LinkedIn. Heck, send the link to my blog to all your Whatsapp friends and everybody in your contactlist.
But if you really want to show your appreciation, drop a comment with your opinion on the topic, your experiences or anything else that is relevant.

Iwan