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.Continue reading “Why is it ok to write pass-through services in a Microservices architecture?”
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.
Today, I was working on an application that uses Microservices based architecture. Each Microservice had its own schema and they talk to each other using their published contracts.
We wanted to keep database migration script with each Microservice rather than keeping a common module to manage database Migrations. We might later migrate to common module for database migration but we want to start by keeping schema for each Microservice separate.Continue reading “Using Flyway To Manage Database Migration In Spring Boot Microservices Application”
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:
- Management underestimate complexity of developing Microservices
- No process to update libraries and tools to the latest versions
- Use of shared services for local development
- Lack of visibility in their version control hosting platform
- No clear definition of a service
- No clear strategy on code reuse
- Polyglot programming
- People dependency
- Lack of documentation
- Feature over platform maturity
- Lack of automated testing
You can read the complete post on Medium.