
Microsoft doubles down on Kubernetes for Azure - CrankyBear
https://blogs.dxc.technology/2017/11/21/microsoft-doubles-down-on-kubernetes-for-azure/
======
gkop
Edit: Thanks to replies explaining that in fact AKS doesn't charge for the
master! I'm leaving the rest of this comment standing because it's an honest
reply to the article posted - Microsoft isn't disingenuous, this article is
just wrong.

> Be that as it may, Microsoft is offering AKS for free. You will only pay for
> the virtual machines (VM) that you use for managing your Kubernetes cluster.
> Microsoft says, “Unlike other cloud providers who charge an hourly rate for
> the management infrastructure, with AKS you will pay nothing for the
> management of your Kubernetes cluster, ever. After all, the cloud should be
> about only paying for what you consume.”

This is disingenuous. We're talking about k8s, so GKE is the comparison point.
Yes GKE charges a flat hourly fee for cluster management, _regardless of the
number or size of the nodes_ [0]. But GKE doesn't charge for the master
instances (which are hidden away behind the GKE product). So AKS will not
charge for the cluster management, but will charge for the master instances.
Neither pricing model is more "for free" than the other.

Also, if we have to think about the master instance sizes on AKS because we're
paying for them, then that's one thing we have to manage on AKS that we don't
have to manage on GKE - GKE adds more value by more completely managing our
cluster.

[0] pedantic: there's actually _no fee_ for clusters of less than 6 nodes.

~~~
AaronFriel
> Also, if we have to think about the master instance sizes on AKS because
> we're paying for them, then that's one thing we have to manage on AKS that
> we don't have to manage on GKE

This is entirely premised on your speculation which turned out to be false.
Curious that you're willing to call this blog post disingenuous when you're
the one spreading falsehoods?

~~~
gkop
"You will only pay for the virtual machines (VM) that you use for managing
your Kubernetes cluster."

------
mephitix
This is a good thing; Microsoft will increase competition in this space by
applying its expertise in dev tools to Kubernetes.

I just hope that MS doesn't add in too many platform-specific pieces that
would encourage vendor lock-in.

For example k8s ingress right now is based on controllers and GCE controllers
support/don't support a wide variety of things compared to nginx ingress...
these areas of Kubernetes make me worried about potential future switching
costs.

~~~
lobster_johnson
Fortunately there's a bunch of ingress controllers you can use: Traefik,
Voyager, HAProxy, and probably several others. And it's surprisingly trivial
to write your own.

So ingresses is not currently a weak point in relation to vendor lock-in
happens. And Kubernetes already supports plenty of non-Google tech; as an open
source project, Kubernetes is refreshingly non-Google-focused (there are a
bunch of players, notably Red Hat and Microsoft, ensuring this).

As an aside, the current ingresses (including the Nginx one and Google's own
GLB one) all have annoying deficiencies (subpar support for TLS and per-route
timeout settings among the biggest). Ingress support is, and has been for a
long time, Kubernetes' weakest point. For example, GLBs max out at 20 TLS
certs (ridiculous if you're hosting many customers on a SaaS solution) and
default to a timeout of 30 seconds (you can't control this using ingress
annotations; you have to manually go in and edit the backends via API or UI)
(which doesnt work for big streaming requests and WebSockets). These are also
very trivial problems compared to the complex ones that are being solved by
big new features in Kubernetes proper, so it's a bit surprising that ingress
implementations are lagging to this extent.

~~~
mephitix
>> As an aside, the current ingresses (including the Nginx one and Google's
own GLB one) all have annoying deficiencies

Agree, this is along the lines of what I meant. For example GCE ingress allows
you to reference a global static IP while this is not possible with solely
nginx ingress due to limitations with the TCP load balancer. There are
separate ingress annotations for GKE/nginx/haproxy, etc. If I want to use the
global-static-ip GCE annotation, this will make it a little harder to move to
Azure.

~~~
bonesss
Totally fair points, and vendor lock-in is something to be highly vigilant of.

For some context, though: the ingress functionality is rather recent in
Kubernetes and is still fleshing out in terms of demands in the market and
across cloud providers. Another year or two will do a lot for equality and
saner networking solutions for small-scale and bespoke K8s deployments.

I got a little shock that I had to set up an ingress controller on each of my
nodes (on our VMWare cluster), but going through the nuts and bolts of it I
can see why it's hanging a bit behind the rest of the product. I think the
devs are being smart letting the ecosystem mature a little instead of pushing
out something half-baked and prematurely limiting.

------
amq
Whenever I look at Kubernetes, I can't help myself but think that it's
overcomplicated, with too many moving parts. Almost as if to incentivise using
the hosted solutions instead of rolling it on your own on some VPSs. I can
deploy a HA Swarm Mode cluster anywhere in minutes, while I'm not sure even
where to start with Kubernetes. Do I use juju (recommended Ubuntu way), or do
I use kubeadm? Which network add-on do I use? How do I upgrade (the procedure
seems to be different with each version)?

~~~
nvarsj
If you’re not prepared to dedicate a small team to running Kubernetes, I’d say
it’s too much for your needs.

Read the Borg paper for an idea of what k8s is meant to solve. If you have
hundreds of services spread across 10s/100s of nodes, then the complexity of
k8s starts to become amortized. Similarly if you have 100s of devs without a
consistent way to do deployments, k8s starts to make sense.

Source: tech lead for a team managing a large on-prem and cloud k8s cluster.

------
rad_gruchalski
I really, really hope aws joins the game. re:invent is around the corner.

~~~
fredsted
Well, you can use something like kops, although it's a little more difficult
to get started, I guess. This new tool from Azure is basically the same thing.

It's a little interesting since they already have ECS, which isn't that bad
either, but it seems like everyone just wants Kubernetes. Will they do both,
or provide a migration path?

~~~
rad_gruchalski
ECS is okay, used it quite a bit recently. It definitely has some quirks to
it, like having to use CloudWatch events to figure out the port given to the
container when using bridge network. Maybe if the service discovery story was
a little bit more defined, ECS would be easier to use. There's lots of little
manual things one has to do around it to make it work as swift as other
solutions available.

With regards to k8s on AWS, I do not have a problem running it myself but some
backing from AWS definitely help defining k8s as "the solution" for running
containerized workflows. Here's one hoping.

------
org3432
So restaurants give you ketchup for "free" too, but turns out you're paying
for it.

This is stupid to say the management node is free, you're just paying for it
in another way. Now if they said they were able to run the node so cost
effectively that it's just included in the hourly node cost, then that's a
plus.

~~~
bonesss
For SMBs and smaller dev shops kicking off their forays into container
development, not to mention customer deployments, the simplified cost models
make it more management friendly and more understandable to non-IT actors.

Whether it is absolutely cheaper than GCE or whatever, and if master
management is a requirement, is a separate comparison based on the solution.
Cutting out the management node costs removes a barrier to entry and creates a
more streamlined product.

Oh, it also makes their Kubernetes services usable within the free credits
they give out on Azure via their MSDN subscriptions... so suddenly millions of
devs can use AKS for demos and temp-hosting "for free", which is huge in
creating mindshare in the Enterprise...

~~~
org3432
I'm sure you're right, but not understand economics to that level wow.

------
Maledictus
I hope they don't embrace, extend, extinguish.

