HN Gopher Feed (2017-11-26) - page 1 of 10 ___________________________________________________________________
Microsoft doubles down on Kubernetes for Azure
43 points by CrankyBear
https://blogs.dxc.technology/2017/11/21/microsoft-doubles-down-o...___________________________________________________________________
gkop - 2 hours ago
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 - 1 hours ago
> 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 GKEThis 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 - 1 hours ago
"You will only pay for the virtual machines (VM) that you use
for managing your Kubernetes cluster."
clhodapp - 2 hours ago
GKE does charge for the masters for clusters of 6 or more nodes.
See https://cloud.google.com/kubernetes-engine/pricing.
Microsoft's offering does not seem to charge you for the masters
ever, so that does seem like a differentiator.
gkop - 2 hours ago
You write "Microsoft's offering does not seem to charge you for
the masters ever". The article says "You will only pay for the
virtual machines (VM) that you use for managing your Kubernetes
cluster". Do you have a source that disagrees with the
article?Edit: to those replying correcting the article, if you
were to create a top-level comment on this thread correcting
the article, we could upvote your comments and better correct
the misinformation. I have edited my own comment explaining
what you have dug up. Thanks for your research!
Voloskaya - 1 hours ago
https://docs.microsoft.com/gl-es/azure/aks/intro-kubernetes>
"you pay only for the agent nodes within your clusters, not
for the masters."
AaronFriel - 1 hours ago
Yes, I have played with AKS. You do not pay for the
Kubernetes masters, just the nodes. In the prior version of
the product (ACS) you would specify a cluster size as a
number of masters and a number of workers/nodes. In AKS, you
only manage the latter and Azure abstracts away the
Kubernetes API.https://azure.microsoft.com/en-
us/pricing/details/container-...
013a - 2 hours ago
Statement's like Microsoft's are horrible; "the cloud should be
about paying for what you consume" well, Kubernetes consumes at
least one master node in order to orchestrate a cluster.But,
Google/GKE does charge for management of the cluster. A constant
fee of $109/mo for 6+ nodes. Its not technically the charge for
the master node, but that cost to Google + other things is likely
where that $109/mo comes from.
rad_gruchalski - 2 hours ago
I really, really hope aws joins the game. re:invent is around the
corner.
fredsted - 1 hours ago
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 - 1 hours ago
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.
mephitix - 2 hours ago
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.
JoshMnem - 1 hours ago
> I just hope that MS doesn't add in too many platform-specific
pieces that would encourage vendor lock-in.That's Microsoft's
main strategy though. Example: Users can't even install Firefox
or Chrome on Windows 10 S.Microsoft announced: "Apps that browse
the web must use the appropriate HTML and JavaScript engines
provided by the Windows Platform."I wouldn't be the slightest bit
surprised to see similar things happening to their cloud platform
as soon as they are able to do them without users' noticing.
lewisl9029 - 1 hours ago
> "Apps that browse the web must use the appropriate HTML and
JavaScript engines provided by the Windows Platform."This seems
like a thing that platform owners are doing more and more (iOS
has a similar clause, and ChromeOS, well, uses Chrome).Is this
just purely a move to stifle competition from web apps that
could threaten control of the platform? Or perhaps I am missing
some nuance behind these kinds of decisions? I'm honestly
struggling to find any room to give them benefit of the doubt
here.
JoshMnem - 53 minutes ago
> This seems like a thing that platform owners are doing more
and more (iOS has a similar clause, and ChromeOS, well, uses
Chrome).Shame on all of them. If it continues, the next
generation will not know what it's like to have technology
freedom like we currently do (in the US, for the most part).
Kipters - 1 hours ago
That's a different product, with different goals. You're right
about 10 S, but it's kinda unrelated to Azure.
JoshMnem - 50 minutes ago
I've lived through the experience of using non-MS products
since the early 2000s, and all of those things are related.
It has been one of their core strategies and still is, though
the techniques are shifting.
lobster_johnson - 1 hours ago
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 - 18 minutes ago
>> As an aside, the current ingresses (including the Nginx one
and Google's own GLB one) all have annoying deficienciesAgree,
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.
th3iedkid - 1 hours ago
In fact MS acquired Deis sometime in March this year.Draft.sh ,
helm etc are under MS now, while they do remain OSS.
xkarga00 - 1 hours ago
Microsoft should write an ingress controller for Azure? Not sure
how you can get into a vendor lock-in situation with k8s. Maybe
Microsoft extends the API with its own blackbox controllers and
force that instead of kube primitives?
plasma - 57 minutes ago
> I just hope that MS doesn't add in too many platform-specific
pieces that would encourage vendor lock-in.I watched one of their
videos demonstrating the product, and they understood people
wanted 100% compatibility with the open-source k8s system and no
special Azure/MS features, and so this was one of their selling
points, which is good.