
Microsoft is Hiring Go engineers to work on Kubernetes - wilsonfiifi
https://www.reddit.com/r/golang/comments/6o2lc3/microsoft_is_hiring_go_engineers_to_work_on/
======
hit8run
I was introduced to the Kubernetes source code by an Redhat Kubernetes Core
Contributor. He showed me the nasty parts how they solved the lack of
generics. Actually they use strings to concat valid go source code based on
reflections. A little tedious but given the constraints for language choice
they had (fast, compiled binary, close to the metal) I think Go is still a
decent choice for Kubernetes.

~~~
tonyhb
Kubernetes is literally the Angular of orchestration systems. SwarmMode is so
much cleaner and less complex to use, dive into, and hack on.

I'm unsure why the community rallies behind Kube considering it's insecure,
horribly complex, and a PITA to configure. I guess because google lied and
said they use it internally, even though they're still using Borg?

~~~
macNchz
Well for one Swarm was released a year ago and Kubernetes went 1.0 two years
ago, so there has just been more time for people to get familiar with k8s. I
myself dug into kube before Swarm arrived and have put off getting into Swarm
because constant framework hopping kind of defeats the purpose of getting
familiar with a new framework in the first place.

While I agree to some extent re complexity, I'd be interested as to what
you're referring to when you say kubernetes is insecure.

~~~
thinbeige
Framework hopping? With your knowledge in k8s you should be able to learn
Docker Swarm and getting a swarm deployed in less than 60 minutes.

~~~
macNchz
Sure, I could definitely get a swarm set up quickly and run something trivial
on it, but then I'll be back to the docs for secrets, stateful containers,
volume mounts, cert management, instrumentation, health checks, load balancing
etc.

My point about 'framework hopping' was that I try to get some value out of the
time spent digging into a new tool/library/framework, rather than trying to
use something new for each new project. Knowing the pitfalls, useful configs,
edge cases, best plugins and so forth goes a long way towards being able to
focus on what you're actually building. I'm not against early adoption and I
am always learning new tools, but I do try to leverage the ones I have deep
knowledge of.

~~~
thinbeige
> I'll be back to the docs for secrets, stateful containers, volume mounts,
> cert management, instrumentation, health checks, load balancing etc.

Almost all of your points are on one page in the doc (just google 'docker-
compose file') which is read and used in 5 minutes. Btw, load balancing is the
default, no real config required (still you can but the defaults are
sensible). Anyway, you are usually 5x to 10x faster than with setting up an
k8s cluster. This should be a good enough reason to give it a try and to make
your own picture of Swarm.

It is up to you but I think you have a wrong picture of Swarm. Something huge,
conplicated and intimidating like k8s. Something you should spend your weekend
and the week after to learn. This is wrong.

Just see is as another CLI tool which you can grasp in the next hour (instead
of surfing the web).

------
majewsky
Not surprising, given that they recently acquired Deis (the company behind
[https://github.com/kubernetes/helm](https://github.com/kubernetes/helm)).

~~~
brianwawok
Hum I was thinking about switching to helm. I think I will steer clear now.

~~~
nikon
I found it has strange defaults (all services publicly exposed) and quite
unfriendly to automate. Ended up sticking with native deployments.

~~~
brianwawok
Yah so the few helm charts I have used, I had not seen a huge value. If I
wanted to change something without a hook, I end up using my own dockerfile
anyway.. so I guess it is helpful as just a reference on how to get a service
to work, but not that useful for prod deploys.

~~~
bryanlarsen
We've standardized on helm for prod deploys. Perhaps it's not a huge value,
but it is a convenient way to bundle together a set of configs, templatize
them and manage them.

~~~
majewsky
Seconded. We use Helm to deploy OpenStack (and various supporting services) on
Kubernetes: [https://github.com/sapcc/helm-
charts](https://github.com/sapcc/helm-charts) and
[https://github.com/sapcc/openstack-helm](https://github.com/sapcc/openstack-
helm)

------
deckarep
Can't wait for Kubernetes Home Edition, Kubernetes Premium or Kubernetes
Server Edition....I know which one we're getting.

~~~
foo101
This is not Reddit!

Please post substantively on Hacker News or not at all.

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)
reply

~~~
thinbeige
It also says: 'Be civil. Don't say things you wouldn't say in a face-to-face
conversation. Avoid gratuitous negativity.'

So calm down.

~~~
foo101
I don't find myself uncivil. I would totally say what I said in a face-to-face
conversation to preserve the decorum of a forum.

------
holydude
I would really love for Microsoft to cooperate on Go with Google. Of course
not the C# approach to sink in all the features but maybe releasing an
official pkg for win32 api and maybe even the GUI.

~~~
pjmlp
Maybe Google could learn how to implement generics....

------
rusanu
I also saw today this article Microsoft Prepares SQL Server 2017 for Linux and
Containers [0], from this tweet[1] "Microsoft Prepares SQL Server 2017 for
Linux and Containers, SQL Server lab runs on kubernetes and docker". If they
moved the entire SQL lab (many thousands of machines) to Kubernetes is quite a
big deal. They're probably warming up on how to manage it at scale, and I'm
pretty sure that moving Azure SQL DB infrastructure to it is the goal. If they
can get better isolation and higher density that today (some Azure Fabric
derivative, afaik), it would save tonnes of moneys.

[0] [https://thenewstack.io/sql-server-2017-brings-microsofts-
dat...](https://thenewstack.io/sql-server-2017-brings-microsofts-database-
linux-container-worlds/)

[1]
[https://twitter.com/slava_oks/status/887359748047216640](https://twitter.com/slava_oks/status/887359748047216640)

------
mandeepj
You might find it relevant. Build a container from scratch using GO
[https://about.sourcegraph.com/go/functional-programming-
in-g...](https://about.sourcegraph.com/go/functional-programming-in-go)

~~~
leastangle
Given "Linux Namespaces and Go Don't Mix"
([https://news.ycombinator.com/item?id=14470231](https://news.ycombinator.com/item?id=14470231))
I am not so sure?

~~~
mandeepj
Sorry. My Bad. I meant to provide this link -
[https://www.youtube.com/watch?v=HPuvDm8IC-4](https://www.youtube.com/watch?v=HPuvDm8IC-4)

I screwed up during copy+paste

------
mtgx
I think it's clear now. Microsoft simply _loves Google_!

Sorry, couldn't help myself with all the "Microsoft loves Linux because it's
working on some Linux code" arguments around here.

Microsoft only does what suits Microsoft's interests. If they want to use
Kubernettes and they _need_ Go engineers for that, or to support Go in any
way, then they'll do it, especially if it makes strategic and financial sense
for them to do so.

~~~
digitalzombie
They can't let Google eat up another space.

They lost to the search engine.

I think Microsoft have waken up and realize they need to be active in all
spaces that open source is at. It seems like this moves will help their cloud
business since there are so much money in there.

Supposely their Azure cloud is doing well and I guess they need to keep at it.

I agree that they're not doing it for the pure of their heart but rather it's
money driven and fear of being left behind again.

~~~
brianwawok
So when do they throw their Microsoft wrench in it..

"Oh and these Kubernetes features only work on Azure Cloud(tm) running Windows
Server(tm), or Microsoft Linux(tm)."

I don't know.. does anyone that isn't a .net shop use Azure? It seems if you
are a .net shop, Azure is the best choice. If you are not a .net shop, why use
Azure? If Microsoft is going to reach a compelling chunk of AWS and GCE linux
developers, I don't think they are going have that easy of a time...

~~~
nxc18
In my very limited experience Azure is much, much nicer than AWS from the
admin experience. Its kind of embarrassing for Amazon how bad AWS is in that
area. Google CE also has very nice UI.

I understand that Azure is competitive on price, and they do support all of
the linuxy things you'd expect from AWS or GCE.

Unfortunately all that comes at the expense of reliability from what I've
seen. :/

~~~
brianwawok
Ya right, so you are selling me a cloud service by the GUI. I don't use the
GUI on any of my providers, so it doesn't really matter. (It might matter to
the same subset of people that use remote desktop to "administer" their fleet
of window servers)

Like I said, I cannot imaginable that many non .net shops would touch azure.
It has neither the features of AWS, nor the magic of GCE.

