There is still much confusion about the differences and commonalities between SOA (service-oriented architecture), microservices, APIs and, even, point-to-point integration.
Is microservices-based approach an alternative to SOA or one of its flavours? What is the relationship between microservices and APIs?
And why you shouldn't rush into exposing your APIs to the external market until they are ready and mature.
Changes are driving new solutions.
The technology landscape is fast-changing and endlessly diverse. So what does this mean for businesses? It means that they need to to boost innovation and re-use of the internal assets most efficiently in order to stay relevant and competitive. Businesses are expected to deliver not only data to multiple audiences (customers, suppliers, employees, partners, etc.) but also through different channels. Think desktop, mobile, tablets, TV, and everything else.
The risk here is that IT become overwhelmed by all the changes and requirements, and, as a result, turn to a quick and easy solution - point-to-point (P2P) integrations. Undoubtedly, this approach delivers results quickly, but we also know that it has enormous implications on the maintenance cost.
Too many P2P integrations lead to so-called 'spaghetti architecture' that is hard to maintain and almost impossible to scale. So, point-to-point integration is not a sustainable long-term solution.
Point-to-point integrations leads to spaghetti architecture
(Source: MuleSoft)
Well-defined, discoverable and reusable services instead of the dreading point-to-point integration has always been one of the main objectives of the service-oriented architecture. Although the basic principle hasn't changed at all, the technology used to implement SOA has evolved.
Microservices-oriented approach.
The traditional technique utilises 'fat middleware' appliances but it is expensive, difficult to scale and, in general, tricky to use and configure.
Therefore, more organisations are migrating to a microservices-oriented approach. Although many people perceive it as an alternative to SOA, in fact, it's an evolution of a 'fine-grained SOA'. It tackles the drawbacks of the traditional SOA approach and is a much better match for the modern data-centric and diverse IT landscape. For a deeper dive, I strongly recommend reading my blog Microservices: everything you need to know.
Unfortunately, there is no silver bullet in IT. If you're considering the microservices approach, make sure your organisation is ready for it as it comes loaded with risks and drawbacks. One of the risks is that services can proliferate internally and become unmanageable if no governance is applied.
Microservises and APIs.
Let us look at the correlation between microservices and APIs. The industry (unofficially) agrees that a microservice doesn't necessarily mean an interface. A microservice is designed and created to serve a well-defined piece of functionality. Only when your service is mature and ready to be consumed by a broader audience, it should be "graduated" to an API, which is, by definition, reusable and discoverable. By exposing the microservice's functionality via its API, we create not only an internal value but potentially an external business value as well.
When the number of microservices in your organisation starts to grow, you'll need an API management layer. This layer would become a single point of access for the whole organisation to access and share data, give feedback, and so forth. The API layer is also used to enforce security, governance, access control, rate limiting, policies, etc.
Expose internal data via APIs
The idea of exposing internal data and functionality via APIs doesn't apply to microservices exclusively. APIs created on top of your legacy systems, ERPs, on-premise or SaaS applications help unlock their data, promote re-use, and make them discoverable. Moreover, APIs provide a single point of access for all kinds of audiences inside and outside your organisation. In essence, API-led approach abstracts the underlying communication protocol, standardises access and simplifies data consumption.
Data exposed by APIs don't necessarily mirror the underlying system. It can (and should!) reflect customers expectations - filter information of interest or aggregate data from multiple systems. MuleSoft's Application Network reflects this principle particularly well.
The External API Economy
When an organisation exposes its internal data via API and generates revenue, it participates in the API economy. In fact, many vendors generate most of their revenue through APIs - Salesforce (ca. 50%), Expedia (ca. 90%), eBay (ca. 60%). More and more companies see the potential of the API economy as a way to not only to monetise the internal assets but also forge new relationships with external partners, offer better services to customers, drive innovation and efficiency. As a result, the number of public APIs is increasing exponentially. As I'm writing this article, the total number is over 20k!
The growth over time of the ProgrammableWeb API directory to more than 22,000 entries
(Source: ProgrammableWeb)
API maturity stages
Bear in mind though, that participating in the external API economy (i.e. generating revenue via APIs) is 'only' the final destination of a long journey with multiple steps, or 'API maturity stages'. Generally speaking, an organisation has to establish the 'internal API economy' first. This stage is all about getting the APIs mature enough to create business value internally and to compete on the external market.
Start with a discovery phase as a preliminary step to identify your organisation's strategic assets (or services). MuleSoft suggests creating a C4E (Center For Enablement). It's a cross-functional team that takes on harvesting reusable assets and best practices, promoting consumption and collaboration, and collecting feedback and metrics throughout all of this.
5 stages of API maturity
After you have discovered your assets, you are ready to get on the path to API maturity. This path consists of a series of steps:
- Assets are "unlocked" through system APIs removing the limitations of legacy systems and SaaS. At this stage, the APIs mostly play the role of the 'wrappers' for the services underneath. They allow consumption without focusing on user experience yet.
- The APIs evolve so they can be consumed in mobility and via multiple channels (i.e. having different APIs retrieving data from the same system, but adapting to the user experience).
- APIs are exposed to external partners (B2B)
- APIs are exposed to the public
API Management platforms
You are probably wondering which tools are most suited for achieving the above-listed stages of the APIs maturity. The answer lies in the API Management platforms; there are loads of options available on the market, but they all seem to offer the following common features:
- API definitions can be designed, documented and tested (via mocks) on the same platform promoting a design-first approach;
- APIs are discoverable via Developer Portals so that users can request access and also provide feedback;
- The API gateways can consume both on-premise and cloud SaaS applications seamlessly;
- The API Platform represents a single point of entry for all the APIs;
- Governance, service level agreements (SLA) and security can be applied to APIs via the API Gateway;
- Usage statistics can be collected, and the APIs' success can be measured;
- Monetisation policies can be applied.
So, participating in the external API economy isn't a straightforward process. Your internal APIs need to reach the very highest levels of maturity. Once you've gone through this process and reached that level, your APIs can be exposed to the external market to generate revenue.
In the next post of this series, I explain how to design a perfect API including 3 bad practices and, finally, the correct approach.
Explore our 🚀 Kich-start Integration Kit. Learn how we approach API-let integration programmes to deliver amazing results in only 90 days.
