True. upgrades is a huge overhead. But you also have K8s management tools for that where they manage upgrades for you. I know it's added cost, but worth the benefits.
Exactly. With being cloud portable you can take advantage of the pricing and new features that come with other cloud providers. Hetzner is for sure growing in popularity a lot.
Open source has also become a great marketing channel. That's how companies first grow their user base, especially for dev tools. Because it's the easiest way anyone can try the product.
Went through your website. I think you need some video or something so that people can understand your product better.
I am an early-stage founder here, and we normally use AWS + ECR + ECS. But, now we are facing challenges because we need to shift to a different cloud or incur costs from AWS. (credits over). But doing that entire thing looks like a 2-3 months project. So I think, if you can solve this challenge, it'd be really nice.
and the other things that you mentioned, they are somewhat easy to do if you're on a single cloud and don't have a complex infrastructure.
> We don't need to deploy environments super often, so just do it manually and update documentation in the process if any variations are needed.
So you don't need to deploy multiple times or you don't do it because the system is stable when you deploy less often? I mean is it by choice or because of some tool or expertise limitation?
> Also, for architecture stored in text files - does that cause any problems for you?
We deploy our services on every merge (multiple times a day) from CI assuming the tests pass. But we don’t re-create our Kubernetes infra when we do that. I set up 3 Kubernetes clusters (staging, prod, internal apps) when I went full-time and have barely touched them other than to apply updates.
> does that cause any problems for you?
Nope. Our Kubernetes setup is just about as simple as it is possible to have a Kubernetes setup. I entertained the idea of going with something else, because we definitely don’t need all Kubernetes has to offer. But I settled on it because it’s what I know best and the overhead+risk of something new would have exceeded the cost of the unnecessary for us baggage that Kubernetes brings.
If our requirements were different or if I was making regular changes, we would be in a very different spot. But as it stands today it is just not a priority.
how much time did it take for you to initially configure it? So with your and other comments, I'm getting a feeling that if you are just on one cloud and don't have a complex architecture, then it's pretty easy to do all these tasks, right?
And even so, how much time would developers be spending on these tasks weekly?
I personally think multi-cloud is over hyped and the complexity isn’t worth it for most organizations. The apps I am responsible for are one AWS region / 3 AZ and we have sufficient uptime. We could be multi-region but the added cost wasn’t worth the benefit and complexity. Multi-cloud makes zero sense.
Multicloud makes sense once you get to megascale where you have a dedicated team negotiating with CSPs over your discounts. If you can credibly flip a switch and move your multi-million dollar workload to a competitor, you can save big money.
This comes on top of the benefit that architecting for multi-cloud at that scale usually forces you to simplify/rationalize/automate ruthlessly and so is probably beneficial for a "mature" org with lots of cruft anyway.
That said there may only be a few dozen companies in the world where this makes sense. I happen to work for one, but most engineers don't. Even then, this is at the extreme right of the maturity curve, meaning that there is lots of lower-hanging fruit to pick first
Multicloud is just an inevitable reality--the default. The only time I have run into homogenous cloud architectures has been in large organizations and even then I was removed from the multi-cloud concerns because I was focused on a single product/service that was hosted in a single cloud infrastructure.
> Understood. But what if you have a multi-cloud setup or you want to migrate to a different cloud to efficiently use credits?
So yeah, one of the clients we were working with had to move from AWS to GCP (mostly for utilizing cloud credits). The setup was small but the estimated time was nearly 2-3 months. It's really a pain, and I think a lot of organizations don't think of doing it because when they weigh rewards and the effort/time needed, it doesn't make sense.
99% of the time it's just a docker container that connects to a database, an object store and redis.
If we need to move it then we move it... not exactly difficult or time consuming. There are always ways of half moving things too, for example we could move the container deployment to another cloud but keep our build process and object store at the original vendor and so on.
In reality we are not going to be shifting production load between cloud vendors every 2 weeks.
