7 ms·
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 Rus
by mweibel 7y ago
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 to get rid of?
- latchkey 7y agoI concur, my same reaction as well. Every place I've worked at where there was a line drawn in the sand like this, showed a huge amount of dysfunction, chair spinning and finger pointing.
- gabrtv 7y agoGabe from the Azure team here. If you’re talking about orgs where software is tossed over the wall from dev to ops, then I agree. The goal here is to empower the internal ops function to build self-service platforms with clean interfaces so developers can do what they do best, which is write code and business logic.
- latchkey 7y ago> "developers can do what they do best, which is write code and business logic" That is the exact mentality that I see as totally dysfunctional.
- resouer 7y agoUnfortunately, that's not what OAM could provide to you. OAM is just a contract between dev and ops so ops could tell what he has (Trait) in a way dev understand, and dev could tell ops what he want (Components) in a way easy to manage by ops. That's all.
- Lutger 7y agoAgree. This looks to me as if the audience is traditional enterprise who haven't yet adopted DevOps and to make kubernetes more accessible. But those are likely better served by either a PaaS or serverless solution. It doesn't inspire a great deal of confidence that the Azure CTO promotes this development model - if he isn't quoted out of context that is.
- gabrtv 7y agoGabe from the Azure team here. The goal of OAM is to promote better layering of the development and operations functions inside any org. This is modeled from what we’ve learned about high-functioning teams operating Kubernetes at scale, plus what we’ve learned running services inside Microsoft. The desire to have software engineers focus only on business logic is strong. This tends to result in the creation of an internal “platform team” that provides services to dev teams. Effectively an internal PaaS. OAM helps enable this pattern.
- jacques_chester 7y agoPivotal 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, applying our existing thinking about product development and lots of learning from industry peers.
- vturecek 7y agoYes 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!"
- 7y ago
- tikkabhuna 7y agoAs 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?
- gabrtv 7y agoGabe from the Azure team here. 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.
- Dev_2019 7y agoAs a developer I don't want to touch ops. So "we" does not exist.
- klodolph 7y agoLike… you don’t want to talk to the ops team at all? You don’t want them to talk to you? (Also… in English, “we” does not always include the listener. Whether the listener is included is unspecified.)
- byte1918 7y agoFrom experience, I think he just means he doesn't want to work on operations tasks. I don't think he has anything against people doing ops.
- ownagefool 7y agoI think the idea that a Ops needs to wake up in the middle of the night to deal with shit outages because a developer is unwilling to stand behind their code is probably outdated. Build & Run is becoming very popular.
- mrweasel 7y agoWe'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 they have no idea what the developers deployed or how it's configured. Developers now need to take responsibility for application monitoring, patch management and incident management. Meaning that we're shifting more work to a group of people that where already in short supply. I don't think we're necessarily moving in the right direction. There's certainly benefits to development and operations working in tandem, but currently we're just moving operations to developers without much consideration for the people that needs to do the actual work. In my opinion your company/solution needs to be somewhat limited for "DevOps" to make sense. For everyone else, it's two separate roles.
- ownagefool 7y agoThis isn't the problem that kubernetes solves, and pretty much every bank or big org I've been involved with have little fiefdoms fighting against teamwork... err I mean DevOps.
- dfcowell 7y agoIn finance at least, there are often regulators that get in the way. For example, in my current company, we’d love to support our anemic Ops team, however a developer having any kind of influence on the deployment process is strictly forbidden by our regulator.
- ownagefool 7y agoI'm not entirly sure this is a regulatory requirement so much so, it's the solution to the requirement. I'd need to look at the regs directly, but I believe just having different roles would be enough, i.e. not being logged in as a production admin all day long, and doing devops and CI/CD, would probably allow a dev to support production under break glass circumstances.
- klodolph 7y agoNot 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 wonky format is supposed to be the interface between teams that aren’t talking to each other.
- baq 7y agoi 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?
- rkangel 7y agoThe 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.
- klodolph 7y agoI 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, no, se, ax, fi, fo, gl, is, sj] Spot the error! Writing a parser is also a bit of a nightmare, because there are a bunch of features which can turn a bit dangerous if you’re not careful—things like cyclic graphs or declaring types of objects. These are complete non-issues for the other formats I listed above—they’re all trees, and it’s very unusual for parsers to let you instantiate unintended types with those formats.
- jacques_chester 7y ago> 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 engineering and platform engineering. What's important is to establish relatively clear contracts between them which avoids unnecessary complexity and delay being transmitted across the Conway boundary. Good interfaces and technical contracts between the roles make this a lot easier. It used to be that getting something up and running was difficult because the incidence of cost and control fell on opposite sides more than once. For example: As a Dev, I need a place to run my software (cost). But someone else needs to provision and install it (control). Or: as an Operator, I don't want to be paged at 3am (cost). But someone else wrote the app (control). When you draw the boundaries so that devs get self-service and ops get to (mostly) ignore what's inside the self-service boxes, a lot of this tension largely vanishes. That's not so much about whether folks sit in the same team and more about using technology to dissolve the tensions altogether. Disclosure: I work for Pivotal, we have been known to dabble in this sort of thing.
- gabrtv 7y agoWell said, Jacques.
- hiccuphippo 7y agoWouldn't this be because they want the ops team to be Azure and don't want the developer to talk to customer support?
- derefr 7y agoYou’re thinking of the separation between devs and ops at the same company. I think the text you’re quoting is talking about the separation between third-party vendors’ devs, and first-party downstream ops people. And it’s never been a goal, to disintermediate ops people from other companies’ devs. We’ve been doing just the opposite for ages, with things like VM “appliances” and Docker images, created so that the interface between “the devs at the company that created this” and “the ops people deploying it” can be more formally defined by some kind of deployment-time configuration API. This is another case of that.
- gabrtv 7y agoGabe 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.
- markbnj 7y agoThere 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. 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.
- gabrtv 7y ago> 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 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?