8 ms·
DevOps is dead. But what will replace it?
- aksss 5y agoSo.. serverless apps will not require managing tons of vms and containers, so devops workload reduces 80%? Am I comprehending point? And prognosis is serverless apps will dominate? I mean, in my small world of using azure app services, azure functions and CI/CD, that makes sense. I work on relatively small and tailored solutions though.
- maccard 5y agoI'm in the process of migrating a handful of small internal systems from azure to AWS - azure is miles ahead in this regard so you're likely looking at it from the perspective of someone using the best tooling available. Setting up Azure Container Instances, or even Azure webapp compared to fargate/elastic beanstalk is just night and day
- afrodc_ 5y agoThis post doesn't really say anything and hand waves over a lot of the complexities of real world deployment and operations that isn't a simple stateless hello world web application.
- nosvince 5y agoI don't think the point of the article was to say technically how to automate everything. But rather that the tools to automate are coming and that we should be on the lookout and ready when they come.
- Animats 5y agoWhat will replace it? 996.
- redis_mlc 5y ago- DevOps originally was supposed to eliminate Operations (Sysadmin) staff by involving Dev with the Infra and Release process. - But Dev is incentivized to create features, not know the intricacies of Release at scale, so dedicated Devops (Operations) teams were again staffed - dedicated DevOps teams are here to stay except in certain unique scenarios. For example, I've seen some Indian-led SV startups that hate Operations staff ("oh, they're overhead") carefully design their production environment around using services that don't need mgmt. (DynamoDB, Lambda, etc.), and that will work up to a certain scale. However, every time they have a problem with AWS, onboarding, security, excessive on-call rotations, etc. their developers have to be ready to become the DevOps they so despise, reducing the number of featueres they can build. - in larger companies, Devs don't have access to production, so again dedicated DevOps teams are needed if only to enforce policy.
- detaro 5y ago> DevOps originally was supposed to eliminate Operations (Sysadmin) staff It wasn't. It was supposed to break down the model of Dev and Ops being separate silos that don't work together well and don't understand/respect each others concerns.
- redis_mlc 5y agoSo ... as I said, an attempt to eliminate Operations (nobody is firing their devs, who create features.)
- imperialdrive 5y agoThis aligns with some of my experience. Btw, your comment appeared 'dead' to me which didn't make sense... I learned about the ability to 'vouch' for the first time. Great feature. HN truly is a well evolved platform. Kudos to all roles for providing this service, visited and valued by so many wonderful geeks. Ty!
- dkdk8283 5y agoI think devops will always be needed in some incarnation for companies that are subject to SOX and SoD.
- wildrhythms 5y ago"Automation killed ______! Invest in automation." -Company openly selling automation product
- davidjytang 5y agoSuch a clickbait title.
- nunodio 5y agoShould we rely on an article written by someone who says "...DevOps team..." ?
- nosvince 5y agoI get where you're coming from, but that is the reality in quite a few medium/large companies I've collaborated with over the years.
- nineteen999 5y agoWait a minute, wasn't devops supposed to replace regular ops and system admins?
- loopz 5y agoDevOps is about sharing common goals and working towards them in collaboration. It's not a role, not a team and not tools.
- nineteen999 5y agoI've worked in devops roles so I don't really need (or agree) with your description. Thanks anyway.
- loopz 5y agoDid you implement a devops culture of cross-function collaboration?
- nineteen999 5y agoKevin, is that you?
- bsaul 5y agoi think there's a clash of definition in that thread. Devops originaly was a job title for sysadmins with high automation skills and able to deploy to a cloud. it later evolved to something much more management related.
- loopz 5y agoDepends who you ask. Everyone seems to invent the definition that local-optimize for themselves. The book Good To Great goes into the dynamics, outside of IT, so is a general pattern.
- Annatar 5y ago
- xrayarx 5y agoNo full author name in the article, nonsense article.
- dkdk8283 5y agoComment makes me think real names are required for credibility. In these times posting as a moniker is more important than ever given the low bar for termination in today’s culture. Lack of a name means absolutely nothing IMO.
- mhoad 5y agoThis is a garbage quality post but the underlying premise I think is fair. I’ve heard much more reputable people like Kelsey Hightower make similar claims recently. Just as a matter of personal interest I spent the last year looking into the question of how close could a small and possibly even competent one person team get to doing “cloud native” “best practices” from day one if they made the right choices. My assessment is that, we as an industry are right now, entering an interesting stage where this is starting to look vaguely possible thanks to some recent offerings. Running Kubernetes for example has in just the past couple of months potentially become a genuinely hands off exercise thanks to GKE Autopilot where you can just throw containers at it and it will just work and do the right thing by default. Granted this is only one part of the problem however. The other super powerful component of K8s however is it’s idea of a reconciliation loop. People are starting to see this as not JUST a tool for managing application lifecycles and scaling but now as one of the key new primitives in automation. If you can specify: 1. The current state of a system. 2. What code needs to be run in order to transition from one state of a system to another Then you can create a custom resource definition in order to manage that for you. This is where you’re starting to see a lot of interesting new things emerge. For example while tools like Terraform are great to setup infrastructure they don’t have a solution for say when someone starts manually adding, removing or otherwise configuring your infrastructure outside of it. That’s a great example of a problem that can now just go away and this is where you’re seeing a new generation of tools emerge in that space like Crossplane. Now I can not only specify my infrastructure as code, have everything go through a gitops style workflow but I can also rest assured that I won’t ever have a configuration drift problem again. Other cool areas I’ve noticed emerging at the application development level include projects like Dapr which is one of the best things to come out of Microsoft in years I think. But for those who are unfamiliar with it their promise is again built on top of Kubernetes custom resource definitions and says here is a single standard API which you can use and we will do pretty much any task relevant to distributed applications for you using best practices and you never have to think about it or touch it. So this means I as a developer or an operator am no longer thinking about things like service discovery or having to set up read replica databases anymore etc. Finally, one more piece of the puzzle I’m excited about is a project called “open application model” which once again is built on top of custom resource definitions and let’s me as a developer to just specify my various applications as common components and traits I.e this is a service and it should be available to the outside world. With that information it has everything it needs to once again just go and do the right thing and I never need to think about it again. Basically, I agree with what is said here even if it’s poorly written. I don’t think right now is necessarily a great time to go and become a Kubernetes expert because the need for them is likely to become much smaller in the future as organisations instead move to various standards that CAN be automated in predictable and reliable ways. P.S Open policy agent is another powerful abstraction that plays a key part here that I haven’t mentioned. But this is a great place to put all of the logic that defines “what is the right thing to do (especially if it is specific to my business)” and the rest of the tools I’ve mentioned here can use that. But normally coding this stuff manually at scale across distributed systems would have become a nightmare.
- PostThisTooFast 5y agoWhatever "DevOps" is...
- Miiko 5y agoCould anybody explain what's the point of using 50% gray for main text font? Does it really look good to somebody besides the designer?
- karmakaze 5y ago> [...] DevOps is dead; the amount of DevOps engineers [...] Post misses the point of DevOps--there aren't DevOps engineers, there are engineers that do their own devops.
- nodejs_rulez_1 5y agoI waited and learned it for a bit but nobody seems to be raising salaries for me to know that crap in addition to other full-stack stuff, so NO, there are DevOps engineers and they get good money for me not to deal with that garbage for essentially free.
- snuxoll 5y agoAye, none of the devs on my team want to deal with infrastructure - they want to push their code and have it go to production. I deal with all that garbage so they don’t have to. I think the title “DevOps Engineer” is a bit of a misnomer, though; my team as a whole does DevOps, I build and maintain the platform.
- karmakaze 5y agoI think team members do varying amount of DevOps but everyone should be involved. When writing code thinking about observability and monitoring, watching deploys as they go out, checking back on things randomly or intermittently whenever there's an inkling to do so, etc.
- ram_rar 5y agoIts a very poorly written article with all the buzzwords one can think of. DevOps is not even remotely close to dead, but rather evolved a lot. Gone are the days, when one could easily ssh into remote prod systems and fix the issue. With shell less Docker images and container orchestration tools (hashicorp stack), CI/CD pipelines, blue-green deployments etc, Devops has become a lot more sophisticated than before.
- hutrdvnj 5y ago> Gone are the days, when one could easily ssh into remote prod systems and fix the issue. With shell less Docker... I think we finally realized that fixing something in prod via ssh is not a good solution and might introduce new bugs on its own. Rather build an infrastructure that allows you to rollback fast. It is also not worth to fix individual machines in a big cluster, just throw them away and bootstrap them from zero. This way you make sure that you don't have accumulated patches and workarounds on your nodes that might lead to future failures. In some companies we reached the point where you don't even fix a cluster in a multi-cluster setup, but throw away the whole damn thing and bootstrap it from zero.
- peakaboo 5y agoYou say sophisticated but in reality, it has become extreamly complex, which is a natural consequence of using tons of different tools and glueing them together.
- nosvince 5y agoAnd that's why there's room for automation to take a lot of the complexity away. Granted it's not going to be easy to have a platform where every tool can seamlessly connect, but we can start with baby steps such as services that automate multi-cloud deployments like the article suggests.
- cdisnow 5y ago> Its a very poorly written article with all the buzzwords one can think of. Agreed. Reminds me of articles and blogs that GitLab team publishes these days.
- MattGaiser 5y agoWouldn't the devops guy just be the person to handles the setup of all that automation? That is what devops is at my company.
- sgt101 5y agoWait, what? Devops is all about building and using automation to enable many rapid releases!
- deleted 5y ago[deleted]
- jpswade 5y agoHere we go again. The view in this article is that DevOps is a role, it was never meant to be this way. The whole purpose of DevOps was to break down barriers between Dev and Ops, by not creating specialist roles and allowing developers to take ownership of ops, removing the need for the SysAdmin gates. Instead what this article highlights is that we’ve moved the complexity to specialist tools which require another specialist role. I would say this suggests you’re solving the wrong problem.
- benjaminwootton 5y agoI’ve never really gotten this argument. People can go really deep on Terraform, Cloud Automation, CI/CD, containerisation etc without being developers or sysadmins. “DevOps Engineer” fits that role perfectly in spite of the breaking-down-siloes goodness.
- jpswade 5y agoThe DevOps tool chain has become so complex that it requires specialist roles that create knowledge silos. The goal of DevOps was to remove those gates and silos. It was meant to be about skills over roles. All we appear to have done is change the tools and role from that of a SysAdmin to DevOps engineer.
- zarzavat 5y agoThis is just the same as when people complain that computers are getting slower even though the hardware is faster. Software complexity expands to fill available resources. Only, in this case the available resources are manpower rather than hardware.
- igetspam 5y agoThen you're doing it wrong. My teams have two components that require review from a specific group: 1. Core infra 2. Anything related to security Outside of those, we all can and do work on everything else. We regularly coach people in terraform and third party APIs to endure they understand that they own their application lifecycle. They control the entire SDLC and we work together to ensure sanity. There are lots of bumps but nobody gets a pass on understanding the in and outs of software development and management. I can't see a cloud based offering being successful without that.
- benjaminwootton 5y agoWe are getting more and more servers, more containers, more complex, dynamic infrastructure, more API driven infrastructure etc. All of this is driven with automation created by DevOps engineers. In addition, there is an absolute mountain of old stuff to modernise and automate. DevOps is going nowhere. It’s day 1.
- nlstitch 5y agoThis article is absolute BS. Multi-tenant, blue green deploys, infrastructure as code.. There are layers and layers of new tools and vendor specific infra required for the cloud. Previously I just needed a server, a git repo and a jenkins job.. now I need 4 services with different apis, roles, rights, a jenkins job and 3 different templating languages like terraform or ansible. No software engineer is going to want to do ALL of that, and if you do.. you should be scratching your head if you're really developing actually business value rather than castles in the sky. Its nice to have new toys.. but if customers are still calling your colleages that crucial things like invoicing or ordering is still broken.. than there is no way to justify weeks of research and development on ops tools before solving athe actual problem ( which would just take hours previously.) So yeah, we actually need more devops people if we really want to keep those new services so that software engineers can actually keep engineering software itself, else everything slows down.
- bobbydreamer 5y agoNo. DevOps will stay and there will be SREs as well and there will be a hybrid of this combination as well DevOps actually didn't break the barriers at all. It just created more roles inbetween Developers, testers and operations and brought in more tools. So people in operations are asked to use the Devops tools as organization has already bought it.