As efficient software applications penetrated every aspect of business workflow, so did the information systems that delivered them. Whether small or large, they spread like a viral fever. Every workflow, department, business unit or a subsidiary took advantage of their efficiency and stable record management capabilities. While their adoption grew, certain challenges became inevitable. How do you make them talk to each other? Most of them are disparate systems looking for information that is captured and stored in another. Efficiencies were there, but the scale was missing.
This gave rise to the whole new world of System Integration (SI), an area within IT that is very dear to me – simply because I have spent most of my work life doing this. Tech evolution is feeling its effect as well.
From dedicated connected pipes to service oriented architectures, SI has come a long way. In recent past, terminologies like “Microservices” and “API” have started to significantly influence the SI design. These two along with SOA at times create a solution kludge for SI architects. Hence, I’m writing this small blog to examine these three concepts and see which among the three in our “Services Soup” are worth further evaluation.
- SOA (Service Oriented Architecture) – A style of software design where services are provided to the other components by application components, through a communication protocol over a network.
- Microservices – Scaled down version of SOA, where services are fine grained and protocols are light weight to improve modularity.
- API (Application Programming Interface) – Set of specifications that aids communication between different software components.
A little Tech Talk
- SOA – This name is so indiscriminately used with Enterprise Service Bus (ESB) that at this point I consider SOA as synonymous to ESB. However, for a Services Oriented Architecture business, entities matter. They are the functional core of the services. As the underlying data model gets complex, so does the business entities that it represents. This leads to the development of complex large size services. Dismantling a large service becomes an inherent challenge. End result: a “Megatron” service with many consumer versions and a tool to manage those versions. SOA garners more business value as technical integration strategy takes a back seat. It promotes inter-operability, flexibility and the concept of shared services. These value-adds help businesses respond actively to changing market conditions but the added complexity, heterogeneity and many moving parts make SOA less attractive in its current shape, especially in an Agile development environment.
- Microservices – They are the contemporary interpretation of SOA. One might consider SOA an evolution and Microservices a revolution in SI. Componentization was the need of the hour and fine grained objective driven Microservices were the answer. They support custom integration and are technology agnostic. They exist to service a very specific need. If another need arises, even though a similar one, you don’t modify an existing Microservice. Rather you create a new one. Adaptive and agile software development methodologies make them a great fit in the current application development environment. They fit well in the Continuous Integration realm. As and when the underlying technologies evolve, Microservices can take advantage of those. When integration architects are tasked with a new SI undertaking, please see if Microservices can be a solution before harping on an existing SOA driven solution.
- API – APIs span over a large section in the SI spectrum. They started as a low-level programming interfaces. In today’s world they can be appropriated as simple HTTP interfaces. They often equate to REST and follow JSON data formats. APIs became popular with the advent of smartphones. Developers needed swift access to back end functions and voila, the commercial API market was born. They started as functional gateways to internal consumers. As markets expanded organization’s data became a vital commercial entity. This made APIs a source gateway to external consumers. Their demand surged with the rise in data analytics. Such scale and widespread distribution of data brought forth the need for security, simple consumption and self-service. Hence, started a new era in IT capability – the world of API Management.
The simplicity and self-administering capabilities of APIs have blurred the line between APIs and SOA. Many companies now use APIs to expose capabilities inside the companies. However, many still use the term “service” for internal design purposes. Microservice is an alternative architecture in the SOA space. It partitioned an aggregate business entity into meaningful atomic units that significantly enhanced agility, scalability and resilience to the SI architecture.
From a financial perspective, SOA and Microservices were developed to satiate internal integration needs. As such they fit the cost containment model of IT. On the other hand, APIs were developed to expose the enterprise data or modular functions to the outside world with an intent to generate revenue. As such they fit the asset management model in IT. Exposing a capability or data to the outside world and developing a revenue model around its consumption made APIs the economic powerhouse in this new Internet Age.
SOA, Microservices and APIs are modern day integration techniques. It is worth evaluating each of them to see which of these technologies can better help meet your organization’s integration needs. From cloud to mobile, the infrastructure platforms are evolving at an ever faster pace. So are the requirements to integrate the systems that service these platforms. Sound knowledge of modern day integration architectures can add agility, elasticity, fault tolerance and adaptability to your design.