Back in the early growth days of the Internet, the late 1990s, developers were realizing that the existing client-server architecture wasn’t suitable for a web-oriented world, and so service-oriented architecture (SOA) was developed. SOA generated a lot of discussion and planning, but in the end it didn’t achieve the lofty goals that people had hoped. Now we are hearing about a new architecture, microservices architecture, and those of us who remember the SOA days are wondering whether microservices will go the same way or if it will be different. From an integration perspective, this is important because developers who got burnt with SOA are reluctant to have a similar experience with microservices.
What is SOA?
SOA introduced the concept of a service – a self-contained unit of work that has well-defined, understood capabilities. Services should be ‘loosely coupled’, meaning that they had little or no information about the definitions of other separate components. SOA was designed to:
- stop developers thinking of individual systems as silos of information,
- improve information flow within and between applications,
- support the flexible reuse of components across applications.
The aim was to expose and access services, and the information about them, so that those services could be abstracted to other process layers and composite applications could be created. It was first described by Gartner in mid-1990s but the interest in the architecture was spurred by the emergence of web services in early 2000s and particularly by Microsoft, who promoted it with the introduction of the .NET platform. For vendors like Oracle and SAP, SOA was important as it provided the opportunity for them to extend their monolithic architecture solutions by re-organizing their enterprise applications into sets of logical services.
What are Microservices?
Microservices architecture is an alternative approach to structuring applications. According to the defining article, it is:
an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms … These services are built around business capabilities and independently deployable … There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.
A microservices-architected application is broken into smaller, completely independent components.
The problem with SOA
SOA suffered from two serious issues.
- it was complex,
- it could be defined differently depending who was talking – especially if it was a technology vendor.
As the hype around SOA was souring, an analyst wrote:
SOA was supposed to reduce costs and increase agility on a massive scale. Except in rare situations, SOA has failed to deliver its promised benefits.
Another problem with SOA was that, as the number of web-enabled applications grew, an alternative model emerged to handle the HTTP-based interactions of web servers. This was Representational State Transfer (REST), which uses the concept of resources and where each resource is handled through a standard, common interface. The REST Web Service approach had several advantages over SOA, including being less rigid and cumbersome, more flexible, and easier to build. You can read more technical detail here.
SOA vs Microservices
Microservices follows a different software architecture to SOA.
Compared to microservices, SOA has other deficiencies:
- SOA cannot support the agility and flexibility required by modern mobile-oriented apps
- it can be argued that SOA was a top-down approach, whereas microservices are more likely to be implemented bottom-up.
In the current developer environment, with the growing requirement for continuous integration and continuous delivery (CI/CD), the microservices approach has several advantages.
- Applications can be divided into discrete pieces with each piece fulfilling a specific need. In SOA, components and they are often implemented as complete subsystems
- Scalability is easier as you only need to address those parts of the application that require more resources. Using SOA, the entire application has to be scaled
- Individual application services can be independently deployed rather than the whole application. With SOA, you need to coordinate with multiple groups
- Different services can use different programming languages, so developers can use the best tool for the job
- Different services can be created and maintained by different teams
- Microservices rely on two lightweight protocols, REST and simple messaging. SOA uses messaging middleware and the more complex SOAP access protocol.
- SOA enhances component sharing, whereas microservices tries to minimize on sharing through “bounded context.”
- SOA uses ‘heavier’ messaging middleware; microservices has an API layer between services and service consumers.
While both SOA and microservices were designed to enable componentization of applications, microservices provide a better way to decouple components within an application.
The use of microservices architecture offers greater agility, scalability, and availability.
Levels of services used – SOA applications vs microservices
A classic case of using microservices is the Netflix platform.
Netflix API is an orchestration service that exposes coarse grained APIs by composing fined grained functionality provided by the microservices.
The discussion on microservices vs SOA has been summed up in this article:
… the cloud encourages a dynamic and elastic vision of application components, where scalability and resiliency are more valuable than composability alone … 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.
Flowgear and microservices
Starting a microservices application project doesn’t require a large budget for software and infrastructure. You can choose which development tools to use, depending on your environment and requirements. When it comes to integrating the microservices, or choosing a solution that will provide you with an integration capability, your integration team will have two choices:
- hand-code custom integrations for all the integration endpoints required,
- make use of an integration platform that has a ready-built library of endpoints.
An organization which was looking for an integration solution had to some elements of a microservice project.
- They had to choose whether to build custom integrations or use an integration platform
- They wanted to separate the integration team from the core development team
According to EventBooking.com’s CTO Rob Scott, using Flowgear they found “a tool that was not only developer friendly, but also allowed us to start on a low budget while we tested and proved the concept.” They were able to start a with a proof-of-concept to get comfortable with the solution. With Flowgear, the integration team could operate separately from core development, and Flowgear’s customer support enabled them to resolve questions and issues quickly.
With Flowgear’s library of connectors, providing an integration service is a lot easier and avoids the problems that comes with do-it-yourself custom code. Your integration team can focus on providing for the needs of internal and external integrations using Flowgear as the tool best-suited to that purpose.
