Microservices and SOA

Similarities, differences, and where we go from here

By Bob Rhubart

March/April 2015

In IT circles mobile, big data, and the Internet of Things (IoT) continue to draw lots of attention. But each of those trends had a beginning—a point at which what was a flat line on a trend graph began an upward climb. The topic of microservices began its ascension late in 2013, and although it remains a mere undercurrent in the overall IT conversation, that current appears to be gaining momentum.

Wikipedia, for one, defines microservices as a software architecture design pattern “in which complex applications are composed of small, independent processes communicating with each other using language-agnostic APIs.”

Sound vaguely familiar? It should. Here’s Wikipedia’s definition of service-oriented architecture (SOA): “A design pattern based on distinct pieces of software providing application functionality as services to other applications via a protocol.”

Much of the general conversation about microservices has focused on how the concept of microservices relates to SOA. To get a sense of how that conversation is shaping up within the Oracle Technology Network (OTN) community, I asked several OTN members about that relationship, and about which aspects of microservices will have the greatest appeal to those now working with SOA.

Microservices are the kind of SOA we have been talking about for the last decade.”–Torsten Winterberg, Oracle ACE Director

“Microservices and SOA solve different problems,” says Eberhard Wolff, a freelance consultant and trainer and head of the technology advisory board for adesso AG. “SOA is a strategic initiative to change the IT of the whole enterprise, separating it into different services, thereby allowing the enterprise to be more flexible.” SOA, Wolff explains, spans different applications and systems in the enterprise, and involves many different organizational units. In contrast, microservices are a way to structure an application, involving only the team responsible for the application. “Microservices must be independently deployable, whereas SOA services are often implemented in deployment monoliths,” says Wolff. “So while the technologies are to some extent similar, SOA and microservices are really different beasts.”

Oracle ACE Director Torsten Winterberg, head of business development and innovation at Opitz Consulting, offers a been-there-done-that interpretation of the microservices and SOA relationship. “Microservices are the kind of SOA we have been talking about for the last decade,” he says. Concepts such as service categories and private services, Winterberg adds, are part of what he calls “classic SOA.”

“But microservices want to bring you into tomorrow,” says Winterberg. “Microservices add a bit to the category concept, defining a service over all application layers, including the UI. So people already doing SOA may gain a kind of new freedom by adopting microservice ideas.” That freedom includes technology independence and an alternative to aging technologies, because individual services within an application can be gradually swapped out for those based on more-modern technologies, without having to replace the entire application. “Classic SOA is more platform driven, so microservices offer more choices in all dimensions,” says Winterberg.

The picture that emerges is not of microservices as an alternative to SOA, but rather as a way to restore flexibility that may have been lost in SOAs that became too rigid and monolithic.

Winterberg’s colleague Sven Bernhardt, a solution architect at Optiz and an Oracle ACE, sees potential for microservices as a way to shift from a top-down to a bottom-up approach to SOA. As an example, Bernhardt points to “scenarios where monolithic legacy applications must be replaced or reimplemented by a more modern solution.” In such cases, he says, “a microservices architecture can provide a foundation for a holistic SOA approach.”

In the end, it all comes down to business value. Oracle ACE Director Lonneke Dikmans, a managing partner at eProseed, observes that many people build “utility services” that create architectural bottlenecks in a SOA. “Think, for example, about a logging service, a print service, or a case service,” she says. “In my opinion, the platform should take care of utilities. If the platform lacks a feature, you should create a library, not a runtime service. We as developers and architects should be busy building business services that offer specific value to the organization.” Microservices, she believes, offer the means to deliver that value. Will microservices play a role in your efforts to build such business services? Join the conversation at

Next Steps

 READ more about microservices

 READ more Rhubart

 GET more Oracle Technology Network architect information

 Bob Rhubart's Blog
 Bob Rhubart on Facebook
 Bob Rhubart on Twitter
 Bob Rhubart on LinkedIn