Hacker News Reader

Comment by ses1984 | Hacker News Reader

ses1984

Why would a saas partner care so much if you're on aws?

Here's a for-instance: Walmart cares because they don't want to give money to Amazon. They also don't trust everyone at AWS to keep their hands off Walmart's data if its stored in AWS.

Now, we can argue encryption and principles of least access until we're blue in the face, but when it comes down to it, Walmart execs simply don't want their data on AWS if there are alternatives. And ultimately, that's all that matters.

There are reasonable concerns about AWS from non-retail too. AWS is using proprietary cloud services to lock in customers. Future increases in AWS's prices will be passed down to the end users.

I don't see it as so much AWS/Google Cloud/Azure is bad, but, did you build something which is impossible to decouple from. That is an upstream cost risk. If a customer can seamlessly move between their own datacenters, AWS, Google, Azure, and so on, that is a good thing.

> AWS is using proprietary cloud services to lock in customers. Future increases in AWS's prices will be passed down to the end users.

That is true of every cloud, certainly of Azure and GCP.

Building a "cloud independent" infrastructure is certainly possible, but it puts you at a huge disadvantage - you can't take advantage of any of the value-added services of the cloud provider.

>> lock in

> certainly of Azure and GCP.

Google's Kubernetes strategy means that this is currently not quite true of Google. Google must have decided that they were better off getting a large share of a smaller pie by creating an open sourcing Kubernetes. This seems quite likely to me: if Kubernetes "wins" then the profit margins will shrink due to competition but Google will be in a good position to become the premier Kubernetes hosting provider. And if Kubernetes wins, it'll be much harder for Google to lock in customers. For now and the foreseeable future both our and Google's incentives are aligned vis-a-vis open source Kubernetes. If K8S wins divergence will probably happen, but until then we'll enjoy the benefits.

This is no different from AWS, which fully supports Kubernetes (e.g. EKS). You can just as easily do a Kube deployment on either AWS or GCP that makes no use of cloud-specific services, but just like AWS, GCP has a ton of great services that are extremely useful but will tie you in to GCP.

That's proof that Google's Kubernetes strategy is working. They've forced AWS to create infrastructure that makes it easier to move off of AWS.

Google is still a distant 3rd but without the Kubernetes strategy I think they'd be much worse off...

Kubernetes absolutely does not mean no lock-in. The lock-in is just quieter (people will eventually realize this).

Use higher-level services (or even long-tail features of low-level services) that are differentiated between cloud providers from k8s, you are locked in.

Make k8s auth work cleanly with cloud auth, you're locked in.

Rely on a cloud provider service to manage master and/or worker nodes, you're locked in.

You can avoid lock-in by manually running a k8s cluster while using only the lowest-level services that every cloud providers offers (VM, block store, NFS, load balancer, maybe one or two others), but most people don't actually want to do this.

The point is that Google is currently actively working towards reducing lock-in. Storage is one area where I've seen some good movement. Microsoft is also contributing a lot of good stuff to make Kubernetes migration easier.

We'll never get to zero, and I'm sure that Google & Microsoft will eventually put more emphasis on complementary products that increase lock-in. But right now it's trending in the right direction.

I don't agree at all. The current trend is for cloud providers to create k8s operators as a way to lock you in by using cloud services in the background. The Spark Operator for Kubernetes is one example of this that was created by Google. It seems like all the major clouds are doing it (I don't actually have an Azure example, but I imagine you could find some).

> There are reasonable concerns about AWS from non-retail too.

Also, Amazon's "everything store" mentality pushes it up against industries that have never considered themselves retail before, expanding the definition of "retail" to the breaking point in some cases. A lot of companies have been surprised when Amazon expanded into an area they didn't expect, and given time a lot more companies might because there hasn't yet seemed to be a stop to Amazon's "everything store" expansion.

> Future increases in AWS's prices will be passed down to the end users.

11 years in, AWS has never raised prices for any service AFAIK despite holding a near monopoly on public cloud for quite some time.

That seems so incredibly unreasonable. It would ruin AWS overnight if it was discovered that they tampered with client data.

Even Microsoft lets its employees use Macs if they want. Use the best tool for the job.

How does anyone even find a service where it (or its providers) in some way shape or form don’t run on AWS?

You don't have to look at specific data. You could glean a lot simply from the fluctuation of the aws bill of a competitor. Oh look, the AWS usage went down by 10% after we launched 1 day shipping. Or look, some competitor's Black Friday usage didn't spike as much as it did last year, etc.

That sounds silly considering Walmart ships some "prime free shipping" stuff. In particular when I order some poster frames, it comes from FedEx ground in a Walmart branded shipping box.

It's not the SaaS partner caring, it's Kroger going "We'll buy your SaaS product, but you better be off AWS in 2 years or we go somewhere else". I've heard first-hand of multiple contracts like this.

he's saying "other retailers pushing down to their partners". Other retailers (Target/Wal Mart/etc) won't work with companies that use AWS.

Reply on news.ycombinator.com