Check my 2 min audio theory on Containers
-
My university and early career was first a career in software engineering, then I did university for specifically manufacturing systems engineering, then I went back to software engineering, did that in university. IT is what I came to last in my career.
I grew up with a father who was an industry leader in exactly this stuff and our plan was to run a manufacturing systems consultancy, even as far back as 1990. So from both sides, manufacturing engineering and software engineering, this is exactly my wheelhouse of study and background.
-
@scottalanmiller said in Check my 2 min audio theory on Containers:
@flaxking said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
@flaxking said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
@flaxking said in Check my 2 min audio theory on Containers:
DevOps is not a department, and companies that uses titles like DevOps Engineer probably aren't really doing DevOps, just using some DevOps tools.
As someone who was in a DevOps department, separate from the non-DevOps SA department, it really is. Uncommon, but real.
DevOps is supposed to be interdepartmental. I would imagine this DevOps department would just be IT with the experience to support Development.
DevOps is using traditionally development processes to do SA work, "Software Defined Administration" it is sometimes called. You don't need developers to have DevOps, In fact, most DevOps shops have none.
Normal SAs support developers, probably better than DevOps does.
That is not DevOps. DevOps is a refactoring of Lean Manufacturing in order to apply to software companies. You can adopt DevOps principals without your own developers, but it you cannot do real DevOps without developers participating in the feedback loop.
We're talking the IT DevOps here, not the software teams using the term for their own stuff. That's the newer (AFAIK) add on term after the fact.
A proposed definition is "DevOps is a set of practices intended to reduce the time between committing a change to a system and the change being placed into normal production, while ensuring high quality." Which is key that it's an ops (aka IT) concern, not a software one. DevOps starts after dev stops. Dev makes a change, Ops puts it into production. DevOps is a type of ops designed to do so quicker and more accurately. But nowhere does that definition suggest that dev start doing ops, that ops start doing dev (of the software itself), or that the two merge or even talk. It's still a pure ops thing, just using techniques learned from dev.
Admittedly the name is ridiculous and probably intended to be misleading, although it didn't originate in English so maybe it's just poor English usage. Calling any form of ops with a "dev" title is just dumb. Ops is ops, dev is dev, using dev concepts in ops doesn't change it from being ops.
It is not the newer add-on, it is the original concept. http://www.jedi.be/blog/2009/12/22/charting-out-devops-ideas/
What you're talking about is one aspect of part of implementing DevOps that is often misinterpreted to mean the whole of it. And yes, it is stupid to call that DevOps. That's just Ops using different tools.
-
@flaxking said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
@flaxking said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
@flaxking said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
@flaxking said in Check my 2 min audio theory on Containers:
DevOps is not a department, and companies that uses titles like DevOps Engineer probably aren't really doing DevOps, just using some DevOps tools.
As someone who was in a DevOps department, separate from the non-DevOps SA department, it really is. Uncommon, but real.
DevOps is supposed to be interdepartmental. I would imagine this DevOps department would just be IT with the experience to support Development.
DevOps is using traditionally development processes to do SA work, "Software Defined Administration" it is sometimes called. You don't need developers to have DevOps, In fact, most DevOps shops have none.
Normal SAs support developers, probably better than DevOps does.
That is not DevOps. DevOps is a refactoring of Lean Manufacturing in order to apply to software companies. You can adopt DevOps principals without your own developers, but it you cannot do real DevOps without developers participating in the feedback loop.
We're talking the IT DevOps here, not the software teams using the term for their own stuff. That's the newer (AFAIK) add on term after the fact.
A proposed definition is "DevOps is a set of practices intended to reduce the time between committing a change to a system and the change being placed into normal production, while ensuring high quality." Which is key that it's an ops (aka IT) concern, not a software one. DevOps starts after dev stops. Dev makes a change, Ops puts it into production. DevOps is a type of ops designed to do so quicker and more accurately. But nowhere does that definition suggest that dev start doing ops, that ops start doing dev (of the software itself), or that the two merge or even talk. It's still a pure ops thing, just using techniques learned from dev.
Admittedly the name is ridiculous and probably intended to be misleading, although it didn't originate in English so maybe it's just poor English usage. Calling any form of ops with a "dev" title is just dumb. Ops is ops, dev is dev, using dev concepts in ops doesn't change it from being ops.
It is not the newer add-on, it is the original concept. http://www.jedi.be/blog/2009/12/22/charting-out-devops-ideas/
I read that, and I see early on, 2009 Patrick mentioning it, and Patrick is the name creator so I'm happy with him being definitive, but if you read it, it seems to just be an "also mentioned" in a list of how to do DevOps well. It doesn't seem core and the feedback being more in design that delivery. I'm fine with that, but it doesn't seem to be "part of" DevOps in his mind, but just a way that DevOps can be doing its just well, no different than System Administration without DevOps should. Dev needs to talk to Ops, they share goals, yes.
He lists the core ideas of DevOps and they are very clearly ops functions. Then in a long list of "devops" ideas, one of about a dozen just mentions that it would be useful for operations to talk to developers early so that they developer around shared needs. Great stuff, but something that existed just as much pre-DevOps, and seems to be simply "a thing to keep in mind". Not core to the concept.
-
@flaxking said in Check my 2 min audio theory on Containers:
What you're talking about is one aspect of part of implementing DevOps that is often misinterpreted to mean the whole of it. And yes, it is stupid to call that DevOps. That's just Ops using different tools.
I see it as the opposite. Patrick's core DevOps...
"Thanks to the devopsdays conference, the idea of devops seems to live on. While talking with other people about it, I realize that it is difficult to frame it within the current IT landscape. At lot of the ideas are coming from different kinds of emerging technologies (T) and process management (P) approaches.
For me the two most important observations are:
- there is a increase in feedback loops between business, all parts of the delivery process and operations
- thanks to this feedback loops we increase the quality and speed up the flow"
This is the core of DevOps, not well described, but pretty clearly about IT, not development. This is the core. Very, very loosely defined to the point of useless, sure.
Then things like DevOps talking dev itself is the extra, the tack on later. It's not "part of" devops, any more than it is of any operations. And just how operations doesn't cease to exist without developers, neither does DevOps.
-
@Emad-R just to go back on topic: do not confuse snaps or lxd with docker. Docker is mostly for developers who do not package their apps.
-
@matteo-nunziati said in Check my 2 min audio theory on Containers:
@Emad-R just to go back on topic: do not confuse snaps or lxd with docker. Docker is mostly for developers who do not package their apps.
LOL, that's a concise way to put it
-
@scottalanmiller said in Check my 2 min audio theory on Containers:
@flaxking said in Check my 2 min audio theory on Containers:
What you're talking about is one aspect of part of implementing DevOps that is often misinterpreted to mean the whole of it. And yes, it is stupid to call that DevOps. That's just Ops using different tools.
I see it as the opposite. Patrick's core DevOps...
"Thanks to the devopsdays conference, the idea of devops seems to live on. While talking with other people about it, I realize that it is difficult to frame it within the current IT landscape. At lot of the ideas are coming from different kinds of emerging technologies (T) and process management (P) approaches.
For me the two most important observations are:
- there is a increase in feedback loops between business, all parts of the delivery process and operations
- thanks to this feedback loops we increase the quality and speed up the flow"
This is the core of DevOps, not well described, but pretty clearly about IT, not development. This is the core. Very, very loosely defined to the point of useless, sure.
Then things like DevOps talking dev itself is the extra, the tack on later. It's not "part of" devops, any more than it is of any operations. And just how operations doesn't cease to exist without developers, neither does DevOps.
I believe everything on that page is all meant to be within the context of companies doing development. But I agree, the core of DevOps is about Ops and Business practices. However, I firmly believe the name DevOps comes from Ops and Development working together, and thus the reason why discussions of DevOps implementation specifics centre around companies doing software development. Though just based on that page, I could see why someone could still take a different view. However, I consider The DevOps Handbook to be the definitive source, rather than notes on the initial discussions.
-
@scottalanmiller said in Check my 2 min audio theory on Containers:
Then things like DevOps talking dev itself is the extra, the tack on later. It's not "part of" devops, any more than it is of any operations. And just how operations doesn't cease to exist without developers, neither does DevOps.
So, I agree that the 'Dev' part is comes after the core of DevOps. So you can practice the core of DevOps without Dev. However, I do not believe that the full complete picture of DevOps is possible without Dev.
-
The core of DevOps isn't anything new, so there wouldn't be a point with giving it a new name without the add-ons.
-
@flaxking said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
@flaxking said in Check my 2 min audio theory on Containers:
What you're talking about is one aspect of part of implementing DevOps that is often misinterpreted to mean the whole of it. And yes, it is stupid to call that DevOps. That's just Ops using different tools.
I see it as the opposite. Patrick's core DevOps...
"Thanks to the devopsdays conference, the idea of devops seems to live on. While talking with other people about it, I realize that it is difficult to frame it within the current IT landscape. At lot of the ideas are coming from different kinds of emerging technologies (T) and process management (P) approaches.
For me the two most important observations are:
- there is a increase in feedback loops between business, all parts of the delivery process and operations
- thanks to this feedback loops we increase the quality and speed up the flow"
This is the core of DevOps, not well described, but pretty clearly about IT, not development. This is the core. Very, very loosely defined to the point of useless, sure.
Then things like DevOps talking dev itself is the extra, the tack on later. It's not "part of" devops, any more than it is of any operations. And just how operations doesn't cease to exist without developers, neither does DevOps.
I believe everything on that page is all meant to be within the context of companies doing development. But I agree, the core of DevOps is about Ops and Business practices. However, I firmly believe the name DevOps comes from Ops and Development working together, and thus the reason why discussions of DevOps implementation specifics centre around companies doing software development. Though just based on that page, I could see why someone could still take a different view. However, I consider The DevOps Handbook to be the definitive source, rather than notes on the initial discussions.
I think doing that makes DevOps a pointless, useless concept. Hopefully that's not what he intended. As an ops practice, it has tremendous value. As a merger of dev and ops, it's just bluster.
