Live data from Hacker News

Microsoft launches new open-source projects around Kubernetes and microservices

techcrunch.com

111–120 of 129 posts

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

#111
post #99
post #97

Earlier quoted context omitted.

There is a whole layer of on-prem care and feeding of kubernetes with which I have no experience (having run workloads on GKE for four years), and it certainly makes sense that there is some specialization of that stuff and separation between the people who implement those things and the people who develop back end apps. But I balk at the idea that there is a general good to be had from further separating dev and ops…

> But I do know that on our much smaller team the back end engineers have become thoroughly comfortable with performing those tasks for their own applications with a little assist here and there from devops. The challenge I'm wrestling with is the smaller teams you're referencing -- the ones who can write the Kubernetes YAML for Ingress, HPAs -- they aren't representative of mainstream enterprise developers. More imp…

>> The challenge I'm wrestling with is the smaller teams you're referencing -- the ones who can write the Kubernetes YAML for Ingress, HPAs -- they aren't representative of mainstream enterprise developers.

Yeah its an interesting question, and I think to some extent it is addressed by the devops model. If you take the entirety of a kubernetes deployment manifest as an example, it represents a range of concepts that cross over from the application to the infrastructure sphere. On the one hand back end engineers should certainly be able to specify their own entrypoints, probes, environments, etc. On the other they are probably not qualified to set affinity and toleration, and might not be familiar with the finer details of probe timing properties or update strategies, again just to give a few examples.

On our team we recognize that a range of inputs are needed from different perspectives to achieve the final deployment spec. The pipeline is based on kustomize and patches so back end engineers can write the patches that set up things like I mentioned above, and devops (which in our group is a role combined somewhat with SRE) can assist in fine tuning those, and in writing patches to set the infrastructure level concerns like what nodepool the thing has affinity for. It's worked well for us but I am not expert in the enterprise arena.

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

#112
post #85
post #71

Earlier quoted context omitted.

That only works until your first outage :) K8s isnt bulletproof and requires significant care. Not to mention constant upgrades

The bit about significant care may be true in on-prem installations, I don't know, but GKE for example is pretty darn bulletproof. As for upgrades, they do come along frequently and you don't want to get too far behind. Rolling nodepools has made the process a lot less labor and time intensive for us.

From my perspective using GKE or any other k8s service isn't you running k8s. It's you paying devops salaries to release managers.

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

#113

Earlier quoted context omitted.

Pivotal Labs in fact has an entire practice focusing on teaching and evolving the practice of "Platform as a Product". Operations is more than "just" operations, it's an engineering practice. You're delivering capabilities to a customer, looking for ways to make everyone's lives easier and better and faster. I think that like folks at Azure, we evolved the approach based on experiences dogfooding various platforms, a…

Yes precisely! OAM is meant to provide some consistency and standardization to this practice, while fully expecting each platform to have unique capabilities and requirements that can be surfaced through the model. It's really illuminating how often we hear "oh hey we're trying to do something very similar to OAM!"

I think the tricky part of the sale will be in abstracting away Kubernetes; or at least, not adopting its conventions for registration and discovery of resources/endpoints. You can keep those and not use Kubernetes, which is more or less how Knative went about it (insofar as it's possible to create an implementation that's Knative without using Kubernetes).

I am however overall very sympathetic to the idea that Kubernetes never drew a crisp line between roles.

Disclosure: I'm writing a book about Knative.

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

#114

Earlier quoted context omitted.

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 gue…

Thank you for articulating this, but I’m familiar with these complaints. XML does give you a lot of freedom to format your data in different ways, which can get you into traps. I’ve run into those traps before, like the decision between attributes and child nodes. This doesn’t add up to XML hate, for me. The way I would probably write the document is: XML Cookbook Jane Doe Tim Pickens This is a fairly boring way to w…

I've grown to like Avro, mostly because of its ability to support schema evolution for reader and writer independently. You get the usual niceties around binary wire format, schema, dynamic parsing and/or code generators etc.

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

#115

Dapr looks like Microsoft's answer to Istio - anecdotally, I've never gotten Istio to work (as recently as a few months ago) so I'll have to give this one a try at some point to see if they've done a better job. OAM though, perplexes me. Even the justification - that k8s is out of scope of the developer, and is handled by ops - speaks to a misunderstanding of some of the advantages clusters provide. Some research [1]…

Dapr is definitely not Microsoft's answer to Istio (see e.g. [1]). But if you are looking for something like Istio but that actually works out of the box (zero config), I'd highly recommend checking out Linkerd.

[1] https://news.ycombinator.com/item?id=21283956

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

#116
post #75

Earlier quoted context omitted.

Fundamentally, k8s isn’t a compute job scheduler—it’s an IaaS state converger, like Terraform, or AWS CloudFormation. As such, it needs to know how to model—and manipulate—the state of pretty much any IaaS resource you have. (And, unlike alternatives, it’s also extensible with custom convergible resource types, too.) That doesn’t mean that k8s itself is all that complex. It just needs a lot of libraries for all the s…

I think Kubernetes-the-scheduler and Kubernetes-the-patterns-with-reified-examples have diverged and are going to continue diverging. The latter is more of a microkernel for distributed control systems. My hunch is that this means OAM may be dead letter in the long run. Abstract from Kubernetes-as-scheduler, fine and good. But Kubernetes-as-microkernel is close to doing that already. Whatever my gripes about the deta…

Keeping different perspectives and roles in mind is important here.

I think the quotes in the article make very good points.

I've introduced Kubernetes at multiple companies , usually with good results.

But Kubernetes is a relatively low level runtime. It requires a lot of knowledge if you want to use it correctly, even with hosted Kubernetes offerings.

Application developers want to specify how the application works without having to learn a whole lot about Kubernetes internals. They also want the freedom to run something on different platforms without a lot of changes.

Think Elastic Beanstalk or Google App Engine, but provider independent. With the freedom to run it locally , maybe on a cheap self hosted cluster for dev deployments and on AWS for production. This is a lot of work right now, even with the hosted Kubernetes offerings.

Also enterprises often want to offload the decision making and rely both on common standard solutions and outside support if things happen. This is hard with k8s due to the flexibility of the platform.

I agree that it is too low level and too complex to provide a good company wide foundation on its own.

OAM could be a very valuable tool to have.

Also the points about Dapr resonant e. Building a complex event driven architecture with many services is what a lot of enterprises want , but it is really hard to do it well. There is a similar effort by IBM , but I don't remember the name right now.

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

#117
Referring to Microsoft's original announcement post of OAM, (https://cloudblogs.microsoft.com/opensource/2019/10/16/annou...), the problem of defining application workflows and their dependencies that OAM is addressing is genuine. We have also faced this problem as part of providing Kubernetes-native platform stacks to our customers.

It will be interesting to see how OAM evolves, especially since it is coming from the same team that is leading the charge on Helm and CNAB (https://cloudblogs.microsoft.com/opensource/2018/12/04/annou...).

Here is what we have learnt about this space in the last one and a half years.

Application portability - While the point about application portability is true, if an organization has decided to adopt Kubernetes, the portability requirement is solved by Kubernetes itself to a large extent. If your application platform workflows are built as Kubernetes YAMLs, then they can be run on any cluster. Kubernetes YAMLs of built-in resources (Pod, Secret, etc.) and Custom Resources (MySQL, Postgres, etc.) can be leveraged to create such Kubernetes-native platform workflows. Our learning has been that a solution that focuses on solving the platform workflows problem on Kubernetes needs to augment existing Kubernetes tools such as Helm, Kustomize, etc. We have been developing such a tool (https://github.com/cloud-ark/kubeplus). Check out this blog post which provides detailed comparison between existing tools. https://medium.com/@cloudark/discovery-and-binding-of-kubern...

On separation of concern between Devs & Ops - Again with adoption of Kubernetes, our observation has been that Kubernetes YAML and the tooling around it such as Helm is becoming a common language of communication between Devs & Ops. In our view the goal for anyone developing new tools/frameworks in this space should be to help break the barriers that have existed between Dev and Ops teams further. One way we are trying to do this is by extending the vocabulary of ‘as-Code’ systems from the Infrastructure world to the ‘platform’ world of application development teams. Check out some of our work in this space primarily focusing on Kubernetes Custom Resources here - https://cloudark.io/platform-as-code

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

#118

Earlier quoted context omitted.

I think Kubernetes-the-scheduler and Kubernetes-the-patterns-with-reified-examples have diverged and are going to continue diverging. The latter is more of a microkernel for distributed control systems. My hunch is that this means OAM may be dead letter in the long run. Abstract from Kubernetes-as-scheduler, fine and good. But Kubernetes-as-microkernel is close to doing that already. Whatever my gripes about the deta…

Keeping different perspectives and roles in mind is important here. I think the quotes in the article make very good points. I've introduced Kubernetes at multiple companies , usually with good results. But Kubernetes is a relatively low level runtime. It requires a lot of knowledge if you want to use it correctly, even with hosted Kubernetes offerings. Application developers want to specify how the application works…

To put it really simply: there's not a lot to kubernetes internals that you should know. The abstractions in k8s are really, really good.

The problem is migration. Old apps don't handle k8s very well. An application that follows the k8s model should be really easy to deal with. It either is one of a bunch of figuratively identical apps, and you connect randomly, or it is part of a master/Replica group. Older applications need help with that, or expect multiple connections to the same host, or... Any number of anti-patterns.

(Databases excluded - the Borg version of Statefulsets operates very differently, significantly because the trade-off of speed/reliability of persistent storage sucks in the cloud world right now.)

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

#119
post #19

Dapr sounds like it could be cool. Almost like a cloud function but with more intelligence.

MarkF from the Azure team here. The idea is to provide a function like experience with any programming language and then have common capabilities like saving state, sending events that your app can use with local host calls. And make this all extensible with components

>MarkF from the Azure team here.

Glad to see you engage. Thanks to enterprise sub & monthly credit azure is def my favorite cloud right now :)

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

#120
post #101

Dapr looks like Microsoft's answer to Istio - anecdotally, I've never gotten Istio to work (as recently as a few months ago) so I'll have to give this one a try at some point to see if they've done a better job. OAM though, perplexes me. Even the justification - that k8s is out of scope of the developer, and is handled by ops - speaks to a misunderstanding of some of the advantages clusters provide. Some research [1]…

> If Azure comes out with an implementation of OAM that uses their VSIs, I'll get interested. Gabe from the Azure team. VSIs? I'd love to understand this better.

Virtual Server Instances - VMs :)
Post reply on HN