Microservices vs. SOA—What’s the Difference?

There are a number of things that help make an application what it is—the most fundamental of which is the architecture it’s based on. To date, most technology has been built on monolithic architecture, with all components existing within one complex application. More recently, however, developers have started compartmentalising each component or service in a given application—making it a total sum of its individual parts.

This new trend in application development is supported by service-oriented architecture (SOA) and microservices architecture (MSA), both of which operate on the core principle of breaking down an application into various self-contained functions. This means, for instance, that there can be an individual payment function, a supporting authentication service, and another component focused on maps. And as these units all function autonomously, developers can work more efficiently, focusing on one service at a time without disrupting the functionality of the application as a whole.

What MSA and SOA bring to the table

In monolithic architecture, all of the parts of an application are interdependent and they operate as a singular, complex unit. If one part of the application needs to be fixed or updated, then that impacts the rest of its components, resulting in outages or cumbersome experiences for the end user. Disrupting this model, both SOA and MSA allow for the development of autonomous units using code that’s scalable, reusable, and loosely coupled.

While both service-based architectures have helped set a modern standard for application development, they have notable differences between them. SOA was first on the scene, allowing developers to build the various application modules internally. While this ultimately made for more application in the long-run, it still required developers to be jacks of all trades, creating the various functionalities for the application.

In MSA, meanwhile, there’s an opportunity to make use of modules designed by other organisations as part of the API economy. In this way, a ride-sharing app could use a PayPal service for payment, Google Maps for mapping, and an Okta product for authentication. This allows developers to focus in on their company’s core competencies and offer new or more refined experiences to their customers.

As a more legacy system, SOA integrations were also bogged down by complex communication protocols, such as SOAP and XML. The architecture did not operate smoothly, was expensive, and wasn’t compatible with mobile devices. As a more granular structure that uses lightweight and simple protocols such as HTTP and REST/JSON, MSA has proven to be more agile and easier to integrate across the board.

The benefits of using a microservices architecture

MSA offers a modern approach for application development. Because of its flexibility and the ability to incorporate services developed by other organisations, it allows companies to become tech companies faster. Rather than spending time building live modules for payment or authentication—both of which are difficult—developers can delegate that work to other companies that know those spaces better. And it’s not just emerging companies that are making use of microservices, established names like Apple and PayPal also see the benefits of MSA, particularly when compared to monolithic or service-oriented architecture. With MSA:

• Services are more reusable, scalable, and independently developed
• Messaging systems and protocols are simple, lightweight, and mobile-friendly
• Each microservice can be developed independently by different teams, and in different languages
• The infrastructure is easy to use with containers, e.g. Docker
• There’s room for modern storage techniques, e.g. NoSQL
• There’s an emphasis on shared code and modules

Blending MSA and security

While MSA has many benefits, it’s important to be aware of the potential risks they may pose to an organisation. MSA often relies on APIs for services to communicate with each other—and according to Gartner, by 2022, APIs will be the major source of data breaches. Like a burglar walking into a bank, a hacker that gets into an API would likely get access to each of the services in the application. This makes secure authentication and authorisation crucial.

As microservices are decoupled, distributed components, each one needs to be able to authenticate and authorise each user trying to access it. However, it’s inefficient and risky to have each of these services handle security on their own accord. Because of this, organisations need to consider implementing unified identity and access management (IAM) that covers all their bases and supports them in the following:

• Set up a single, secure point of access using an API Gateway secured by OAuth 2.0
• Implement streamlined authentication tools like Single Sign-On (SSO), with an added layer of security from Adaptive Multi-Factor Authentication (MFA)
• Centralise access policies and management for all your microservices within a central administrative interface
• Choose a robust identity management tool that helps centralise access management

MSA is rapidly becoming a popular architecture for building agile and scalable tech infrastructure. As organisations continue to onboard it into their development practices, it’s critical that they consider the security implications and implement strong mitigating factors that protect their business and customer data. By adding a comprehensive identity management tool to the mix, organisations are much more likely to develop applications that offer seamless customer experiences while also being secure.

To learn about how Okta can help you add an authentication layer to your application, sign up at developer.okta.com.