How have you avoided the confusion around DevOps? Skip to points: 👇 00:29 Follow The Money 01:08 A Warning About Tool Vendors 02:17 A Warning About Consultants 03:04 A Warning About Recruiters 03:47 DevOps Defined 05:32 When Doesn’t DevOps Work? 07:41 Dysfunctional DevOps Teaming 09:40 DevOps Practices To Consider
I’ve seen it be that, yes. If that’s expected of me I make sure they understand the throughput of features from me will go down. As long as they are okay with that I don’t mind this kind of work. But as I’ve said in other videos it’s important companies treat us as individuals. There’s nothing wrong with some developers not wanting to do this kind of work!
Ehhhmm... No really. The idea, for me, is that the developers understand what the sysadmin does and the sysadmin understand what the developer does. Not to do it for really. The problem is that people tend to think as you say and, at the end, they resist to learn new things.
Varo Roldan Just look at the job posts... that is the theory, but reality is a different thing. I used to be a sysadmin at one point and those jobs were decent... now, not so much. Lots of people getting laid off and positions eliminated in various infrastructure areas due to DevOps... and the quality/security is suffering I interact with lots of organizations and you wouldn’t believe the things I see... from people who don’t actually know networking trying to be network engineers , to people who don’t know databases trying to perform dba functions ... just because they are developers
@@ivanhoek yes, that happens. And that's the problem with not understand what devops is about. I've seen that and tried to said "don't say devops or agile when you are not using it because it's counterproductive" but didn't succeed at that... Perhaps it the problem with new things, with a fashion thing that the most important is to say that you are using and not really apply it... I don't know...
Yes, that's the reality. Responsibility list for a dev is getting longer and longer all the time because companies want to skimp on costs. I haven't seen a person with good ops skills in years anymore because I am the one automating the cloud infra while simultaneously doing feature development. My compensation has not increased.
DevOps to me is a culture not a practice. Doing some Automation doesn't make it DevOps...Talking to each other and co-ordinating tasks avoiding silos. Its not hard...just work together. It needn't cost a penny. I've never seen an industry as bad as Tech, for reinventing the wheel rather than address the problem.
why are consultants so succesful in making money off the devops movement? Because management is unwilling to change: 1) operations are still a cost center, devs are budgeted though sales and marketing, or even worse, an "innovation stipend" 2) same goes for agile: 2 week sprints but managers still keep 6 month Gant charts with complete feature maps that they never communicate to the teams.
I'm a CS major set to graduate soon and after years of hearing this term DevOps and wondering what exactly it means/entails i finally have clarity thanks to this 15 minute RUclips video. Thank you so much for this!
Great video, thank you for sharing your thoughts. What I got out of this is that proper DevOps is about getting the right work culture and team alignment -- not just automation. Changing technical tools is relatively easy, but changing an organization's culture is hard.
DevOps is old term, new age buzz word is Site Reliability Engineer, a term introduced by Google and probably a better description for what the job should entail.
I’ve done Lean, DevOps, Service Excellence etc. over many years. Like all “management methodologies” they all eventually escalate cost due to the fact they offer so many billable overheads (perfect for consultancies). As such they eventually get replaced by a new one that hasn’t yet acquired all the hangers on. The really interesting thing is the industries belief that changing methodology is the answer. In reality anything can work as long as you don’t let it get out of hand. Personally I think that if a developer has to perform more than an hour of admin a week then there’s a problem. If there’s productivity issues it’s usually down to the people/management. I’ve seen many projects delivered in weeks for tens of thousands where others took years, cost millions and took years despite being smaller and les sophisticated. The difference being the management overhead.
The key part of the word DevOps is the Ops part. It’s operations related to development, whereas Operations in general is operations for the entire company, primarily production systems. Generally, DevOps and Operations are completely different and rarely speak; about the only thing they both have in common is hardware, assuming they aren’t completely in the cloud. LOL.
I like this, true Devops occurs when the two groups work together and solve common problems, goes hand in hand to your secret to scrum , deliver and adapt, fail fast, then make changes that the customer really needs after the cross-functional moved something to production
DevOps being a culture and a mindset as opposed to a set of skills and practices cannot be overstated. It is like saying knowing ten thousands theorems and their demonstrations makes someone a mathematician, when in fact a printer could do the same. Many times I've tried to impose, because in retrospective that's what I did, and it mainly got ignored, opposed, or finally trashed because it often takes a whole team and their feedback to make things that are good enough to have a productive value. Just hiring a "devops" guy thinking his magic will trickle down into your teams and increase their productivity is just plain magical thinking.
In my previous company, I was self designated devops. Everything was so black-boxy from infra standpoint, I decided to ask to join partially operations team. I was sort of a guy that sat between ops and dev for some time. Then I was trying to make devs more aware of the prod runtime and expose ops to dev concerns and type of thinking. It took A LOT of time to put everyone on the same page. It was rather an issue of the attitude than tech.
Great testimony. Sounds like you are deep into understanding the cultural shift. I wish more people in the DevOps arena were focused on this like yourself!
Hi! Could you please clarify why are you considering DevOps a subset of Continuous Delivery? In my understanding it's more like DevOps = Lean + cultural things + CD.
Getting developers and operations to work together is necessary for approvals and coordination to move fast enough to continuously deliver software. But you can leave those two silo'd and have all the technology you want, and still not be able to deliver fast. At least that's my perspective based on the Continuous Delivery book (which is one of the best books I've ever read on software period).
@@HealthyDev CD book by Humble and Farley is great, a gem for ones without experience leading a team, really. But when speaking about DevOps, the most authoritative sources AFAIK are "10 deploys a day" (Allspaw, Hammond) and "The DevOps Handbook" (Kim et al). - 10 Deploys a Day ruclips.net/video/LdOe18KhtT4/видео.html - The DevOps Handbook www.amazon.ca/DevOps-Handbook-World-Class-Reliability-Organizations/dp/1942788002/ref=asc_df_1942788002/?tag=googleshopc0c-20&linkCode=df0&hvadid=293004119900&hvpos=&hvnetw=g&hvrand=860162250242797978&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9000914&hvtargid=pla-568661774152&psc=1 Here Gene Kim basically redefines DevOps to "the three ways" from CALMS, but gets people like John Allspaw, Patrick Debois, and Jez Humble, so it's the most current compromise. From what I know, DevOps always contained CD, starting from "John Allspaw's DevOps". What happens with recruiters, vendors and all the "DevOps Engineers" and their super weird understanding of what's optimal, is another topic entirely. Maybe everyone will settle with SRE term which, frankly, better serves its purpose.
@@redpillsolutions9698 yep the DevOps handbook is good. Honestly I am suspect of some of Gene Kim's motives for reasons of partnerships with certain vendors. His relationships with Jez certainly lends credence. But that's another conversation...
@@HealthyDev Btw, I totally agree with the emphasis on the vendors' role. In a sense, they had little choice since the moment someone discovered that the word DevOps sells, you either join the game or lose. Gene Kim is a "management consultant" type of person IMO too, but it was him who managed to consolidate enough of the founders...
@@redpillsolutions9698 for sure, he's a key person and we have a lot to thank him for. I just am a little bit weary, similar to how Jeff Sutherland sold out on agile by focusing on it "getting stuff done faster" when that wasn't the point of lean methods - though it's what management wanted to hear etc.
I was hired once as a "DevOps" engineer and all I did was operations. I asked during the interview "isn't this just regular operations?" and nobody could give me an answer.
Very interesting channel, thank you! I’m trying to decide between two computer science degrees (in Sweden). The first focuses on “Software development and operations”; besides programming, it includes courses about sysadmin, configuration management and continuos delivery. The second focuses mostly on “web programming” and shares many of the foundational courses with the other program. Would you say there is any benefit to learning the “DevOps” skills from the first program? I mean benefit, in general, for every future software developer, not just for those who want to work in a DevOps role. I know this is not the topic of your video. But maybe, with your experience and perspective of the tech sector, you could help me out a bit. In any case, thank you for your videos!
Hey Eric great question. As someone who doesn’t have the curriculum for these two degrees in front of me, I’ll offer what I can. If developing web apps and things that support them like APIs and integrating with third party services is interesting to you - you might be better off with that degree. The specialization is going to set you ahead for employers that need people in that role. I’ve done a lot of this work and it can be a lot of fun in the right environment. On the flip side, DevOps/CD related positions are incredibly hot (and competitive) right now. If setting up the infrastructure upon which apps run, figuring out how to get things performing well, monitoring things, and security are interesting to you this is also a great initial career choice. If you want a job unrelated to web apps this one also could help you as many systems with no user interface (think data science, data processing, or various services for sale to other companies) need a solid infrastructure. I’m of the belief that all engineers will need all of these skills eventually in their career. There’s a lot to learn and you really can’t go wrong if you pick whatever sounds most fun to work on day to day. It’s much more important starting out to consider what you’ll be passionate about more than money, because when you’re new you have to prove yourself. You’ll have plenty of opportunities as your career moves forward to pick up more skills on the job. I hope some of that helps! Thanks for watching Eric. 👍
@@HealthyDev Many thanks for your insight, Jayme. I really appreciate you taking the time to answer my question. It’s difficult to know what I would enjoy most without going all-in. So I will go for what feels right at this moment. Of the first program I like that I’d get exposure to different parts of the process, so in theory, even if don't want to work with DevOps in the future, I’ll probably discover what things I find more fun to work with. So it’s seems like a good starting point. Thank you for the reassurance :)
Absolutely. You’ll find things to enjoy (and be challenged with) either way. Good to hear you’re taking your next step. Don’t let anyone convince you that you’ll ever be boxed in by a choice. You can always learn more (outside of your initial degree) if you want to shift directions!
I think it's good, often even necessary, to know what others do and that different groups communicate. But that's something that should be done anyway. However, the problem with DevOps is that it's often pushed by the MBA types who think it's a good way to get rid of either developers or sysadmins, and let the remaining group do both. Sadly, I have seen a lot of nasty (and sometimes dangerous and expensive) results from letting devs do sysadmin stuff and vice versa. CI/CD is another dangerous thing imho, at least in reality, where it's almost always done wrong. We have a joke here which goes like "CD means shipping the software once the auto-updater works.", and too often that's exactly what people do.
Yeah I’ve seen some of this too. 🥺 Until a team has been through several cycles of seeing work go to production and what good monitoring and stability practices are required for reliable releases, it often makes sense to still have approval gates between each environment where the approvers are more experienced than the rest of the team. But this needs to be understood as a transitional phase and plans need to be made to level up general development practices so the team can eventually spread skills around better IMHO. I talked some more about this in another video “The Journey To Cross Functional Teams” that may help someone: ruclips.net/video/dQLv8lBja6w/видео.html
We just don't have an ops team (same in a previous company) and devs are expected to run the applications. QA is doing releases, but with less understanding of what they actually release; the rarely look at or (want to) understand the code to ship. At the same time, many are clueless about the infrastructure. Now after further development and change in personnel, more alarms than usual are popping up (we do have some alarms in place), but they are either misleading or people on call are not sure about them. Realizing that there might be a knowledge gap that has been pointed out by devs, middle management is now considering to spread some knowledge.
Yeah cross functional teams (DevOps as an example etc.) don’t work in every situation for sure. It’d be interesting to know if developers feel they have enough time to learn what they need to about infrastructure so they can keep it as part of their skill set, or they just have no interest in it. Sometimes developers want to learn and do it but they’re under too much pressure.
The latter is the case. We are working on new products and not maintaining much. An onboarding process is not yet fully established. At the same time, productivity is suffering due to bureaucracy and recent tooling changes, e.g., dumping Slack for Teams while still running an outdated version of JIRA. It is hard to give feedback on these issues and the priorities that would actually help us from a daily business point of view.
@@CyReVolt ah OK. I hear you. One thing I got better at over my career, which isn't a silver bullet but it's surprising how well it works; is to create charts and graphs of my arguments before bringing them to management. If you can measure some quantifiable facts about the cost of running outdated JIRA for example, putting the difference in something visual is harder to ignore when you present it. It's sad that we need to "draw pictures" to get some people to pay attention (and this isn't all management of course!) but it's more common than I like to often admit. Hang in there!!!
Yea we're trying that, thank you for your feedback! :-) We have been promised a new JIRA instance for a while, then it was on hold, and it's now supposed to come by the end of the year. We'll see.
I've been a systems engineer for more than 15 years. Basically, I'm an "Ops" guy, though we don't call ourselves that--it's called Infrastructure, not Ops. DevOps fails because DevOps is a programmer ideology and uses programmer procedures. It does not use any of our 40+ years of tried and true Infrastructure procedures. We use ITIL and other process frameworks. We have considerations of Governance and Security--things that aren't even mentioned in DevOps. We don't use Jenkins and we have our own configuration managers (ex. SCCM, SCOM, WSUS) and monitors (ex. SEIM such as Splunk and NOC software). Most things can not be automated because every vendor does not want to talk to their competitor's systems. Developers don't have to think about network security, firewalls, data centers, virtualization, and cloud IaaS. And what ultimately kills DevOps, developers have very little understanding of Information Security as defined in important Sec practices such as CIS benchmarks and NIST.
devops is good in theory but Don't have everybody do everything - it makes no sense to have everyone spread so thin and no one have any time to gain real expertise at development AND operations/infrastructure/testing/deployment etc - you end up with jacks of all trades and masters of none - if you want things done right you need specialization, and division of labor - as long as there's good concise communication and minimal bureaucracy (minimize meetings), things can run smoothly
DevOps really is treated as the new modern way of being a Sys Admin. I have noticed in my career that DevOps persons each are assigned to one or more projects, but they are still in their own team - they are not really with the teams they are supposed to assist. Thus we have the idea of overlapping teams in big organisations. From my understanding of DevOps, ideally, the team members should learn enough about the tooling to run, deploy and monitor services themselves. There might be a Sys Admin setting it up at a infrastructure level but that is besides the point. As someone said, DevOps is a culture - I add mindset too. It fails in practice the same way as Agile because the implementors see a process and not a mindset focused around people and their needs.
It is about breaking down structures and not simply transforming them with the same people now in new departments and with other processes. The management loves processes because they standardize and makes it possible to measure stuff - measure success, but never failure in order to learn. You only learn from the good things… Process equals control. But I have noticed that processes actually hinder real growth in the team and economically. Unused potential in those who feel that their hands are tied behind their backs. But that is when perspectives, money, and risk-taking comes into the picture.
From the operations/Production DBA side, I hate that the DBA is stuck making modifications to WAR files for every target environment. To me, DevOps describes a process to automate this process so on the operations side we just need to deploy to our target without modifying configuration files. I bring it up in SCRUM meetings but just hear crickets.
Jayme; as you head into cross functional teams, are you concerned about breaking down the segregation of developers only working in dev environments for security or change management? It seems that if you combine dev and ops people, and start to cross train, you could also be blurring that line of control. I've worked in shops where no developers had access to prod, but if you're starting to combine and cross train roles, how do you handle that?
Hey Johathan, great question. I'm finding many teams are using infrastructure as code and automated deployment technologies, without understanding the principles of Continuous Delivery as a whole. Reading that book, it explains how when a deployment pipeline is architected correctly, it allows developers and operations to work together when change is introduced without losing that boundary (SOX compliance etc). Cross training is a complex topic, but it usually starts with merging weekly and/or daily planning sessions with devs and ops (on the same products). Ultimately a re-org is usually needed. I talked about this some more in a video I did earlier in the channel about the journey to cross functional teamwork. If you haven't see it already, you can watch it here: ruclips.net/video/dQLv8lBja6w/видео.html
@@PaulSullivan828 The book is literally "Continuous Delivery" by Jez Humble and David Farley. Excellent! David Farley has a RUclips channel of the same name on here, well worth subbing if you haven't checked it out yet.
I'm a student who has only covered DevOps in the last few months, and after joining a company as an intern and working with a team who made use of tools like TeamCity to participate in the DevOps movement, it was quite frustrating listening to my dev team complain constantly about the ops team and how they wanted to do things. Why use TeamCity if you're not a team!? It's funny how simple DevOps is but how difficult it actually is to get right.
U should do a video comparing and contrasting DevOps, SecOps, and Operations in general (we used to call it SysOps in the old days). SysOps and SecOps share a lot of similarities, but DevOps is completely differently. U are correct that DevOps has been taken advantage of by recruiting firms. Frankly, a decent architect can do this job and that entire department himself. LOL.
The last company I worked for, got worse. They went from cross functional teams to separate ops, devops, development departments. The developers were told that they had to write all the automation in languages which were totally foreign to them and to make matters worse there was not generally enough time to do proper coding and testing. And to make matter really "fun" the DevOps guys kept changing the rules because there always is a technology that is better. To makes things even more chaotic DevOps thought they could dictate the architecture processes the developers could use (they had a separate architectural department). Every sprint was a death march.
Yikes, sorry Darrel. Yeah there's a lot of industry thrashing trying to get this done right. It will be a while until people get better at working on cross functional teams (and not swapping out frameworks too often)...
My company uses DevOps position as an excuse to cover 8 people work. Frontend/backend developer, graphical designer, UI designer, project manager, first line support, system administrator, network engineer. Also DevOps team is rated as support under same level as front desk or HR.
@@HealthyDev First and most important, thank you for your videos. Me and my colleague really like them. It provides some material for the thinking how to do better. As for the frustration, indeed it feels that way., especially as our team lacks structure and willingness to take responsibility. It took around 3 meetings just to decide how we will write commit messages instead of usual "Fixed a bug", later RFC was introduced for the new and existing projects as a means to add structure. But it quickly became just another bureaucratic tool to show for higher management that we have structure and behind the scenes we have a project which is still in planning/RFC phase for 6 months and somehow servers are being deployed to production....
@@VectorCrusader hang in there. The transition to doing this type of stuff isn't easy (as you're experiencing) and also if bad actors want to use it for their hidden agendas (as with anything really) it's another opportunity. Hopefully y'all are able to ride the waves and it becomes easier as you keep doing your best to improve!
I work as "devops", even when I say that this positing shouldn't exist. I try to say that devops is a cultural thing that uses some tools and not the other way around. Many companies, as you said, think that " If I create the perfect environment and pipeline, everyone will want to use it", and, in the end, it doesn't happen. I believe, like you, that companies should start creating the groups and, then, add the software. Many of us, at some point, are very similar to the end users and resist changes... Even when they can be benefitial
My brother does the same type of work and it sounds like he runs into some of the same challenges, You may have watched it already, but I did an older video on the journey to cross functional teams that relates to this: ruclips.net/video/dQLv8lBja6w/видео.html
@@HealthyDev yes! I agree with what you say there. But... How do you act when the first thing that pops up, when you start talking with the managers on those groups is... "who is going to be the leader of that group?" is hard for many leaders, on old organizations most of all, to understand that's not about power what we are trying to create and they start to fight each other for maintain their position... That's why it's a cultural thing first...
@@AlvaroC77 good question. Cultural change is slow and messy. How well it goes really depends on how fast people learn, how much they respect each other, and how rewards and motivation is setup for the team. It's a complicated thing that can't necessarily be given a "how to" here unfortunately. It requires a lot of context about the people and the history of what's been tried in the past. Hope that makes sense.
@@HealthyDev it does, yes. But, I suppose that is up to us to keep spreading this ideas and it's culture. It's hard and frustrating some times and fun in most of the occasions. I'll keep enjoying your videos!
( 4:55 ) - Reason why what you call Operations Personnel aka proper name "Network Engineers" report to their own managers and Software report to their own managers, is because Software Developers don't know Network Engineering. They don't hold a Cisco CCNA, CCNP or CCIE certification to Deploy, Manage, Secure & operate Cisco Hardware. And even those that do have a Cisco Certification, when they were hired at the company as a SWE, their job is not Network Engineer, its Software Engineers. Here is a simple break down. DevOps - Deploy, Secure and Maintain software for the enterprise. Software Engineers - Create and develop the companies software for the company clients. Network Engineers - Deploy, Secure and Maintain Enterprise network. Network Engineers maintain PIX, ASA, Switches and Routers..... Software or DevOps DONT DO THAT.... --- DevOps & DecSecOps are the middle man between Software Engineers and Network Engineers.
If your company infrastructure is on-premise Cisco hardware and you maintain your own networks I do see that most developers today don’t have that skill. I disagree however (obviously) with your description of DevOps. This is an example of exactly what I’m talking about in the video - technology vendors veiling the message to suit their purposes. There are many training courses, books, and technologies that get DevOps completely wrong. It’s the same problem we have with agile practices right now.
From my experience, there's no one I've known who cares about the projects they're working on, they only care about their part in it. That's the main reason why DevOps doesn't work.
Yeah.. my company understands devops as 3..n people in price of one. Developer that does also ops, administration, env maintenance, formal things etc....
Yeah this is where I think more teams are headed. I talked about that journey in another (poorly filmed early) video: The Journey To CROSS FUNCTIONAL Development Teams ruclips.net/video/dQLv8lBja6w/видео.html
Not having roles might spread us too thin though. At my company, operations is the expert on configuring devices....developers are experts within the applications we make. We have great communication, and when things go wrong we are able to work together effectively without blaming the other side. That being said, I really appreciate that they do the majority of that stuff, and I can focus more time on development. The roles do serve a purpose....it would be inefficient to expect everyone to learn everything. That being said, like sooooooo many things in IT, we definitely need to cut down on reaching for a new software/role/document/process/whatever when really all we need is better communication skills. What do you think?
DevOps is a position, you have to hire someone to do that specifically... please stop drowning developers in even more things they need to learn to do, they have enough on their plates already... with companies requiring developers to work several different jobs under their hat at this point (developer, designer, architect, QA, data science all in one package) now you want to add another one... NO! DevOps should be a different position and developers shouldn't have to do that as well as everything else they do already
See, I don't understand why this separation of developer and production groups is a thing... Common sense says that you should have those teams together and maybe separate out the keys to making a feature go live be in the hands of a three to five key system so everyone of the key people have to sign off before taking a feature live. No wonder things are so slow in these companies...
I like the idea of the shared meetings and goals. I think the roles should still be kept separate, I've met some really really good developers and some really really good ops, but never a really really good devops - they always seem overwhelmed and stressed out - there's too many skills to be an expert in all of them. We also have a separate proper ops only team, but no actual 'just dev' team. I think the ideal would be: * Dev team * Ops team * Both with different bosses, but the same mega boss who's invested in everything working together * A weekly shared meeting (but separate meetings too) * Both involved in deployments * Devs on call (or night devs) - that way there is more accountability for releases ;)
Lots of good insight and practice ideas here - thanks for sharing! I get the feeling that you may also get some value out of another video I did related to this one about "The Journey to Cross Functional Teams": ruclips.net/video/dQLv8lBja6w/видео.html
Are you really still surprised by the fact that people in the field constantly take tools for goals? It's so common you really should have got used to it by now. ;)
How have you avoided the confusion around DevOps?
Skip to points: 👇
00:29 Follow The Money
01:08 A Warning About Tool Vendors
02:17 A Warning About Consultants
03:04 A Warning About Recruiters
03:47 DevOps Defined
05:32 When Doesn’t DevOps Work?
07:41 Dysfunctional DevOps Teaming
09:40 DevOps Practices To Consider
Pin your comment so it stays at the top.
Lol the real problem is - hard to teach an old dog new trick.
@@yli8888 yeah for sure. That seems to be a problem with a lot of new ideas that come into the industry.
It’s really a way of tricking developers to do sysadmin, network engineering and database administration for no extra compensation
I’ve seen it be that, yes. If that’s expected of me I make sure they understand the throughput of features from me will go down. As long as they are okay with that I don’t mind this kind of work. But as I’ve said in other videos it’s important companies treat us as individuals. There’s nothing wrong with some developers not wanting to do this kind of work!
Ehhhmm... No really. The idea, for me, is that the developers understand what the sysadmin does and the sysadmin understand what the developer does. Not to do it for really. The problem is that people tend to think as you say and, at the end, they resist to learn new things.
Varo Roldan Just look at the job posts... that is the theory, but reality is a different thing. I used to be a sysadmin at one point and those jobs were decent... now, not so much.
Lots of people getting laid off and positions eliminated in various infrastructure areas due to DevOps... and the quality/security is suffering
I interact with lots of organizations and you wouldn’t believe the things I see... from people who don’t actually know networking trying to be network engineers , to people who don’t know databases trying to perform dba functions ... just because they are developers
@@ivanhoek yes, that happens. And that's the problem with not understand what devops is about. I've seen that and tried to said "don't say devops or agile when you are not using it because it's counterproductive" but didn't succeed at that... Perhaps it the problem with new things, with a fashion thing that the most important is to say that you are using and not really apply it... I don't know...
Yes, that's the reality. Responsibility list for a dev is getting longer and longer all the time because companies want to skimp on costs. I haven't seen a person with good ops skills in years anymore because I am the one automating the cloud infra while simultaneously doing feature development. My compensation has not increased.
DevOps to me is a culture not a practice. Doing some Automation doesn't make it DevOps...Talking to each other and co-ordinating tasks avoiding silos. Its not hard...just work together. It needn't cost a penny. I've never seen an industry as bad as Tech, for reinventing the wheel rather than address the problem.
Love it. Thanks for sharing your insights!
why are consultants so succesful in making money off the devops movement?
Because management is unwilling to change:
1) operations are still a cost center, devs are budgeted though sales and marketing, or even worse, an "innovation stipend"
2) same goes for agile: 2 week sprints but managers still keep 6 month Gant charts with complete feature maps that they never communicate to the teams.
I'm a CS major set to graduate soon and after years of hearing this term DevOps and wondering what exactly it means/entails i finally have clarity thanks to this 15 minute RUclips video. Thank you so much for this!
No problem! Happy to think you’ll enter the workforce knowing this already.
Great video, thank you for sharing your thoughts. What I got out of this is that proper DevOps is about getting the right work culture and team alignment -- not just automation. Changing technical tools is relatively easy, but changing an organization's culture is hard.
Spot on summary! 👍
Perfectly said. Really good video. Million dollar consultant advice exactly at 10:58. Good to know there are people outside that understand.
DevOps is old term, new age buzz word is Site Reliability Engineer, a term introduced by Google and probably a better description for what the job should entail.
Great video. Really enjoying your channel.
Thanks John!
I’ve done Lean, DevOps, Service Excellence etc. over many years. Like all “management methodologies” they all eventually escalate cost due to the fact they offer so many billable overheads (perfect for consultancies). As such they eventually get replaced by a new one that hasn’t yet acquired all the hangers on. The really interesting thing is the industries belief that changing methodology is the answer. In reality anything can work as long as you don’t let it get out of hand. Personally I think that if a developer has to perform more than an hour of admin a week then there’s a problem. If there’s productivity issues it’s usually down to the people/management. I’ve seen many projects delivered in weeks for tens of thousands where others took years, cost millions and took years despite being smaller and les sophisticated. The difference being the management overhead.
Rapid deployment of new bugs.
The Homer Simpson way: The wrong way, but faster
The key part of the word DevOps is the Ops part. It’s operations related to development, whereas Operations in general is operations for the entire company, primarily production systems. Generally, DevOps and Operations are completely different and rarely speak; about the only thing they both have in common is hardware, assuming they aren’t completely in the cloud. LOL.
I like this, true Devops occurs when the two groups work together and solve common problems, goes hand in hand to your secret to scrum , deliver and adapt, fail fast, then make changes that the customer really needs after the cross-functional moved something to production
not being sarcastic, you've nailed it
DevOps being a culture and a mindset as opposed to a set of skills and practices cannot be overstated. It is like saying knowing ten thousands theorems and their demonstrations makes someone a mathematician, when in fact a printer could do the same. Many times I've tried to impose, because in retrospective that's what I did, and it mainly got ignored, opposed, or finally trashed because it often takes a whole team and their feedback to make things that are good enough to have a productive value.
Just hiring a "devops" guy thinking his magic will trickle down into your teams and increase their productivity is just plain magical thinking.
Agreed 100% with everything you said...Lovely Video and well presented and understood.
In my previous company, I was self designated devops. Everything was so black-boxy from infra standpoint, I decided to ask to join partially operations team.
I was sort of a guy that sat between ops and dev for some time.
Then I was trying to make devs more aware of the prod runtime and expose ops to dev concerns and type of thinking.
It took A LOT of time to put everyone on the same page. It was rather an issue of the attitude than tech.
Great testimony. Sounds like you are deep into understanding the cultural shift. I wish more people in the DevOps arena were focused on this like yourself!
Hi! Could you please clarify why are you considering DevOps a subset of Continuous Delivery? In my understanding it's more like DevOps = Lean + cultural things + CD.
Getting developers and operations to work together is necessary for approvals and coordination to move fast enough to continuously deliver software. But you can leave those two silo'd and have all the technology you want, and still not be able to deliver fast. At least that's my perspective based on the Continuous Delivery book (which is one of the best books I've ever read on software period).
@@HealthyDev CD book by Humble and Farley is great, a gem for ones without experience leading a team, really. But when speaking about DevOps, the most authoritative sources AFAIK are "10 deploys a day" (Allspaw, Hammond) and "The DevOps Handbook" (Kim et al).
- 10 Deploys a Day
ruclips.net/video/LdOe18KhtT4/видео.html
- The DevOps Handbook
www.amazon.ca/DevOps-Handbook-World-Class-Reliability-Organizations/dp/1942788002/ref=asc_df_1942788002/?tag=googleshopc0c-20&linkCode=df0&hvadid=293004119900&hvpos=&hvnetw=g&hvrand=860162250242797978&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9000914&hvtargid=pla-568661774152&psc=1
Here Gene Kim basically redefines DevOps to "the three ways" from CALMS, but gets people like John Allspaw, Patrick Debois, and Jez Humble, so it's the most current compromise.
From what I know, DevOps always contained CD, starting from "John Allspaw's DevOps". What happens with recruiters, vendors and all the "DevOps Engineers" and their super weird understanding of what's optimal, is another topic entirely. Maybe everyone will settle with SRE term which, frankly, better serves its purpose.
@@redpillsolutions9698 yep the DevOps handbook is good. Honestly I am suspect of some of Gene Kim's motives for reasons of partnerships with certain vendors. His relationships with Jez certainly lends credence. But that's another conversation...
@@HealthyDev Btw, I totally agree with the emphasis on the vendors' role. In a sense, they had little choice since the moment someone discovered that the word DevOps sells, you either join the game or lose. Gene Kim is a "management consultant" type of person IMO too, but it was him who managed to consolidate enough of the founders...
@@redpillsolutions9698 for sure, he's a key person and we have a lot to thank him for. I just am a little bit weary, similar to how Jeff Sutherland sold out on agile by focusing on it "getting stuff done faster" when that wasn't the point of lean methods - though it's what management wanted to hear etc.
I was hired once as a "DevOps" engineer and all I did was operations. I asked during the interview "isn't this just regular operations?" and nobody could give me an answer.
Lol I know a lot of people personally who can relate….
Very interesting channel, thank you!
I’m trying to decide between two computer science degrees (in Sweden). The first focuses on “Software development and operations”; besides programming, it includes courses about sysadmin, configuration management and continuos delivery. The second focuses mostly on “web programming” and shares many of the foundational courses with the other program.
Would you say there is any benefit to learning the “DevOps” skills from the first program? I mean benefit, in general, for every future software developer, not just for those who want to work in a DevOps role.
I know this is not the topic of your video. But maybe, with your experience and perspective of the tech sector, you could help me out a bit. In any case, thank you for your videos!
Hey Eric great question. As someone who doesn’t have the curriculum for these two degrees in front of me, I’ll offer what I can.
If developing web apps and things that support them like APIs and integrating with third party services is interesting to you - you might be better off with that degree. The specialization is going to set you ahead for employers that need people in that role. I’ve done a lot of this work and it can be a lot of fun in the right environment.
On the flip side, DevOps/CD related positions are incredibly hot (and competitive) right now. If setting up the infrastructure upon which apps run, figuring out how to get things performing well, monitoring things, and security are interesting to you this is also a great initial career choice. If you want a job unrelated to web apps this one also could help you as many systems with no user interface (think data science, data processing, or various services for sale to other companies) need a solid infrastructure.
I’m of the belief that all engineers will need all of these skills eventually in their career. There’s a lot to learn and you really can’t go wrong if you pick whatever sounds most fun to work on day to day. It’s much more important starting out to consider what you’ll be passionate about more than money, because when you’re new you have to prove yourself. You’ll have plenty of opportunities as your career moves forward to pick up more skills on the job.
I hope some of that helps! Thanks for watching Eric. 👍
@@HealthyDev Many thanks for your insight, Jayme. I really appreciate you taking the time to answer my question. It’s difficult to know what I would enjoy most without going all-in. So I will go for what feels right at this moment. Of the first program I like that I’d get exposure to different parts of the process, so in theory, even if don't want to work with DevOps in the future, I’ll probably discover what things I find more fun to work with. So it’s seems like a good starting point. Thank you for the reassurance :)
Absolutely. You’ll find things to enjoy (and be challenged with) either way. Good to hear you’re taking your next step. Don’t let anyone convince you that you’ll ever be boxed in by a choice. You can always learn more (outside of your initial degree) if you want to shift directions!
Damn! your voice is swaying me to click the subscribe button. lols. Good content, keep it up!
HA thanks wenry, welcome to the channel ;)
I think it's good, often even necessary, to know what others do and that different groups communicate. But that's something that should be done anyway. However, the problem with DevOps is that it's often pushed by the MBA types who think it's a good way to get rid of either developers or sysadmins, and let the remaining group do both.
Sadly, I have seen a lot of nasty (and sometimes dangerous and expensive) results from letting devs do sysadmin stuff and vice versa. CI/CD is another dangerous thing imho, at least in reality, where it's almost always done wrong. We have a joke here which goes like "CD means shipping the software once the auto-updater works.", and too often that's exactly what people do.
Yeah I’ve seen some of this too. 🥺
Until a team has been through several cycles of seeing work go to production and what good monitoring and stability practices are required for reliable releases, it often makes sense to still have approval gates between each environment where the approvers are more experienced than the rest of the team.
But this needs to be understood as a transitional phase and plans need to be made to level up general development practices so the team can eventually spread skills around better IMHO.
I talked some more about this in another video “The Journey To Cross Functional Teams” that may help someone: ruclips.net/video/dQLv8lBja6w/видео.html
We just don't have an ops team (same in a previous company) and devs are expected to run the applications. QA is doing releases, but with less understanding of what they actually release; the rarely look at or (want to) understand the code to ship. At the same time, many are clueless about the infrastructure. Now after further development and change in personnel, more alarms than usual are popping up (we do have some alarms in place), but they are either misleading or people on call are not sure about them. Realizing that there might be a knowledge gap that has been pointed out by devs, middle management is now considering to spread some knowledge.
Yeah cross functional teams (DevOps as an example etc.) don’t work in every situation for sure. It’d be interesting to know if developers feel they have enough time to learn what they need to about infrastructure so they can keep it as part of their skill set, or they just have no interest in it. Sometimes developers want to learn and do it but they’re under too much pressure.
The latter is the case. We are working on new products and not maintaining much. An onboarding process is not yet fully established. At the same time, productivity is suffering due to bureaucracy and recent tooling changes, e.g., dumping Slack for Teams while still running an outdated version of JIRA. It is hard to give feedback on these issues and the priorities that would actually help us from a daily business point of view.
@@CyReVolt ah OK. I hear you. One thing I got better at over my career, which isn't a silver bullet but it's surprising how well it works; is to create charts and graphs of my arguments before bringing them to management. If you can measure some quantifiable facts about the cost of running outdated JIRA for example, putting the difference in something visual is harder to ignore when you present it. It's sad that we need to "draw pictures" to get some people to pay attention (and this isn't all management of course!) but it's more common than I like to often admit. Hang in there!!!
Yea we're trying that, thank you for your feedback! :-) We have been promised a new JIRA instance for a while, then it was on hold, and it's now supposed to come by the end of the year. We'll see.
@@CyReVolt I figured ;). No problem.
I've been a systems engineer for more than 15 years. Basically, I'm an "Ops" guy, though we don't call ourselves that--it's called Infrastructure, not Ops. DevOps fails because DevOps is a programmer ideology and uses programmer procedures. It does not use any of our 40+ years of tried and true Infrastructure procedures. We use ITIL and other process frameworks. We have considerations of Governance and Security--things that aren't even mentioned in DevOps. We don't use Jenkins and we have our own configuration managers (ex. SCCM, SCOM, WSUS) and monitors (ex. SEIM such as Splunk and NOC software). Most things can not be automated because every vendor does not want to talk to their competitor's systems. Developers don't have to think about network security, firewalls, data centers, virtualization, and cloud IaaS. And what ultimately kills DevOps, developers have very little understanding of Information Security as defined in important Sec practices such as CIS benchmarks and NIST.
devops is good in theory but Don't have everybody do everything - it makes no sense to have everyone spread so thin and no one have any time to gain real expertise at development AND operations/infrastructure/testing/deployment etc - you end up with jacks of all trades and masters of none - if you want things done right you need specialization, and division of labor - as long as there's good concise communication and minimal bureaucracy (minimize meetings), things can run smoothly
DevOps really is treated as the new modern way of being a Sys Admin. I have noticed in my career that DevOps persons each are assigned to one or more projects, but they are still in their own team - they are not really with the teams they are supposed to assist. Thus we have the idea of overlapping teams in big organisations.
From my understanding of DevOps, ideally, the team members should learn enough about the tooling to run, deploy and monitor services themselves. There might be a Sys Admin setting it up at a infrastructure level but that is besides the point.
As someone said, DevOps is a culture - I add mindset too. It fails in practice the same way as Agile because the implementors see a process and not a mindset focused around people and their needs.
It is about breaking down structures and not simply transforming them with the same people now in new departments and with other processes.
The management loves processes because they standardize and makes it possible to measure stuff - measure success, but never failure in order to learn. You only learn from the good things…
Process equals control. But I have noticed that processes actually hinder real growth in the team and economically. Unused potential in those who feel that their hands are tied behind their backs. But that is when perspectives, money, and risk-taking comes into the picture.
From the operations/Production DBA side, I hate that the DBA is stuck making modifications to WAR files for every target environment. To me, DevOps describes a process to automate this process so on the operations side we just need to deploy to our target without modifying configuration files. I bring it up in SCRUM meetings but just hear crickets.
Jayme; as you head into cross functional teams, are you concerned about breaking down the segregation of developers only working in dev environments for security or change management? It seems that if you combine dev and ops people, and start to cross train, you could also be blurring that line of control. I've worked in shops where no developers had access to prod, but if you're starting to combine and cross train roles, how do you handle that?
Hey Johathan, great question.
I'm finding many teams are using infrastructure as code and automated deployment technologies, without understanding the principles of Continuous Delivery as a whole.
Reading that book, it explains how when a deployment pipeline is architected correctly, it allows developers and operations to work together when change is introduced without losing that boundary (SOX compliance etc).
Cross training is a complex topic, but it usually starts with merging weekly and/or daily planning sessions with devs and ops (on the same products). Ultimately a re-org is usually needed.
I talked about this some more in a video I did earlier in the channel about the journey to cross functional teamwork.
If you haven't see it already, you can watch it here: ruclips.net/video/dQLv8lBja6w/видео.html
@@HealthyDev which book?
@@PaulSullivan828 The book is literally "Continuous Delivery" by Jez Humble and David Farley. Excellent! David Farley has a RUclips channel of the same name on here, well worth subbing if you haven't checked it out yet.
I'm a student who has only covered DevOps in the last few months, and after joining a company as an intern and working with a team who made use of tools like TeamCity to participate in the DevOps movement, it was quite frustrating listening to my dev team complain constantly about the ops team and how they wanted to do things. Why use TeamCity if you're not a team!? It's funny how simple DevOps is but how difficult it actually is to get right.
The increasingly self centered attitude of most modern people shows up everywhere these days. 🤦♂️
I enjoy your videos. 👍🏽🙏
U should do a video comparing and contrasting DevOps, SecOps, and Operations in general (we used to call it SysOps in the old days). SysOps and SecOps share a lot of similarities, but DevOps is completely differently. U are correct that DevOps has been taken advantage of by recruiting firms. Frankly, a decent architect can do this job and that entire department himself. LOL.
Cool idea!
now I see white papers and conferences for DevSecOps 🙄 another excuse to sell consultancy and software services lol
The last company I worked for, got worse. They went from cross functional teams to separate ops, devops, development departments. The developers were told that they had to write all the automation in languages which were totally foreign to them and to make matters worse there was not generally enough time to do proper coding and testing. And to make matter really "fun" the DevOps guys kept changing the rules because there always is a technology that is better. To makes things even more chaotic DevOps thought they could dictate the architecture processes the developers could use (they had a separate architectural department). Every sprint was a death march.
Yikes, sorry Darrel. Yeah there's a lot of industry thrashing trying to get this done right. It will be a while until people get better at working on cross functional teams (and not swapping out frameworks too often)...
My company uses DevOps position as an excuse to cover 8 people work. Frontend/backend developer, graphical designer, UI designer, project manager, first line support, system administrator, network engineer. Also DevOps team is rated as support under same level as front desk or HR.
Yeah there's cross-functional, and then there's dysfunctional 🤦♂️ Sorry that's got to be really frustrating.
@@HealthyDev First and most important, thank you for your videos. Me and my colleague really like them. It provides some material for the thinking how to do better.
As for the frustration, indeed it feels that way., especially as our team lacks structure and willingness to take responsibility. It took around 3 meetings just to decide how we will write commit messages instead of usual "Fixed a bug", later RFC was introduced for the new and existing projects as a means to add structure. But it quickly became just another bureaucratic tool to show for higher management that we have structure and behind the scenes we have a project which is still in planning/RFC phase for 6 months and somehow servers are being deployed to production....
@@VectorCrusader hang in there. The transition to doing this type of stuff isn't easy (as you're experiencing) and also if bad actors want to use it for their hidden agendas (as with anything really) it's another opportunity. Hopefully y'all are able to ride the waves and it becomes easier as you keep doing your best to improve!
I work in HR and want to leave it....Dev Ops sounded great but i see where this may lead me...lol
Security is the new Ops team.
I work as "devops", even when I say that this positing shouldn't exist. I try to say that devops is a cultural thing that uses some tools and not the other way around. Many companies, as you said, think that " If I create the perfect environment and pipeline, everyone will want to use it", and, in the end, it doesn't happen.
I believe, like you, that companies should start creating the groups and, then, add the software. Many of us, at some point, are very similar to the end users and resist changes... Even when they can be benefitial
My brother does the same type of work and it sounds like he runs into some of the same challenges, You may have watched it already, but I did an older video on the journey to cross functional teams that relates to this: ruclips.net/video/dQLv8lBja6w/видео.html
@@HealthyDev yes! I agree with what you say there. But... How do you act when the first thing that pops up, when you start talking with the managers on those groups is... "who is going to be the leader of that group?" is hard for many leaders, on old organizations most of all, to understand that's not about power what we are trying to create and they start to fight each other for maintain their position... That's why it's a cultural thing first...
@@AlvaroC77 good question. Cultural change is slow and messy. How well it goes really depends on how fast people learn, how much they respect each other, and how rewards and motivation is setup for the team. It's a complicated thing that can't necessarily be given a "how to" here unfortunately. It requires a lot of context about the people and the history of what's been tried in the past. Hope that makes sense.
@@HealthyDev it does, yes. But, I suppose that is up to us to keep spreading this ideas and it's culture. It's hard and frustrating some times and fun in most of the occasions.
I'll keep enjoying your videos!
I think a lot of leaders and managers do not understand the difference between automation and streamlining.
( 4:55 ) - Reason why what you call Operations Personnel aka proper name "Network Engineers" report to their own managers and Software report to their own managers,
is because Software Developers don't know Network Engineering. They don't hold a Cisco CCNA, CCNP or CCIE certification to Deploy, Manage, Secure & operate Cisco Hardware.
And even those that do have a Cisco Certification, when they were hired at the company as a SWE, their job is not Network Engineer, its Software Engineers.
Here is a simple break down.
DevOps - Deploy, Secure and Maintain software for the enterprise.
Software Engineers - Create and develop the companies software for the company clients.
Network Engineers - Deploy, Secure and Maintain Enterprise network. Network Engineers maintain PIX, ASA, Switches and Routers..... Software or DevOps DONT DO THAT....
--- DevOps & DecSecOps are the middle man between Software Engineers and Network Engineers.
If your company infrastructure is on-premise Cisco hardware and you maintain your own networks I do see that most developers today don’t have that skill.
I disagree however (obviously) with your description of DevOps. This is an example of exactly what I’m talking about in the video - technology vendors veiling the message to suit their purposes. There are many training courses, books, and technologies that get DevOps completely wrong. It’s the same problem we have with agile practices right now.
From my experience, there's no one I've known who cares about the projects they're working on, they only care about their part in it. That's the main reason why DevOps doesn't work.
Yeah.. my company understands devops as 3..n people in price of one. Developer that does also ops, administration, env maintenance, formal things etc....
Is devops a worst job to choose it as a career anybody reply?
I would take it a step further and say that developers and operations need to learn each other's skills and that I think the roles should go away.
Yeah this is where I think more teams are headed. I talked about that journey in another (poorly filmed early) video:
The Journey To CROSS FUNCTIONAL Development Teams ruclips.net/video/dQLv8lBja6w/видео.html
Not having roles might spread us too thin though. At my company, operations is the expert on configuring devices....developers are experts within the applications we make. We have great communication, and when things go wrong we are able to work together effectively without blaming the other side. That being said, I really appreciate that they do the majority of that stuff, and I can focus more time on development. The roles do serve a purpose....it would be inefficient to expect everyone to learn everything. That being said, like sooooooo many things in IT, we definitely need to cut down on reaching for a new software/role/document/process/whatever when really all we need is better communication skills. What do you think?
@@andrewmusholt9327 I think it's fair to say that different environments have different needs. What kind of devices are you talking about?
DevOps is a position, you have to hire someone to do that specifically... please stop drowning developers in even more things they need to learn to do, they have enough on their plates already... with companies requiring developers to work several different jobs under their hat at this point (developer, designer, architect, QA, data science all in one package) now you want to add another one... NO! DevOps should be a different position and developers shouldn't have to do that as well as everything else they do already
See, I don't understand why this separation of developer and production groups is a thing... Common sense says that you should have those teams together and maybe separate out the keys to making a feature go live be in the hands of a three to five key system so everyone of the key people have to sign off before taking a feature live. No wonder things are so slow in these companies...
that's true !!
I like the idea of the shared meetings and goals. I think the roles should still be kept separate, I've met some really really good developers and some really really good ops, but never a really really good devops - they always seem overwhelmed and stressed out - there's too many skills to be an expert in all of them.
We also have a separate proper ops only team, but no actual 'just dev' team.
I think the ideal would be:
* Dev team
* Ops team
* Both with different bosses, but the same mega boss who's invested in everything working together
* A weekly shared meeting (but separate meetings too)
* Both involved in deployments
* Devs on call (or night devs) - that way there is more accountability for releases ;)
Lots of good insight and practice ideas here - thanks for sharing! I get the feeling that you may also get some value out of another video I did related to this one about "The Journey to Cross Functional Teams": ruclips.net/video/dQLv8lBja6w/видео.html
The Phoenix Project
One of my top 10 favorite engineering books!
that is a really bad place to put a guitar
Are you really still surprised by the fact that people in the field constantly take tools for goals? It's so common you really should have got used to it by now. ;)
What makes you think I’m surprised? 🤔 These videos are to help people, not me.
For me devops its just more advance form of admin jobs.
Sounds like ops sees the writing on the wall and don't want developers to automate them out of their job.
They have a choice to learn to code, that writing has been on the wall for over a decade...
From what i've seen of Devs I'm not worried about that happening any time soon.
Word documents, jesus christ
All unneeded BS.
No.
Video made many useful point.
But, you probably have no heart to hear them.
lol, there are someone who lost their job to automation