3 ms·

Thanks for all the info! Very informative. "Updating dependencies across all services is somewhat of an anti pattern in microservices, this chain of dependenc

• chuhnk 11y ago
  Very early on we had a lot of critical updates in core libraries which meant rebuilding everything and releasing but at the time the number of services were quite low and we were still in the R&D phase. Overtime that maturity meant changes going out were mostly feature based and we could afford to lag those things out. You're right though, certain things require rebuilding everything but we try to approach that pragmatically. On the platform team we'd have ownership of say 20-30 services so over a period of a week we can push those through a staging and load test environment then to production. We have 4 or 5 other teams that do the same. There are tools to ensure we can keep track of which libraries are in production and if anything is out dated. Like I mentioned before. There are definitely tradeoffs to microservices and they don't make sense for every use case but if you look at the companies that adopted this architecture pattern you'll see the common journey they all went on. Monolithic architecture for the first few years, scaled by brute force, money and people. Eventually stalling in development and organisational speed of execution. Taking a step back to reevaluate and then determining a migration path to a new decomposed service oriented architecture.