Microservices Architecture (MSA) is Nothing but Evolved SOA

DZone 's Guide to

Microservices Architecture (MSA) is Nothing but Evolved SOA

If you are a professional involved in the enterprise IT domain, there is a good chance that you have heard the term "microservices". Now, let me tell you why MSA is nothing but SOA in a proper, evolved state.

· Integration Zone ·
Free Resource

If you are a professional involved in the enterprise IT domain, there is more of a chance that you may have heard the term "microservices". In your organization, there will be many people talking about this and you may already have read lots 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 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, the technology industry does not allow you to settle down. It does not care about your money or time, it will keep on throwing new concepts and jargon into the picture. Microservices is that kind of thing which you have come across recently. With this blog post, I want to show the people who have spent most of their budget on SOA adoption, that they 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 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 describe 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, those are some sets of features which you need to be alarmed if your system doesn't have them. 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 the first place, you may not encounter this issue. The fundamental concept of SOA is to modularize your systems into independent services which cater 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 depends 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 if you are using MSA or not. If you design your services in a proper way, you can work in 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 designed 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 microservices architecture but a 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 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 the worst conclusions you have ever made and it will not work in your enterprise. If you need further information on that, you can read the following links.


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

integration, microservice architecture, microservices, soa

Published at DZone with permission of Chanaka Fernando , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}