
‘AWS vs. K8s’ Is the New ‘Windows vs. Linux’ - puzza007
https://zwischenzugs.com/2019/03/25/aws-vs-k8s-is-the-new-windows-vs-linux/
======
jrudolph
> 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.

~~~
tstrimple
> 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?

~~~
OldManAndTheCpp
Because the services offered after getting onto the public cloud are better
than the internal ones, more transparently priced, and cheaper.

~~~
kkarakk
*if they've bothered to hire more than a cloud specialist. Most of the time the in-house talent won't have time to train in the specificities of cloud used and things with continue as earlier albeit now with cloud branding

------
jpgvm
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.

~~~
cs02rm0
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.

~~~
jpgvm
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.

~~~
sklarsa
Why not use helm? I'm looking into spinning up (and eventually
productionizing) a k8s cluster at my job and I was leaning towards using helm
since some pieces that I was thinking about using are installed via helm
charts ([https://github.com/kubernetes/ingress-
nginx](https://github.com/kubernetes/ingress-nginx) for example)

~~~
solatic
If you use third-party Helm charts, you eventually need to add onto the
generated objects in a way which the chart doesn't support, and then you're up
a creek without a paddle. This is precisely the use case which Kustomize tries
to fix and it was the only real strength which Helm had to begin with (i.e.
the ease of installing third-party software on your cluster).

In the meantime, because you must install Helm into every namespace in your
cluster into which you desire to install charts, it's a massive resource hog
and security risk. Charts themselves also need to be hosted somewhere, so you
end up needing to install Chartmuseum, Harbor, or Artifactory (if you didn't
have Artifactory already), and they have their own operational costs.

~~~
navd
I thought it would be useful to add that you can also generate k8s manifests
from a helm chart using the `helm template` command.

I'm in the same boat where I avoid helm if at all possible.

~~~
alexandre_m
That only works for local checked out copy and not remote repo URL,
unfortunately.

------
newaccoutnas
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.

~~~
zwischenzug
That's using AWS as a VM and VPC provider. AWS don't want you to do that, or
at least, that's not how they'd like you to use their services (IMO).

~~~
etaioinshrdlu
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.

At least this is my impression.

~~~
scarface74
Of course they would love for you to do a lifts and shift, it makes them more
money than if you are “cloud native”.

------
carlsborg
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.

~~~
rakoo
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.

~~~
acdha
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.

------
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).

~~~
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”.

------
holografix
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.

~~~
pcnix
This is a pretty good read on Google's strategy for dealing with AWS -
[https://stratechery.com/2016/how-google-cloud-platform-is-
ch...](https://stratechery.com/2016/how-google-cloud-platform-is-challenging-
aws/)

------
peterwwillis
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.

------
danw1979
> 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 ?

~~~
scarface74
No. Lambda, DynamoDB, autoscaling read replicas on Aurora, Serverless Aurora,
and even the regular old autoscaling groups are easy to automate and maintain.

------
namelosw
If it is the New 'Windows vs. Linux' then K8s will prevail.

Because it's server-side market :P

But seriously there will be a better K8s eventually. For example, make K8s
work as Heroku or AWS Lambda. After that, there's no point using bare cloud
for most of the players.

------
brtknr
Drawing comparison between OpenStack and K8s is also invalid IMO... they
operate at different levels of abstraction. You can use K8s with OpenStack as
a cloud provider as with any other cloud provider. K8s is intended to abstract
away the infrastructure that lies underneath and give you a consistent way to
deploy services across different cloud providers.

~~~
majewsky
In fact, my team does Kubernetes on OpenStack on Kubernetes. :)

It's OpenStack on Kubernetes because we deploy the OpenStack components on a
baremetal Kubernetes cluster (with actual payloads running in VMware), and
it's Kubernetes on OpenStack because we have an addon service that allows
customers to spin up Kubernetes on the VMware VMs created by OpenStack. We
also dogfood this because the baremetal Kubernetes cluster is not large enough
to hold all our internal services.

~~~
jrudolph
So you're running VIO / vmWare integrated OpenStack?

~~~
majewsky
No. We started with our efforts before VIO was a thing. You can see what we're
doing at [https://github.com/sapcc](https://github.com/sapcc), though
admittedly that org is quite busy and I don't know every part of it myself.

------
poxrud
The strength of AWS does not come from any individual offering, but from the
way the many services effortlessly tie together. Job queues, email/sms
services, databases, all available under the same api. Sure I could install my
own open source versions of these but I'd rather spend time writing code than
worrying about security patches and updates.

For me the biggest game changer was realizing the true power of lambda, and
I'm not talking about using it as an http responding webhost as most blogs
describe. But as a way of reacting to events within your infrastructure. Any
AWS service that can generate an event can have a lambda function associated
with. Run code on file uploads, database updates, completion of backups ...the
possibilities are endless.

~~~
nameless912
> effortlessly

Uh...have you ever actually used AWS? There's friction all over. It's
certainly not a seamless experience going from API to API.

~~~
rmdashrfstar
Your comment is unproductive and unnecessarily sarcastic. It would seem
obvious the parent has used the services provided by AWS, and your focusing
entirely on the perceived negatives and friction when combining services is
not constructive.

Are you suggesting there is less friction in using multiple softwares, likely
as self hosted, produced by separate developers, compared to using services
hosted by AWS which allow you to only worry about building your product and
managing links between services? The latter almost undeniably leads to greater
productivity over the former, and if you're interested more about building and
delivering a software product, that must be preferable.

------
srouhaewaehy
Which of the two is Linux? It's more like Windows vs Java.

------
paulftw
Software Engineer's fallacy: if all you have is software/programming skills
you start to look for an open source linux based solution to holding wooden
boards in place, one that doesn't vendor lock you into the iron ore.

With Windows vs Linux the premise was you install absolutely free software on
a computer you __already own __and you end up with a superior computing and
programming environment.

With k8s - you switched to it, now what? You have to buy server hardware, rent
or build a room, run wires for electricity and broadband, build cooling,
physical security, etc etc etc. You will stop paying hourly rate to Amazon,
but all the upfront and recurring costs will chew into that saving and you'll
question whether it was worth the drill. Foremost, it will all take days and
weeks, but with AWS it takes intolerable 20 minutes to spin up the k8s control
plane (did I remember the term right?)

Even if you do all of that and blog about your great success, what's your plan
for when it goes viral and visitors flow in to leave accolades on your
visionary move?

With AWS, you could just spin up more servers to deal with extra traffic. With
your own datacenter, you'd have to order new servers, perhaps from Amazon's
same day delivery...

~~~
cs02rm0
_With k8s - you switched to it, now what? You have to buy server hardware,
rent or build a room, run wires for electricity and broadband, build cooling,
physical security, etc etc etc._

I'm not sure that's the choice. You can run kubernetes in the cloud, can't
you? e.g. EKS on Amazon.

~~~
paulftw
So you also agree that there's no standoff between AWS and K8s, unlike an
article titled "'AWS vs. K8s' Is the New 'Win vs Linux'" would suggest?

It also talks about building a personal data center quite a few times (at
least that's how I read it).

K8s is likely to replace EC2, ECS, and all other unusable amazon bloat to
become the default AWS API. But it's not going to damage AWS, it's going to
enhance it and become part of it.

~~~
marcinzm
AWS is an expensive cloud provider. If you commoditize it then then Amazon
will either have to charge less (= less revenue/profits) or user will switch
to cheaper cloud providers (= less aws revenue/profits). That is the point the
article is making.

------
nagyf
The article forgets about Azure or GCP. I know that AWS is the most popular,
but you shouldn't forget about those 2. From the article it seems like there
are AWS and nothing else, which is obviously not true. And Azure is backed by
Microsoft, GCP is backed by Google, so if "Bezos loses his mind" there will be
other alternatives besides Kubernetes.

~~~
martingxx
> And Azure is backed by Microsoft, GCP is backed by Google, so if "Bezos
> loses his mind" there will be other alternatives besides Kubernetes.

You missed the point that moving from AWS to GCP or Azure is going to be
_extremely_ complex and expensive if you have used all those shiny AWS
platform features. It is very easy if you are using k8s.

~~~
scarface74
Sure migrations of a large complex infrastructure is easy...says no one who
has actually done it.

------
k__
Is this some kind of DevOps joke I'm too serverless to understand?

~~~
k__
I mean, seriously.

AWS has EKS and as far as I know, it added many K8s features to ECS in the
last years. So even if you are one of the unlucky people who is locked in by
containers, there are plenty of options to run K8s managed and unmanaged on
AWS.

This discussion sounds like some taxi driver who insists on only driving a
taxi build by themselves instead of buying a car build in large volume
production.

------
throw2016
This illustrates the confusion around infrastructure and apps by 'devops' in a
rather telling way. It's a bit like comparing Mysql or Postgresql and Aurora.
Both give you databases and even some builtin replication technology but only
one gives you databases plus availability and scalability out of the box.

Without that you would have to engineer your own distributed architecture and
actually have the infrastructure in terms of bandwidth, regions, networking
and data centers to scale to.

AWS gives you availability and scalability out of the box. Usually only a
cloud provider can give you that with physical infrastructure in multiple
regions, bandwidth, networking, things like floating ips, replicated storage
and in the case of things like Aurora architecture and engineering. Kubernetes
is a container orchestration application.

------
languagehacker
I think this is the analogy folks who really want to hang their hat on K8s
would like to force. It feels familiar, and it helps justify the tremendous
personal investment of time it takes for running your own K8s cluster with
high uptime. The usual adage that "free software is only free if your time is
of no value" really does apply here.

Assuming you're writing code that lives happily inside of a container, and
assuming that you're not taking advantage of anything else AWS has to offer
(which is increasingly improbable), moving from ECS to EKS or GKE isn't a big
deal if you need the additional configurability that real Kubernetes offers.

Personally, I like running things on Fargate-style containers so I can keep
things as serverless as possible.

------
nailer
Because it's a waste of time?

In my the same way I spent years of my life thinking about 'the desktop' when
the desktop was about to get killed by mobile, arguing about MicroVMs vs
containers is useless: they're just somewhere to run functions.

------
tanilama
K8s is not an AWS comparison, at least not a proper one.

K8s is software, but AWS is software + hardware. Your K8s cluster likely would
still be hosted on AWS/Azure/GCP.

K8s lives upon the cloud providers, they are not competitors.

------
trpc
while I don't really understand how ‘AWS vs. K8s’ Is related to ‘Windows vs.
Linux’, I guess k8s is a threat to AWS primarily when it comes to EC2 just
like it is a threat to commercial linux distros since it makes the underlying
VM and host OS totally temporary and replaceable, but what can k8s do to AWS
SaaSes (e.g. RDS, SNS, etc...)? almost nothing (even though it gives you the
opportunity to migrate from one SaaS to another while still having
availability using the help of istio for instance), you can't really escape
the lock-in

~~~
martingxx
> what can k8s do to AWS SaaSes (e.g. RDS, SNS, etc...)?

k8s has allowed us to not use RDS any more because we now host PostgreSQL
inside k8s instead. It's a bit more overhead, but we're now portable and run
in gcp too with the same k8s manifests and almost no porting effort.

So yeah, we escaped the lock-in.

And now we're not just tied to the AWS stuff and we're experimenting with
cockroachdb and other products that aren't there "natively" in AWS, so beyond
escaping lock-in, we're more ready to experiment with newer stuff.

~~~
philliphaydon
Everyone keeps talking about vendor lock-in. In regards to RDS you can still
export your database and move somewhere else. But we use it because we don’t
want to manage the database, we don’t want to worry about availability zones
and syncing the data and failing over for updates. I don’t want to setup k8s
instead and configure it and maintain it. That stuff is boring for me.

~~~
marcinzm
The vendor lock is is not the data in RDS, it's the ops code that sets up and
integrates RDS with everything else you do. K8S allows you to use the same
code to setup a database, or most anything else, in any cloud host.

~~~
pbalau
My only ops code is a thin wrapper over the secrets manager API, that converts
from a secret to something Django orm or sqlalchemy can use to connect.

My pain point is db migrations, from version X to version Y. My bad to pick
Django for our internal tooling web app and go with its orm. Fairly confident
that I can change that to sqlalchemy easy, if I get the time for it.

------
kerng
The article forgets to define the terms its using, I think the author means
Amazons EKS service vs. running your own k8s on AWS VMs - not sure.

Could also be that they compare AWS vs. GCP, but I'd dont think so.

------
Blackstone4
In terms of the comparison AWS vs. K8... are we not talking a much larger
stack to replace AWS? i.e. VMware/OpenStack + K8 + Docker...Maybe this is what
the author was implying?

------
tnolet
I have container orchestration and management problem: use K8S.

I have the need to do business using computers: use AWS.

------
badsavage
"wasting their lives compiling Linux in their spare time" stopped reading
there

------
mcqueenjordan
Sorry, not following the logic here either. Not even close. It's a blog with
ads from an author that is big into Docker. It's not ad hominem; it's just cui
bono.

The author put scare quotes around the "real workloads" AWS can handle/solve
for. I'm not sure the author really has the experience to know what real big
workloads look like. OpenBet? Barclays? Doesn't sound like a background in
large scale technical problems that gets to sneer at the workload sizes of
others.

I'll admit my biases -- I used to work at AWS and I'm a happy customer. But if
you don't understand it or don't have the appropriate technical needs for that
level of infrastructure, don't try to draw such a poor analogy and make really
weird claims.

> There are limits on all sorts of resources that help define what you can and
> can’t achieve.

Huh? Yeah, of course... Certain tools have certain purposes, built to solve
specific problems. Kind of like the UNIX philosophy. Do one thing and do it
well. You know about the UNIX philosophy, right? Limits? Everything has
limits.

> In the same way, some orgs get to the point where they could see benefits
> from building their own data centres again. Think Facebook, or for a full
> switcher, Dropbox. (We’ll get back to this).

You should build your own data center if it is _strategically advantageous_
for your company to be in the data center business. I'd argue that Facebook is
in the data center business mostly for historical and timing reasons, and that
for Dropbox, it actually might be a strategic advantage because they're
basically, uh, an _infrastructure company._

> Which brings us to AWS’s relationship with Kubernetes. It’s no secret that
> AWS doesn’t see the point of it.

Actually, I do think it's a secret. It must be your little secret to yourself,
though, because I don't think anyone else thinks this. Could it just be that
building a product takes time and people?

> IAM is the true source of AWS lock-in (and Lambda is the lock-in technology
> par excellence. You can’t move a server if there are none you can see).

Have you ever even built anything on cloud infrastructure? Doesn't seem like
it from your writing. Lock-in is a really uncharitable synonym for "solves a
difficult problem well."

Also, Lambda is about the easiest thing to migrate I can think of. Its surface
area that your code touches is remarkably small, by design. If anything, it's
fairly clear there were many opportunities for Lambda to make product
decisions that could've really locked customers in -- which they elected not
to take.

(Typed on a phone, forgive typos.)

~~~
jacques_chester
The sticky part of Lambda isn't the API, it's the services and events you
integrate with. The code you provide is small, necessarily your surface-to-
volume ratio is much higher.

------
Stranger43
It probably more like windows vs Unix(tm) whit something else eventually
emerging as the go to for pragmatic practioners

------
CyanLite4
AWS will be around in 5 years. It has an established business model making
billions of dollars per year.

K8s won’t be around in 5 years. It’s peaking towards the top of the hype
cycle. If you’re wondering about cloud lock-in, then you don’t get the power
of the cloud.

~~~
navd
I disagree, I think k8s is entering the slope of enlightenment. The ecosystem
is still early, but there are some amazing tools being built that can make you
very productive.

~~~
CyanLite4
And that in itself is the reason why k8s is hype. Too many tools, too much of
an “ecosystem”. Too complex. Linux suffers from these issues as well.

------
arthry
I think ECS vs K8s would be a more proper title.

------
StreamBright
Anybody who thinks that Kubernetes can be compared to AWS has absolutely no
idea what these things are.

~~~
martingxx
Can you elaborate?

I disagree with you and I have been using both (as well as gcp) in production
for years.

They are both platforms that you write an application stack against. One is
portable and can run in any cloud, the other only works in AWS.

Just because one is ALSO a cloud provider doesn't make them incomparable.

