Category: microservices

These days I am working on building a next generation mobile banking platform. One of the solutions that I was designing this week was around how to handle configuration masters in Microservices. I am not talking about Microservices configuration properties here. I have not seen much written about this in the context of Microservices . So, I thought let me document the solution that I am going forward with. But, before we do that let’s define what these are configuration masters.

In my terminology configuration masters are those entities of the system that are static yet configurable in nature. Examples of these include IFSC codes for banks, error messages, bank and their icons, account types, status types, etc. In a reasonably big application like mobile banking there will be anywhere between 50-100 configuration master entities. These configuration master entities have three characteristics:

• They don’t change often. This means they can be cached
• They don’t change often but you still want the flexibility to update existing items or add new items if required. Typically, they are modified either using database scripts or by exposing APIs that some form of admin portal(used by IT operations people) uses to add new entries or modify existing entry
• The number of rows per configuration master entity is not more than 1000. This make them suitable for local in-memory caching

This week I had a discussion with one of the developers in my organization on pass-through services. A Pass-through service is a service that wraps an existing service without much logic. Its job is to delegate to the downstream service. The existing service could be legacy service or an external third party API. The developer was questioning the purpose of pass-through services and the amount of development effort that goes in writing and maintaining them. In this post I am sharing the reasons that I gave to the developer to help him understand why pass-through services are not a bad idea and they can be helpful in the long run.

This week at the office we started work on a big enterprise project. We decided to go with Microservices architecture for the following reasons:

• We are working on a business domain composed of multiple subdomains
• The application needs to scale to twice the current load. They already have an application built using legacy technologies. We have to modernize the technology stack along with scaling to twice the current load.
• Since this is a big project we will have multiple teams working on it. Microservices architecture is well suited for a large and growing engineering team.
• Help the organization become API first. All the business APIs will be exposed using an enterprise gateway that third parties can integrate with.

Over the last couple of years I have done architecture review of multiple product teams that are on their digital transformation journey. Most of the teams were building products following Microservices architecture. They had all the right intentions to use Microservices based architecture — faster development, better scalability, smaller independent teams, independent deployment, using the right technology for the job, etc. But, most often I found teams struggling with Microservices. They failed to leverage the benefits of Microservices to their advantage. In this post, I will share reasons why I think teams were struggling with Microservices.

For people new to Microservices I recommend reading Martin Fowler’s article on Microservices. I like the Microservices architecture definition mentioned in the article.

The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

The list of reasons is below:

1. Management underestimate complexity of developing Microservices
2. No process to update libraries and tools to the latest versions
3. Use of shared services for local development
4. Lack of visibility in their version control hosting platform
5. No clear definition of a service
6. No clear strategy on code reuse
7. Polyglot programming
8. People dependency
9. Lack of documentation
10. Feature over platform maturity
11. Lack of automated testing

You can read the complete post on Medium.