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.
-
I've officially run out of time to argue with you today. Maybe another day we can continue another pointless back and forth.
-
@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:
Here's a decent article from Jess Frazelle. She was on the core Docker Dev team and is a Linux kernel dev.
Except she gets the basics wrong. I'm sure she knows the ins and outs of Linux containers, but she is using "container" incorrectly in a new, made up way. BSD Jails and Solaris Zones are both containers. In fact, the term containers started with the Jail system, it predates everything else. Any other use of container is a new use, like cloud. Cloud computing is a very well defined thing and the term originated there. Similar with containers. Now she's trying to use it in some unique way and trying to say that the "founding fathers" of containerization aren't containers at all, that's total BS.
We were using containers before Linux started using the term, and Linux copied it both in name and technology from those that came before it.
She even mentioned Solaris Zones which are explicitly containers. And jails is a synonymous term with containers. We could call LXC a form of jails and be correct.
https://en.wikipedia.org/wiki/Operating-system-level_virtualization
"..containerization, refers to an operating system feature in which the kernel allows the existence of multiple isolated user-space instances. Such instances, called containers,[1] partitions, virtualization engines (VEs) or jails (FreeBSD jail or chroot jail), may.."
She's saying "Docker containers" aren't a thing. She's separating them out because people are calling them "containers" when they aren't. Whereas LXC/zones/jails are.
She never says that, ever. She once refers to Linux containers, but that's LXC, not Docker. Otherwise, she just says "containers." From where do you get the impression she's even aware of Docker, let alone speaking about it? Docker isn't mentioned a single time in the article, DockerCon is, but that's a conference and easily people talk about other things there, too.
The article doesn't appear to be about Docker at all, but contrasting LXC with Zones, Jails, and VMs.
From where do you get the impression she's even aware of Docker, let alone speaking about it?
These are the kind of things you say that people get annoyed with. Well first she's written a decent part of Docker so there is that. Second, she's speaking to the myriad of people who have heard of Docker and think it's something that it isn't. She's pretty famous for understanding how all of this works together.
Of course her AUDIENCE has HEARD of Docker. But you can't actually say that she's talking about Docker when she never once even implies it, and specifically says something very different (that it is LXC.) You are adding your own interpretation to her words. Maybe she means Docker, if so, she's a terrible writer. You don't use the wrong term for something you use every day and just assume people think you meant the opposite. That's insane.
It's not ME doing something annoying here. You are showing me an article that clearly says one thing that isn't too bad. But are claiming it's actually referencing something very different, and meaning something it doesn't say. Instead of taking it at face value, you are twisting her words into a meaning that isn't there at all. And then saying I'm being annoying for not having added my own interpretation to the article that isn't there in any form.
Even if you are correct, how could I without the goal of making it be about Docker, possible think it was about something never mentioned and explicitly ruled out? LXC is Linux containers, Docker is not. It can't be me being annoying here. If I claimed the article did that, you'd jump all over me for making up its meaning.
No I'm looking at historically what she has said. Of course you can look at one sentence out of a thousand and construe it to mean someone doesn't know what theyre talking about.
I looked through the ENTIRE article. That she has written about other things in the past would never be a reason to assume she got it all wrong here. I've written about Linux a lot, but if I write about Windows, it would be insane and totally wrong to claim that based on my having written about Linux previously that all of the times that I mention Windows that "obviously you are supposed to know that I actually meant Linux." That's nuts.
I assume she's not just some Docker drone but a human capable of and expected to discuss more than one specific topic. No amount of other writings on Docker should rule out her being allowed to discuss LXC.
That she is aware of Docker, all the more that we'd note expect her to confuse Docker with other things that aren't Docker. The more she knows Docker, the more likely this article isn't about Docker but can be taken at face value of being about Linux containers.
-
@stacksofplates said in Check my 2 min audio theory on Containers:
I've officially run out of time to argue with you today. Maybe another day we can continue another pointless back and forth.
Honestly, I feel like you are arguing just to argue. You are using all kinds of weird terms and saying you didn't say them or describing them clearly.
You say Docker uses a shared kernel obviously, but over and over again say it doesn't. But you don't see that conflicting?
-
@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.
