> EKS (like all AWS services) is heavily integrated with AWS IAM. As most people know, IAM is the true source of AWS lock-in
This one thousand times over. Lots of companies have multi-cloud on their strategy but when it's time to actually implement it they find that the cost to adopt hyperscaler #2 is just the same or even more as they spent on integrating hyperscaler #1. While Kubernetes makes workloads portable between vendors, organizational processes for "boring" chores like IAM, tenant provisioning and billing/chargeback aren't. Integration of these processes can get really expensive if you need to re-implement basic "enterprise" process like e.g. four-eyes-principle/seperation of duty on role assignments for each of your cloud vendors and technologies. The IAM systems differ ever so slightly across vendors and that brings a ton of complexity.
The larger the company, the more likely it is that the real bottleneck to cloud adoption is on these processes, not the technology. I know it's hard to imagine if you're coming from a startup background where you can just take the company credit card and get an account on AWS, GCP or Azure in a second. But for developers in big co., acquiring a public cloud account may take months and forms over forms of paperwork, getting roles put into the central corporate directory etc. The investment into these (often atrocious) processes for hyperscaler #1 create a big lock-in.
Disclaimer: I'm a founder at Meshcloud, we build a multi-cloud platform that helps organizations consistently implement organizational processes like IAM, SSO, landing zone configurations etc. across cloud vendors and platforms.
I work at Pivotal, we have both Kubernetes (PKS) and Cloud Foundry (PAS) offerings. With Cloud Foundry we abstracted away the IaaS pretty much entirely, including IAM and SSO, for the reasons you outline (and were doing so before Kubernetes existed). We also went out of our way to make "give the developer an account" as easy as possible. I worked in Pivotal Labs before moving to R&D; the ease of just getting something running on CF vs the various homegrown platforms I encountered was just amazing and was part of why I switched divisions.
This kind of generalised, simplified capability is quickly emerging for Kubernetes too. Knative is such an effort (we contribute there too), there are many others. What has typically been missing, in my view, is an understanding that different roles need different things from a platform. Kubernetes kinda blurs the business of being an operator with being a developer.
That's fine at a small scale. It's also workable, including some automation, at large scale if you trust everyone. But there are lots of folks in the middle who are at large scale who can't just let anyone do anything they like. They need crisp boundaries between developers and operators which are safe and easy to traverse. You also need top-to-bottom multi-tenancy with no way to opt out, which is not yet a thing to vanilla Kubernetes.
In any case, I don't think AWS is going to be wiped out by Kubernetes. But taking a counterfactual view, it seems plausible that the introduction of Kubernetes has flattened their lockin trajectory and hence reduced their long term profits as an area under the curve.
> But for developers in big co., acquiring a public cloud account may take months and forms over forms of paperwork, getting roles put into the central corporate directory etc.
I help companies re-architect their solutions for the cloud, and I've worked with companies who had a multi-month process for requesting and provisioning new "cloud servers". If it takes you just as long with just as much overhead to deploy a VM in Azure as it does to buy and provision a physical server, why are you even moving to the cloud?
In my experience AWS is the huge waste of time. I spent years on and off effectively building poor implementations of k8s to make AWS digestible to developers. If you work in "IT" rather than infrastructure for a large software company you might not have experienced this as internal IT is more static and easy to run on AWS/VMWare/whatever.
For me k8s finally signals moving beyond that problem and onto more interesting things as it "solves" that. Devs understand it "well enough" or can copy/paste from another project and get going without hand holding.
People that don't understand the value of the single unified API vs the hodge podge of AWS garbage (don't even mention CloudFormation) are completely missing the point.
Sure it's no better for running your "IT" workloads, but that isn't what it's for.
I think your prediction that k8s facilitates a future where even more random developers are copy-pasting whatever they find on old blog posts into their company's production infrastructure is probably 100% correct. Sounds good I guess :)
I've hardly looked at k8s, it looked like a pain to get a docker-compose file running in it the last time I looked. I think there was a tool to translate it to something kubernetes could deal with.
That said, after the last four months I've had of trying to get Route53, API Gateway, Lambdas, ECS, VPCs, Cognito, DynamoDB, S3, CloudFront, etc, etc running in CloudFormation I really can't imagine it's worse under any slightly involved scenario.
Translating something from docker-compose into k8s isn't generally hard. But yeah CFN is a nightmare, I wrote a bunch of tools to try make it suck less and contributed to stuff like cfndsl and I could still never get it to the point that I could have developers use it without an abstraction layer.
k8s definitely helps with the "all my apps stuff in one place that is easy to see". There are some pitfalls to avoid though. Don't use helm, it's bad for your health. Avoid deploying your own k8s cluster unless you really need to, just use GKE. Avoid custom resource definitions unless they are well supported, migrating off them can be hard - prefer tools that look at annotations etc (like external-dns, cert-manager and friends).
Of course things get difficult when you need statefulsets to run things like Kafka/ZK and friends but it's definitely possible and they run well once setup.
In my mind k8s is the only option right now that doesn't result in man-years being wasted on pointless AWS bullshit.
They're really not as bad as you've made it sound. I've been working with CF for 1.5 years, and I've done everything you've listed above (and more) with deep integrations into each other, and more. The most difficult was cognito, but that's because of their naming choices. Second most was ECS, but that's because of the time needed to flesh out and reason about everything.
There are plenty of examples on github/gitlab for most of the services you mentioned. Like most programming languages, you need to separated the wheat from the chaffe; 99% of the CF publicly available sucks. Hit me up if you need help.
I'm not really following, perhaps it's too early here. AWS is a cloud provider, Kubernetes is container orchestration software. Here's a crazy thing, we do K8S on AWS.
K8S is the commoditization of of Amazon's compute infrastructure. This standardizes it and makes it easier to switch and to build vendor independent tooling around it. Of course the strategy of AWS now at least be the first two parts of the old Microsoft strategy with regards to open standards: https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis... (Hopefully not the third part.)
There is still lots that Amazon does that is unique and proprietary. And it has tons of respect in the industry.
But as more becomes standardized on Kubernetes and more becomes automated via Service Providers, it will make further commoditize the market.
Google needs to do the following:
- Better CDN that can work with any origin.
- Work hard on getting Service Providers/Service Catalog into Kubernetes with all the latest Google Services (it is very patchy support at the moment.)
- Buy Gitlab and support the shit out of it -- that is one great product.
IDK about Gitlab. Google has the worse reputation about keeping products alive. That reputation along with the privacy reputation is going to drive adopters away, especially the ones who are not using GitHub because of Microsoft.
If you take a step away from the spiral that is AWS PaaS / SaaS services, k8s isn't that dissimilar to EC2, VPC, EBS, and IAM and thus a lot of the same arguments around lock-in apply.
This will become more obvious as people put windows VMs on k8s because it's there and they can.
I think it's pretty clear that AWS is happy for you to use their services in all manner of ways, using heavy AWS-proprietary services or not. Nothing wrong particular with "lift-and-ship" as they call it when you migrate on on-prem app mostly unchanged.
The article sounds like a comparison of buzzwords tailored for the technically challenged. I mean, I'm pretty sure that a Dilbert strip will be created based on the reaction of the pointy haired boss to this specific article.
Inaccurate analogy. Container based compute is a very small part of the AWS ecosystem. You are missing the bigger picture. Companies are migrating to AWS for end to end managed infrastructure including directory services, databases (sql and non sql), managed ETL pipeline infrastructure, batch processes, backups, data processing and analytics at scale, high durability storage at scale, a host of mobile app services, even satellite ground station infrastructure of late. This list is a subset. And all this comes with compliance and security out of the box on the infrastructure side, and a very low support overhead on the IT side compared to if you did it yourself.
And finally these are not isolated services. They can be used as building blocks or layers. For example your aws lambda compute might be triggered by s3 events.
I think you're actually agreeing even more with the author. Windows has everything you need for most of the usages you would have, all of it is integrated and the out of the box experience is functional. Linux at the time was a big mess of different softwares with different guarantees of working, maintained by duct-tape bash scripts and custom configuration files. If you wanted something, you had to work to have it.
This was only true for end-user desktops. For technical work and servers, Windows had a few built-in things and a ton of things which could, with significant work, be installed — nothing like a simple apt-get install for years, which is why so many places switched rather than paying people to spend hours clicking through installers and then troubleshooting why it failed.
My thoughts exactly. Insofar as Kubernetes provides one abstraction (for container orchestration) it reduces lock-in and provides standardisation for just a small part of the IT landscape, and even then there are alternatives that may be more appropriate depending on the use-case (Heroku, Docker swarm mode, ECS, Fargate, serverless).
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.
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).
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.
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.
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.
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.
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.
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.
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.
Let's not forget that Google wanted/wants a piece of the IaaS/PaaS pie and AWS has a huge first mover advantage. Someone smart at Google said:
"Hey we have this barely usable, rocket-science level complex, container orchestration tool. How about we make it available to everyone and make sure the message is that you can deploy anywhere? Get people to look at us as an alternative instead of AWS as the default, while using a tool built by us".
Of course AWS was not excited about supporting a tool that might make it easier to leave AWS.
It's an imperfect analogy so we're all going to take what we want from it. Here's my take:
Windows enabled businesses to start doing business without a ton of r&d. It was ubiquitous and supported and functional.
At the same time, with Linux you could invest all your capex into a datacenter and 1Us and build clusters for cheap and transfer all that money you would have spent on a complete system on opex to develop one. In some cases it's just plain necessary, and has some great success stories.
Sadly, I'm seeing a lot of businesses throw away time and money on NIH, justifying it with restrictive budgets. They claim they have to build all their solutions from scratch, rather than pay for managed ones, because it's cheaper. Those people often don't understand the true cost, and are wasting both time and money, when they could be buying ready solutions to start churning out products.
But then again, there are businesses that literally do not need to move fast, improve their products, increase efficiency, etc. For them, spending money on tech is more a hedge against an uncertain future than a business decision. They'll invest in anything if they think it makes them relevant.
So, Windows vs Linux is probably less important than the underlying motives of a given business, and whether it's managed well. Anyway, neither of them disappeared, and there's still good cases for both.
> Interestingly, the reasons AWS put forward for why private clouds fail will be just as true for themselves: enterprises can’t manage elastic demand properly, whether it’s in their own data centre or when they’re paying someone else.
This really rings true with me. I feel like Amazon aren't doing enough to tackle this problem though.... Does anyone else find the standard AWS tools for demand scaling to be like working against the grain in comparison to the rest of the platform ?
No. Lambda, DynamoDB, autoscaling read replicas on Aurora, Serverless Aurora, and even the regular old autoscaling groups are easy to automate and maintain.
Readit News
This one thousand times over. Lots of companies have multi-cloud on their strategy but when it's time to actually implement it they find that the cost to adopt hyperscaler #2 is just the same or even more as they spent on integrating hyperscaler #1. While Kubernetes makes workloads portable between vendors, organizational processes for "boring" chores like IAM, tenant provisioning and billing/chargeback aren't. Integration of these processes can get really expensive if you need to re-implement basic "enterprise" process like e.g. four-eyes-principle/seperation of duty on role assignments for each of your cloud vendors and technologies. The IAM systems differ ever so slightly across vendors and that brings a ton of complexity.
The larger the company, the more likely it is that the real bottleneck to cloud adoption is on these processes, not the technology. I know it's hard to imagine if you're coming from a startup background where you can just take the company credit card and get an account on AWS, GCP or Azure in a second. But for developers in big co., acquiring a public cloud account may take months and forms over forms of paperwork, getting roles put into the central corporate directory etc. The investment into these (often atrocious) processes for hyperscaler #1 create a big lock-in.
Disclaimer: I'm a founder at Meshcloud, we build a multi-cloud platform that helps organizations consistently implement organizational processes like IAM, SSO, landing zone configurations etc. across cloud vendors and platforms.
This kind of generalised, simplified capability is quickly emerging for Kubernetes too. Knative is such an effort (we contribute there too), there are many others. What has typically been missing, in my view, is an understanding that different roles need different things from a platform. Kubernetes kinda blurs the business of being an operator with being a developer.
That's fine at a small scale. It's also workable, including some automation, at large scale if you trust everyone. But there are lots of folks in the middle who are at large scale who can't just let anyone do anything they like. They need crisp boundaries between developers and operators which are safe and easy to traverse. You also need top-to-bottom multi-tenancy with no way to opt out, which is not yet a thing to vanilla Kubernetes.
In any case, I don't think AWS is going to be wiped out by Kubernetes. But taking a counterfactual view, it seems plausible that the introduction of Kubernetes has flattened their lockin trajectory and hence reduced their long term profits as an area under the curve.
I help companies re-architect their solutions for the cloud, and I've worked with companies who had a multi-month process for requesting and provisioning new "cloud servers". If it takes you just as long with just as much overhead to deploy a VM in Azure as it does to buy and provision a physical server, why are you even moving to the cloud?
For me k8s finally signals moving beyond that problem and onto more interesting things as it "solves" that. Devs understand it "well enough" or can copy/paste from another project and get going without hand holding.
People that don't understand the value of the single unified API vs the hodge podge of AWS garbage (don't even mention CloudFormation) are completely missing the point. Sure it's no better for running your "IT" workloads, but that isn't what it's for.
That said, after the last four months I've had of trying to get Route53, API Gateway, Lambdas, ECS, VPCs, Cognito, DynamoDB, S3, CloudFront, etc, etc running in CloudFormation I really can't imagine it's worse under any slightly involved scenario.
k8s definitely helps with the "all my apps stuff in one place that is easy to see". There are some pitfalls to avoid though. Don't use helm, it's bad for your health. Avoid deploying your own k8s cluster unless you really need to, just use GKE. Avoid custom resource definitions unless they are well supported, migrating off them can be hard - prefer tools that look at annotations etc (like external-dns, cert-manager and friends).
Of course things get difficult when you need statefulsets to run things like Kafka/ZK and friends but it's definitely possible and they run well once setup.
In my mind k8s is the only option right now that doesn't result in man-years being wasted on pointless AWS bullshit.
There are plenty of examples on github/gitlab for most of the services you mentioned. Like most programming languages, you need to separated the wheat from the chaffe; 99% of the CF publicly available sucks. Hit me up if you need help.
There is still lots that Amazon does that is unique and proprietary. And it has tons of respect in the industry.
But as more becomes standardized on Kubernetes and more becomes automated via Service Providers, it will make further commoditize the market.
Google needs to do the following: - Better CDN that can work with any origin. - Work hard on getting Service Providers/Service Catalog into Kubernetes with all the latest Google Services (it is very patchy support at the moment.) - Buy Gitlab and support the shit out of it -- that is one great product.
If you take a step away from the spiral that is AWS PaaS / SaaS services, k8s isn't that dissimilar to EC2, VPC, EBS, and IAM and thus a lot of the same arguments around lock-in apply.
This will become more obvious as people put windows VMs on k8s because it's there and they can.
At least this is my impression.
Deleted Comment
And finally these are not isolated services. They can be used as building blocks or layers. For example your aws lambda compute might be triggered by s3 events.
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.
>> 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
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.
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.
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.
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.
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.
"Hey we have this barely usable, rocket-science level complex, container orchestration tool. How about we make it available to everyone and make sure the message is that you can deploy anywhere? Get people to look at us as an alternative instead of AWS as the default, while using a tool built by us".
Of course AWS was not excited about supporting a tool that might make it easier to leave AWS.
Windows enabled businesses to start doing business without a ton of r&d. It was ubiquitous and supported and functional.
At the same time, with Linux you could invest all your capex into a datacenter and 1Us and build clusters for cheap and transfer all that money you would have spent on a complete system on opex to develop one. In some cases it's just plain necessary, and has some great success stories.
Sadly, I'm seeing a lot of businesses throw away time and money on NIH, justifying it with restrictive budgets. They claim they have to build all their solutions from scratch, rather than pay for managed ones, because it's cheaper. Those people often don't understand the true cost, and are wasting both time and money, when they could be buying ready solutions to start churning out products.
But then again, there are businesses that literally do not need to move fast, improve their products, increase efficiency, etc. For them, spending money on tech is more a hedge against an uncertain future than a business decision. They'll invest in anything if they think it makes them relevant.
So, Windows vs Linux is probably less important than the underlying motives of a given business, and whether it's managed well. Anyway, neither of them disappeared, and there's still good cases for both.
This really rings true with me. I feel like Amazon aren't doing enough to tackle this problem though.... Does anyone else find the standard AWS tools for demand scaling to be like working against the grain in comparison to the rest of the platform ?