Granularity – The word micro in microservices is not completely related to the number of operations, apis or endpoints that will be exposed from your service. Some people tend to think that they can have a single operation per microservice which will leads to a number of services. Managing those would be a nightmare. It’s difficult to implement microservices immediately without the proper requirements in place, but you also want to ensure that your scope is not too narrow or too broad.
Architectural Complexity – Microservice architecture is fairly complex. Anyone who is planning to adopt it needs to understand the various components involved in addition to development efforts. Apart from the new development and architecture style, you also need to consider that things like automation, service discovery, and service registration rely on a service choreography other than service orchestration.
Service Ownership – Organizations must assign owners for each microservice. Service owners are not the people who are involved in every day development, but rather who are responsible for service governance, lifecycle, promotion etc. Service owners are those people who decide what functionality goes into those services, when to create a new version, when to retire a particular version and to decide if another microservice should be created instead of adding functionality to the existing service.
Culture of Automation – With microservice adoption, the number of components involved increases dramatically and managing them manually will be inefficient, error prone, and next to impossible. We need to make sure that we have automated builds or CI/CD using tools like Jenkins or TeamCity. If your organization is using Docker, then you need to set up a docker registry and find an automated way to create docker images and keep those images updated. You can use tools like Chef or Ansible for automated environment preparation.
Refactoring Services and Databases Together – You need to avoid migrating existing services to microservices along with database because it takes time to find the right granularity of service. If you change the service and database together, then you will need to handle the database schema change over and over. If your service is too narrow, then you will need to break your schema to multiple schema, but if you decide later on to merge your microservices then you will need to combine your schema too. It’s always ideal to test your service granularity for a while. Once you feel confident enough, then move forward with your database schema breakdown.
Follow the Crowd – If you think you should use microservices because they are new and popular, you may end up in deep trouble. Before you proceed with microservices, you need to understand the pros and cons. Be sure to consider carefully what problem you are looking to solve and what the benefits could be.
Going Full Speed – Organizations need to start with just a few services to see how they are working. Determine what the right granularity is, what new components are required, what new skills are required, what kind of automation is needed, and what organizational and management changes may be needed. Once you are satisfied, you can add a few more services and repeat the same testing process. Initially organizations need to be patient so they can see the benefits. The journey can take a couple of months to a year, but once you address the challenges and implement the changes, the rest of the journey should be fine.
