Welcome to this three part series on microservices. I talk about this a lot with my customers and I thought it was about time to put a few blog articles out around it.
Microservices are a popular choice in a marketplace where systems are becoming increasingly more distributed. Getting it right is difficult though. If you succeed, however, you can reap some significant benefits from implementing Microservices.
Managing a large number of services
Your organisational structure will no doubt have to change when moving to microservices. You cannot have dedicated teams that look after each individual service 24/7. Instead you may want to move to a product-aligned model where services are grouped together based on the value that they deliver to the customer.
Aligning your teams around these products can have a benefit in both building, running, and maintaining your solution.
Keeping track of small and targeted services
Moving to a DevOps model is almost inevitable when running a large scale microservices operation. The people building the services need to be responsible and accountable for running them, otherwise you will not reach the quality and pace required to move many services into production quickly.
At the same time the sheer amount of services will require you to cut layers of process around who is responsible for each on at any one point.
This touches areas such as on-call rotas, training, daily rituals, engineering time allocation and others and will likely mean a fundamental change in how the organisation operates. (compared to an organisation building a monolithic app)
Orchestration, Automation & Monitoring
While a major benefit of microservices is that you can host, update, and deploy each service independently, there is also a benefit in using orchestrators for bundles of services. (Service Fabric, Kubernetes, etc.)
If you decide to go down the route of an orchestration model, you will then need to consider aspects like geographic redundancy, failover, and high availability, as you are betting on a single cluster to run several services. There is obviously a cost saving involved and many orchestration platforms come with additional features like integrated service discovery or distributed memory management.
On the other hand if you choose to use other platforms you need to implement these services yourself, or architect them in such a way where they are not required.
Everything needs to be automated. From your build to your deployment. A move to microservices will often reveal manual bottlenecks in processes that need to disappear in order to make the services a viable option for your organisation.
Getting monitoring right will be paramount during your move. With microservices you cannot simply log onto a machine to get event logs. Your engineers need to think about what information they need to know about the service and implement a logging strategy across service. (e.g. introduction of a correlation id for actions that touch several services)