"The best way to get the right answer on the Internet is not to ask a question, it's to post the wrong answer." - Ward Cunningham (possibly)

Thanks to those who've commented with corrections/suggestions, I'll go through them try and get the content fixed up where possible. Will need to have a lie down and possibly an epidural before going through the comments again to pull out the changes needed.

Hello, this is dwmkerr the author - your comments are all spot on - the earlier in the book you go the more work it needs, I've learnt a lot along the way TBH probably the entire first part needs a rewrite, that's actually going on at the moment as I'm working with a publisher.

I've linked to this post/comments on the repo (issue #210), they should all get addressed but it might be a while before the online version gets sorted, I'm closing out the final chapters online, once I've done this I'll likely go back to the beginning and rewrite/edit/put in a more consistent style (more code snippets, fewer screenshots etc).

Love it :) I think the "consistently connect to a projector" is similar. Moyle's Law seems popular here and has generated a great conversation, I'll raise it as a suggestion on the repo and see what people think!

I guess since it's lasted 20+ years, perhaps it's more prescient than I thought?

EDIT: I see that you've submitted an RFC but it misses (what I think is) the point. It's really the corollary of the law that is important as it states how hard it is to do date/time correctly (and you'll notice that the bulk of the discussion here is on the corollary). As I noted above, this was intended to be funny and including it in a list with real laws is just that much funnier!

That's awesome! Hyrum's Law is one of my favourites in the repo and one I share the most often :)

I've been working on a number of microservice projects and have found them to at times be wonderful, at times frustrating. All in all I think it's just a case of YMMV, that with or without can be fine, as long as the decision making is sane :)

Hi Adam,

Thanks for the point! In this case I meant more the situation that the same service (single service, single DB) might be running with more than one version concurrently (during a rolling deployment, or a canary deployment etc) which can lead to issues. The other case is that if services depend on an old contract there could be times where teams might run multiple versions of a service to allow different APIs to be used, rather than a single version of the service which exposes all current compatible APIs. Although to be honest, this is an issue with any service.

Thanks gfiorav for the comments!

1. I think here I was going for 'death' more in terms of the end of the hype, rather than the approach! 2. Agreed. As people get more familiar with the patterns, tools and code and so on it does get easier. The point is more that it can be a hell of a journey :)

I see what you mean. What I was trying to say is that regardless of whether you have combined devops or separate dev/ops, there is a lot of complexity in managing an orchestration cluster. I kind of muddied it by suggesting the devops approach is important to be building good software (which I think is actually arguable).

However, I don't actually think a central team is always necessarily the best way to handle the cluster, it depends on the setup in the org and how many people are using it. In some cases it might be best to have the team who use it most heavily handle it, and share their best developers with other teams on rotation. But there's lots of options here. I agree the points are a bit unclear!

Definitely a good approach, I'd like to update the article to mention this as a recipe for success. The only challenge I've seen is when the old app is still doing work behind the scenes, such as running crons or dequeuing messages or whatever.

Thanks for the comments. When I was writing the article I kept on thinking that really this is just the same old fundamental problem in a new guise, which is in many ways just how to manage component boundaries and dependencies, particularly when you are looking at a system which is being handled by more than one person.