91–100 of 129 posts
Dapr looks like a slightly beefier sidecar-based service mesh.
The sidecar pattern is shared by a service mesh, so I understand the comparison. However Dapr is focused on enabling in-IDE experiences versus intercepting and proxying networking traffic like a service mesh.
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 he mentions marketplace, maybe he's talking about product developers and ops teams in other organisations? Elastic, for example, publish an OAM that helps X organisation to get started and they can customise the implementation?
Yes that is what Mark meant. At Microsoft we care deeply about empowering ISVs — we always have. OAM is designed to allow components from an ISV to be bound to a runtime environment by a separate consumer, where the concept of traits can provide configurability for things like ingress, autoscaling, secrets management, etc.
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…
> This statement sounds very backwards to me. Isn't this increasing the separation between devs and ops which we want to get rid of? I think the answer is that this can't be settled once and for all, because there are economies from specialisation and diseconomies from coordination. My general view these days is that for a sufficiently large org, you will inevitably have a degree of separation between application eng…
When Docker came out, I was just finishing an in-house-Heroku style project at my employer, based on LXC containers. I watched as Deis came along, promising to give the same benefits in an open platform. I was sad to see Deis go away after the Microsoft acquisition. The industry got all excited about Kubernetes, but it seemed to me like we were backsliding from progress that had been made toward a 12 Factor platform. (https://www.12factor.net/) . It's very encouraging to see that coming back.
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.
This is exciting! When Docker came out, I was just finishing an in-house-Heroku style project at my employer, based on LXC containers. I watched as Deis came along, promising to give the same benefits in an open platform. I was sad to see Deis go away after the Microsoft acquisition. The industry got all excited about Kubernetes, but it seemed to me like we were backsliding from progress that had been made toward a 1…
Glad you like what you see. The original Deis team worked on much of it. I’m happy to say we have a lot more innovation coming in the PaaS space.
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…
Gabe from the Azure team here. We do want to promote more separation between dev and ops. Taking on too much conceptual overhead is hard for any engineer. By having developers focus on business logic and operators focus on platform concerns, both can be more productive.
But I balk at the idea that there is a general good to be had from further separating dev and ops. Isn't the whole point of kubernetes to provide useful control abstractions over the complexities involved in deploying components on the back end? You seem to be implying that once an engineer has developed a thing it needs to be tossed over a wall so that a specialist can write the k8s manifests, determine the runtime resource requirements, provision ingress, etc. Maybe that general approach is necessary in the enterprise environments which seem to be Azure's primary target market, I don't know. 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. Most of them never have to touch kubectl because deployment to test and production environments is handled by ci/cd pipelines, so really their concerns are focused on writing proper manifests to create the environment their thing needs. I don't think that is too complex a task for someone whose daily job is writing back-end server components.
Earlier quoted context omitted.
Not only that, but YAML as configuration has some pretty significant drawbacks in that the natural (but disastrous) trend is towards using text templating systems to generate YAML files. It’s also a bit difficult to parse or write correctly. Yes, you “shouldn’t” use text templating systems for YAML and you “should” use well-tested YAML parsers and emitters. But I am very skeptical here, especially given that this won…
Gabe from the Azure team. +1 on YAML having its fair share of problems. I like to think of them as our collective problems, since nothing has emerged to replace YAML yet. If something does I’m certain OAM could be adapted to it. I’ve personally seen some promising exploration of config through Turing-complete languages like TypeScript. See Pulumi.
I think if you have this viewpoint, you have probably defined your problem too narrowly, and may want to revisit some of your requirements.
I took a look at some of the example config files in the GitHub, and what I see are future problems when people deploying applications need to use some kind of templating system to deploy multiple variations of an application (e.g. production / development, or different replicas).
If you show these configuration files and ask a developer to whip up some templates, they are almost certainly going to reach for a text templating system, and down the road you will see broken configs. This creates an additional burden for tech leads who will need to educate their team on how to avoid the various traps when generating YAML files.
I could be deeply mistaken here about the nature of how these config files work, but that is my first impression. What I would be looking for if I were evaluating this software is an alternative configuration format which is more “bulletproof” like JSON or XML, since I know that there is excellent tooling for these formats, and they don’t suffer from the same kinds of traps and other defects as YAML does.
Earlier quoted context omitted.
Gabe from the Azure team here. We do want to promote more separation between dev and ops. Taking on too much conceptual overhead is hard for any engineer. By having developers focus on business logic and operators focus on platform concerns, both can be more productive.
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…
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 importantly, they're not representative of the millions of new developers who we need to empower with simpler code-to-cloud solutions that are also build on a layered, industry-standard foundation (e.g. Kubernetes).
How do we empower these new developers without separating concerns and reducing cognitive overhead around ops?
Somehow these enterprise people have turned Kubernetes, which basically was an advanced job scheduler for compute resources, into a unnecessary complex monster (just look at the LOC of kube-api). And that's still pretty decent compared to all the other projects in the ecosystem (looking at OpenShift, Istio ...). I really don't believe a lot of people have a valid use case for these projects like OAM when you look at…
A fair amount of bulk rests at the feet of Golang, not Kubernetes per se. Vast sweeping vistas of Kubernetes code is generated from a handful of files because generics are silly and code generation is just swell.