Are you interested in automated testing? If so, become a member of the Java Testing Society!

The Microservice Architecture Sounds Like Service-Oriented Architecture

service-oriented architecture

I didn’t understand the service-oriented architecture. I thought that it was just one of those highly theoretical and very impractical software architecture patterns.

In other words, I considered it to be an architecture fanatics’ wet dream.

Then I read an article titled Microservices by Martin Fowler, and the service-oriented architecture started suddenly make sense to me.

What Changed My Mind?

Martin fowler specifies the microservice architecture as follows:

In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare mininum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

After I read that, something clicked inside my head. I realized that the microservice architecture sounds a lot like the service-oriented architecture which is specified as follows:

Service-oriented architecture (SOA) is a software design and software architecture design pattern based on discrete pieces of software providing application functionality as services to other applications. This is known as service-orientation. It is independent of any vendor, product or technology.

A service is a self-contained unit of functionality, such as retrieving an online bank statement. Services can be combined by other software applications to provide the complete functionality of a large software application.

Why didn’t I get this sooner? I think that there are two reasons for this:

  1. I am not a big fan of fancy architecture diagrams and technical gobbledygook, and these are the tools which are often used to explain service-oriented architecture. I guess you could say that I couldn’t see the forest from the trees.
  2. Most of the applications which I have created during my career have been “normal” web applications. In other words, the user interface shown to the user is rendered in the backend. Using service-oriented architecture in these applications didn’t make any sense to me because it was simpler to add everything to the same binary.

The rise of single page web applications has had a major impact to my thinking. When the backend provides a REST API to the frontend which decides how the received information should be rendered, the service-oriented architecture starts to make sense because it has the following benefits:

  • We can divide the application into discrete pieces. Each piece fulfils a specific need and have their own domain-specific language.
  • We can scale only those parts of our application that require more resources.
  • We can deploy individual services instead of deploying the whole application.
  • Different services don’t have to use the same programming language. In other words, we can use the best tool for the job.
  • Different services can be created (and maintained) by different teams.

The service-oriented architecture isn’t a silver bullet but it offers solutions to the problems caused by the monolithic architecture.

There are two problems which bothers me the most:

  • It is damn hard to organize the code into modules which don’t have dependencies with the other modules of the application. Although I think that this isn’t the fault of the monolithic architecture, it is still a problem found from most monolithic applications (if you use Spring, you have other problems too).
  • The language of the monolith is often full of compromises. I confess that I am a bit obsessed about domain-driven design and I would love to use its full power in my work. However, it is hard to do this when all code belongs to the same monolith which have to fulfill different business needs which have different vocabularies. Maybe this is one reason why enterprise applications often use very generic and confusing language.

Maybe I am a bit too enthusiastic about this but it is safe to say the service-oriented / microservice architecture has finally made its way to my toolkit.

The Name Doesn’t Really Matter

The service-oriented architecture might have a bad reputation because it sounds enterprisy, and everyone knows that enterprisy is a bad thing (at least in hipster circles). Maybe that is why some people have started to call it the microservice architecture.

Or maybe I don’t really understand the service-oriented architecture, and that is why I cannot see any difference between it and the microservice architecture (this is probably true).

Because I am not an architecture consult, I don’t really care what the name of this architecture style is. All I care about is that I found a new way to solve some of the problems caused by the monolithic architecture.

About the Author

Petri Kainulainen is passionate about software development and continuous improvement. He is specialized in software development with the Spring Framework and is the author of Spring Data book.

About Petri Kainulainen →

13 comments… add one

  • For me the thing that comes to mind with SOA is all the outdated and over engineered ESB products that big vendors try to sell which require me to use all their horrible proprietry service orchestration, discovery and security extensions to a plethora of standards each competing in XML hell. Feels like Dante’s inferno.

    For me Micro services seems to promise a simpler more decoupled view with more emphasis on distributed event handling using simple well known things like http and atom rather than the Soap RPC style we often see in current enterprisey systems. I think the key thing will be identifying which tasks it is best suited and as always what are the trade offs that I need to appreciate. There is a lot of miracle hype at the moment and some of that needs to subside although I’m optimistic as it potentially reduces complexity and if we are lucky could remove a lot of big enterprise vendor crap at the same time.

    • I agree with you. It seems that I had forgotten the dark side of SOA. Although I suspect that you can use SOA without using these complicated legacy products. The thing is that the consults who sell these products are damn good salesmen (their bonuses depends from it). I have listened a few such presentations in the past, and I must admit that they can be very convincing.

      If the architect / manager has lost his touch with the reality, he might very well make a mistake and believe these snake oil salesmen. It is too damn easy to make decisions when you don’t have to deal with the consequences of your decisions every day.

      Also, after an architect / manager has bought an expensive enterprise platform, everyone must use it because that person doesn’t want to look bad in front of his managers or colleagues.

      Enough with ranting.

      I agree that the microservice architecture emphasizes simplicity over complexity (and vendor lock-in). Maybe that is why I noticed it in the first place.

  • I still fail to see how SOA, micro-services, etc are fundamentally different / novel from EJB, CORBA, mainframes and lots of other tech that came before. Essentially, we have always created “services” (i.e. API) to decouple / render reusable parts of complex systems…

    • It seems that you are not the only one.

      Maybe the biggest benefit of the microservice architecture is that it is not called SOA? Like Magnus said, SOA brings back bad memories for many developers.

      • I’m interested in this from a service discovery point of view. If we have a universe of loosely-coupled, independently-deployed services that each “do one thing well”, how can I discover them?

        For example, I’d like to walk up to the network and ask: “Give me an endpoint that implements the live Customer search service version 2″.


        • I think that this blog post answers to your question a lot better than I ever could.

        • Eureka… of the netflix variety…

    • Here’s how I’ve come to understand it. If anything below the service-layer is shared, you’re not doing SOA. The entire point is that the top-level decomposition of your system (i.e. its architecture) is into services. That means each has its own individual set of layers. Even something as simple as sharing a database gives you a layer-oriented architecture.

      Imagine an accounting system with payables, receivables, and banking services. Using SOA, each would have its own private domain and persistence components. You might have, for instance, three relational databases. They could all be on the same server or not. What’s important is that they are separate, thus allowing them to diverge should the need arise.

  • I am excited about implementing this architecture in my application. Ours was an monolithic application based on Spring web flow’s. We used to put one web flow in one module. A module had a flow, xHTML’s, controllers, etc. Later we changed the UI and added REST services to it. Broke modules into two parts- client & server. Now server side module has controllers which intereact with back-end systems and provide JSON’s to client side. Server side modules have now microservice architecture. Ours a valid case of microservice architecture.
    But now I have doubt why we wrote a monolithic application at the very first time?
    Should all monolithic applications be converted into microservice architecture ?

    • One reason why we write monolithic applications is that this is they way Spring apps have been traditionally implemented, and that is why the monolithic architecture is often the first thing that comes to mind when we start a new project. There is no need to feel bad about it though. When we get more experience and learn new things, we realize that there are other options as well.

      However, I don’t think that we should start rewriting the existing monolithic applications. The problem is that it takes a lot of time and the customer isn’t probably going to for it unless it has a clear business benefits. Of course if there are performance problems in some area of the application, it might make sense to rewrite that area to use the micro service architecture.

  • “The rise of single page web applications has had a major impact to my thinking. When the backend provides a REST API to the frontend which decides how the received information should be rendered, the service-oriented architecture starts to make sense because it has the following benefits”

    Not sure on how single page apps affected SOA or microservice at all. If you have 100% ajax app, it means only one thing – you build your user interface on client side(given that you don’t duplicate/have business logic on client side in java script which is poor design itself).
    I guess there is no diff between SOA and Microservices. The Microservices has scope that much broader then SOA, I would even say that it include SOA in itself.

    • Not sure on how single page apps affected SOA or microservice at all.

      You are right. Nevertheless, they have had a serious impact on my thinking for the reasons I mentioned in the blog post.

  • Hi Petri

    How one should deal with security concerns (authentication & authorization) in MSA ? Lets say I have some RESTful micro services interacting with each each through AMQP as mediator between them. How can I use Spring Security to authenticate and authorize my requests to micro services.


Leave a Comment