Episode #4: “SOA vs Microservices Architecture”

SOA Myth Busters – Episode #4: “SOA vs Microservice Architecture”

So, are you interested in SOA & Service Orientation technologies?, that’s great because we also are, and work with those every single day since a long time ago. As integration professionals, we’ve seen the SOA stack grow, change, incorporating new products and technology with each passing year.

We’re  Arturo Viveros and Rolando Carrasco, the SOA Myth Busters from Mexico, and as we go with this series we will  put to the test a number of questions, myths and urban legends regarding SOA, Digital Transformation and much more, in seek of finding out which myths are true and which are not.

Introduction

Microservices Architecture is one of the disruptive technologies which have definitely taken center stage in these early days of the Digital Transformation era. Its fundamentals and value proposition are very appealing and in context with many of the architectural and functional needs of modern platforms and initiatives, so let’s begin by taking a quick overview:

ed deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies”“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 automat

The above definition by Martin Fowler is fairly simple and at first sight doesn’t really introduce any extraordinary or revolutionary concepts. However, the best way to understand this architectural style as well as its differentiators and potential benefits, is contrasting it to what we may call traditional “monolithic” architectures:

With the term “monolith” being one of the most dreaded in IT lore, the design principles for which Microservices stand for become even more impactful:

As we can infer from the image above, the Microservices approach (right) focuses a lot on componentization, scalability and autonomy, among other things, as opposed to a Monolithic application (left).

Before going on with the article, it’s very important to remark that we’re talking about design approaches here, which will lead to the realization of solutions with certain distinctive characteristics. This is absolutely independent to the technology of choice, so we can avoid falling into the “I’m using the XYZ platform/framework/programming language, therefore I’m producing Microservices” trap.

So, as we usually do, let’s ask ourselves some questions and try to answer them as soundly as possible based on our experience and the facts at hand:

What makes Microservices so “disruptive”?

Basically, this would be directly related to what they’ve brought to the table in the context of Digital Transformation:

“Digital transformation refers to the changes associated with the application of digital technology in all aspects of human society”

So one of the best things about Microservices, is that in their purest form they would pretty much mimic the kind of “Services” people are generally striving for in their increasingly digital-driven lives:

• Lightweight
• Self-Contained
• Autonomous
• “Pluggable”
• Replaceable
• Scalable
• Context-Aware
• Etc.

All of these are “qualities” which we would seldom associate with the traditional notion of a “Service”, particularly a SOAP-based web service, so the “Microservice” nickname has been a clever way to differentiate this architectural style from the increasingly-maligned WS stack.

Ok, yeah, but what about SOA?

As we have already stated, the Microservices value proposition is fairly easy to understand. However, when we begin to analyze and go beyond the buzzwords, we will surely notice that a lot of it is very much in line with the Service Orientation design  principles which have been around for quite some time (and provide the basis for Service Oriented Architecture). Let’s take a look at some of those:

The thing here is that these design principles are not absolute, nor is it possible to implement them all at 100%, so while most SOA implementations traditionally have tilted towards attaining:

• Standardized Service Contracts
• Reusability
• Composability

Microservices implementations commonly tend to focus more on:

• Loose Coupling
• Autonomy
• Abstraction

There’s of course much more to it and we’re not even close to being done, but the bottomline here is that we’re still talking about service orientation, and looking to realize common goals such as: organizational agility, business and technology alignment, reduced overhead, revenue of investment, increased federation, etc.

Can SOA be Monolithic?

If we were to stick with it’s purest definition, then it couldn’t and shouldn’t be. Nevertheless, when it comes to the practice, many solutions which were born and labeled as “SOA” initiatives, have been challenged over time by many factors and not always produced the desired outcome.

Moreover, some remnants of those train-wreck projects form the SOA first era (some 10 years ago) still dwell on IT ecosystems and could even be called “Legacy SOA”.

So yes and no, as asking this kind of question is really a matter of differentiating between SOA as an architectural style realized by applying service orientation principles to a meaningful extent, or as a moniker which can be associated with any kind of product and/or solution regardless of its level of compliance to those principles (or total lack thereof).

So, are Microservices “The Answer”?

It’s fair to say that Microservices have really hit the nail in many senses and thus started off with a bang, producing some incredible success stories and compelling very high profile organizations to embrace them. Nevertheless, those with enough experience in IT Development and Architecture, should agree that when it comes to information technology there has never been a panache and probably never will be.

On the other side, it’s only logical that many people lately have jumped off the SOA bandwagon and into the Microservices one, as a new and appealing technology will always offer what human nature craves so much: burying a suspect past and starting anew.

Definitely Microservices got off to a much better start than what SOA managed in its beginning, which is really good news for Service Orientation as a whole, but that doesn’t mean that there won’t eventually be failures, challenges and pitfalls as well.

As Architects, we ought to take advantage of the momentum for sure, but we most also learn from the past and be responsible enough not to raise false expectations among our customers / organizations or even guide them off a cliff by being reckless instead of assertively disruptive.

Does this mean SOA is close to done?, or can it still be effective?

Sometime ago we had a conversation with a colleague from a country in Latin America. He told us that he was leaning towards a Microservices Architecture as opposed to SOA for a new system, but wanted our opinion.

So we asked him back: can you describe your business case?, what are the main purposes of this system and which strategic goals are being pursued? He responded: that’s not clear yet but we want to use Microservices because we have read in many places that SOA is pretty much dead and its development process is not as fast as with Microservices.

Interesting answer but yet not a right answer. We’re saying interesting, because it is amazing that many people are still getting caught up in this discussion. The “SOA is dead” internet-driven trend is almost 10 years old now, and totally out of context for the time being, so it is very important that the decisions we make and the conclusions we jump to are based on actual facts, experiences and case studies.

For SOA, something that really makes a difference today is the extent, quality and overall strength of the bodies of knowledge developed around it. This includes design patterns of course, which as their name implies are proven solutions to common problems. Some examples to boot:

http://www.soapatterns.org

http://www.soa-manifesto.com/annotated.htm

http://www.oracle.com/technetwork/articles/soa/ind-soa-toc-1934143.html

Furthermore, the principles and strategic goals championed by SOA have become increasingly appealing to many organizations in the eve of Digital Economy, whether it is at an Enterprise level or at a departmental/project level. So it is kind of silly to think about SOA as a bad idea, or as an antique strategy.

As we already explained, while the “old” brand of SOA could be called many things like “monolithic”, “dysfunctional”, “etc.”, Industrial / Contemporary SOA  has proven to be one of the most effective and disruptive Architectural styles, becoming an accelerator of several digital transformation strategies as well as a launching platform to build and expose web APIs.

But there is so much fuzz about Microservices and its success stories, does SOA have anything similar to boast about?

Imagine a powerhouse TELCO company who wants to increase and diversify its revenue stream by enabling MVNOs (Mobile Virtual Network Operators), or a Financial Institution who intends to do B2B and brokerage in multiple countries (thus needing a 24/7 operation).  Can you figure out what is running behind the curtains in their IT ecosystems to make these endeavours possible? Those are real cases, award winning projects where a well established SOA implementation and discipline provided the framework for embarking into an ambitious process to move from their legacies and mainframes to a much more agile / dynamic architecture.

Intelligent and successful organizations will strive for governance and maturity while fostering innovation and looking into disruptive options at the same time (a bi-modal approach).  There are many ways to achieve this without compromising the benefits of the discipline. Some examples out of our own experience:

1. Automated provisioning / optimized infrastructure deployment: Nowadays with the usage of tools like Puppet, Ansible, Chef, Docker, we can pretty much automate the provisioning of any kind of Service (any vendor) and streamline the  long cycles of installation, deployment, tuning, etc., adding also scalability, resiliency and many other qualities to our service inventories and making SOA projects more agile and feasible to complete in time.
2. API Management: An organization which is looking to go into this Digital Transformation, needs to promote the usage of APIs. One way to do it is to unlock your current SOA assets and present them as managed APIs for external consumers.
3. Implementing a Microservices ESB, where the design pattern is cleverly leveraged to provide common ground for SOA Services and applications being built with the Microservices philosophy.

Is it possible for these two approaches to coexist in the same ecosystem?

Definitely, and we’ve already mentioned something in the last paragraph. If there is already a SOA platform in place, but for any reason the organization has opted to start building microservices (or viceversa), then it is a good idea to make both approaches coexist.

How is that going to happen? Let’s keep in mind that both SOA and Microservices are defined at their core by the Service Orientation principles, so there must be a good level of intrinsic interoperability there, enhanced also by the tools, technologies and standards we may be using to implement one or another.

Let’s take a look at the following image taken from an article by our good friend Luis Weir:

Reference: http://www.soa4u.co.uk/2015/04/a-word-about-microservice-architectures.html

In this case an ESB provides a way to expose & communicate some of those microservices, while also avoiding the “micro-silo” pitfall. Without this bus, those microservices will be isolated with challenges to communicate with each other, compromising interoperability, transport and transparency within a distributed architecture.

Conclusion

So now that we’ve dealt with those questions, let’s summarize and make some conclusions before wrapping this up:

• The monikers and buzzwords can sound great in paper, but they also can foster confusion and mislead people to jump into precipitated or altogether wrong conclusions, so it would be recommendable to understand the fundamentals of Service-Orientation before choosing an architectural style and/or the combination of design principles and patterns which will better suit our organization’s requirements and strategic goals.
• It has been common for Architects and Developers to shift from design patterns, technology, etc. with relative disregard for fundamentals and continuity, but in order for our technology platforms to mature we must avoid this impulse. Learn to innovate without throwing out the window what you have learned, achieved and deployed with so much effort.
• Try to be disruptive but not just for the sake of it. Rely on architectural blueprints, methodologies, discipline and technology which can effectively streamline your development, deployment, maintenance, provisioning, troubleshooting, etc. The ultimate goal is to be able to respond faster to change while remaining in context with what the business and the customers require. If you’re achieving that through Microservices , SOA or both, then you are on the right track. And again, be smart and do not force the issue, because that will rather disrupt your organization’s stability and probably your own work.
• Study, read and learn from your own mistakes. A colleague once said: to succeed with Microservices, you need to suffer them. That is very true. But not just with Microservices, but with any other discipline.

We certainly hope that this body of work has been interesting, useful and enjoyable for you appreciated reader. Let’s meet again in our next episode!!

The SOA Myth Busters