1. 25

    1. 13

      There are good pain points, nice article. Resonates with me a lot.

      In addition, I can make a small contribution that sometimes (may vary from project to project) it is just too tedious to get environments up and running to develop using architectures like this

      If you have a small team, you will end up fighting with all kinds of mocks for your cloud (if not deployed as remote development environments, which is costly if they are big enough), and then you will need to fight with data reconciliation, uniformity and proximity (similarity of your data with your customers/clients data) and after all, testing that are accurate enough to rely on

      Debugging it is utterly insane in a microservices architecture world, and if your team is small enough (~10?), you could lose days of work just to discover what’s going on.

      1. 3

        At my previous gig, I was part of a team who had built to generate ad “dev” environment. We had 85 (and counting) microservices in production, so the dev env had this dependency graph and based on what you clicked through the portal would remove or delete services. It was quite something, unfortunately I left a few months before the stable release although many developers were already using this new system to spin up the dev env in k8s.

        For debugging, you need distributed tracing. I don’t recall having too many problems once a framework that took care of the basics (logging, tracing, etc.) was introduced. One could argue that at a certain point there was little space for variability and innovation as everything was tailored around this home-grown golang framework.

    2. 10

      While these sound negative, I don’t mean to say this is a negative experience. There are many positive things I’ve noticed too, but I already expected them because proponents of microservices have done a good job of marketing the idea to me already.

      Having been burned by microservices in the past, I’d be interested to hear more about the positive things you’ve noticed!

    3. 3

      I don’t yet know how to detect dead code in microservices.

      Maybe have a network monitoring system that can count how many calls are made externally? Seems like this should be done at the level of the framework used to build the microservices, whether nginx or Django/Phoenix/Flask or whatever else. HTTP servers generally already do this counting and have ways to tell you about it, you just need to aggregate it and make it visible… Though I guess that becomes their “introduce a call counter into every endpoint” option.

      Dynamic languages sometimes also have trouble with dead-code detection for similar reasons. Your functions are loosely coupled and can be pieced together at runtime.

      If you’re unsure whether or not code is dead, and that’s why you don’t want to remove it, then that uncertainty is already telling you a great deal about your architecture and the developer relationship with it.

      hoo boy this is so true.

      I eagerly await the author’s revised assessment in a couple years. I would also love to hear them talk about what benefits of microservices they’ve concretely observed. They say “there are many positive things I’ve noticed too, but I already expected them because proponents of microservices have done a good job of marketing the idea to me already”; would be interesting to hear a compare-and-contrast of the marketing vs their observations.

      1. 2

        If you are in any web service, setting up tracing (I think Honeycomb is the best at this) is a no-brainer. Just a major win, and makes answering a lot of questions super simple.