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.