API and Microservice

API and microservices are two words we use interchangeably. Are they the same? No. But they are codependent.

APIs are consumer focused. The motivation behind defining an API is to answer one fundamental question, "What do consumers want?" APIs can interact with multiple services to get the desired result for the consumer.

Microservices use APIs to communicate between microservices. A single API call can request a single service or request multiple microservices to fulfill the consumer's needs.

Checking an order status in an e-commerce website requires a response from an order service or an inventory service. APIs can act as an information provider to the consumer by requesting information from multiple services managing multiple records systems. Microservices are built to accomplish repeated business tasks. Microservice architecture helps to decouple systems.

Imagine multiple teams working on different features in one codebase. A great deal of collaboration is required to deploy, test and add new features. This acts as a severe bottleneck to the speed of delivery.

There are plenty of samples available on the internet illustrating why we need microservices. I want to add a very accessible analogy to this pool of examples:

Running a restaurant also requires a great deal of collaboration and a systemic design to serve a great experience. If one chef is expected to cut the vegetables, cook them and serve them to a customer, the amount of work involved is astronomical.

The chef can delegate a few of his tasks to others, as shown above.

1. This reduces the dependency on one chef.
2. This also decouples the system; each chef can do their task independently without worrying about the rest.
3. The speed of delivery also increases.

This is the same principle behind microservices. We decouple the entire system so that each team can work on their feature without worrying about the other moving parts.

Microservices it is!

The APIs work in conjunction with the microservices. We followed the API-led connectivity paradigm in creating the APIs.

We categorize API into three types.

• Experience API: These are generally external-facing APIs that provide a different experience to consumers from a common data source, catering to each consumer's needs. Mobile consumers expect much less data when compared to desktop clients. This gives rise to different needs.
• Process API: Process APIs take care of the business processes associated with the data, for example, an order going through multiple checks and validations before it gets inserted into the database.
• System API: These APIs expose the systems of record to the outside world, for example, a document manager API to manage documents for the entire organization.

The design of the system should always depend upon the needs of the business. No "one-size-fits-all" solution exists. At Mutual of Omaha, we recently built an order processing system for one of our products. The requirement was to expose a SOAP API to an external vendor and an SFTP integration for fixed-width files.

The Current Day

We already had a giant monolith that included a UI, database connectivity and Spring integration code, tightly knit into one service. It supported two file formats, and any deviation from these formats required numerous code changes, changes in the table structure and new flows to handle the business process. Changes were making the codebase more and more complex and challenging to understand.

Our external-facing SOAP service was no different. Operations were tightly knit into one service with redundant code in almost every module.

Process

The entire process was broken down into three parts and distributed between three teams; each team worked on one category of API, which paved the way for parallel development.

Each of these microservices will be deployed in a container environment with replication and auto-discovery enabled. We decided to use the vendor’s integration platform to build experience APIs, which helped accelerate the integration.

Going back to our restaurant analogy, when the chef chooses to start with chopped vegetables instead of chopping them before use, it greatly reduces the meal preparation time. Using readily configurable components helps us accelerate delivery. It has implicit functions to parse incoming data and transform it into the required format. Configurable connectors and API listeners help us to build an API in a short period of time. We built our external-focused API and SFTP integration with reusable components from the vendor's platform.

Parsing

The received data was in a different format. We created a configurable parser in our experience APIs, which helped us to convert the fixed-width file data to the required format.

The parsing process is configurable and straightforward; it requires schemas for input and output formats. Schema-based parsing provides us with a greater ability to adapt as data format changes. Configurable schemas can easily accommodate changes.

The process APIs were a little more challenging; it involved a family of microservices (orchestrated and event-driven) working together to fetch and validate data from multiple systems of records.

The resulted order was finally inserted into the destined location using another system API.

API-led connectivity has encouraged other teams to develop and publish reusable system APIs that give access to records systems.

Reusable components reduced the code burden on teams. The old way of building applications is tiring. So is the old way of integrating. Tools like Mulesoft have democratized APIs. Microservices running in containers have helped make deployment and distribution of work easy, resulting in accelerated delivery and robust systems that are more adaptable to changing environments.