On May 31, 1897, Mark Twain was presenting at a speaking engagement in London when he told a reporter that “The reports of my death are greatly exaggerated.” This was over 100 years ago, when death hoaxes could not be disproven by Googling.

In a similar vein, many articles have reported that SOA is dead and will be replaced by microservices which represents the next evolutionary stage.  If true, this is great for microservices and bad for SOA, until you look a little closer to see the truth.  How many times were we told that COBOL was dead, despite Indeed still listing 1,245 job listings today.

The idea still involves making big things out of smaller language-agnostic bits like APIs, and concentrating on business tasks.  Reusability, shared data storage, service-bound and ESB are replaced by lightweight, decoupling and independent data storage, context-bound and a lightweight messaging bus.  Common governance has oriented towards relaxed governance.

Fact-checking is important these days, regardless of whether you agree or disagree with the thesis being presented.  Let’s begin by examining the body – why is it believed that SOA died?  Let’s look at reasons why SOA implementations have failed, realizing that the push towards APIs is not the reason.  Reasons include:

  • Using an ESB to hasten implementation can create a single point of failure.
  • It takes too long to create a runnable end-to-end solutions when you build starting from low granularity.
  • Design-time governance, deployment and operations can weigh it down.
  • The service focus might only appeal to some departments of the company, leading to an incomplete software solution.

Let’s tackle each of these potential causes of death.  While ESB implementations can suffer from the potential for a single point of failure, the likelihood can be greatly reduced through proper SOA testing.  If you lack proper SOA testing, you are undergoing a titanic risk and should best consider outsourcing that skill.  A fault in a microservice, of course, has more finesse in that it doesn’t risk clogging up the master service request manager.

If the granularity is too small, how does microservices help?  This should in fact compound the problem since you’re now starting at an even lower level.  The fact is, mid to large enterprises are better off size-wise using larger pieces, and would suffer by moving to smaller ones.

The microservices gain agility over the larger SOA services is a nice gain, but the overall scope of business tasks must be scaled down in order to profit timewise.  While the governance is looser and the messaging less complex, these are trade-offs that work to balance the complications of working with smaller components.  Scope also extends to the department reach issue.

Microservices isn’t a bad thing, but it is designed to be building blocks for an application, not an enterprise system of applications.  So if you’re putting together a mobile web app, feel free to use a microservices architecture, and if the scope is larger, please consider SOA.

If you’re looking for a job today on Indeed, you’ll do better seeking SOA than microservices, by over a 6-to-5 margin. The employer tipping point still leans towards SOA.