[whoisjuan]

I disagree. The only reason for AWS slow adoption of Kubernetes was because they couldn't find a strong use-case within their customer base.

Customers knew they wanted to use it, but they really didn't know how or why it would be better than using other type of container architecture.

AWS doesn't build services for customers to toy around. Every new service is a significant investment so the data and the use cases need to be really strong.

AWS can almost always wait for any new technology to show strong signs of adoption before doing anything in that space. Their leadership gives them that advantage. Of course other vendors jump faster into new spaces because that's their only chance to close the gap.

This happens with almost everything that is new. Another example is Blockchain.

[thefounder]

Bollocks! AWS has had few horses(i.e aws ECS) in this race so they waited to see if they can win. Obviously K8 wins over ECS so now they have no choice but embrace K8. The last thing Amazon wants is to be easy replaceable with a different provider. I guess this is same with the underdogs as well(i.e Google/Microsoft) and that's why they do all they can to lock you in with proprietary services(i.e Appengine, Datastore etc).

[StreamBright]

AWS no other choice? I am not sure if you are following what AWS does (like for example the MongoDB story).

>> The last thing Amazon wants is to be easy replaceable with a different provider. I guess this is same with the underdogs as well(i.e Google/Microsoft) and that's why they do all they can to lock you in with proprietary services(i.e Appengine, Datastore etc).

Datastore has S3 API and it is trivial to replace it with other products.

https://cloud.google.com/storage/docs/interoperability

[thefounder]

Datastore can't have an S3 API and is not easily replaceable. You linked to a different product(Cloud Storage).

[ngrilly]

There is some lock-in with Google Datastore, but not with App Engine, at least with the new "standard environment" based on gVisor. I run perfectly standard Go or Python HTTP services.

[thefounder]

The thing with Appengine is that even if you run the standard env(which is more expensive and has some limitations) you are highly likely to use Datastore and other proprietary services that are tightly integrated in the appengine environment. The whole thing feels like a bait to lock-in, just like the initial pricing which went off-rails.

[ngrilly]

The new version of the Standard Environment removed most limitations (and you can still use the Flex Environment when required):

https://cloud.google.com/appengine/docs/the-appengine-enviro...

And using the proprietary App Engine API is not recommended anymore: “We strongly recommend using the Google Cloud client library or third party libraries instead of the App Engine-specific APIs.” (source: https://cloud.google.com/appengine/docs/standard/go111/go-di...)

You can use App Engine with a standard MySQL or PostgreSQL database and S3-compatible object storage.

Like you, I used to avoid App Engine because of lock-in, but they radically improved things with gVisor.

Yet, I agree about the price, especially with the Flex Environment compared to standard Compute Engine :-(

[Blackstone4]

I feel like this is quite a cynical view. Amazon and other cloud providers want to attract and keep users by providing the best product possible. This may come in different forms so some people want easy-to-setup databases (AWS RDS) others want auth (IAM) handled for them, others scalability (Appengine) or maybe email (SES). In order to create these services and to make life easier for those who want them, it may require proprietary technology that results in lock-in. Don't get me wrong. They would love some lock-in but it is not at the forefront of their minds when creating a service.

[geezerjay]

> They would love some lock-in but it is not at the forefront of their minds when creating a service.

I really find that assertion hard to believe. AWS is notoriously expensive and oddly enough its added value comes in the form of proprietary technologies which require non-transferable tech skills. The lock-in overload goes to the extreme of leading technicians to specialize exclusively in AWS services which leads to the infamous title of AWS engineer. This doesn't happen by chance, but by design. It's like a very expensive mousetrap designed to help victims get in but being practically very hard if not impossible to get out.

[scarface74]

The most expensive parts of AWS for us are:

RDS - hosted non proprietary databases.

EC2 - Standard VM hosting

Redshift - a proprietary OLAP database that uses standard Postgres drivers

S3 - object storage. But there are so many S3 API compatible storage providers, there is little “lock-in”

But the fact is that lock-in is overrated. Your CTO is statistically as likely to move their entire infrastructure just because a few engineers promised it would be “seamless” as your DBA is going to move away from their Oracle installation because developers “used the Repository Pattern to abstract database access”.

[Blackstone4]

I feel like often people want to have their cake and eat it. As in they want both freedom to switch services easily and easy-of-use. What I am saying is that ease-of-use sometimes comes at a cost and that cost is lock-in.

No one is forcing you to use AWS. You could build your own private cloud datacenter, implement OpenStack, configure k8 and deploy your docker containers. If a server fails, replace it. Install your updates etc. To me that sounds like a lot of work (assuming I don't have a large organisation behind me) and I would rather have some of that setup for me. It's a trade-off...

[thefounder]

What stops Google from open sourcing Datastore, or AWS from open sourcing dynamoDB? These cloud providers with proprietary services are the new Oracle. They are actually worse than Oracle b/c they can cut off your access to your database in seconds.

Google open sourced k8 so that they can get a pie from AWS and then lock you in with other proprietary services.

[Blackstone4]

> What stops Google from open sourcing Datastore, or AWS from open sourcing dynamoDB?

They have invested millions into creating cloud software. If they open source it, what is stopping other firms from taking that software and creating their own cloud offering?

Would you work for free? Would you open source all the work you have done?

[martingxx]

Its 2019 and people still confuse the different kinds of "free" when talking about open source software.

(Also, yes, I open source as much of my work as possible, and I'm paid to write it)

Also, AWS is BUILT on open source, they just don't open source the extra bits they added on top. Just like how Microsoft took an open source tcp/ip stack and open source web browser, added some stuff, and called it their own.

[thefounder]

They are also using millions worth of open source software.

Why would they open source it? To provide a way out to customers. They don't even provide a mongo-like license.

I can't forget a session at Google I/O how they were insisting that appengine is not open source because we are too dumb to understand it....yeah sure what about k8, now? I can run it on my Mac, I even contributed few commits.

[scarface74]

DynamoDB is dependent on many of AWS’s services and infrastructure.

[tallanvor]

This post reminds me of a junior developer here. Very smart and driven, but not to the point in his career where he has a full picture of what we're doing. Kubernetes is his current obsession, and he wants to use it for everything.

AWS is implementing Kubernetes to make it easier for people who use it already to migrate to their service. It's the same reason all other cloud providers are doing so.

I can pretty much guarantee that the products Amazon introduces aren't designed to lock people in or make it hard to switch, it's to make it easy for them to start using AWS and not NEED to switch. They design products and their APIs to solve problems customers are facing. This is what everyone is doing.

[zwischenzug]

Author here. This is absolutely not true. I worked for an AWS customer that wanted to use it and had a crystal clear strategy for why. The idea that AWS didn't have a business case for EKS is _laughable_. Also laughable is the idea that K8s didn't have enough traction to be worth the investment.

EKS was a bolt from the blue - we'd been quietly told by senior staff that ECS would be moved to a K8s API (which we may have taken). My feeling was that business trumped the engineering view that ECS was enough, but that's nothing more than my speculation.

[scarface74]

Because you “worked for an AWS customer” that wanted it is not a valid reason for why AWS should invest in the service.

[whoisjuan]

Why would you think that a particular AWS customer anecdote (at your 1 to 1 scale) asking for K8s is validation for building a managed K8s service at the enormous AWS scale?

I think you didn't understand my argument. I'm not saying people didn't have use cases. They likely did. But nothing at an enterprise level. Nothing at the moment could hint someone paying multi-million dollar contracts contigent to having a K8s managed service.

A single customer asking for K8s doesn't prove anything in the larger picture. A larger picture where you have to invest millions of dollars if you move into that particular space.

Also, please pardon my delicacy here, but what's the need for using the word "laughable"? I don't understand what's laughable about my position. I really don't get why people think that the best way to prove their point is to undermine a challenging opinion with pejorative adjectives.

[jpatokal]

This sounds... implausible, given that every metric I've seen for k8s is pretty much hockey-sticking. For example, it's the 2nd largest open source project ever (after Linux) by contributors & commits.

The OP's hypothesis is that Amazon would much prefer ACS to succeed, because it exists already and provides nice lock-in, and AKS was only launched (after considerable internal shitfights, I'd imagine!) once it became clear they can't just ignore k8s.

[repolfx]

Linux isn't the largest open source project ever! Look at Android - it incorporates Linux and then adds vastly more on top.

[quickthrower2]

With K8s you are not spared having to understand the cloud architecture, or containers or Linux. You need to know all that and then how K8s works

Whereas something like Lambda in theory you can know less, because it hides stuff from you. You don’t need to understand Linux to use it.

I imagine this would have limited the number of users wanting k8s.