Most enterprises have some experience with SOA in developing and deploying applications, and most of those companies now have some experience with microservices -- another service-based component model that some say is competitive with SOA and others say is complementary. To align your own SOA and microservices initiatives, create a definition of the goals of both methodologies that suit your operation, delineate software methods that meet those goals, define your merger and set specific architectural rules and design patterns to enforce those methods.
An interesting paradox emerges when thinking of services as the basis for application development. While most planners believe the original SOA model is similar to the microservices model now emerging, much of the formal documentation still separates SOA and microservices. If we're to evolve SOA to support microservices, that formal separation has to be resolved first. To do that, you have to accept that both SOA and microservices are probably defined incorrectly most of the time, partly because an intermediary service model is often overlooked.
Examining SOA and REST
SOA was designed primarily to support the flexible reuse of components across applications, building on the principles of modularity in software design that emerged decades ago. With SOA, modules bound directly into application images were separated and coupled through a network connection as services. There were few restrictions on the function of these services, just as there are few restrictions on what a module can do. Instead, emphasis was on discovery through registries to allow developers to find useful services.
When the web became popular and web-enabled applications exploded, an alternative model emerged in the HTTP-based interactions used by web servers. Representational State Transfer (REST) models function not explicitly as a processing component but rather as a resource. RESTful design would represent an answer, while traditional SOA would represent a process. To use RESTful design, architects and developers would shift from using modules that were network-linked to getting answers that were location-independent. REST is therefore conceptually different from SOA.
Microservices implementation presents management challenges.
That's critical in merging microservices and SOA because microservices evolve from the REST model, so they represent a different software architecture paradigm than SOA did initially. IBM defines a model where merging the two methodologies puts microservices at a lower level. Another model is where SOA is a layer below microservices. So which is right? It goes back to REST.
RESTful components -- if they're authored truly as resources -- would be stateless, sharable, and scalable or replaceable. Those properties are highly desirable if not essential in cloud-ready applications. So for cloud development, it would make sense to adopt the SOA-under-microservices approach.
A microservice is a small, generally useful piece of functionality that's accessed over the network via a RESTful interface. To put SOA under a microservices front, we'd have to implement it partly using SOA, which means harmonizing SOA with the RESTful front-end interface. How easy that would be depends on the complexity of the implementation and the specific SOA details involved.
In theory, it's possible to embed a multicomponent SOA implementation in a microservice, but the practice would have some significant risks. The first step in making it work would be to ensure that the basic REST properties aren't compromised, which means that the SOA components would have to manage any stateful behavior and be able to present an answer or resource-modeled interface. That's easier to do if a single SOA component is encapsulated in a microservice rather than a sequence of components.
State control issues can be difficult to resolve optimally, without making changes to the SOA implementation. Stateful components hold values between activations, making it difficult to scale, replace or share them. In some cases, it's possible to use a database to retain state on a given transaction. But that could introduce a processing delay when multiple instances of a service are deployed because the database could be local only to one of them. Therefore, use that approach only if you're sure it will work.
Impact of SOA and microservices
Merging SOA and microservices can also result in a "culture conflict" because SOA is normally used with discovery and registry processes that facilitate component binding and prevent mismatched parameters. As SOA has evolved, some of the tools used for registration and discovery have evolved to a broader mission, and it's smart to check all your SOA registry contenders to see if one will serve microservices applications, too.
With microservices, explicit coordination of binding is often not the case; more care will be necessary in the application architecture and development processes to implement procedures such as API registries to resolve the SOA and microservices discovery differences and ensure proper use. Cloud providers like Amazon and Microsoft provide API registry services, and there are tools available in both open source form (WS02 Governance Registry or the Fabric8 development platform) and proprietary form (SwaggerHub or Microsoft, IBM and Oracle as part of a development platform).
These tools illustrate an important point about microservices, made even more important where SOA integration is required. It's essential to adopt a standard framework for your APIs that's supported by design tools and patterns at the developer level. Since some development work will be necessary to frame SOA elements as microservices anyway, that will be a good time to put design patterns into place to enforce a consistent API model across microservices. This practice will pay dividends down the line because it will let developers integrate SOA in a standardized way.
The convergence of API and SOA registries will raise the long-term question of whether a commitment to either microservices or SOA is best, even though merging the two methodologies is possible. For the near term, you're likely to strike a microservices-side balance if you have a significant commitment to cloud development and an SOA-side balance if you're predominantly augmenting traditional data center computing with web technology. In the long term, as is the case with so many other computing-policy agenda items, it will depend on where the cloud goes.
The holistic approach to SOA and microservices
Learning about SOA trends
Comparing microservices and SOA