0

I am used to, and instinctively want to, deploy microservices individually. To understand the dependencies/contracts between them and roll-out updates in such a way as I can monitor the success of individual changes, one at a time.

However, I see a number of teams that seem to treat a set of closely related microservices like a monolith - pushing out 5/6 new applications in parallel as a known and tested single unit.

Susan Fowler writes in her book Production-Ready Microservices a checklist of production-readiness characteristics. One is...

"Are deployments to production done all at the same time, or incrementally rolled out?"

When I first read this I assumed she agreed with me, that incremental was preferable. But I can see how it could be read both ways?

What did Susan Fowler mean when she wrote this, and what are the advantages of either methodology?

Andy Hume
  • 40,474
  • 10
  • 47
  • 58
  • Hey Andy could you expand the idea behind pushing out 5/6 new applications treating them as monoliths? Did you find the answer to your question? – Willemoes Jul 07 '17 at 00:06
  • 1
    Hi @Willemoes. What I've seen is that teams that are used to developing on a monolithic application, like to batch up changes across multiple services into a single commit (in a monorepo) and a single deployment. So an API change and any associated client change are rolled out in one deployment, despite the fact there's no guarantee about which will succeed or startup first. If the client starts-up before the API then this leads to obvious failures. – Andy Hume Feb 23 '18 at 23:15

0 Answers0