DevOps Is Dead! Long Live Platform Engineering! Did We Get Confused?
Vložit
- čas přidán 31. 05. 2024
- "DevOps is dead!" That's a commonly repeated sentence these days. Some might say that Platform Engineering is replacing DevOps. But is DevOps really dead? Is it being replaced by Platform Engineering? Or maybe, we are just confused.
#devops #platformengineering #idp
▬▬▬▬▬▬ 😳 Sponsor 😳 ▬▬▬▬▬▬
🔗 Akeero: hubs.ly/Q01tNvgc0
Consider joining the channel: / devopstoolkit
▬▬▬▬▬▬ 💰 Sponsoships 💰 ▬▬▬▬▬▬
If you are interested in sponsoring this channel, please use calendly.com/vfarcic/meet to book a timeslot that suits you, and we'll go over the details. Or feel free to contact me over Twitter or LinkedIn (see below).
▬▬▬▬▬▬ 👋 Contact me 👋 ▬▬▬▬▬▬
➡ Twitter: / vfarcic
➡ LinkedIn: / viktorfarcic
▬▬▬▬▬▬ 🚀 Other Channels 🚀 ▬▬▬▬▬▬
🎤 Podcast: www.devopsparadox.com/
💬 Live streams: / devopsparadox
▬▬▬▬▬▬ ⏱ Timecodes ⏱ ▬▬▬▬▬▬
00:00 Is DevOps Dead?
01:26 Akiro (sponsor)
02:11 Before Everything
06:48 Self-Sufficient Agile Teams
08:26 Here Comes DevOps
12:31 The Rise Of Platform Engineering
18:24 Is DevOps Really Dead? - Věda a technologie
![[柴犬ASMR]曼玉Manyu&小白Bai 毛发护理Spa asmr](http://i.ytimg.com/vi/0TsXQ7z2Dh4/mqdefault.jpg)
Is DevOps dead? What do you think?
I guess it depends on what you call 'devops', and which phase of which hype cycle you mean... as you very well laid out, the concepts are very much alive, no matter what label we try to use.
You guys should stop believing this you tubers who is just talking crap about AI replacing Programers, they are literally doing all of this for like and views, literally......instead listen to people like the CEO of gitHub or CEO of scale AI or the CEO of open AI this guy's literally said that AI and HI human intelligence are meant to be augmented
@@onoseaimayo8261 I don't think AI was mentioned even once in this video, and hardly anywhere else in this channel.
@@DevOpsToolkit 😂😂😂
In few years: "PLATFORM ENGINEERING IS DEAD" -> "LONG LIVE SYSTEM ADMINISTRATION"... Ppl start to realize cloud is super expensive.
as an old sys admin, ex-devops ,new SRE and future platform engineer: IMO devops culture is the zombie process of today's technologies and as it is known, zombies cannot be killed. :)
Can a fresher with no experience get into devops ?
@@rakshithsketches7056 Im a fresher and currently a devops. So I have to say it’s possible. But perhaps, in company where many process has been settled and with enough senior to train and watch over us.
TRUE DAT!
same here... from assembler to backend to SRE
Zombies cannot be killed! 😀 .. Nicely put.
I have been working as a DevOps engineer for the last 4 years doing exactly what a platform engineer is doing. We have 1 team called "DevOps" that is doing all the automation and developing services for CI/CD, k8s platform, security related stuff like vulnerability scanning and base image maintenance and I explain my team as having the dev teams as our customer. Turns out my team is doing platform engineering.
Same goes for me too.
This proves that naming stuff is still the biggest challenge of IT 😀
"stuff" it is!
Just shared this with the rest of 799 people in my org. You nailed it , completely true story. Being part of a startup (not anymore) for last six years.. I was able to find my company at every stage of this story.
Bro......this was brilliant. When you made the comment about "security No longer giving you spreadsheets with your vulnerabilities..." I was like, " That's exactly how it works at my job!". you have a new subscriber here.
Wow! I've never seen such a clear and organized view on DevOps.
I'm a DevOps engineer, and believe me - I don't know what it exactly is.
And I'm sure I'm not the only one.
Your videos would definitely help.
First i would commend you for tackling this subject. Not many have the balls to put a mirror Infront of the industry or have a broad public image so others will listen. The fact you choose to deal with the concepts without mentioning tools is also a really good way to present the contradictions and deal with them first before even contemplating tools.
I have been in the industry for almost 25 years and have been practicing "DevOps" before Patrick gave it its name and working on my versions of IDP before that had a name either.
I have my disagreements with the DevOps Guru, and not placing emphasis on the cloud revolution nor the bad influence "You build it, you Run it" did to the industry in causing to some degree orgs misunderstanding what DevOps is.
Since this isn't the right platform for long articles, i will end with saying that we don't need to go from 2 silos to more silos, one team can do majority of these tasks but it MUST be inclusive to allow everyone to contribute in a more inner source mentality and hopefully people will work on the implementation of DevOps via CA(L)MS and stop changing titles for money. Management and IT leadership NEED to change and adapt as changes can be painful and require full backing or they fail, no matter what title you give it, Agile, DevOps, Platform Engineering etc.
100%
Yep, also about 25 years in the industry, and of it over 15 years as a DevOps before it was called "DevOps", I agree 100% !!
In one of our large contracts, one of our giant customers together with our brilliant sales people decided that we are doing devops now. Because there are dev teams and there is an ops team (in India of course) and we provide both in the contract - DEVOPS!!! My Developers still had to create tickets and fill out giant excel sheets and hand over protocols and wait for days and what not, but devops! Haven't escalated me out of another project so fast in 17 years. So done with agile coaches and devops gurus basically fresh from university...
Anyways, everything the man says is correct. It's still painful at times especially in big companies with unexperienced people, but the best solution for a basically unsolvable problem.
I love your video! Thank you so much for explaining this in such a funny and lovely way:) I work as a Release Manager so trying to improve the proceses for a large project and interacting a lot with Platform team. I also naturally figured out that it makes sence to develop tools and give them to teams and I try to do my job the same way, providing the framework which is easy to use!
Great to hear that
One note about Dev teams adopting testing: I agree with you, but I think there are still valuable remnants of QA expertise. There are two scenarios in which I think they show up
1. In a sufficiently large organization, once you've saturated your value-add with automated tests and guardrails to make sure they exist, I think it still pays to have a few experts in Quality Assurance ad Quality Engineering who can spend their days thinking about how to raise the bar. Decoupled teams building decoupled software often end up in silos. Sometimes adding yet another siloed QA/QE team who looks for patterns of problems caused by silos within a product or suite of products can help improve the cohesion of the independent systems where necessary.
2. In some older organizations with a lot of big balls of enterprise-integration-heavy mud spanning many tightly coupled applications, I could imagine that the job of circumnavigating your product looking for potential problems caused by a change could be a 40-hour-a-week ordeal that benefits from "one-skull" expertise.
Ideally, we avoid these situations by making our systems easy to change with layers of orchestration where necessary, and decoupled messaging where orchestration is not necessary. Furthermore, I think introducing a QA/QE team to a group of devs that haven't written tests for their code without the intention of using that team to teach developers to test their code self-sufficiently puts accountability in the wrong hands. But if the governance and documentation of your domain, data model, APIs , etc. is developed too late, and/or if the number of integrations booms with no end in sight, you may need to pay someone or a team of people to try to keep up with it all.
1. There is a clear value in having experts in testing just as there is value in having other types of experts. I do not think that self-sufficient teams should act in isolation. Instead, I'm suggesting that we should not be throwing things over the wall because that thing is the responsability of something else. A team developing an application should, among other things, make sure that application is tested. Now, that does not exclude involving people from other groups, quite the contrary. Nevertheless, asking for help is quite different from not doing something and assuming that someone else will do it for you. What I'm trying to say is that "specialized" teams are there to help rather than being responsible for whatever someone might throw to them.
2. When we go into legacy systems, everything I said in this or almost any other video goes to thrash. All bets are off in those cases and the main question is often "how can we survive for a while longer".
Finally, telling anyone "now you do it while I know that you don't know how" is a recipe for disaster. There must be a transition period coupled with reorganization and reskilling.
@@DevOpsToolkit I totally agree.
At 15:35, I think you make an important point: That team expertise is permeable and not isolated or rigid. Everyone on my team has some working knowledge of AWS, but they need me (the DevOps dude) to be expert in pipeline development (for us Github Actions) and infrastructure; however, all of our developers adjust small bits of our infra and actions according to their needs! They are often slower and more naive, but the basics are not hard to grasp; and visa versa, I could develop frontend or backend, but I would be slower than them because that's not my specialization. They mostly need me to maintain security and to prevent blockers, which happens literally everyday.
Ultimately, no one has time for everything, so it breaks down to pragmatic categories of job distribution to create optimized teams. Anyone can do DevOps, just not everyone takes the time to become expert in these systems. Since joining my team, development process has sped up significantly simply due to overcoming blockers via my exposure to Linux and CI/CD concepts (which is why your videos are so valuable, btw).
The days at my job are working basically as a DevOps consultant, closely with QA and agile, while answering my team's questions about AWS, microservices, and actions; and I also perform the tasks requested my tech lead doesn't have time for, or direct tickets from the project owner (with collaboration of course).
That's exactly what I'm thinking of, even though I might use different names than you.
I think PE is great new term. It describes much better what the "ops" part of the org should be doing. DevOps is a nice idea but too vague, just becomes something to fight over the true meaning endlessly. Not that PE is a super well defined term, but it at least gives weight and some degree of clarity to the purpose of all the CI/CD and infra stuff. Namely build platforms that developers building the business applications can leverage for better productivity.
100% agree, also doing platform without platform level services or IDP falls apart and becomes operations, admin stuff.
all we did was go in a circle ....we build a product, threw it over the fence for deployment, then devs took over and decided they wanted to do everything (cloud native) , then we turned a corner and told devs NOPE get a devops person to write all your IaC and deployment pipelines and get back to work , NOW we are back at throwing it over the fence to a Platform team who sole purpose is to simply choices so we have uniformity .
It doesn't matter how you organise your team, or teams, you always lose something. If you're in a team with other departments, you lose expert knowledge sharing, if you're in a team with where everyone has a similar job, you lose the inter-team communication. Good team management will always be better than 'devops' or 'platform engineering', yet we barely talk about anything else these days.
You're right. Every cultural change (including DevOps) must include management or, often, should be led by management. I should stress that or maybe create a video dedicated to it.
Thank you very informative! Funnily I learned what agile is supposed to mean in this video too!
Very well explained, thank you! I think many companies never really understood DevOps and started calling their ops teams DevOps teams. What they were actually doing wasn't wrong, but it should be called Platform Engineering instead of DevOps
I work in a company with about 35 Devs in my department which are split into 7 teams. One of them is the Platform team. We did a similar thing as with the Testers you mentioned and integrated the infrastructure experts into Dev-Teams. So our Platform-Engineers are members of 2 teams (20% in Dev-Team, 80% in Platform-Team). This avoids throwing infrastructure topics over the fence and problems are solved within the team with all the platform-team standards. It motivates Devs to learn topics outside their comfort zone without pushing them too much. They won't be experts but It enables them to understand how their code is running in production.
The platform engineers have still enough time to implement centralized topics like monitoring, logging, IaC, CI/CD, and IDP development.
To put it in one Sentence: We stopped being a team of DevOps but focused on having full stack DevOps-Teams.
Speaking of "full stack": we did the same with UX-Design experts.
That sounds great!
I watched this at 1.5×Speed in order to maintain consciousness because the information flow is very slow. I like your presentation very much!
This is a very succinct, fascinating and horrifying view of the experience of the industry’s exposure to DevOps over the past 15 years.
Horrifying because of the speed and agility consultancies and tool vendors were able to corrupt and twist the message of DevOps such that no heed could possibly have been paid to the actual progenitors of the field.
The actual developers of the DevOps way have clearly had effectively zero impact on the industry when compared with the massively corrupting influence of the vendors and “guru’s”.
Not only were you apparently never exposed to actual DevOps, there is still misunderstanding about what DevOps truely espouses.
DevOps would NOT have a bunch of teams dedicated to the infrastructural elements as you have suggested.
DevOps would have delivery teams made up of members of every discipline required to develop software solutions for END CUSTOMERS.
The members of each discipline are more than capable of talking each others language and understanding each other WITHOUT being bundled into a team together. The members of different disciplines are not. That is why we create cross functional teams!
The idea is to destroy the silo’s not simply redraw their boundaries!
And that is all even you have done in your confusion out what DevOps really is.
The destruction of the silo’s was not simply to remove the effect of creating competing KPI’s that cause silo’s to become unhelpful to each other (and indeed outright combative) but just as crucially to remove the intermediaries between the actors of different disciplines trying to work together to create working software.
When you redraw the silos boundaries like you have, even to focus on infrastructural elements to provide to customer facing devs, you are putting those intermediaries back in place but now in the form of a team instead of a whole department.
And they will struggle to provide the customer facing Dev teams what they need because they are no longer USING the software they are providing and they are no longer DOING the job they are providing them to facilitate!
All the internal services, infrastructure etc that the CUSTOMER FACING dev teams need should be created BY THEM in cooperation with each other.
Platform Guilds are a good idea.
Platform teams that are no longer using their platform for the same purpose as their customers is a terrible one.
I feel that we are talking about the same goals but expressing ourselves in a different way.
Almost the same goals.
Goal of breaking down major silo’s yes.
Goal of never EVER building a new one. No.
Just cos you called all your teams Dev doesn’t mean they are all the same capability.
You just changed the silos from function-based to product-based but you still made silo’s with the attendant wait times, service requests and mismatched kpis as the big ones. Except now they are small squads who REALLY cannot service all the requests of the customer facing squads in a timely manor.
As another commenter said: many smaller silos is not better than few big ones.
The people that use the shared tools/services/platforms should be the ones to build them.
Not people in mini-silos that don’t use them to serve the same customers.
All X-func product squads build software for organisations customers.
They also collaborate to create the tools/services/platforms that will help them do this.
No platform team silo.
No security tools team silo.
We (the x-functional product squads) know what we need and we have the skill sets within the squads and the collaborative working practices to work together to create it for ourselves.
Enabling teams with specialist knowledge to help educate/guide us in some areas for limited time? Sure.
Highly Specialist skill set team to do very hard, very specialised work that only needs doing once in a blue moon? Sure.
But damned if I’m going to start having to wait for an even smaller silo to be over worked and under staffed and have kpis that don’t mesh with mine to get a feature added to the platform, tool etc that I need to do my job again. Forget that.
We don’t need you silos group of “platform engineers” to do it for us.
We all know what we need from the platform.
We can build it.
We don’t need your little security tool silo.
We have Greg. He’s a security guy.
And that squad over there has Jane. She’s fire!
They work together on the security tools we both need so they serve us both.
Etc etc etc.
Great explanations as always! 🎉 I’m curious to know which company introduced the term Platform Engineer?
I'm not sure who introduced it :( The term has been with us for a while but only recently became a commonly used one.
The slide explaining "Before Everything" and the slide explaining "IDP" look similar in construction but instead of just an "expert" its teams. The focus now though, as I'm understanding it, is to build a generic PaaS to allow for service consumption. Also, I'm surprised you didn't mention the rise of cloud and SaaS as enablers of platform engineering.
In theory, on-prem users can build an IDP just as Cloud users can. In practice, Cloud users tend to be more agile and open to changes so are more likely to build a good IDP. On top of that, being able to consume SaaS helps a lot. Nevertheless, I wanted to keep it short without diving into on-prem vs Cloud/SaaS debate.
As for the expert... It's one expert in diagrams but it can be (and often is) any number since the goal is to enable teams to be self-sufficient (to do everything alone).
If companies allow each platforms engineer team have their own tools set I think it will works
But then it will create a lot different tools in same layer
It could be go to a situation like this
Team a using AWS
Team b using GCP
Team c using others
What if team a resign and other teams does not have the knowledge
If case is dedicated team to do the job I think it just title a change for many existing Devops
Platforms are technical tools you build through the composition of multiple (software) technologies. DevOps is bigger than any one technology or any group of technologies - it's actually about people, their problems, and managing the lifecycle of the (software) solution. You therefore still need DevOps to build platforms... because a platform is a software solution that delivers software solutions.
What are essential k8s and cloud skills developer of end user apps should have, when he uses internal platforms which hides complexity of operations? Is skill of using concrete platform tools enough? Or whether he/she still should understand how cloud and k8s I working?
I do believe that a certain level of understanding cloud and k8s is a must. Otherwise, the design and code of the app might be done in a way that does not fit into cloud and/or k8s. That does not mean that I expect everyone to know everything about those. That would be impossible.
You put it down very nicely, can you give an actual real-life scenario? of where a Platform Engineer is coming in?
A platform comes in when the company decides to have an IDP to consolidate existing tooling and practices and create new ones.
It was my thoughts for all the last year! You must be stole it! :D
Just kidding, nevermind ;)
I do highly appreciate how you did managed to formalize this simple idea.
Great Job, really!
Guess one more nail in the coffin of DevOps is that everybody are just tired of trying to explain what is the DevOps. The simplicity of the Platform was here on the surface all these times for sure!
However there are small problems with the naming. The Platform itself is an abstract, even prefixed with word Internal it is not really good at sound. At the same time as it is abstraction it can interfere with some other stuff going on in a company.
For instance, there is a team, providing end-users service based on a big data, which were pre-cooked by the teams group, called Platform.
Basically they treat Platform as the data on which they build the service, not the services behind.
I know, I know, it might be a single company or a team problem of meanings, however there's allways be an issue to rename the word, included in every process of development.
What would you recommend in such case when the word is already occupied?
in4: [IDP] must be a logo of initiative to influence people by
I always tend to come up with original names for internal projects instead of using general names adopted by the industry. Call it Gandalf, Unicorn, spiderman, ...
Well done Viktor - difficult subject well handled 👏
Interesting, I’ve called my teams platform or cloud platform for years now. It consisted of SRE’s, SDET’s, CE’s, and SecOps. We followed devops methodologies; always hated the term ‘DevOps Engineers’, doesn’t even make sense.
Explained very well 👏 great motivation 🙂
Very informative video. Thanks. My next question is, for someone that’s a new college graduate, how can they go about getting into platform engineering?
Platforms are valuable mostly to bigger companies. Get a job in one, no matter the position. From there on, you can get in contact with different teams and learn about their needs.
This channel is a gold mine. Thank you.
Man, i was a Sysops when there was no Internet in my country, yes, i was a System Operator handling Bulletin Board Systems (BBS), then i was called System Administrator (SysAdmin) for a couple of data center, a network Engineer in others, System Engineer in other places, Tech Support Manager, IT Manager, Security Engineer, ... and now a DevOps practice lead, but you know what? those have been just professional names in my evolution, I am a Sysops or Sysadmin forever, don't care if this was working in development environments or not, working together as one with dev or not, don't care if you work setting up physical routers, firewalls or cloud system, now Kubernetes, all is part of the same, We are Sysadmins, I consider my self a Sysadmin, one that is experienced and updated, I'm all the Sith.
I was also managing a BBS. Not many even know that such a thing existed.
Behaviour Driven Development should also be considered. Otherwise you will code features not needed or wanted by business.
A helpful read on this is “BDD in Action: Behavior-driven development for the whole software lifecycle” by
John Ferguson Smart
Does that mean that DevSecOps is next to be killed off :) Not as the 'vison' but rather the common process of Dev and Ops teams deciding on the security that should be integrated as it is 'their' job.
Different experts working together will not be killed no matter how we call it.
Platform Engineering is simply a repackaging of DevOps WITH the VISION of a mature DevOps pattern for multi/distributed team engineering efforts. This is for eliciting explicit buy-in from various stakeholders for this vision early in a way that "digital transformation" is rarely able to. Now when someone has some odd idea it gets really easy to point at the vision and elaborate on their misunderstandings.
Practically, DevOps will always be simply the streamlining and optimization of the SDLC and ALM overall, for the maximization of value stream potential. (Potential.) That's all it's ever been, or will be, no matter what DevFooOps comes next.
I would rather say that DevOps is, first and foremost, a cultural change while platform engineering is a clear technical mandate which often enables DevOps (enables teams to be self sufficient).
What do you think about platform engineering on top of public cloud providers like Azure/AWS/GCP? Does this even make sense? I know platform is a big term and a lot of components fall into it, but knowing more and more services on Azure/AWS/GCP are available including monitoring, trending etc. as a service, would mean a DevOps approach with small teams taking care of their own services/applications would make sense again? Would the platform engineering team be the owner of a subscription/tenant on Azure/AWS/GCP? How could other teams contribute? Would the platform engineering team have to keep IaaC open for contribution? Can you maybe provide some key points of tasks the platform engineering team would take car of?
Cheers
The answer depends on a different question. Does it make sense in your case to enable everyone in your company to be self sufficient or you prefer to manage resources for them. In the former cade, IDP makes a lot of sense no matter whetyer your using aws, gcp, azure, or anything else. It is unrealistic to expect everyone to understand VPCs, subnets, and all the other typically low level details. On the other hand, if the model "i will do that for you" works better, than IDP has less of a value.
In general, majority of medium to big size companies are going towards building an IDP because "i will do it for you" does not scale. For smaller companies it is a different situation.
@@DevOpsToolkit that makes perfect sense. thanks for clarifying 💚
As a DevOps Consultant who has been pushing our company to rename and we finally got Platform Engineers greenlit (we wanted Platform Architects but hey ho) I can say DevOps now just makes App Developers throw work over the wall to the point now that DevOps is fast becoming a new form of old style Ops.
The thing is DevOps is a process, not a role, but fast became a role and the industry adopted a name of a culture as a job role as it made recruitment easier.
So I disagree as DevOps is dead as it never should have been a role in the first place and the developers are starting to wake up and say enough is enough.
I think DevOps failed at what it set out to do and so it's natural that it'll evolve into another role.
I am first and foremost a developer but I happen to not be writing application code, but tools, etc. for the platform side of things.
I also spend a lot of my time shifting my work left and getting the application developers to manage and take care of the Terraform and their pipelines too which frees me up to do more work on the platform as a whole, or developer tools.
One important omission here is the stage and size of the company. A three person startup will literally do everything, dev - dev, ops, testing. It's not even a big deal with all the cloud services that make this easy. So that's the "real" DevOps. Also full stack is an unavoidable reality at this stage.
As the company grows and you start to have more customers and staff you may find it saves a lot of money to move more ops stuff in house, or you hit some limits of what the platform you are using can do, so ops becomes a bigger part of someone's job, maybe you call them a DevOps engineer. But still they are in the cross functional team, not a separate team. So still DevOps, but getting less like everyone does everything. Also, hiring full stack people is hard so you are likely hiring other specialist types on the teams.
As you get bigger you may have multiple teams and they all have some of this operations stuff going on and there's a chance to avoid redundant work by forming a platform team that builds shared tools, libraries, and knowledge across teams. That's a sort of refactoring of the teams for efficiency and l but the teams would still have people doing some ops, so teams are doing DevOps.
So platform team is not an alternative to DevOps but it can be a good idea for bigger companies that are doing DevOps to avoid redundant work.
I agree that the benefits of building platforms increase with the size of a company.
"sometimes ...dead is better... " - Pet Cemetary
Diggin the shirt. And great content!
The people promoting the PaaS and Platform Engineering and PlatformOps terms often mention Crossplane as an enabling technology.
I intentionally avoided mentioning tools (including Crossplane) in an attempt to first figure out what it is, and later jump into how to do it.
No, It's just a new name for the same things.
Nobody knows anything anyway.
Should a DevOps engineer also be an SME on how to use the IDP?
I guess that whomever built it is the SME.
Here's a question, then. If I'm a DevOps Engineer, what can I do to help myself evolve & transition into a Platform Engineer?
Pick a set of tools that enable you to build a platform (e.g., Backstage, Crossplane, etc.) and create a system in which experts in your company can contribute their services to that platform. Platform engineers are as much developers as facilitators for other experts to convert their experience into platform components. Depending on the choice of the tools, you'll need to learn specific programming languages (e.g. JavaScript for Backstage). That shouldn't be a problem though since most DevOps Engineers are programmers (that's the Dev in DevOps) and switching from one language to another is typically not a big deal for coders.
@@DevOpsToolkit Beautifuly detailed response, thank you so much. You definitely deserve more subscribers.
I'll start looking for a new job ASAP.
If only DevOps was something that is accepted as something particular. There are still tons of companies who hire people for admin jobs and call it a devops. So I guess, at the end of the day, it doesn't matter how it's called. It's more of a umbrella terms to name stack of technologies combined together and IT crowd hungry for new roles and games to keep IT an interesting place. At least that's how I look at it. I guess I don't care about title and achievements. I just want it to be fun and enjoyable after 2-3 years - if it is, and you keep learning something new - that's a good sign. Also if the pay for it and you can work remotely from any place in this collapsing world - isn't it a dream?
I think that DevOps has at least one big difference to Ops because it allows engineers to get away with writing code and it being seen as part of the job rather than trying to avoid work. It is often hard to get the time to build the underlying structure if you're always doing things by hand.
Doing things by hand works only in very small organizations/systems. It does not scale (without ever increasing the amount of people) so it almost always fails in bigger organizations or results in unbearable cost. That's where DevOps is often beneficial. Even when it's implemented wrongly, it often results at least as a motivation to automate parts of the processes (if not to create self-serve services).
Exactly! As organisations have gotten bigger, and technology/tech solutions more complex, especially with the migration to the cloud, automation has been needed. Having been a NOC staff member, working in a data centre, a decade ago and being told off for trying to be lazy when I suggested all sorts of automation steps , e.g. for delivery of fixes when monitoring identified a fault, the shift in perspective for what Ops are allowed, nay encouraged, to do is incredibly welcome. Now I am running a team where I get to do big design decisions and automate everything that can be, to deliver solutions that allow others to resolve their needs.
Now it is platform engineering. Meaning creating platforms for devop eg among other things, developing IDE for developers. My question is won't platform engineers need collaboration, communication, automation and integration --DEVOP? Given your explanation, I can not see difference between platform engineering and devop. Otherwise, who will provide platforms for platform engineers? So long as the activities of the platform engineers is still going to be software development and IT operations, it is still going to be devop. I think platform engineering is probably another name for devop or at best a subset of devop specifically for the development of IDE.
I tend to distinguish DevOps from Platform Engineering as former being, first and foremost, a cultural change while the latter is a technical role.
As for collaboration... I agree. The platform cannot be built by a single person or a single team (actually, it can, but it shouldn't). It's a colloborative effort where different experts "plug" their services into the platform (IDP). It's OK (and preferable) for one team to own it, but everyone collaborates. That means that Cloud, Kubernetes, security, pipeline, etc. experts are building their services (that can be consumed by others individually) and "plug" them into the IDP so that there is a single platform everyone can use instead of having independent and, often, unrelated services.
Guess which video CZcams autoplayed right after this one?
"DevOps is dead. Embrace platform engineering", you know by who 😅
I can guess :)
I had this contract with a real platform engineer in Mercado Livre company, those guys create a really good platform callas fury that control EVERYTHING!
DevOps is not about any technology or any roles. But unfortunately it made as role and stopped producing values to org. Platform engineering was there as early on as Ops vs Dev time, not named as PE. But it got limelight because of the tools and how infrastructure delivered(Cloud, PaaS) these days and no everyone can understand everything. What I see is old sysadmin/app support skills and roes split into various stream(PE/SRE) and various stage of Software development and make developers to move fast/get feedback. Core of DevOps is still remains the same as how sharing ideas, knowledge and experiences of dev and ops together make the impact for business to deliver values.
Is devops dead? Definitely not! It's like mob mentality if some people think platform engineering is way to go everyone wants it. But the reason is to build platform we need devops/cloud engineers. Now some orgs want less burden of managing this work and here comes new companies like env0 which provides devops self service platform. So you're just using SaaS product to manage company infrastructure rather than managing it by yourself.
IMO:
DevOps is about continues problem solving / debugging / automation and cost/time optimization of processes..
DevOps is dead for engineers that jump on new tech trends and change jobs every 6months from one start up to another (what we call a hitman dev) ...
IDPs (internal development platforms) are just another tool for Dev/QA/Tester/Sec/Ops teams, you need the right tool for the job.
For AWS the AWS Service Catalog for example can be seen as a IDP , is just a way to make things easier but you do not see a new role only bases on this right?
I do not see new roles for anything. All I want is people (call them developers) building services which can be consumable externally or internally.
Amazing video, thanks.
Glad you liked it!
full stack dev = agile team.
Hello, I'm planning to learn devops as non IT guy. Please guide me.
Focus on dev or on ops first.
Devops can't be dead,because whole IT architecture depends on it
Even when I have a DevOps title I still push that DevOps isn’t a role, but a culture. I’m still an App dev on the team, who happens to know all the other parts as well. Maybe with a more personal goal to improve DevOps culture, DX, and dev lifecycle (speed and quality). And the freedom and time to make those changes.
Can a fresher with no experience get into devops? Or is it better to go to development / automation
Development (coding) is the most important and hardest to master skill in our industry. Everything else is easier, so I always recommend the same. Learn to code first.
How do you imagine AI programming and things like ChatGPT will change how we org?
For now, those are more helper tools than anything else. I, for example, use GitHub Copilot all the time. It's suggestions are sometimes spot on, at other times require minor modifications, while, at others, are completely wrong. I cannot imagine accepting its suggestions blindly, just as I would not accept the first result in StackOverflow without validating it first.
So, Copilot and other similar tools (most of them based on OpenAI, including ChatGPT) are helpful but cannot be trusted on face value. That might change in the future and if it does, it will only mean that we (developers) will need to change what and how we do our work (as we constantly do anyways). Neither now not in any forseable future, those tools will replace developers (except those working on trivial code).
i never learned it, so thank goodness
Ah, I'm going to miss the days of being called a DevOps Unicorn 😂
"I need it monitored" --> SRE
same thing different name, and the change is only between companines and responsibilities
😂 loved your dumb down explanation
@5:04 ..when you do ALL of that yourself..sigh..well except the agile coach part lmao
@16:20 stop pubishing mee.. (all me, again)
There are certain advantages being a one-man band.
devops was highly misunderstood anyway, everybody thought it was a role when it was actually a methodology - hence recruiters asked for knowledge in practically everything xD
I am afraid likely a there is darker side of this story. When you call somebody as a platform engineer, implicitly you are saying that person has an engineering degree. However, the trend in IT industry has been vice versa. Could be it be that this is how Academia playing their cards to bring the necessity of paper-certificate ownership? Also what compasses that "platform" is another ambiguity; it could be a ml/ai platform that requires data engineering or it could be a basic k8s platform which by itself is unnecessary as there are fully managed k8s paas out there.
This is an underrated question that should be answered. Over to you experts!
Do not do this to me, i start a Devops Job in January. :D
The akeero is dead, the devops isn’t. 😂😂
Hi Viktor
Hi
ah so totally biased by Akeero paid sponsoring. got it!
Every role will be dead soon, ask ChatGPT. 😁
me: what is the most popular programming language? -> javascript -> learn javascript -> found article that said that javascript is dead -> abandon javascript -> end
No bro ChatGPT improves productivity of programmers it cannott replace programmers.
@@BRSanush let's talk in 2025....
ChatGPT is new google, it cant replace people but would give them better results on questions instead of having 10 different answers , so yes more productivity
@@nikhil2049 you are not able to comprehend the difference between AI engine and search engine...
I'm worried Platform Engineering will be interpreted(much like DevOps) as Ops teams by another name.
Creating software isn't a factory line process where you can stuff code in one side and get built running products out of the end. I think successful Platform Engineering teams going forwards are going to be providing tools to their Application teams and not solutions to them. The distinction being that ultimately the Application teams are responsible fully for their operations and SDLC and not farming part of the process off to another team, but instead being enabled by higher level abstractions than we currently have. It allows them to follow the Agile process while not being burdoned by much of the detailed complexity of infra, monitoring, testing and release engineering.
Well said
This guy : ‘Devops is dead”
*cries in jesbikka voice*😂
What/who is jesbikka?
You are wrong, you need to try job search platform engineers , all results are cloud and DevOps engineers. There is no platform engineers in HR.
I do know that there is a massive demand on the market for DevOps Engineers. What I'm saying is that it's false. That companies missunderstood what DevOps is. A similar situation was happening many times before. There was a huge demand for full-stack engineers until companies realized that it's not a great idea to think that a single person can do all that well. There was crazyness around Agile and there are many other examples. That's how hype curves work. We get to the top of the curve when many missunderstand what's going on but want to be on it, than the curve goes down and gets to realistic expectations and less missunderstanding. It's improvement, but less of it than people think when at the top of the hype curve.
You are, nevertheless, right. If job demand is the measure, DevOps Engineer is currently at the top. It probably overtook "Docker" as the top sought-after technology now that most realized that Docker is not suitable for production.
RIP devs
Salary increase? Ha ha. OK, the video needed some humor.
That might not be true for existing employees but I do think that new offers are giving more for "DevOps Engineer" than "Ops", "Sysadmin", and other ops-related titles.
DevOps is dead, and it is being replaced by people that know how to write code, no matter what subject matter they have an expertise in. Knowing linux systems cannot be an excuse for not knowing how to write code and expose your expertise as an API for your customers (internal or otherwise)
This.
the irony is doing a video sponsor about PaaS at the same time defending devops. you are a comedy hahahha
Another dumb and unusable concept which actually takes turn to what previously was. I work in IT for a long time and I am tired with stupid people who think they are clever and develop dumb concepts. I'm doing many things, I can do many things in IT, and I was always laughing about these all new buzzwords and dumb ideas which seem fresh to someone who just entered IT, but not for someone who seen most of it already ...
As a Devops, first thing to i do is cleaning repo commits and adopt the GIT strategy , enough to get into brawl with devs 😛
This is ITSM, just with new name.
What is ITSM?
Yes, what is ITSM
@@DevOpsToolkit Service now is ITSM tool, where employees can utilize self service platform. e.g One common request between teams is for Cloud resources: a developer needs a fleet of machines to test out a codebase or the IT team in finance has a request for infrastructure to run their new accounting software.
Got it. In that case, ITSM and IDP are similar (if not the same).
I will have to disagree in almost everything after the first half of the video. In my experience, I have never seen someone in DevOps say "you developers should do this" or "you ops guys should do that". DevOps Engineer is a role with real duties, some of them are:
• Create processes and manage the SDLC
• Create automation to implement Continuous Integration & Continuous Delivery
• Solve challenges that come up from the previous point in collaboration with Developers and Operations
• Create, manage and maintain a platform to efficiently manage CI/CD processes (e.g. Jenkins with custom bash scripts, plugins or other automations)
• Incorporate the best security practices according to Security specialists in CI/CD
• Get feedback from developers and testers to build dynamic and reliable test environments and reliable test data
• Get feedback from all the teams to incorporate observability to the CI/CD, from building and packaging, to getting the test results in integration tests
• Build processes and automations for manual or fully automated environment promotion of the current version, based on the feedback from Developers and Business people
So, a DevOps Engineer has real duties and real responsibilities. He works with Developers and Operations to solve problems and create automations.
I would never expect from Developers or Operations to setup CI/CD or configure dynamic environments.
About IDP, this is not a new idea, actually it is the pillar of DevOps. A DevOps Engineer, from day ONE, starts building the CI/CD platform for a company.
What is different now? From monolithic applications we have moved to cloud native applications. A DevOps Engineer has to build a bigger platform, he takes more "developer-like" and more "operations-like" responsibilities. For example, he needs to use Python or Go to build automations maybe on top of Kubernetes, use cloud native tools, expand them, or define networks, ingresses, gateways inside Kubernetes.
So in a nutshell a DevOps continues building the IDP that he was always building. The difference now is that it is bigger. He needs different tools.
People who say that DevOps is just culture, probably have worked in companies that had absolutely no idea what DevOps is.
Finally, I really dislike titles in videos like "DevOps is dead". Most people do not even know the duties of a DevOps Engineer and your definition of a DevOps is totally different than mine. Why even ask if it is dead or not?
I think that your last paragraph is the key. DevOps tends to mean many different things to many different people. You, for example, tie DevOps to CI/CD and that makes a lot of sense. Others, on the other hand, associate it with other areas or practices.
What we probably all agree that it is primarily about removing friction and handovers.
The reason for that title lies in an increased number of people pivoting towards platform engineering as something that replaces DevOps. I think that's wrong. If anything, IDPs enable it.
P.S. By Ops, I meant "everyone but application developers" or "people on the right side of application lifecycle". Since those are many roles, I used "ops" (probably badly, but mentioned a couple of times in the video) as an "umbrella" term meaning "not directly working on the code of end-user applications".
@@DevOpsToolkit
clickbait title for your video though
In practice, yes. The intention, however, was to "mock" titles that seem to be popping up a lot recently, especially from one particular company.