The fundamental differences between microservices and SOA

Core concepts in microservices and SOA

There have always been two dimensions to the notion of SOA. At the conceptual level, SOA is a model for building applications by assembling components that can be shared among applications and hosted independently. At the implementation level, SOA developed a series of standards to define application characteristics and interfaces, broker access and provide security, including Simple Object Access Protocol and Web Services Description Language.

Many of SOA's underlying concepts are also core concepts in microservices. However, microservices apply these concepts through the lens of the internet, the web and REST interfaces.

Nearly every development team is familiar with REST and programming web-based applications, so they already have the basic knowledge to cope with microservices development. The focus of implementation just needs to shift to the web, which will involve adapting to some new procedures.

The term microservices can be a source of confusion for some former SOA developers. This term may conjure up the image of hundreds or thousands of services that consist of a couple lines of code that can be called upon as needed. Such a microservices framework would almost surely generate enormous delays because of message transfer latency. Former SOA practitioners should keep in mind how SOA's componentization design principles are equally effective for microservices.

Where microservices and SOA differ

The difference between stateless and stateful behavior is likely to be the most confounding issue for SOA developers to grasp. One simple rule is that you should never store data within a microservice. That practice would limit the ability to scale under load or replace a failed service. If you need to maintain data or context across multiple instances in a microservices architecture, store the data either with the calling software and send it to the microservice when it's called, or get it from a back-end database. Design microservices so that calling them with the same input will always generate the same output.

There is also a fundamental difference in how SOA services and microservices are used by an application. SOA services normally appear as procedures or functions, meaning they are designed to emulate locally written software components. For example, when an SOA service is needed, you call it. By contrast, microservices are not called but are a resource you draw from. When they are used in event processing, for example, they are triggered by an event rather than explicitly called. Finally, microservices are typically stateless, where most SOA components are stateful.

Addressing security and governance issues is also more nuanced in microservices. Many organizations have developed standardized methods for security, identity management and governance around SOA. However, most companies do not have any standardized methods to deal with security and governance issues in microservices. Architects moving to microservices must devise methods to address these needs and then ensure they are standardized across the entire IT ecosystem. If they are not, differences in security and identity procedures will stall deployment. It also means that, when opportunities for new applications are identified, there's a risk of hidden incompatibilities. Thankfully, there are many proven token-based systems for identity management and security for microservices. Standardizing on one will preserve open microservices use without compromising security and governance.

If the cloud is the future, then microservices are too.

Another area where microservices and SOA differ is in organizing workflow. SOA applications are often linked with an enterprise service bus (ESB), where execution is guided by business process management (BPM) language. Microservices are called explicitly from applications, so the sequencing of process steps is done at the application level. Also, remember that microservices are reusable components. They are not big chunks of applications, which is what ESB and BPM languages support. However, there are programming design patterns that provide similar process orchestration using microservices.

Interfaces of any sort require some sort of data exchange mechanism. With SOA, the traditional mechanism is XML, which can be flexible. However, some developers find XML verbose and complicated. With microservices, you can still use XML, but many developers gravitate toward JSON because they find it easier to work with. If your team is very familiar with XML and not Java, you can use XML. But JSON is best in most cases, and the transition should not be difficult for most SOA programmers.

Are microservices worth it?

The only question that remains is whether SOA developers really need to adopt microservices techniques at all. There is still plenty of SOA development going on, and many large and prominent applications are still based on SOA from both a conceptual and implementation perspective. But the cloud encourages a dynamic and elastic vision of application components, where scalability and resiliency are more valuable than composability alone. Cloud models are better suited for component interfaces that are lightweight and capable of being shaped dynamically at runtime, which is the perfect use for a REST-based microservices architecture.

If the cloud is the future, then microservices are too. SOA isn't going to disappear, but it's also unlikely to be adapted to these new requirements. Software practices are moving to microservices, so SOA practitioners should be prepared to go there as well.