In my work, the term “cloud-agnostic” gets thrown around a lot. It’s well intentioned, and quite justified - you’d be hard pressed to find a tech company that hasn’t been bitten by a major change or closing of a service provider. But I have to wonder whether it’s worth the effort to be truly cloud agnostic, or if it’s even possible given the current state of tech. The recent change to Redis’ licensing are a good example of this. Before the change, if you asked anyone familiar with it “hey, is Redis cloud agnostic?”, they likely wouldn’t have hesitated to tell you that it was. Though (relatively) rare, these things do happen. And when they do, every developer gets a little more paranoid and a little closer to a full-blown case of “Not invented here” syndrome.

That’s the worst case scenario, however. Though the risks are very real, the benefits of going all-in on a vendor aren’t to be understated.

• Cloudflare’s edge stack with Workers, Pages, R2, D1, KV, and more is incredibly compelling, especially with their pricing being well-suited for small-to-medium projects. Though Cloudflare aren’t likely to go away, significant pricing changes aren’t unheardof. And if something were to occur, it’s pretty difficult to move that entire stack elsewhere, even with the semi-recent open-sourcing of the Workers runtime.
• Fly.io and others like it offer an impressive feature set and some pretty seamless CI plugins. That said, their Docker-ish architecture and custom networking system would make it something of a nightmare to port apps powered by it to another platform.
• Supabase seems to be the favourite child in the tech community at the moment, and for good reason. Though they are proudly open-source, one can only imagine the inevitable headaches that would come along with moving a managed application to being self-hosted. Moreover, if the company were to collapse for some reason, your app would effectivelty be done for with no guarantee of security updates, even if a community fork was to materialise.

Despite this doom and gloom, I’m guilty of using many such providers. For side projects especially, the convenience is unmatched. Of course, I care a decent bit less about my side hustles than my “real” job and could probably just stomach them being gone forever. But then again, is it not the side hustler’s dream to quit their job and go all-in on your side hustle? Therefore, shouldn’t we be setting ourselves up for success if/when that happens?

At this point, another gotcha of these services emerges - the migration away from them. Can you imagine the headache of migrating your 100% Workers-based infrastructure to something else? Or rewriting all the APIs Supabase provides for you out-of-the-box? Regardless of a company’s permanence or the likelihood of their pricing changing dramatically, one must consider the possibility that future you decides $product isn’t the right fit for them anymore. In a truly cloud agnostic world, you taking your binaries and move them elsewhere. But when each service must differentiate itself in some way, it’s never really that simple.

I guess the conclusion here is that one should think twice before jumping on the hype train. If you made it this far, you probably didn’t need me to tell you that, but alas, here we are. I suppose as developers and engineers we need to decide for any given project where we draw the line, and that’s going to differ based on circumstances. But if circumstances change, how do we handle moving the line? Should we even move the line? I wish I knew.