Live data from Hacker News

DevOps is broken

blog.massdriver.cloud

341–350 of 363 posts

Re: DevOps is broken

#341
post #340

Earlier quoted context omitted.

Roles are muddy because life is muddy...and because people can do more than one thing at a time. Also because save for a few roles, businesses rarely need people 100% allocated to one role or task. Responsibilities are nice, and job titles mean people mostly do x or y. My favorite example is that of a restaurant. You hire waitors, diswashers, bartenders, line cooks, prep cooks, hosts and hostesses, and managers. And…

Communication with the other roles you work with is key though in that case, otherwise you'll have chaos - e.g. because the waiters don't know that the bartender took the table, or because the cooks need things the next morning that aren't where they're supposed to be.

Exactly.

You wouldn’t expect a bartender to table every person, prepare all their drinks, cook all their food and clean up their table.

But that’s kind of what we keep trying to do, because we have new bartending tools that make it so that you need fewer and because we claim communication is harder than doing everything in one role.

Then when that person invariably gets overloaded; we hire more bartenders and complain they’re not good enough at cooking your specific dish.

Re: DevOps is broken

#342
post #232
post #17

I’ve long held this opinion but I consistently get drowned out. DevOps has different meaning depending on who you’re talking to, even some definitions that appear similar are different in nuanced but important ways. All “devops” as a job title has done has muddy responsibilities and given many folks the wrong impression of what an operations discipline should be. There is also a lot of rewriting of history that gets…

Do those different breeds of engineers work in one team or in separate organizational branches? The problem the term 'devops' is addressing, the way I understand it, isn't that of insufficient individual jack-of-tradesness, but that of too much separation between (internal) organisations. It should be perfectly possible to build a "devops" team from deeply specialized experts and turning it into a job description see…

> Do those different breeds of engineers work in one team or in separate organizational branches?

It doesn’t matter as long as communication is open.

Proper ops is all about reducing the bus factor. Procedures don’t depend on people, they depend on being good at communicating.

If your ops person got hit by a car, I would expect that everything would continue running, I would also expect to find some clear documentation, this is mandatory.

Re: DevOps is broken

#343

Earlier quoted context omitted.

What's "capitalism" in this context, and what's its actual connection to software development practices? What are "forms of efficiency" and "forms of value", and how does complexity "unlock" them?

Capitalism is a company that is attempting to solve X problem or do Y thing etc. Forms of efficiency are "how fast can they solve that problem". And complexity doesn't unlock anything. It's just inherent in the problem space a company takes on.

>Capitalism is a company that is attempting to solve X problem or do Y thing etc

So basically any organized human activity is now "capitalism"?

>Forms of efficiency are "how fast can they solve that problem"

From which follows that "new forms of efficiency" means that previously it didn't matter how fast they can solve that problem, but now, due to "moving further out on the software complexity curve", it has begun to matter?

>And complexity doesn't unlock anything.

Then what is meant by "moving further out on the software complexity curve unlocks new forms of efficiency"?

Re: DevOps is broken

#344

Earlier quoted context omitted.

> Data sovereignty per microservice > An important rule for microservices architecture is that each microservice must own its domain data and logic . Just as a full application owns its logic and data, so must each microservice own its logic and data under an autonomous lifecycle, with independent deployment per microservice. https://learn.microsoft.com/en-us/dotnet/architecture/micros...

The big issue I've seen is that takes a lot of work, so people cut corners. The problem is of course when you cut corners with microservices and rely on a shared database for instance, suddenly you're dealing with 40% of the costs of a microservices and 0% of the benefits.

That's completely untrue and glosses over the very real costs of transaction management in such an environment.

Using a shared database allows you to punt a lot of that complexity to a system that's been specifically designed for it, and working well for probably 20+ years.

Too many people think microservices don't have their own, severe, downsides. The likes of netflix, google, et al, can afford to pay people whose entire job is to manage the complexities of these approaches that flat don't exist in other scenarios.

But it's a hell of a lot simpler to use a single database if you can get away with it.

Re: DevOps is broken

#345

Earlier quoted context omitted.

Back when I was in the real world [1] working for a startup, I would do your typical serviceless solution with Lambdas, S3,SQS, etc. I couldn’t just use ClickOps and create everything on the console and expect someone else to recreate everything with IAC. I had to know how to do it. I think to push back is rightfully coming from the “ops” part. I consider “creating the CloudFormation/CDK/Terraform” code as part of “d…

> I think to push back is rightfully coming from the “ops” part. I consider “creating the CloudFormation/CDK/Terraform” code as part of “development” as part of coding. > If you use Docker, wouldn’t you consider creating the Dockerfile as part of development? Sure you could argue a developer could, or even should create these things in theory. The problem is then when it goes down I have made two problems out of one.…

So if I need to create a bunch of Lambdas, queues, sns topics a few dynamodb tables an S3 bucket, etc and tie it all together, are you proposing that the developer should just create everything in the console and then call over someone else to go behind me and write the infrastructure as code?

Re: DevOps is broken

#346
post #298

I disagree. DevOps was intended to break the organizational mindset of having this group of people here doing this set of activities and this other group of people over there doing that set of activities when in reality both groups of people are needed to work together and deploy software. It was about breaking down those organizational silos. Anybody creating a dedicated "DevOps" team was way off the mark, unless th…

I think that was not mentality. Maybe after years of working that way it turned out into mentality. That was employee utilization approach where you hire 1 DBA and he runs all DB stuff because hiring DBA for each team does not make financially sense as there is not enough day to day work for DBA specialist on a project/product. Other stuff is that DBA/SysAdmins have to have access to customer - company data so you st…

Good things happen when developers are involved in Ops. Most developers would prefer to develop and not focus so much on Ops, and so they take the steps to automate the Ops as much as possible and essentially make the problem go away. Dedicated Ops staff won't do that because that would put them out of work.

Re: DevOps is broken

#348

Earlier quoted context omitted.

I think everyone can agree that for most complicated things there are many sides to a story that makes up the present state of the system. I think taking a very opinionated stand in any complicated subject by itself negates the possibility of a mature and complete analysis of any subject. So the title itself of this article is unfortunate.

Shouldn't a mature and complete analysis result in a conclusion, i.e. an opinionated stand backed up by correct reasoning?

Yes it should result in a conclusion but the conclusion should not simplify it in a way that the true nature of the issue is lost.

Re: DevOps is broken

#349

Earlier quoted context omitted.

It is a scam. It should absolutely be assumed that you could perform these job functions - it makes you a way better engineer! But being expected to is a scam because the skill ceiling on each is so amazingly high that only a scam artist would expect someone to be able to perform all three to a specialist level. The same issue happened when QA departments got the boot. I deeply understand testing strategies (both man…

I perform all three roles for one company. I agreed to it upfront. I do it in less than 40 hours a week at a very respectable salary. I get maybe 1 after hours call a year for an Ops task. My boss knows that I won't do QA or Ops nearly as well as I do Dev, and he knows that QA and Ops time come out of Dev time (not personal time) and he's okay with that because that's the stage we're in. If you think that is a scam,…

I do. Ask for more money.

Re: DevOps is broken

#350

> The problem is most engineers don’t want to do operations work. There's your problem. You have people who build stuff without caring where and how it runs. Recipe for disaster.

I don't understand. I want to develop code. I don't want to become an AWS/S3/Github/Jenkins/Action/terraform/etc expert. I know enough of this to be dangerous but not at a level that passes as professional. Yet I am regularly tasked with maintaining the full deployment of code. There's a reason to have a team of people doing this "DevOps" work. Just like we have a team of people who do SRE. It creates a standard and…

That's like saying that you want to develop code but you don't want to use computers. It's part of the job. Maybe try mobile app development instead?
Post reply on HN