This week’s Top 10 is a little bit different...
The latest episode of our Continuous Discussions (#c9d9) podcast focused on Microservices and Continuous Delivery.
Ever since the episode aired, we’ve gotten great feedback from people—who are either curious and just starting out with evaluating Microservices, or sharing their struggles with decomposing their applications and managing microservices in Production.
Anders has previously written about the challenges of Microservices and best practices for designing Continuous Delivery pipelines for microservices-driven apps. The latest #c9d9 episode had some additional great tips shared by our experts that we thought were worthwhile to call out.
Below are some takeaways from this episode. If you are looking into Microservices as a viable architecture for your offering, we encourage you to watch the full episode below for more goodies and some recommendations for tools of the trade.
1) Microservices take on one of the best practices of writing code–do it in small batches. Every time you add a feature, ask yourself if it really belongs in this service. Individual features might end up being their own services. - Daniel Rolnick
2) Anything that is going to be done more than once needs to be code-defined and not human-defined. This ensures your pipeline is versionable and testable. - Usman Ismail
3) Microservices provides a 10:1 benefit compared to monoliths. It allows you to deploy to a small batch of your servers, enabling you to roll back and scale up again quickly. For a release that might take 10 minutes in a monolith, it would only take one minute in a microservice. - Darko Fabijan
4) Don’t just jump on the microservices bandwagon to be cool. Understand why you are switching to microservices–is it for code? Operational reasons? Scalability? If you don’t know what your most important goals are in switching to microservices, then don’t do it. - Anders Wallgren
5) It’s not a one size fits all model–you can still do Continuous Delivery and microservices with monoliths. Mix and match microservices and monoliths, if combining the two works best for you. - Daniel Rolnick
6) Microservices put you in the world of graphs instead of trees. You can go to an independently deployed service model, but be careful about when you are deploying and how that impacts your graph. - Usman Ismail
7) Monoliths are cheaper, but will come to bite you later. While microservices may be slow in the beginning due to the increased need for monitoring and logging, it will save you in the end. - Darko Fabijan
8) When you move from monoliths to microservices, you lose comfort and certainty. Implement phase and canary deployments to give you back the certainty you lost. - Daniel Rolnick
9) Having a monitoring system, like DataDog, separate from your own logging system doesn’t make sense. De-bugging at that level requires a unified logging system. - Usman Ismail
10) Microservices is a journey. Starting out as a microservice won’t allow you to understand your problem and pick the correct service boundaries. Let your monolith decompose naturally as you gain the skills and tools to run microservices. - Anders Wallgren
Watch the full episode: https://youtu.be/ciGcTivBSVg
The original article can be found here.