Setting up microservices is really quite hard. Its not just about the technology but it involves culture and habits that the team have in order to have the discipline and also the ease in order to create services that would scale well. One would have to kind of switch the thinking behind all the best practices and theory. I kind of summarized some points that are found interesting about how some of the companies deal with and manage microservices.
Important: These are not best practises but it is more of tips of how to get microservices working.
- Use some sort of cloud/virtualization technology (although I say it is not really just the technology but this is like the minimum needed). Why do you need this? It is so that you can easily scale your individual components. Imagine if you were using the traditional way of buying hardware in order to scale up? The moment you attempted to scale, you will be told that you will be told that you would have to wait a couple of months just to get that hardware up and running.
- Some components one would need in order to get the whole thing up and running would be:
- VMs or Docker containers to host the compute services
- Event bus - The one component that would handle all the messages generated by services. The events that occur would distribute among all the services in a pubsub way of doing things.
- Centralized logging - For convenience in trying to understand what is happening in each service within the microservices world.
- Services/apps in the microservices architecture has to be small and nimble and has to ensure that it should only do 1 thing and it should do it well. It should be coded such that the whole model of that services can be maintained in a single developer’s head after just reading it and it is maintainable that way; ideally. But with these small codebases for each service, it should be easily replaceable. If you try to scale a component and it starts straining beyond a certain point? Just kill it.
- If you need a library of some code base to be distributed among your service, just don’t do that. Instead, one you could do is to create a distributed service instead and let that handle all that load/work
- Each service should just already just expect errors. Network fails, Other components will fail. Only thing you would need to just ensure that the service would be able to withstand all that.
- Centralize your logging with a distributed service. If you have like tens/hundreds of microservices and each one runs like 4-5 copies of itself, you would need to be crazy to go into each and every single one of those service to get the logs.
- Battle between async and sync services. Some of the speakers were all for async microservices as that seems to be the natural tendency of the microservices world. However, async services are not easily understood by developers; developers tend to think more of the synchronous way of doing things where processes occur in some sort orderly linear fashion. But whatever it is, one should just stick with paradigm of communicating any events that occur back to event bus.
References
Here are some of the videos as reference for all the points that I mentioned above:
- Dealing with microservices for the frontend. Most talks out there actually talk about how microservices handle back end services but this is one of the few that gave a few ideas of how to do front end in the microservices world. https://www.youtube.com/watch?v=wIID1wHZWpg
- The philosophy behind how microservices came about. Kind of interesting on how he found inspiration behind the microservice idea by looking into Biology and emulating that design. https://www.youtube.com/watch?v=-UKEPd2ipEk A pretty nice summary of some of the challenges that one would face when doing up microservices. https://www.youtube.com/watch?v=Ztjk4RGc4gI