21–30 of 129 posts
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…
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…
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…
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.
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.
(Also… in English, “we” does not always include the listener. Whether the listener is included is unspecified.)
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.
Build & Run is becoming very popular.
Earlier quoted context omitted.
As a developer I don't want to touch ops. So "we" does not exist.
Like… 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.)
Earlier quoted context omitted.
As a developer I don't want to touch ops. So "we" does not exist.
I 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.
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.
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"
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…
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…
am i just old?
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 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.