Thanks for the comment, let me try to answer :) >if the dev leaves? Their code should be in a viewable repo and it should maybe even be documented. If it's not

Thanks for the comment, let me try to answer :) >if the dev leaves? Their code should be in a viewable repo and it should maybe even be documented. If it's not, no sweat, because I've seen lots of undocumented code in my life from bigger teams. Continue using the service until someone becomes an expert in it or the business problem is solved again. But, ideally you would have a few devs as experts on a few different services. It doesn't need to be 1:1. >Service goes down while dev on vacation I'm thinking a production service should aim to have 2 devs and 2 ops supporting it. They could each be responsible for 2-3 major services and 2-3 minor or experimental services. >Single point of failure Let's say you have a service that, if you give it a user id, returns only the history of that users orders. It doesn't fulfill orders or give delivery statuses or help initiate a customer support conversation. It is conceivable that if this service goes down in production, there may not be a way to get order history from anywhere else quickly. The information definitely exists in another db in another service somewhere, because that's the db where the order history service gets its information in a read only status. But it's not all neatly organized and available over HTTP. What do you do? You make the order history team own their SLA, otherwise their SLA will own them. In microservices world, you can't blame other people if you go down. You just have to do everything you can to keep your service running, by configuring AWS yourself and being on call yourself.