Why Micro Services Architecture (MSA) is nothing but SOA in a proper, evolved state

If you are a person who is in the enterprise IT domain, there is a more chance that you may have heard the term "mircoservices". In your organization, there will be many people talking about this and you may already have read lot of material on this term. First of all, it is a great idea and if you can use those concepts in your enterprise, that is pretty good. So then, what is this topic all about?

Let me explain a bit about the topic and the message I want to spread. If you are an old enough IT professional, you may have gone through the hype of SOA and might have been adopted that in your enterprise. After spending millions of dollars and years of engineering time, now you have a solid SOA adoption and everything is running well (not perfect). As you know, technology industry does not allow you to settle down. It does not care about your money or time, it will keep on throwing some new concepts and jargons in to the picture. Micro services is that kind of thing which you have come across recently. With this blog post, I want to show the people who has spent most of their budget on SOA adoption, that you don't need to worry about the MSA hype. You are already doing that and it is a seamless transformation from where you are and where you need to go with the MSA (if you want to go that way).

I will start with a list of things that people tell about the existing SOA architecture and describes as advantages of MSA.

• Applications are developed as single monoliths and deployed as a single unit
• Utterly complex applications due to many components and their interaction
• Even hard to practice agile development strategies due to tight coupling
• Hard to scale parts of the application since entire application needs to be scaled
• Reliability issues with one part of the application failure may cause the entire application to stop functioning
• Startup time is minimal, since we don't need to startup fully fledged servers

Well, that is a some set of features which you need to be alarmed if your system is not having. Does that mean that you need to scamper through and collect all your resources to work and learn about MSA? Before doing that, let me explain how you can improve your existing system to fulfill these requirements without knowing anything about MSA (I'm not saying you shouldn't learn about it).

Applications are developed as single monoliths and deployed as a single unit

If you have followed the SOA principals in first place, you may not encounter this issue. The fundamental concept of SOA is to modularize your systems into independent services which caters specific requirements. If you have developed a single monolith with all the capabilities, then go and fix it. This is nothing new from MSA. it was already there and you have not executed properly. If you need to deploy these services in separate servers, you could have done that. But there were no concepts like containers back then and you didn't want to waste one server for one service. The container based deployments are not coming from MSA and it is already there and you can utilize that with your existing SOA services.

Utterly complex applications due to many components and their interaction

This is something you cannot get rid of even if you adopt MSA. It really depend on the capabilities of your application and the way you have developed and wired different components. You can revisit your application and design it properly. But it is irrelevant to SOA or MSA.

Even hard to practice agile development strategies due to tight coupling

Coupling between different services is utterly a design choice and it will be there no matter you are using MSA or not. If you design your services in a proper way, you can work on an agile way.

Hard to scale parts of the application since entire application needs to be scaled

This is again a design choice which you have taken in the past to couple the different services and deploy them in the same server. If you could have design it according to the SOA principals and if you had container based deployments, you may have not encountered this. Nothing coming from MSA.

Reliability issues with one part of the application failure may cause the entire application to stop functioning

Once again the idea of container based deployments and proper design of your services may have fixed this kind of issue.

Startup time is minimal, since we don't need to startup fully fledged servers

Nothing specific to MSA. Container based deployment and server less applications could have fulfilled this requirement. 

All in all, by considering the above facts, we can see that, there is nothing much coming from this micro services architecture but set of things which were already there in SOA and new concepts like container based deployments are represented as a concept and with a special word. I don't have any intention to criticize the term and the importance. What I wanted is to tell you is that, there is nothing much you need to change if you are already doing SOA in your enterprise and willing to adopt MSA. 

One last thing I wanted to mention is that, sometimes people think that they don't need the integration layer once they have the MSA in place. That is one of worst conclusions you have ever made and it will not going to work in your enterprise. If you need further information on that, you can read following links.

References:

[1] https://blogs.oracle.com/integration/entry/microservices_and_the_integration_platform

[2]http://kasunpanorama.blogspot.com/2015/11/microservices-in-practice.html