I’ve been thinking about micro-services lately as a way to organize projects. I think I understand the concept better when I think of them like dynamically-linked libraries. At first, it seemed inefficient to have different services communicate through HTTP calls instead of just using them in memory functions. However, by separating small components into different independent services, it allows updates to occur to only the service like updating a DLL, instead of having to update the entire app. The benefits are worth it, to try as an experiment, at least. They provide strong module boundaries, allow for independent deployment and allow an agnostic choice of technologies to work together as a system.
The strong boundaries between services are enforced at a functional level. The service has to have an API for other services to communicate with it. Each service has to check the status and health of itself and other services. Since each service is independent, they allow for a higher granularity of testing. To be truly independent, each service must manage its own database. The database can be collocated on the same machine, lowering the latency between the app and the database. To get data from another service, you need to use the other service’s API, not a database query. While projects with submodules can enforce more modularity, there is still a certain amount of glue code needed for reusability. The benefit of a truly independent service is that it’s easier to scale up to multiple instances based on the demand of said service, instead of the entire app.
Things you need for micro-services to work.
• A container technology like Docker, and a management of multiple containers to work together like kubernetes.
• A private container repository like Docker Hub for the containers.
• Kubernetes can deal with distributing the micro-service containers across the servers, automatically scaling across one or multiple machines to fully utilize resources. It can run locally on your laptop and have the same distributed container system used in production as when developing the code.
Negatives
The negatives of microservices are that it increases operational complexity, creates a distributed system, and is only eventually consistent. The operation complexity is dividing a project into independent service containers, instead of a simple project with all code inside one repository. Now you really need a container cluster manager like Kubernetes instead of a simple git pull. Its only eventual;y consistent because it decentralizes data management.
What happens when you rewrite your monolithic app into microservices? What if you increase complexity, make the app slower, and use more costly service providers? Technology keeps changing, container technology will keep improving in efficiency. I think its an idea worth exploring.
