Weekly Top 10: Considering Microservices? Here are Some Tips from the Community to Keep in Mind

Written by: Electric Bee
3 min read
Stay connected

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.
Panelists Usman Ismail , Daniel Rolnick , Darko Fabijan and our own Anders Wallgren discussed some of the best practices and tips to approaching a transition to microservices.
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.


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.


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.


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.


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.


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.


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.


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.


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


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.


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.

Watch the full episode:

Stay up to date

We'll never share your email address and you can opt out at any time, we promise.