Earlier quoted context omitted.
lol this is how it works at a startup - 1. auth? probably an internal service, so don't expose it to the outside network. 2. monitoring? if the service is being used anywhere at all, the client will throw some sort of exception if its unreachable. memory problem? it should take 3. deployment? if its a go service, literally a bash script to scp over the binary and an upstart daemon to monitor/restart the binary. rollb…
I agree more or less with 1 and 4 mostly. But for monitoring either you would have to monitor the service calling this microservice or need to have a way to detect error. > if it does have memory leaks anyways, just basic cpu/mem usage monitoring on your hosts Who keeps on monitoring like this? How frequently would you do it? In a startup there are somewhere in the range of 5 microservice of that scale per programmer…
For example, kubectl rollout assumes that your service is already packaged as a container, you are already running a k8s cluster and the team knows how to use it. In that context, maybe your method is a lot better. But in another context where k8s is not adopted and the ops team is skilled at linux admin but not at k8s, my way might be better. There’s no one true way and there never will be. Technical decisions cannot be made in a vacuum.