I’ve seen my fair share of projects and customers over the past 10 years working in the software Integration industry. At Polarising, the solid expertise in this area allows me to work every day with a team of Architects capable of determine the best solution to the existing challenges, discussing about all the different approaches, and deciding from both an Architecture and Technology point of view.
Is there a right and wrong approach for a specific type of business? First, let’s check each one out.
Point-to-point Architecture
Already in the category of legacy architecture, this was the most common architecture in the early 2000’s. It consisted in the integration of data from several applications, using a specific channel for each integration flow. This means an ever-growing number of channels and connections between systems, making it difficult to manage the Integration Platform.
Simple to design and implement, this type of middleware might be a good option for low scale integration scenarios where change is predictable. Otherwise, it’s not a recommend architecture, since it has high maintenance costs per each application added, leading to the redevelopment of each connector to each application. It was this lack of scalability that led to what it’s usually referred as a “spaghetti” architecture.
SOA (Service Oriented Architecture)
To face the challenge of scalability, SOA emerged as an approach that allowed to decouple all integrated applications by exposing their functionalities as services. Each service can then be used as a small building block to compose larger functionalities and systems, leveraging on a centralised Enterprise Service Bus and standardised messaging. This aims to ensure high service reuse, with easier governance and change management, since changes can be performed only on ESB-level and abstracted from other systems.
This type of architecture has become mainstream for the last 15 to 20 years in what concerns to integration and has allowed several companies to easily integrate their systems and those of external partners. But on its downside, SOA has proven itself hard to govern in not so controlled environments, creating similar services and wasting its reuse potential.
Governance requires the definition and enforcement of a strict set of rules, usually by an Architecture team or a SOA Centre of Excellence. This is something that most companies wrongly see as an avoidable cost, leading to an ungoverned SOA that can easily be also compared with a “spaghetti” architecture.
Microservices Architecture
This “newcomer” shares several characteristics with a SOA architecture, aiming to achieve some of its goals. And it does so with the promise of a simpler architecture, easier to govern, more scalable and better suited to the advent of cloud computing.
How? Well, it’s precisely here that you can find the difference between a SOA service and a Microservice. Where in SOA, services are seen as mere building blocks of one large platform/framework that can be used to orchestrate larger functionalities and processes, Microservices are completely independent entities that can evolve on different lifecycles and be developed in different technologies, also following a different sets of rules, scaled as needed, without impacting each other.
While this leads to a more flexible architecture that can easily scale and adapt to a company’s evolving needs, there is a growing risk of losing control of microservices and ending up with a set of unmanageable services, again resembling a “spaghetti” architecture – where have we heard this already?!
A few more architectures or variations could be named, such as an Event-Driven Architecture (EDA) or a Database-oriented Middleware (for which Polarising developed PortaTM, a Java-based software that allows the exposure of Stored Procedures as Webservices).
In the end, the often-unanswered question is what’s the best architecture. From my experience it all resumes to determine the best approach for each scenario. Although being the “next best thing”, a Microservices architecture is far from being ideal to every business. SOA is a proven architecture, suitable for most scenarios but it requires strong governance to evolve properly. And even a point-to-point architecture can be suitable in some small-scale scenarios, even though it has fallen in disuse.
It’s clear to me that only with experience are we able to access such scenarios and determine the best option. One should always investigate past projects for lessons learned, understand what best fits the next project/challenge and avoid following the “new buzz” just for the sake of being the latest trend. I could name a few companies that are always implementing the “next best thing” and end up with a large set of legacy integration platforms and a nightmare to manage in the future… But I won’t;-)
Hugo Pascoalinho
Polarising Consultant
Head of Architecture & Technology
-
Hugo Pascoalinhohttps://polarising.com/author/hugo-pascoalinho/
