Generating Microservices Boilerplate with CookieCutter

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.
Continue reading “Generating Microservices Boilerplate with CookieCutter”

Using Flyway To Manage Database Migration In Spring Boot Microservices Application

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”

11 Reasons Why You Are Going To Fail With Microservices

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.