Check my 2 min audio theory on Containers
-
@scottalanmiller said in Check my 2 min audio theory on Containers:
@stacksofplates said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
@stacksofplates said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
@stacksofplates said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
She is correct, of course, that the designs are different. Each OS approaches the problem from a unique angle. But all are containers and use a shared kernel to manage resources.
Docker doesn't require a shared kernel is my point. You can run a single process that requires nothing shared from the kernel. It's effectively like starting a normal so process.
I'm confused, though. "Normal processes" use shared kernels. If we use Linux or Windows, and no containerization at all, all processes use shared kernels, that's the core of normal operating system functions.
Hypervisors are what allow us to use non-shared kernels, whether for OSes or something else (rare.) Docker either has to provide another kernel that isn't shared, or must share the one that is there. That the workloads aren't tied to a specific kernel is very different than not requiring that they share whatever one is there.
Kernel agnostic isn't the same as kernel-free. You can't be kernel free, not really. You always need the kernel unless you have no multi-tasking on the system whatsoever.
But by that definition if you used Ansible to start a process you would say Ansible is using a shared kernel. That's such a weird way of saying it. Obviously a process has to use a kernel. The "sharing" comes in where you have a whole set of different libraries, etc and have to rely on a kernel that's outside of itself.
Correct, we don't say that because it's obvious and necessary so stating it is like saying that Ansible requires an OS. But obviously Ansible requires a shared kernel. What makes us mention it with containers is that unlike all other forms of virtualization that use a hypervisor to use non-shared kernels, containers are shared kernel virtualization. So it is mentioned all the time because it's necessary to understand that it is truly a container and not some other thing.
By that definition every process would be virtualized because every process would need a "shared kernel"
You are being intentionally obtuse. You pointed out how absurd it is to mention shared kernel for things that are obvious, so we don't. All mentioned of shared kernel, except when explaining kernel sharing explicitly, is a reference to container virtualization. Any reference to not being shared kernel, is a reference to Type 1 or Type 2 para/full virtualization.
Last comment. There is nothing ovtuse about it. It is literally exactly what you said.
But obviously Ansible requires a shared kernel.
-
@stacksofplates said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
@stacksofplates said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
@stacksofplates said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
@stacksofplates said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
She is correct, of course, that the designs are different. Each OS approaches the problem from a unique angle. But all are containers and use a shared kernel to manage resources.
Docker doesn't require a shared kernel is my point. You can run a single process that requires nothing shared from the kernel. It's effectively like starting a normal so process.
I'm confused, though. "Normal processes" use shared kernels. If we use Linux or Windows, and no containerization at all, all processes use shared kernels, that's the core of normal operating system functions.
Hypervisors are what allow us to use non-shared kernels, whether for OSes or something else (rare.) Docker either has to provide another kernel that isn't shared, or must share the one that is there. That the workloads aren't tied to a specific kernel is very different than not requiring that they share whatever one is there.
Kernel agnostic isn't the same as kernel-free. You can't be kernel free, not really. You always need the kernel unless you have no multi-tasking on the system whatsoever.
But by that definition if you used Ansible to start a process you would say Ansible is using a shared kernel. That's such a weird way of saying it. Obviously a process has to use a kernel. The "sharing" comes in where you have a whole set of different libraries, etc and have to rely on a kernel that's outside of itself.
Correct, we don't say that because it's obvious and necessary so stating it is like saying that Ansible requires an OS. But obviously Ansible requires a shared kernel. What makes us mention it with containers is that unlike all other forms of virtualization that use a hypervisor to use non-shared kernels, containers are shared kernel virtualization. So it is mentioned all the time because it's necessary to understand that it is truly a container and not some other thing.
By that definition every process would be virtualized because every process would need a "shared kernel"
You are being intentionally obtuse. You pointed out how absurd it is to mention shared kernel for things that are obvious, so we don't. All mentioned of shared kernel, except when explaining kernel sharing explicitly, is a reference to container virtualization. Any reference to not being shared kernel, is a reference to Type 1 or Type 2 para/full virtualization.
Last comment. There is nothing ovtuse about it. It is literally exactly what you said.
But obviously Ansible requires a shared kernel.
Yes, because we were discussing what you said about how processes share a kernel. We had to stop using the term in the virtualization sense. Keep in context.
I had literally just explained why we had to mention in there when normally you never would.
But that is all just misdirection. Why were you so passionate about Docker not sharing a kernel, if you knew that it did? You said it many times. You argued over it. Then you said that obviously it had to.
It's one thing not to mention it because we all know it has to share a kernel. But you were explicit in that it did NOT share a kernel.
That's why I feel you are arguing just to argue and being intentionally obtuse to make it seem like I'm trying to argue. Containerization, including Docker, means virtualization with a shared kernel. That's what makes it that. But you said Docker wasn't this. But now say it is. You are going back and forth. My point hasn't changed. Docker is a container. First it was a form of LXC, now it is its own. Docker doesn't run full VMs, it uses shared kernels. Maybe Docker can manage KVM, but that's an unrelated topic.
-
@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.
-
@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.
-
@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.
-
@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 can be confusing in DevOps, because ops uses dev toolchains. So CI, build, release, etc. happen within the ops cycle, which makes it sound like they are overlapping with the same cycles that the devs have. But the dev CI and the ops CI are different things. Same concept, but one happens independent of the other.
-
@flaxking said in Check my 2 min audio theory on Containers:
That is not DevOps. DevOps is a refactoring of Lean Manufacturing in order to apply to software companies.
That's definitely not a thing. As someone from both a manufacturing systems background and a software engineering background, nothing is less related. They are polar opposite concepts. Because one sounds cool, a lot of things in SE take manufacturing names and some incredibly bad shops actually make the mistake of trying to apply manufacturing concepts to SE, but it's the biggest failures around.
You can't take something from manufacturing and apply it to SE, because SE doesn't have manufacturing.
In traditional manufacturing, you have a mix of something like 1% engineering (designing a product) and 99% manufacturing (reproducing that design.) Take a car, 1% of the cost is designing it, and 99% or more of the cost is shaping the metal and leather into the car you want to drive. Refactoring manufacturing to make it cheaper and better is worth a fortune in cost savings. No one does this to the car designers because all you care about is a good design, if it costs a little extra to design, no big deal, it's a cheap piece anyway.
Software Engineering has no manufacturing side, it's only the design side. So no amount of manufacturing processes applied to SE would "do anything." There is no component of software engineering to apply them to. It's pure design. You COULD call copying the software or downloading it the manufacturing piece, but that's just a bit silly. If you want to do that, then SE is 99.99999999999% design and .000000000001% reproduction. So we'd always ignore it. Because refactoring that, even cutting the effort in half, isn't worth even pressing a button to do, it's that trivial.
The terrible thing that sometimes happens is people who don't know engineering confuse engineering with manufacturing and try to apply things like defect rates or efficiency studies to creative design processes used in engineering. No one would ever do this to a mechanical engineer, but some people manage to get in control of software shops and don't remember that they are engineers and try this resulting in epic disasters. As designs can't have "defect rates" in the way manufacturing does, it makes no sense. Reducing defects doesn't have benefit, it might actually bring problems.
Agile methodologies in software are nothing like similar sounding things in manufacturing. In one it is about increasing defects and fixing them faster to improve design processes. In the other it is about reducing initial defects. Very different, essentially opposite things.
-
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.
