Live data from Hacker News

Microsoft launches new open-source projects around Kubernetes and microservices

techcrunch.com

41–50 of 129 posts

Re: Microsoft launches new open-source projects around Kubernetes and microservices

#41

Basically this is a helm chart. Which is one of the problems of k8s - a typical application consists of multiple services that need to be deployed together. In Docker Swarm, that's a Stack. K8s has no equivalent. So there's no answer to "how do i deploy/update my flask api and celery workers together"

> In Docker Swarm, that's a Stack. K8s has no equivalent.

My take is that the equivalent in k8s is it's declarative management with configuration files. Just kubectl apply -f your.yaml and you're good to go.

Re: Microsoft launches new open-source projects around Kubernetes and microservices

#42
post #32
post #29

Earlier quoted context omitted.

i honestly have trouble understanding the love for yaml when decades ago everything was xml and it was almost universally hated. technically you can define a yaml-xml isomorphism and as a consequence they both should be treated as unsuitable, and yet... yaml somehow is cool and xml isn't. am i just old?

The fact that they're isomorphic to machine partly misses the point. Yaml is immensely more friendly on the human to write (and read). Yaml is used when people need to write declarative instructions to machines, and it does a good job of that. XML is much more of a pain to read and write by hand.

my point is that yaml isn't easier to write at all; it isn't as verbose but it bites you all over the place with unexpected behavior and the fact that validating the schema isn't the same as checking the syntax is super frustrating as you can create a valid yaml file with a typo and it'll be an either invalid or noop configuration. i'd rather have a proper DSL, preferably strongly typed.

Re: Microsoft launches new open-source projects around Kubernetes and microservices

#43
post #29

Earlier quoted context omitted.

i honestly have trouble understanding the love for yaml when decades ago everything was xml and it was almost universally hated. technically you can define a yaml-xml isomorphism and as a consequence they both should be treated as unsuitable, and yet... yaml somehow is cool and xml isn't. am i just old?

I didn’t understand the XML hate either. It was just a bit annoying to parse, depending on the language and ecosystem you used. It was a little verbose, but so what?

The biggest problem to me is that XML is not a data serialization language, it's a document markup language. In documents, the distinction between attributes and content makes sense. In data serialization, the choice of whether a given datum is an attribute or a text content appears rather arbitrary. Should I write this?

  
    XML Cookbook
    Jane Doe
  
Or this?

  
Now attributes don't work when there are multiple values, so I guess I should use attributes for single values and child nodes for lists:

  
    Jane Doe
    Tim Pickens
  
But that rule also has problems. If I decide to include markup in the title, it suddenly needs to be a child node again:

  
    The Awesome XML Cookbook
    Jane Doe
    Tim Pickens
  
Also, "author" is a misleading name for a field that is actually an array, so should I actually use an "authors" node to make that clearer?

  
    XML Cookbook
    
      Jane Doe
      Tim Pickens
    
  
Or maybe:

  
    XML Cookbook
    
      
      
    
  
Now compare to this to YAML:

  book:
    title: XML cookbook
    authors:
      - name: Jane Doe
      - name: Tim Pickens
Or even just:

  book:
    title: XML cookbook
    authors: [ Jane Doe, Tim Pickens ]
I need to make way fewer design choices when writing that down. In fact, I probably don't need to design anything since that's already the data structure that I've written down as a type somewhere in my code. That's why it's a good idea to use a data serialization language for, well, data serialization.

Re: Microsoft launches new open-source projects around Kubernetes and microservices

#44

Basically this is a helm chart. Which is one of the problems of k8s - a typical application consists of multiple services that need to be deployed together. In Docker Swarm, that's a Stack. K8s has no equivalent. So there's no answer to "how do i deploy/update my flask api and celery workers together"

> In Docker Swarm, that's a Stack. K8s has no equivalent. My take is that the equivalent in k8s is it's declarative management with configuration files. Just kubectl apply -f your.yaml and you're good to go.

Ideally yes, however in practice a template engine is nice.

Re: Microsoft launches new open-source projects around Kubernetes and microservices

#45
post #7

OAM is essentially a YAML file. It can be put in a service catalog or marketplace and deployed from there. But what’s maybe most important, says Russinovich, is that the developer can hand off the specification to the ops team and the ops team can then deploy it without having to talk to the developer. This statement sounds very backwards to me. Isn't this increasing the separation between devs and ops which we want…

As a developer I don't want to touch ops. So "we" does not exist.

"we" doesn't necessarily include all.

Anyway, that's a bit sad IMHO. In my opinion, running what you build is great to discover ways to improve your software.

Regardless if you want to or don't want to touch ops: You still might want to talk to ops or vice-versa. Even if you have strict roles for devs and ops (and no mixed roles), you might be in a team where both are present and hopefully talk to each other.

Re: Microsoft launches new open-source projects around Kubernetes and microservices

#46
post #7

OAM is essentially a YAML file. It can be put in a service catalog or marketplace and deployed from there. But what’s maybe most important, says Russinovich, is that the developer can hand off the specification to the ops team and the ops team can then deploy it without having to talk to the developer. This statement sounds very backwards to me. Isn't this increasing the separation between devs and ops which we want…

As a developer I don't want to touch ops. So "we" does not exist.

The truth of what the code that you develop actually does, is in production; often buried in log stores and timing stats and other "ops" places.

It's better if that data is unearthed and fed back into the development process, it's better if that feedback loop is closed, it's better if that separation is removed.

That's one of the reasons for "DevOps" as originally formulated.

Re: Microsoft launches new open-source projects around Kubernetes and microservices

#47
post #36

Earlier quoted context omitted.

I used to think YAML was friendly for humans to read. Then I wrote a parser for it, and discovered all the weird corners, edge cases, etc. I now consider it to be a fairly user-hostile format, which should be avoided in favor of just about everything else (XML, JSON, TOML, text protobuf, etc are all more friendly). For example, consider this map of regions in YAML: regions: northamerica: [ca, us, mx] scandinavia: [dk…

> Stop the error! I know this is rhetorical, but I've been bitten by this enough times so for those who don't know `no` will translate to a boolean false.

Am I rhe only one who likes single quotes around literal strings?

Re: Microsoft launches new open-source projects around Kubernetes and microservices

#48

Earlier quoted context omitted.

We're reaching a point where two groups of people, rather than one, is required to wake up in the middle of the night. Previously just the operations people needed to get up, now developers need to be on-call as well. Operations teams are scaling down their monitoring to just infrastructure, because the applications are more opaque than ever. Incidents at the application level are no longer fixable by Ops, because th…

I would say that the problem in this situation is hard to avoid. If you can have an operations team who are experts on the application as well, and have the team more closely integrated with the development team, then you generally don’t need to wake up developers at night. I spent a few years on a team set up like this and it worked very well. If your project isn’t big enough for its own operation team you can share…

DevOps is not a role. You arebtalking about a modern ops role in this dialogue.

Merging the two as you said, is DevOps.

Re: Microsoft launches new open-source projects around Kubernetes and microservices

#50
post #36

Earlier quoted context omitted.

I used to think YAML was friendly for humans to read. Then I wrote a parser for it, and discovered all the weird corners, edge cases, etc. I now consider it to be a fairly user-hostile format, which should be avoided in favor of just about everything else (XML, JSON, TOML, text protobuf, etc are all more friendly). For example, consider this map of regions in YAML: regions: northamerica: [ca, us, mx] scandinavia: [dk…

> Stop the error! I know this is rhetorical, but I've been bitten by this enough times so for those who don't know `no` will translate to a boolean false.

Thanks. I was staring at the snippet wondering. I'm not all that familiar with YAML, so I thought perhaps all the values needed to be quoted rather that just written as is.
Post reply on HN