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.
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?
If by "the Angular of orchestration systems" (I'm going to assume Angular 1 because Angular 2 gives me headaches still) you mean that it's really easy to do what should be easy, and feasible to accomplish really complex things, then I would agree. But I don't think that's what you meant.
As far as security, that's now purely a property of the way you deploy it. Secrets can be encrypted (feature in alpha), RBAC is fully supported, TSL client certs are preferred for AuthN, and HTTPS is supported across the API endpoints. I'm not sure what more you could ask for on the security side.
I don't know that Google says they're using K8s internally, either. It's always been sold by Google as a ground-up rewrite of what the authors wish Borg would have been. Not only that, but it's supported (developed) by dozens of small companies, as well as Google, Red Hat, and an increasing number of large companies interested in its growth.
Finally, it's governed by the Linux Foundation. If there's another org that can help scale and properly govern one of the most popular modern OSS projects, I'm drawing a blank.
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.
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.
> 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).
Borg has so many knobs that Kubernetes still lacks (or always will, by design), but there are already unspecified Google projects running on Kubernetes.
Just getting back into Go (was Clojure), missing generics were annoying indeed. Though doing things with strings in source isn't fundamentally different from type erasure in the JVM (can wiki the term). Ie. Generics in Java are strings in the source code that don't make it through compilation either, Java just has explicit syntax for it and IIRC C++ templates generate a collection class for each type.
As one of the perpetrators of gengo, we focused on simple, fast, and dirty. We wanted something a little higher level than Go AST to deal with types (for gen), and we knew we wanted to gen a ton of code.
Some of the Kube code generation would not be solved by generics (or at least, not obviously) such as our API conversion logic which defines arbitrary transforms between structs and generates the rest. The others (proto, defaulting, etc) would.
Go isn't particularly fast or close to the metal as compiled languages go - I feel like a lot of people compare it against scripting languages but those aren't the only alternatives. If GC is acceptable you have a wealth of mature languages available with a proper type system, e.g. OCaml.
Just the most well known ones, even if most of them are currently no longer used and failed the market for various reasons.
Algol-68RS, CLU, Mesa/Cedar, Oberon, Oberon-2, Oberon-07, Active Oberon, Modula-2+, Modula-3, Eiffel, Component Pascal, Swift (RC is a GC algorithm), Standard ML, MLton, Sing#, System C#, .NET Native (VB.NET and C#)
Does Go have a strong type system, or does it have an Algol-style type system? I'm pretty sure it's the latter, unlike OCaml and Haskell. It's competing with C++, in other words, so there's your basis for comparison.
Go's type system is "strong," as far as that goes. In comparison to OCaml and Haskell, Go's type system is less expressive. That is, OCaml and Haskell will let you express more invariants in the type system more easily.
The point of a type system is to make it easier to reason about your programs, so a type system like C's, where almost all of the types are size specifications, like the difference between short and int and long, is almost orthogonal to the purpose of having a type system in the first place: It doesn't matter if someone's height in centimeters is an int or a long, it matters that it can't be added to their age in days, and if someone tries it, the compiler catches it and alerts the programmer to nonsense in the codebase.
Being able to represent both their height in centimeters and their age in days in a 32-bit integer is pointless trivia unless you're designing a bits-on-the-wire network protocol specification, or interfacing with hardware registers, or designing a binary file format, in which case C's type system still doesn't give you enough information, because endianness is not specified.
Object systems are an attempt at solving the "Foogols don't have real type systems" problem, but they drag in notions of hierarchy which don't always fit outside of toy problems, and not even then. Plus, Smalltalk-style object systems which mandate that everything must work via message-passing drags in even more complexity orthogonal to the idea of finally having a semantic type system. And as long as there are still size specification pseduo-types, boxed or unboxed, the type system still has an inherent hole in it, because you can still say nonsense which type-checks perfectly cleanly.
So saying Go has a strong type system and comparing it to OCaml or Haskell is meaningless, because the two kinds of type systems (that is, real, semantic type systems versus size specifications) aren't trying to do the same thing.
Your entire comment seems to be about C. But you asked about Go. C's type system is classically considered "weak" and Go's is considered "strong." This isn't controversial, insomuch as "weak" and "strong" have meaning in the first place. C will perform some implicit conversions between types for you. Go won't. That's the difference that causes one to be considered weak and another to be considered strong.
Any two type systems can be meaningfully compared. My comparison was exceptionally broad and seems perfectly consistent with everything you said.
My point is, types which specify low-level details about data size and representation but not the semantics of which operations are actually sensible to use on them and which types can be meaningfully used together are not really types, in that they don't make programs any easier to read or write.
I also deny that autoconversion weakens a type system. For example, if you have a data type which holds a person's height, it is utterly uninteresting what units it's in most of the time, and it can save a lot of trouble if the runtime or compiler keeps track and converts automatically if you try to add a height currently being stored as inches to one currently being stored as centimeters, or adding centimeters to fractional centimeters rounded to the nearest millimeter, for example. There are any number of purely mechanical autoconversion tasks which can and should be done automatically and which don't change the type, in that they don't change which operations are valid for the value. And that autoconversion still wouldn't make adding height to age any more sensible, even if the two values were truly indistinguishable at the machine code level.
> the semantics of which operations are actually sensible to use on them and which types can be meaningfully used together
Go lets you do this just fine. I think it would help if you used concrete examples to demonstrate what you mean.
> I also deny that autoconversion weakens a type system.
Deny it all you want. I don't really care to get into a definitional war with you. The definitions I use are the ones that have a consensus backing them[1]:
> in general, a strongly typed language is more likely to generate an error or refuse to compile if the argument passed to a function does not closely match the expected type. On the other hand, a weakly typed language may produce unpredictable results or may perform implicit type conversion.
If you read that article, you'll see that most of it is about describing what the terms mean. There is no precise definition, and I've been careful to embrace that fact in my comments. Nevertheless, in common usage, the terms "strong" and "weak" in the context of type systems typically demarcate the prevalence of implicit autoconversions between types.
> And that autoconversion still wouldn't make adding height to age any more sensible, even if the two values were truly indistinguishable at the machine code level.
Weaker type systems permit this form of autoconversion. Notice that "strong" and "weak" are properties of the type system itself, and that they refer to implicit autoconversions between types. Autoconversions that occur because of appropriate polymorphism defined by users of the language is an orthogonal concept.
I think the bottom line is that you aren't using "strong" and "weak" as they are commonly used. If you want to make up your own definitions for them, then please just say that so that we can stop wasting time. (I have no problem with you coming up with your own definitions, I just want you to acknowledge that you're doing it.)
You didn't use a single concrete example. Please show some Go code that demonstrates your point.
> I also don't appreciate being downvoted for having a pleasant discussion relevant to the topic.
I didn't downvote you (I couldn't even if I wanted to, HN disallows it). But you have certainly not made this a pleasant conversation. Your comments aren't intelligible to me. I've asked for clarification and you haven't given it, which leads me to believe you aren't interested in a good conversation.
> Proof that the type system I'm talking about isn't weak
I never contested that.
> unlike the ones C and Go have.
The only claim I've made is that Go's type system is "strong." You have, not once, ever responded to this claim directly.
Keep in mind that reference counting, which Rust supports in its standard library, is a also form of garbage collection. It may not be part of the core language, but then again neither are RAII in C++, monads in Haskell, and getters/setters in Java.
Yeah...no GC'd language is really close to the metal.
> I think Go is still a decent choice for Kubernetes.
After what you described, it sounds like the authors decided to double down on their choice and dig a deeper hole rather than use the right tool for the job.
Why? Azure can only benefit from this and Azure's pretty damn good right now. It seems like an alignment that will be beneficial for everyone involved.
No matter where you are, Microsoft gives you far better guarantees _and_ technical options to make sure your systems are your own. If you're going to interact with EU folks, Azure is by far the best way to still get modern cloud benefits and obey privacy and data locality laws.
Sadly they've discovered that's only really an enterprise play. Even if it's cheaper, Startups just don't care enough (truth be told, they can't generally source good distributed systems and even in the EU view regulatory compliance like tech debt). Grabbing helm, I think MS is trying to appeal to the smaller market by adopting Google's (very interesting and good) approach of making the core admin layer open source.
Microsoft hasn't shown interest (or has refrained from) making many fully batteries-included-but-now-you-can-never-leave approach Google has (which has mixed results, GAE was a disaster but Firebase seems very good?), so they need something sustainable to market Azure to smaller customers (their current strategy is substantial subsidization).
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.
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.
For example, if you want to deploy a distributed TensorFlow training on kubernetes with multiple parameter servers and task servers, it is a nightmare to do just with kubernetes yaml templates. Helm and it's go templating makes it much much easier.
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.
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.
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.
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.
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...
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. :/
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.
That's an unusual experience. The Azure API is _horrible_ throughout (the AWS one is more variable, but the common parts are fine). The Azure portal may be pretty, but that is at the expense of being actually usable or useful.
Oh my god, no. The Azure Portal is absolutely the worst part of the Azure experience, by a long, long stretch. I don't know anyone who uses it regularly who likes it.
I doubt Microsoft have much to gain making a competing container orchestration platform. On the other hand, having Azure be a solid place to host Kubernetes is probably a huge financial win for them.
