Hacker News new | comments | show | ask | jobs | submit login

I've previously had to work with an application that was deployed to multiple clouds. In our case, we deployed the whole app to each cloud as an independent environment, so our environments included entries like: foo-production, foo-staging, foo-development, bar-production, bar-staging. It kept the architecture a bit simpler, but in turn required more extensive monitoring and testing. The biggest annoyance was having to setup tools and services multiple times. If you automate stuff it's not so bad, but not all tools can be easily automated.

If I were creating a new app I'd probably contain each backend service to a single cloud environment. Different services can be in different cloud environments, but no cross-cloud services. I'm uncertain the extra complexity would be worth it, at least for many of the use-cases I'm considering. Having fewer environments to setup and maintain is a big win in my book.




Yes, this has been my experience with various companies attempting to do this - however there's been a lot of progress recently in both cloud vendor standardization and the rise of containers and kubernetes that makes this much easier.

Running multiple Kubernetes clusters in different cloud vendors with configuration details abstracted away in a more self-contained service that can be deployed by itself as the bootstrap process makes things much easier. Consul is a good system for this, deploy it once (manually if necessary) then everything else refers to it to figure out the environment details automatically.


We're using Rancher and Terraform to achieve this. The operational overhead is massively reduced compared to just a few years ago.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: