First developers ended up doing testing, then requirements and now operations. Soon you will see developers cleaning the office area and watering flowers in landscape.
I’m a devops engineer. I like platform engineering because it puts devops teams into a product mindset. Products they give their customers, the internal users and developers.
I recently got thrown on a few devops projects at work. It took a while to figure it out but then I was like "oh, I'm just programming for the other devs on my team rather than the end user".
Yup. If you make 50 devs just 10% more efficient, that's like adding five new heads to the worker pool. It's a great feeling. They can stay better focused on the app rather than all the periphery stuff.
IMO the fundamental thing in devops is the lack of organisational division between development and operations, having a team that both creates code and is responsible operational quality. Just having a CICD-pipeline doesn't count if you have one team pushing updates and other team being responsible of managing operational issues and creating bug reports. E2E responsibility is the key. Some of the greatest triumphs of mine have included first adding logging in code, deploying those and then creating monitoring scripts to pick them up and refining them, creating alerts, eventually leading to understanding the root cause.
Also this video speaks so much from my heart. This understanding of the "idea" of collaboration is how the world really should be, wether it be in IT or in any other field. For a while it gave me a hard time wondering why people were misusing the term "DevOps" (with "Platform" it seems to be the same thing as I understand it) in such an obviously "dumb" way by drawing boundaries and using "DevOps" (or "Platform") even as a name for a department to set themselves apart from others. Or it might be management which is dividing the "resources" (aka people). To then speak of a "team" is pure irony and part of the same misuse of actual concepts and people. The underlying problem is deeply embedded in the "system" and of how a business works: through competition. This is completely against the idea of collaboration which is so deeply embedded in our culture that the same thinking is applied also from inside of organizations and even encouraged. Quality is a consciously unwanted anti pattern in those environments because collaboration is regarded as a thread there. The ones who are good at it could otherwise outsmart the ones who are not. Or the ability itself is misused by individuals out of personal interests over the interests of the whole group, sacrificing product quality. While the scientific view of the world should always be defended, for example by talking about what best practices, proven techniques and terms for those really mean, the very basic and archaic way of human life will always try to neglect it. That is what we also are on the other side of the coin.
In my decades of doing "OpsDev" (I'm operations first!) -- this is perhaps the best single video I've seen covering this wide array of topics in an approachable way. I'm building a badging program at work and this video is climbing to the top of the "prerequisites" playlist. Thank you!
In platformOS, we often use the phrase "automated DevOps" to indicate that our partners will not have to worry much about the underlying infrastructure. We have built abstraction layer using GraphQL, which allows us to take care of the operations and allow developers to focus on continuously delivering :) value to their business. After watching your video, we might want to think harder about our slogan, though!
It can be good to be picky with words. It helps with clear understanding and gaining a clear picture. The reason for so much confusion is because software engineers, marketing staff, consultants and more and have not been picky with words. In some cases they have maliciously abused terminology.
What's in a name? We used to call it evolution in the 80's. But that evolution began with an impact analysis on process efficiency and system components then publishing a return on investment calculation (unless the change was mandated by a regulatory body).
This video touches on what software development has become in the last decade. You have application code. You have IAC code in Terraform, Cloudfromation, Pulumi, etc. You have pipeline code in github actions, etc. What does this mean for TDD? I'd like to hear how you would TDD your way to a realistic cloud application, for example a real-time data pipeline in one of the clouds. Is TDD even relevant for provisioning resources in the cloud?
Semantics matter because I've worked in and observed many software and infrastructure development and maintenance teams that take the meanings to heart and plant a flag on the molehill in destructive ways.
For me, "continuous delivery" is about delivering value to the hands of customers. Not just getting code into production. The company i work for atm often uses release flags to deploy code, which then sits inactive and unused for months...
this space is full of fairly clear and good intentions expressed as confusing, overlapping, rarely repeatable definitions, which, when taken to extreme, get one into some mythical places (for example the idea that people are "devops", hence they do requirements collection, design and implementation of front and backends, pipelines, dashboards, on-call, supporting operations and everything under the sun). Related, the "what's in the name" is important if one wants to avoid the cognitive load - "devops" seems more clear (have devs and ops collaborate closely - same team preferably) than "continuous delivery", which sounds like half of the solution, in the sense of "ok, what about after delivery?" "Platform engineering" by definition is "the practice of planning and providing such computing platforms to developers and users", which is immediately strikingly odd (since users and devs are really not alike). Tongue in cheek - we should enlarge these definitions even more - include psychology (at least mention therapy) and the little print which states that "business" can still layoff anyone for whatever immediate cost reduction they could fathom. Back to the subject, maybe a simple "hey, do this, try to avoid doing that" might suffice for most
Yeah. CD and DevOps are approaches that focus on working in a lean way and focusing on shared goals. Unfortunately, DevOps allows 'DevOps developers' on 'DevOps teams' to completely miss the point. It also allows people in product and elsewhere to think they arent needed for that lean shared goal stuff.
Good question, but unfortunately, there is no "single" way, it depends on your skill set and your company. Operations has a variety of roles, one being help desk, more on the front customer side. Backend ops deals more with the database, operating system. But Dev Ops per se, at least the CI is more on the development side, so you would have to migrate your skills from help desk support to either Ops backend/operating systems support and ultimately development or straight to development. Some large companies have Dev Ops on ops side so you might just have to migrate to that. It really depends on the company, ask your manager to put you in touch with some Ops folks that work in Dev Ops or development. All the best.
I don't believe devops is about delivering things faster to production. I believe it's more about doing things in a more controlled and more reliable way. Faster delivery to production is just a consequence. I also believe platform engineering is an integral part of devops. Maybe platform engineering isn't always performed consciously, but working devops cannot happen without platform engineering. For devops to work you need things set up in such a way that teams can work within clearly defined boundaries in relation to other teams - if coupling is too strong, one team's failure can become many other teams' failure, with those other teams being incapable to do anything about it, and consequently failing the "more reliable and more controlled" aspect which I believe is defining devops. That's where platform engineering comes in, whether you call it that way or not. You structure your entire organization, both technically and organizationally, in such a way that there are natural borders with clearly defined interfaces between domains covered by different teams, along which teams can align. Each team owning their domain and managing it reliably and in a controlled way, with other teams having a clear understanding of what they can expect and what they can ask for, and how things are delivered, comes naturally once such a structure is in place.
Hey Dave, could you make (or point me to) a video that would convince any manager and architect that automated tests are the heart of continuous delivery? It sounds pretty obvious, but apparently it isn't.
The closest video I have at the moment is this one on ‘managing up’, this might be helpful - How To Manage Your Boss! (Managing Up) ua-cam.com/video/bCEmRwsmmlY/v-deo.html
When I see or hear "DevOps" nowadays it's generally referring to InfraOps and/or Deployment and Observability Tooling. True DevOps is what engineering teams do as part of taking responsibility for the operation of their software.
DevOps isn't supposed to be interpreted as a technique or a framework, let alone a role. DevOps is a _movement_. Its vision is to bring together the activities of system development and system operation, and when you bring it as closely together as possible -- a single person develops AND operates -- you will find that development skills get applied to carrying out the activities under the umbrella of "operations," such as release management and environment provisioning and configuration. Hence the resulting proliferation of "devops tools" such as those enabling IaC. But far too many people conflate those tools such as Ansible, Chef, TF, etc. with the movement!
Continues delivery is not always necessary for devops, especially for mission or security critical systems.... it just doesn't make sense to describe it like that.
6 місяців тому+7
As a platform engineer and devops engineer I was very hesitant to click the video and also very eager at the same time xD For me it all boils down to scopes as such: DevOps = Ensure the DevEx is the best and everything is pushed as left as possible. Platform Engineering = How we make everything that is being created by either DevOps or the developers the most reusable as possible in a manner that is compliant with the organization needs.
Far too many organizations want to develop significant applications, get them through QA and get them into production. The problem is that this is too coarse-grained. The end users won't know if what you're delivering meets their needs until they can play with it. So you need to go finer-grained on delivery. If you can, more easily, roll out a web service / microservice which does something useful, then roll out something which uses same to provide a UI, you're more likely to determine which services work and which ones don't, as well as seeing what UI works for the users and what doesn't. But, you will say, we have UI designers and architects which design all this stuff. We don't need an iterative approach. Really? How many of your explicitly designed / architected projects end up with a ton of requirements for a follow-on / 2.0 project, because "you delivered what we asked for, but not what we need?" If the devs can't play with the service, you don't really know what's going to work well / efficiently in your particular infrastructure context. If the end users can't play with the UI, you don't really know what they need. Requirements gathering is not a single step that you do up front with wireframes and prose; sure, you can get SOME of them up front, but you won't get ALL of them until the users can play with the UI and until your devs can actually beat on the infrastructure. Which means your feedback loop goes all the way back to requirements gathering, iterating until you get something which works efficiently / reliably AND does what the users need. Whether you call it DevOps or CI, it supports the rapid iteration and delivery of finer-grained dev products. Done properly, with automated testing (unit and integration) as gatekeepers to the process, you can go a long way toward ensuring code quality AND get stuff to the prod environment in a timely fashion.
Platform teams build a framework/platform for the devops engineers. They pick the best solutions (self developed or adopted from a devops team) and make them to the golden standard. So each devops team has a blueprint of a golden path for the complete software lifecycle.
DevOps engineers were created by market forces. Engineers figured out that they could increase their salary 20% by marketing themselves as DevOps Engineers, and corporate recruiters discovered they could drum up greater interest for traditional ops roles by rebranding them as DevOps roles. Technology leaders happily embraced this rebranding because they wanted to suggest that they were leveraging more modern practices. Anytime a company says they have DevOps engineers, I always ask them a simple question: "Where are your Agile engineers?"
I kinda saw it like the smart devs are taking over ops because ops wasn't really doing a great job. Ops needed to get better. Devs needed to understand ops a little better.
@@kayakMike1000 I guess that's one point of view, but my understanding has always been that DevOps means that developers participate and automate the operations side of things along with coding the solution. Your point of view sounds like the common misunderstanding Dave Farley touches upon 7:32 where dev and ops are seen as separate, instead of together. The problem with siloed ops teams is that they simply do not know how and why the system works. They can only guess as to what the engineer was thinking and only after the fact, rather than being involved with development and also engineering a better solution in parallel. So it's a bit more than just developers don't understand how the software operates, it's simply that they don't participate.
Summary: - DevOps is Continuous Delivery, just read our book. - Platform Engineering is about teams structure and says nothing about Continuous Delivery
One of the problems I see with the term DevOps is when it's used to describe an engineer as opposed to a team. Requiring an individual to hold all that in their head? What about cognitive load? What about burnout? DevOps Engineer? No thanks! DevOps Team? Yes please!
why would you code the same thing over and over again. platform gives all the apis to do everything. coded once. yep you first code a platform that can do everything, then build apps on top of it.
In my experience DevOps usually means "We don't need an Operations team anymore. Developers can do it in their spare time"
Exactly my current experience 🤐
Do it in spare time 😭
First developers ended up doing testing, then requirements and now operations. Soon you will see developers cleaning the office area and watering flowers in landscape.
I’m a devops engineer. I like platform engineering because it puts devops teams into a product mindset. Products they give their customers, the internal users and developers.
I recently got thrown on a few devops projects at work. It took a while to figure it out but then I was like "oh, I'm just programming for the other devs on my team rather than the end user".
Yup. If you make 50 devs just 10% more efficient, that's like adding five new heads to the worker pool. It's a great feeling. They can stay better focused on the app rather than all the periphery stuff.
Love this comment. It's accurate
I thought devops is the dude you hang out with in the playstation room at the office.
@@denisblack9897 we do that too
Excellent video! Since early in my career, when people asked about my process, I would just say: "Make something that runs. Keep it running."
For me, devops and CD are philosophies and not roles. It's a way of doing things - flow, feedback and learning. Agile is the what, and CD is the how.
devops is the jack of all trades. Programmer, Operations, Automation, DBA, QA, cloud, Builds, Architect, infrastructure.
IMO the fundamental thing in devops is the lack of organisational division between development and operations, having a team that both creates code and is responsible operational quality. Just having a CICD-pipeline doesn't count if you have one team pushing updates and other team being responsible of managing operational issues and creating bug reports. E2E responsibility is the key. Some of the greatest triumphs of mine have included first adding logging in code, deploying those and then creating monitoring scripts to pick them up and refining them, creating alerts, eventually leading to understanding the root cause.
Bingo
👆
Also this video speaks so much from my heart. This understanding of the "idea" of collaboration is how the world really should be, wether it be in IT or in any other field.
For a while it gave me a hard time wondering why people were misusing the term "DevOps" (with "Platform" it seems to be the same thing as I understand it) in such an obviously "dumb" way by drawing boundaries and using "DevOps" (or "Platform") even as a name for a department to set themselves apart from others.
Or it might be management which is dividing the "resources" (aka people). To then speak of a "team" is pure irony and part of the same misuse of actual concepts and people.
The underlying problem is deeply embedded in the "system" and of how a business works: through competition. This is completely against the idea of collaboration which is so deeply embedded in our culture that the same thinking is applied also from inside of organizations and even encouraged.
Quality is a consciously unwanted anti pattern in those environments because collaboration is regarded as a thread there. The ones who are good at it could otherwise outsmart the ones who are not. Or the ability itself is misused by individuals out of personal interests over the interests of the whole group, sacrificing product quality.
While the scientific view of the world should always be defended, for example by talking about what best practices, proven techniques and terms for those really mean, the very basic and archaic way of human life will always try to neglect it. That is what we also are on the other side of the coin.
This is a good review of the central ideas to create a successful software development team.
In my decades of doing "OpsDev" (I'm operations first!) -- this is perhaps the best single video I've seen covering this wide array of topics in an approachable way. I'm building a badging program at work and this video is climbing to the top of the "prerequisites" playlist. Thank you!
Glad you enjoyed it!
In platformOS, we often use the phrase "automated DevOps" to indicate that our partners will not have to worry much about the underlying infrastructure. We have built abstraction layer using GraphQL, which allows us to take care of the operations and allow developers to focus on continuously delivering :) value to their business.
After watching your video, we might want to think harder about our slogan, though!
It can be good to be picky with words. It helps with clear understanding and gaining a clear picture. The reason for so much confusion is because software engineers, marketing staff, consultants and more and have not been picky with words. In some cases they have maliciously abused terminology.
Pervasive issue. It's almost a meme at this point when a recruiter doesn't know there's a difference between Java and JavaScript, right?
What's in a name?
We used to call it evolution in the 80's. But that evolution began with an impact analysis on process efficiency and system components then publishing a return on investment calculation (unless the change was mandated by a regulatory body).
This video touches on what software development has become in the last decade. You have application code. You have IAC code in Terraform, Cloudfromation, Pulumi, etc. You have pipeline code in github actions, etc.
What does this mean for TDD? I'd like to hear how you would TDD your way to a realistic cloud application, for example a real-time data pipeline in one of the clouds. Is TDD even relevant for provisioning resources in the cloud?
Semantics matter because I've worked in and observed many software and infrastructure development and maintenance teams that take the meanings to heart and plant a flag on the molehill in destructive ways.
Ultimate form of devops, use PHP, every http call builds your app. Develop directly on production, immediate deployment after you hit save.
as a junior devops engineer the operation part is dominant to the extend that i do not understand from where the dev in devops came from.
For me, "continuous delivery" is about delivering value to the hands of customers. Not just getting code into production. The company i work for atm often uses release flags to deploy code, which then sits inactive and unused for months...
this space is full of fairly clear and good intentions expressed as confusing, overlapping, rarely repeatable definitions, which, when taken to extreme, get one into some mythical places (for example the idea that people are "devops", hence they do requirements collection, design and implementation of front and backends, pipelines, dashboards, on-call, supporting operations and everything under the sun). Related, the "what's in the name" is important if one wants to avoid the cognitive load - "devops" seems more clear (have devs and ops collaborate closely - same team preferably) than "continuous delivery", which sounds like half of the solution, in the sense of "ok, what about after delivery?" "Platform engineering" by definition is "the practice of planning and providing such computing platforms to developers and users", which is immediately strikingly odd (since users and devs are really not alike). Tongue in cheek - we should enlarge these definitions even more - include psychology (at least mention therapy) and the little print which states that "business" can still layoff anyone for whatever immediate cost reduction they could fathom. Back to the subject, maybe a simple "hey, do this, try to avoid doing that" might suffice for most
Yeah. CD and DevOps are approaches that focus on working in a lean way and focusing on shared goals.
Unfortunately, DevOps allows 'DevOps developers' on 'DevOps teams' to completely miss the point. It also allows people in product and elsewhere to think they arent needed for that lean shared goal stuff.
How does one go from working in help desk to working in DevOps or Continuous Delivery?
Good question, but unfortunately, there is no "single" way, it depends on your skill set and your company. Operations has a variety of roles, one being help desk, more on the front customer side. Backend ops deals more with the database, operating system. But Dev Ops per se, at least the CI is more on the development side, so you would have to migrate your skills from help desk support to either Ops backend/operating systems support and ultimately development or straight to development. Some large companies have Dev Ops on ops side so you might just have to migrate to that. It really depends on the company, ask your manager to put you in touch with some Ops folks that work in Dev Ops or development. All the best.
@@vizion007 Great, thanks!
I don't believe devops is about delivering things faster to production. I believe it's more about doing things in a more controlled and more reliable way. Faster delivery to production is just a consequence.
I also believe platform engineering is an integral part of devops. Maybe platform engineering isn't always performed consciously, but working devops cannot happen without platform engineering. For devops to work you need things set up in such a way that teams can work within clearly defined boundaries in relation to other teams - if coupling is too strong, one team's failure can become many other teams' failure, with those other teams being incapable to do anything about it, and consequently failing the "more reliable and more controlled" aspect which I believe is defining devops.
That's where platform engineering comes in, whether you call it that way or not. You structure your entire organization, both technically and organizationally, in such a way that there are natural borders with clearly defined interfaces between domains covered by different teams, along which teams can align. Each team owning their domain and managing it reliably and in a controlled way, with other teams having a clear understanding of what they can expect and what they can ask for, and how things are delivered, comes naturally once such a structure is in place.
Hey Dave, could you make (or point me to) a video that would convince any manager and architect that automated tests are the heart of continuous delivery? It sounds pretty obvious, but apparently it isn't.
The closest video I have at the moment is this one on ‘managing up’, this might be helpful - How To Manage Your Boss! (Managing Up)
ua-cam.com/video/bCEmRwsmmlY/v-deo.html
@@ContinuousDelivery Nice! If you teach a man to fish...
When I see or hear "DevOps" nowadays it's generally referring to InfraOps and/or Deployment and Observability Tooling.
True DevOps is what engineering teams do as part of taking responsibility for the operation of their software.
DevOps isn't supposed to be interpreted as a technique or a framework, let alone a role. DevOps is a _movement_. Its vision is to bring together the activities of system development and system operation, and when you bring it as closely together as possible -- a single person develops AND operates -- you will find that development skills get applied to carrying out the activities under the umbrella of "operations," such as release management and environment provisioning and configuration. Hence the resulting proliferation of "devops tools" such as those enabling IaC. But far too many people conflate those tools such as Ansible, Chef, TF, etc. with the movement!
Continues delivery is not always necessary for devops, especially for mission or security critical systems.... it just doesn't make sense to describe it like that.
As a platform engineer and devops engineer I was very hesitant to click the video and also very eager at the same time xD
For me it all boils down to scopes as such:
DevOps = Ensure the DevEx is the best and everything is pushed as left as possible.
Platform Engineering = How we make everything that is being created by either DevOps or the developers the most reusable as possible in a manner that is compliant with the organization needs.
"either DevOps or the developers".... bang, DevOps is just dead.
@@Maelstrom-qi8tu I bet they have a "DevOps team" at his company lmao
DevOps: People + Process + Product -> Value
Far too many organizations want to develop significant applications, get them through QA and get them into production. The problem is that this is too coarse-grained.
The end users won't know if what you're delivering meets their needs until they can play with it. So you need to go finer-grained on delivery. If you can, more easily, roll out a web service / microservice which does something useful, then roll out something which uses same to provide a UI, you're more likely to determine which services work and which ones don't, as well as seeing what UI works for the users and what doesn't.
But, you will say, we have UI designers and architects which design all this stuff. We don't need an iterative approach.
Really? How many of your explicitly designed / architected projects end up with a ton of requirements for a follow-on / 2.0 project, because "you delivered what we asked for, but not what we need?"
If the devs can't play with the service, you don't really know what's going to work well / efficiently in your particular infrastructure context. If the end users can't play with the UI, you don't really know what they need. Requirements gathering is not a single step that you do up front with wireframes and prose; sure, you can get SOME of them up front, but you won't get ALL of them until the users can play with the UI and until your devs can actually beat on the infrastructure. Which means your feedback loop goes all the way back to requirements gathering, iterating until you get something which works efficiently / reliably AND does what the users need.
Whether you call it DevOps or CI, it supports the rapid iteration and delivery of finer-grained dev products. Done properly, with automated testing (unit and integration) as gatekeepers to the process, you can go a long way toward ensuring code quality AND get stuff to the prod environment in a timely fashion.
That's very wise, except what's the point of the wisdom if the decisionmakers don't read/watch any of this? ;)
Platform teams build a framework/platform for the devops engineers. They pick the best solutions (self developed or adopted from a devops team) and make them to the golden standard. So each devops team has a blueprint of a golden path for the complete software lifecycle.
DevOps engineers were created by market forces. Engineers figured out that they could increase their salary 20% by marketing themselves as DevOps Engineers, and corporate recruiters discovered they could drum up greater interest for traditional ops roles by rebranding them as DevOps roles. Technology leaders happily embraced this rebranding because they wanted to suggest that they were leveraging more modern practices. Anytime a company says they have DevOps engineers, I always ask them a simple question: "Where are your Agile engineers?"
I kinda saw it like the smart devs are taking over ops because ops wasn't really doing a great job. Ops needed to get better. Devs needed to understand ops a little better.
Then again... I was doing DevOps before it was called DevOps. I was called a Technical Analyst.
@@kayakMike1000 I guess that's one point of view, but my understanding has always been that DevOps means that developers participate and automate the operations side of things along with coding the solution.
Your point of view sounds like the common misunderstanding Dave Farley touches upon 7:32 where dev and ops are seen as separate, instead of together.
The problem with siloed ops teams is that they simply do not know how and why the system works. They can only guess as to what the engineer was thinking and only after the fact, rather than being involved with development and also engineering a better solution in parallel. So it's a bit more than just developers don't understand how the software operates, it's simply that they don't participate.
I might call this the Right way.
Summary:
- DevOps is Continuous Delivery, just read our book.
- Platform Engineering is about teams structure and says nothing about Continuous Delivery
Platform engineering is the data structure, while DevOps is the algorithm.
One of the problems I see with the term DevOps is when it's used to describe an engineer as opposed to a team. Requiring an individual to hold all that in their head? What about cognitive load? What about burnout? DevOps Engineer? No thanks! DevOps Team? Yes please!
Dirty truth of DevOps, it's out sourced ops to the cloud.
why would you code the same thing over and over again. platform gives all the apis to do everything. coded once. yep you first code a platform that can do everything, then build apps on top of it.
DevOps is like cancer for Cyber Security Experts...
Pls explain
When the regression always tests the same thing, new things are not shown.
Brilliant video, thank you!