The difference between microservices and SOA

Since it emerged more than a decade ago, Service Oriented Architecture (SOA) has been both widely praised as a modern and agile approach to software development and infrastructure architecture and dismissed as a colossal waste of time and money. Missed expectations for many SOA projects led one analyst in 2009 to declare, “SOA is dead.”  That said, the architectural principles of microservices seem to echo those of SOA, leading many who have dealt with the challenges of SOA to wonder what the differences are between microservices and SOA. 

The cultural differences between microservices and SOA

An important and often overlooked difference between microservices and SOA is organizational culture. Service oriented architecture (SOA) is a model of infrastructure architecture and an approach to application development.  Its key principle is an infrastructure architecture around services rather than entire applications.The emphasis is on creating components called services, which are discrete units of software that provide a specific business capability and can be reused for other purposes. In an SOA model, developers create new applications by orchestrating a collection of services instead of building out an entire software program, eliminating code redundancies across multiple applications. 

This sounds very positive in theory, but in practice it became unwieldy. When enterprises first adopted SOA, many chose a “top-down” approach. This entailed launching a single organization-wide SOA initiative and selecting a closed proprietary SOA stack from a big vendor such as IBM or Oracle. Once this stack was purchased, the company would begin a planned rollout process, often with the help of consultants. The company’s development team would then learn and use the product to re-architect all existing systems as well as design new applications according to SOA principles. These developers would have to throw out their existing tools, processes, and skill sets and be heavily retrained on the new solution. 

This has numerous disadvantages today, particularly when businesses have to prioritize speed and innovation. There simply isn’t the time available to rip and replace current systems. The process led to particularly slow release cycles, as all of the integrations and new connections had to be created and managed by IT, who were already underwater rebuilding the existing architectures. As one writer put it, “Ultimately, this prevented people from operating, developing, changing and migrating SOA artifacts.  Changing one artifact created multiple (and unknown) downstream impacts. As integration use cases moved outside of central IT with the advent of SaaS, it became clear that these traditional SOA stacks couldn’t handle the speed of connectivity required.”                    
            
It must be emphasized that the principles of SOA are still valid today. But the needs of the organization have changed drastically, requiring a change in organizational culture. When we consider the differences between microservices and SOA, we have to think not just about technology, but also business culture, people, and business processes. SOA had to be established from the ground up for every company. It was very much a central IT development and flowed out from central IT. Central IT had to enable it, manage it, and govern it. By contrast, a microservices architecture provides solution logic in a decentralized manner with the standardization of microservice contracts in the form of APIs. Whenever a microservice is created in an organization, central IT must enforce the discipline of making that service reusable so that other teams can use that asset via an API-led connectivity strategy. Eventually, multiple teams from different domains or lines of business can implement services with their own choice of technology but yet remain aligned with the business in their purpose. 

This represents the evolution of IT’s role from provider to partner, resulting in the enablement of teams throughout the business to adapt the core capabilities to their own particular needs. IT has to shift its mindset from complete control to a distributed authority over technology in the business. It requires a federated approach to governing and controlling data, applications, and systems. This allows IT to be a platform enabler for the organization, will increase productivity through reuse, and will make change more predictable and easier to manage.

How to resolve the differences between microservices and SOA

One of the primary challenges that IT faces today is a capacity gap between the demands of the business and what resourcing is able to provide. With every corner of the business needing solutions to handle SaaS applications, mobile applications, big data and analytics, IoT, virtual reality, and whatever future technology comes along, It simply doesn’t have the resources to supply all the solutions that everyone needs. 

The ideal IT architecture is one that combines both a composable service architecture and the organizational principles behind microservices. In other words, businesses should be approaching microservices AND SOA, rather than microservices vs SOA. To do that, your enterprise IT architecture should be organized around an application network.  

An application network combines the notion of small, composable services designed around particular business capabilities, all made reusable and connected to each other via APIs. 
                    
Unlike prior approaches in SOA implementation initiatives to connect applications, an application network is designed to allow many people both inside and outside the enterprise to have controlled access to business data and to the reusable microservices. This will occur by allowing anyone in the business to use consumption models they are familiar with. In other words, it makes it easier for someone in the organization to create a useful application, use of data, or an API creating a particular experience through a composable service approach, and then expose that value to the network. If that service is  made available beyond the scope of any particular project, then the provider’s service is exposed to the network and may be leveraged in other scenarios. Through the application network, teams who have a need can more easily access the service through the work of the original team, without the explicit help of that team. 

Reuse principles in microservices vs SOA 

Reuse is an important principle of microservice design. However, another important principle is to limit the scope of reuse to specific domains within the business, which provides an important way to differentiate between microservices and SOA. In the early days of SOA, designing enterprise-wide canonical models of reuse was fruitless because it was too ambitious. Everything was designated for reuse, creating inefficiencies. Microservices instead proposes a ‘merit based reuse’ approach, in which an emerging model is preferred over a predetermined one.  In this way, LoB IT teams, who are already creating new applications or uses of data, make services they find useful available to others, who then self-serve those reusable assets. The principle of reuse emerges from the ground up, with the most useful services gaining prominence through organic behavior. 

A holistic, platform approach to microservices

MuleSoft recommends a holistic, platform approach to microservices, implemented through an application network and built on the strategy of API-led connectivity. Not only does API-led connectivity provide the integration so crucial to the proper function of your technology stack, it will allow developers throughout your organization, not just the central IT team, to create new solutions in a manageable, reusable, and governed way. In addition, MuleSoft’s platform approach provides a unique operating model to allow both LoB and IT to build, innovate, and deliver new solutions wherever needed throughout the organization. Take a look at more resources on microservices which can enable IT to deliver faster at a lower cost.