Hacker News Reader

Once you have your production systems running on a cloud vendor it becomes increasingly difficult to move off it regardless if you're only using OSS components, there's an inherent risk with every migration that grows the more services you use and years you host on it that needs to be offset with any migration and given the major cloud vendors are comparatively priced, there's little incentive to invest their time and energy doing that instead of focusing on their core business.

The small players will always stay niche, a cloud is effectively a network monopoly (like iOS and Android) with most companies only wanting to invest in the cloud that's going to have everything they need when they need it, they'll still offer proprietary services to differentiate against the other 2 cloud vendors and additional way to lock you in and make it harder to migrate away.

You could choose to build out your system to be completely cloud agnostic but that is generally regarded to be economically irresponsible in itself preventing you from leveraging the best features available in each cloud.

...but that is generally regarded to be economically irresponsible in itself preventing you from leveraging the best features available in each cloud.

This is only true as long as the costs of maintaining a cloud provider abstraction layer are greater than the costs of being locked in to a single vendor. I believe that some businesses, once they are armed with an abstraction toolkit like this, will be able to employ arbitrage between the cloud vendors for themselves, and sell that toolkit to other companies who want the same kind of freedom.

And then somebody creates a free software alternative, and will maintain it and keep it up to date.

Speed to product, risk, and access to talent(via other people's code) matters much more than cost, for most software business.

The problem of leaky abstractions can't be solved by slapping yet another abstraction on top. The best case is that you become locked into your cloud provider abstraction layer instead of the cloud providers themselves - and then what stops them from becoming just as monopolistic?

> locked into your cloud provider abstraction layer instead of the cloud providers themselves

but the assumption is that this layer is free (due to OSS), and the "owners" of this layer cannot pull the carpet under you by raising prices.

> You could choose to build out your system to be completely cloud agnostic but that is generally regarded to be economically irresponsible [...].

I don't see it being anywhere near that clear-cut.

Seems more akin to what the RDBMS world went through for a long time, and still does, because people insist on using things other than Postgres[1]. You can stay SQL-standard compliant, writing your app to be portable. Or you can use these appealing proprietary extensions to the spec, and not be portable.

Seems like a majority of folks writing in-house choose to use the extensions, and the majority of folks who want others to use their software make an effort to be cross platform.

You'll probably see a similar split with cloud services, although I'm not sure it will necessarily follow the same lines.

[1] That's a joke, there.

Yes, but except at the micro level you need capital to compete, and getting hold of capital means paying rent to those who already have it. If you are clever you can make more than you pay back in rent, perhaps so much that you are in a position to lend out a surplus and collect rents of your own. But once you join the rent-collecting set, your economic incentives change drastically and you'll start getting lots of offers for moat digging services.

> but I don't think the major cloud providers have much of an uncrossable moat

Billions of dollars and years of constructions to just start trying to enter the market, where you will fail because your offerings are relatively pathetic on multiple fronts.

Billions of dollars spent means nothing unless it actually takes billions to launch a hosting company. It doesn't.

You'd need to have some damn clever and hard to copy idea to have any competitive edge.

When Google and Amazon are not making their own specialized hardware (good luck implementing your own TrueTime or TPU or competing with them with ML or DB products built on off-the-shelf stuff) they get custom made chips at prices you can't by Intel et al and have things like a very sophisticated SDN backed by a private global physical network infra and enormous amounts of expertise of building and running very efficient DCs. And then there is a software stack which often is literally more than a decade ahead of industry practice.

All the things you list are not a part of the moat to compete with the big providers. They are barriers to becoming as large as them. But 10,000 smaller hosting companies could easily start to cut in on their long tail customers. Most any mid size hosting company could handle the traffic and compute of 95% of companies out there.

You still haven't given any indication what those mid sized hosting companies would hope to compete on for the "long tail customers". Even if all the scale advantages Amazon and Google have currently don't translate into better prices across the board (mostly because they like those margins on e.g. network egress and they have sufficient lock-in for most customers) why, as someone in charge of provisioning cloud facilities for some small or mid-sized company, would I even contemplate going to a competitor?

What's gonna be more useful CV and CYA wise? Who's ever been fired for choosing AWS? How is being expert in <obscure hosting provider> going to advance my career? Where do I hire people who know about <obscure hosting provider>? How would I even realistically learn that <obscure hosting provider> might be a good fit for my needs?

I’d love a world where an ML chip is baked into phones, motherboards, and the like so we can move our data out of the cloud and get the same features.

Honestly I can’t see the cloud making sense for another decade.

NVidia’s new hobby board for $99 + open source has me imagining a future where someone like myself can offer similar experiences to Alexa or a number of Googley features to family and friends in a few years.

> We are in the process of doing the same with our DB and will migrate from a hosted Aurora instance.

Just curious, you are going to host your database on k8s? Or is there some other solution you are looking at?

My understanding is that k8s is great when you need stateless services, but gets more complicated when you need to maintain state. Been a while since I looked at it, though.

You can actually run production ready db in k8s pretty easily. There is volume and stateful set and DNS, I could see limit to what it could run.

Yes, we are putting our production mysql (mariadb) into k8s. We use a stateful set and the data is stored on persistent volumes. Even if the pod or whole cluster goes down, the data remains. So far, I am finding it more stable than a bare metal setup. Because if the db instance fails, k8s kills it and spins up a new instance using that same persistent data disk. In the meantime, there is a read replica running on a different node that can take some failover.

We also have a job that runs nightly to make a dump of the db and store it in the object store and the persistent disk has a snapshot scheduled for every two hours and in both cases, we are backing up the binary logs, so we can do point in time recovery much like AWS's Aurora offering.

We may eventually switch to a mariadb Galera cluster where there are 3+ master pods that distribute the load and can stay available if one pod dies. But I haven't done the research on stability of that setup yet. A few years ago it wasn't ready yet, but I imagine it is by now.

Yeah. I really want to go back to managing my own database servers and ElasticSearch servers....

you get what you pay for. If you use managed services from a vendor, you get convenience for the price of lock-in.

You’re always locked into your infrastructure. Out of all of the business risks that most companies face, the least is being locked into your cloud provider.

Your CTO is no more going to risk an infrastructure migration because you pinky promised that it would be “seamless” than your DBA is going to migrate from your seven figure Oracle installation to Postgres because you used the “Repository Pattern to abstract your database access”.

And yet, I know many people that are chomping at the bit to migrate away from Oracle and just as many more that have successfully migrated away. Infrastructure cost can be a significant cost of your business depending on what you do.

We are using elasticsearch for non-critical log management. But as for the mysql server, what maintenance/management are you really getting from a managed service like Aurora or Google Cloud SQL?

Our K8s deployment is setup to automatically make backups and test those backups periodically with a full restore. It also notifies us in case of a failed backup. Updating the software is as easy as a single helm command and scaling is about the same as with Aurora. Either you set it up to scale up automatically or you go in and upgrade instances when needed.

Aurora admins aren't monitoring your server for performance issues then making configuration tweaks to speed things up. So I'm not really seeing a lot of difference.

What are we getting? Automatic updates, backups, point in time recovery, multi AZ redundancy of storage, autoscaling synchronous read replicas, and much better performance than your self hosted Mysql instance.