BACKGROUND IMAGE: iSTOCK/GETTY IMAGES

E-Handbook:

Microservices development presents integration, deployment challenges

Manage Learn to apply best practices and optimize your operations.

Managing the merger of SOA and microservices

Expert Tom Nolle discusses why your allegiance to microservices or SOA doesn't necessarily have to be a choice, if you can work with both.

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.

Next Steps

The holistic approach to SOA and microservices

Learning about SOA trends

Comparing microservices and SOA

This was last published in February 2017

Dig Deeper on REST and microservices

PRO+

Content

Find more PRO+ content and other member only offers, here.

Join the conversation

2 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

How has your enterprise used both microservices and SOA?
Cancel
I'm not sure that I share the distinction between SOA and REST. It's true that they are both design patterns (I would hestitate to use the word architecture although TBH it's just semantics) that approach the delivery of capability following potentially (but not necessarily) from different stances, one being based around resources and the other process, or service. To be honest I'm not convinced that the are incompatible nor that their principle differing characteristic is the management of state. From a practical standpoint, state exists in both, so whilst stateless is an aspiration in either case, in non trivial implementations it still exists which ever style you choose (I'm talking about the reality of imperfect application design here whether legacy or indeed brand new rather than philosophically - their are *always* compromises they relate to affordability vs. dogma). The orchestration of services (micro or otherwise) also to me doesn't distinguish SOA and REST (if we're comparing 'architectural' styles we should probably say SOA and ROA). Both need to deal with similar concerns, unless that is you set a particular internal policy around which use cases fit which approach, but that I suspect would quickly become an intractable debate that offers no value. Likewise with granularity. Whilst there might be some emphasis in micro-services to use fine-grained business functions, the same might equally be said of SOA. I recall long discussions about the optimum level for service granularity and decomposition in the early days of SOA. These nearly always resulted in ... it depends'. So to me, the things that are shared between SOA and RESTful are greater than the differences, especially when you get down to implementation details. My 4 cents FWIW.
Cancel

-ADS BY GOOGLE

SearchSoftwareQuality

SearchCloudApplications

SearchAWS

TheServerSide

SearchWinDevelopment

Close