Microservices

The term Microservice is used so often that a clear, high-level explanation is definitely in order. This post is not a canned definition but a collection of insights based on Yasgar Technology Group’s 30 years of experience in software development and integrations.

Independence

Microservices are an architectural approach in which a complex application is broken down into smaller, independently deployable, or modular services. Each focused on specific business capabilities. A complex application does not have to be complicated; a user portal is a fine example.

Application Programming Interface

The main component of a microservice is the Application Programming Interface (API). An API web service is built just like a website. However, it is designed to only return data instead of a graphic screen that users can interact with. Many developers view microservices only in terms of the API used to fetch or save data. While this is technically accurate, it ignores the fundamental change in attitude about how user interfaces are designed and coded.

User Interface

Let’s start with the User Interface, often called the Website, Front End, UI, or Presentation Layer. Most developers will not consider the user interface when they discuss microservices because it seems unrelated to them. The user interface can be an internally used Windows Application, an Intranet application (only used within the company), or a public website. The goal of the user interface in a microservice architecture is only to have the responsibility to format, display, and collect data. It would not have much business logic built in, except for the necessary stops not to accept incomplete data.

The significance of this is that it allows the development team to make changes, sometimes even drastic changes, and not have to redeploy the User Interface.

A microservice contains a discrete set of endpoints that handle a particular area. An endpoint is simply a term for an individual piece of functionality. For instance, the call to retrieve a customer will be one endpoint, and the call to save a customer will be another. This definition is what we use at Yasgar Technology Group. There are arguments that the Customer functionality is one endpoint whether you are fetching (getting) or saving (posting). In the way of example, microservices may contain ways to save and retrieve data in the following areas:

Customers
Orders
Invoices
Shipments

Each of the four examples above would be a separate microservice, which can be enhanced and deployed separately.

One crucial factor is that microservices can be deployed in any configuration and with almost any development platform. A microservice does not have to be written to use the HTTP protocol or in a particular programming language. Your company should write your microservices in a format your development team can easily support.

…the most critical feature of a microservice platform is that your existing staff can support and improve it.

Yasgar Technology Group has witnessed a microservice project started for businesses by an outside consultant who used the platform of their choice. This is fine as long as it’s a platform your internal resources can maintain once the consultant is gone. On more than one occasion, the developers eventually started to re-write services in the platform of their choice because the new platform was too complex or cumbersome for the existing staff to use. I need to reiterate that the most critical feature of a microservice platform is that your existing staff can support and improve it. If the company brings in a new platform, development teams rarely have the resources to abandon their platform of choice and start using something new with exclusivity. What happens is the old platform eventually wins, and the new platform starts to become a hindrance.

Data

The vast majority of APIs will access some data store. This data will usually come from a database used by your company to either store and retrieve data from the application itself or data stored by other applications, such as your order entry system, claims system, or even your Customer Relationship Management (CRM) system.

An API can also use or incorporate data from another API. Some developers claim there is an unwritten rule that an API should not call another API, but it is necessary and occurs all the time. A good example is calling a customer record where the user may authenticate through a third-party system such as Okta®; a call must be made to Okta to get any relevant information that might be useful.

Independent Data Structures or Business Objects

An application, whether a User Interface or another API, should be loosely coupled to the API. This means that minor changes in the API will not break the User Interface. One of the most important factors is that any change in the source data, whether from a database or another API, also doesn’t cause any problem with the User Interface. This deserves to be explored in a little detail.

One of the most significant issues Yasgar Technology Group has experienced when entering a project mid-stream is that the development team has written the APIs to return data to the User Interface in a format very similar to the database structure. This is called “tightly coupled”. The issue here is that when a change is made to the database, then there must be a change to the API, which is expected. However, it now means that a change must also be made to the User Interface. This should be avoided as much as possible.

The more components that must change, the higher the risk of introducing bugs at every level. It also increases the scope of testing. These factors have the secondary effect of elongating the development effort, which doesn’t allow for a timely release of the changes to production.

Here’s a very common example. In many databases, especially older ones, the customer record has fields that store the address. A business area wants to allow a client to have multiple addresses. The API should be designed so that a Customer can have multiple addresses, even if the database can only store one. Now, the development team makes a big change to the database, where the addresses are stored separately, and a customer can have unlimited addresses.

If the API were tightly coupled, then massive changes would have to be made to the API. Then, those massive changes will snowball into the User Interface. This is why Yasgar Technology Group designs their APIs to return business objects to the UI, which tries to cut these issues off at the pass before they occur. If an API already returns a customer that can have multiple addresses, then when the database change happens, no changes are needed in the User Interface because it is already designed to deal with multiple addresses, even though, up until now, it has always only had one.

By decoupling components, microservices promote agility, enabling teams to work independently, innovate faster, and improve overall system resilience. This approach fosters easier maintenance and updates, enhancing the ability to adapt to evolving business needs and technological advancements.

Versioning and Continuous Integration / Continuous Deployment (CI/CD)

One of the most powerful features of microservices is the ease of deploying them regularly. One of the most coveted wants from business areas is to have a business need defined on Monday, requirements written on Tuesday, development on Wednesday and Thursday, testing on Friday, and deployment to production on Monday. This seems like a pipe dream for many companies, but it is entirely feasible with the proper microservice architecture.

Microservices in a CI/CD environment are often automatically deployed with an automation tool. Versioning the endpoints that have “breaking changes” mitigates the risk of breaking something that is using the API.

Let me explain by way of example. A new “Customer” endpoint is released to production and is starting to be used by other applications. A security review finds that the customer’s Social Security number is sent in plain text. The development team remediates this issue and encrypts the Social Security number returned using a standard library function. This would break any application using it, as they do not expect it to be encrypted.

If the team is using a standard HTTP Customer endpoint, it will probably look like this:

/api/customers/v1

When the development team remediates the issue, they will release the endpoint as a new version.

/api/customers/v2

This allows the other teams time to incorporate the change into their code without requiring an extensive coordination effort to ensure they all release their code changes simultaneously. Once it is confirmed that all teams are using the “v2” version of the API, then the offending “v1” version can be retired.

Microservices facilitate agility, scalability, and resilience in modern software development.