Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Big DevOps Misunderstanding

wolfoliver.medium.com

Post reply on HN
Print view View original

31–40 of 321 posts

Re: The Big DevOps Misunderstanding

#31

Post by cortesoft »

kqr wrote: post #22
cortesoft wrote: post #17

As someone who has lead a devops team, and still has a devops team reporting to me, I have also struggled with the idea of having a team called devops, since it does go against the devops philosophy of devs owning their software in production. However, in our case (and probably many others), our devops team is responsible for creating and maintaining the tools and processes that allow the dev teams to manage their sy…

This describes what I've heard referred to as an internal platform team.

Yeah, that might be a more accurate title at this point.

Part of the reason that the name DevOps was chosen almost 10 years ago when it was started was to help signal to the wider org the cultural shift we were undertaking, and that the expectation was going to be for devs to own their systems all the way through production.

At this point, we would probably change the name, but the team is quite attached to the name after 10 years. We actually did try to rename the team, but everyone still called it the devops team and we gave up on the change.

Re: The Big DevOps Misunderstanding

#32

Post by avip »

Personally I think it's pretty great that I can write Dockerfiles, run them locally, and call it the day because this is also what runs in production.

So basically I have no clue what the dude is talking about - we have a great setup which is x10 better than what we had before.

No?

Re: The Big DevOps Misunderstanding

#33

Post by 988747 »

mrweasel wrote: post #15

> You build it, you run it While I do like that definition, it also means that most companies/organisation cannot do DevOps, as software development is often bought as projects, and operations is a recurring cost.

Also, government regulations such as HIPAA explicitily force you to have separation of duties, so true DevOps is against them. Developer being able to push their code to production can earn you some hefty fine at the next audit.

Re: The Big DevOps Misunderstanding

#34

Post by d0mine »

mrweasel wrote: post #15

> You build it, you run it While I do like that definition, it also means that most companies/organisation cannot do DevOps, as software development is often bought as projects, and operations is a recurring cost.

Software is never done. It can only be abandoned.

There are projects that change slowly but they do change nonetheless unless they are no longer used.

Re: The Big DevOps Misunderstanding

#36

Post by KaiserPro »

I did not entirely agree with the main assertion of the post. However having re-read it, I do now broadly agree.

I would say that devops _should_ be a spectrum. I have always worked at places that never really had rigid boundaries between sysadmin and dev. So I was really quite baffled by the initial push to devops (Isn't that what you were doing before? How can you be a sysadmin if you can't code.)

Having a department of devops is fine, so long as most of them are embedded into dev teams. Assuming you rotate your devops around dev teams, its a good way to remove single persons of failure, and increase standardisation. Depending on size, there might be a chance to have a core systems/platform team.

Re: The Big DevOps Misunderstanding

#37

Post by safeerm »

Really great post. When I was at AWS, we did everything with IaC but that luxury of time and investment is not avail to many. We're working on this problem but ensuring that devs has a) full transparency what's going on, b) ability to evolve their arch and c) building right on your AWS account. We just moved someone from Heroku to AWS handling 1B requests/day at 1/4 of the cost.

have a bunch of AWS execs backing us too; they know this is a problem. Happy to chat more if you want to give it a spin: tinystacks.com

Re: The Big DevOps Misunderstanding

#38

Post by Spooky23 »

cortesoft wrote: post #17

As someone who has lead a devops team, and still has a devops team reporting to me, I have also struggled with the idea of having a team called devops, since it does go against the devops philosophy of devs owning their software in production. However, in our case (and probably many others), our devops team is responsible for creating and maintaining the tools and processes that allow the dev teams to manage their sy…

The problem with philosophy is that reality has a way of getting in the way.

Think of home improvement. If my toilet is clogged, it doesn’t make sense for most people to call a plumber. That doesn’t mean that plumbers are bad, just that it’s easy for a generalist to do basic tasks.

Likewise “pure” devops rarely makes sense because developers are assigned to projects that end, and sustainment doesn’t require the same skills. It’s cheaper to pay for 20% of a $75/hr ops engineer than 100% of a $150/hr senior dev.

Re: The Big DevOps Misunderstanding

#39

Post by jollybean »

When the cloud was young, devs could indeed push their own code. They didn't need the sysops people. It was a major change.

But as the cloud became more complex, invariably, SysOps just took on a whole new shape. Instead of buying hardware and keeping Ethernet boxes wired and alive, you now have K8s etc..

I suggest we have failed somewhere along the way: it shouldn't be necessary for real DevOps up to significant scale.

If our tooling were good enough, it should be mostly fairly automated.

'Containers' seem to be a messy, hacky afterthought when what we really probably just needed was 'configs'. Cloud Lambdas, Queing, Caching, Logging could be feasibly made very simply configed ... on all the Cloud Providers it's fairly complicated, just beyond the ability for a regular dev to stay on top of along with the rest of dev stuff.

Re: The Big DevOps Misunderstanding

#40

Post by hodgesrm »

> This trend is also supported by Kubernetes as this is a technology which is hard to master. So people start splitting up responsibilities again. One part of the team developing the application the other part of the team managing the infrastructure.

Kubernetes administration is hard to master. It's analogous to running VMware in production, or any cloud technology for that matter. None of them is easy, and they all require relatively specialized knowledge.

Kubernetes development on the other hand is relatively straightforward. Minikube is my goto environment whenever I have to put together an app that consists of more than a single process. As long as you pay reasonable attention it is not hard to move such applications from dev to staging to production.

Edit: fixed markup

Post reply on HN