Hacker News Reader

Comment by LaserToy | Hacker News Reader

I always thought that DevOps are developers who can do ops. But in recent years I see more and more people calling themselves DevOps, even all they do is ops with simple scripting.

I think we need a new name for developers who run their code in prod, as DevOps is diluted.

So, I’m this light name of the article is utter BS. As devs we deal with a lot of different databases, be is SQL, NO SQL or graph and dealing with them is part of our job. If all you do is run stuff and release - you don’t have Dec component, so you just Ops.

View on HN

I have been doing DevOps since before it had a name.

Been running on AWS for the better part of 8 years now and running multiple production environments for clients and as an employee.

Over the years, I have seen the term "DevOps" slapped on so many things I don't even know what it means anymore.

For some, it's a culture, for some, it's a team, for some, it's a role.

SRE is now getting the same treatment. No idea what it means most of the time.

IMO, the only places where it's done successfully view it as a culture and neither of the other two.

That said, the easiest way to make yourself more 'in-demand' right now is to make it your title.

As someone who does ops and development, when I look around in the market and see companies hiring full time devops roles, I usually see big red flags. The only jobs that I tend to want lately are on development side at small companies or the operations side at larger ones.

I tend to see Dev ops as mostly ops but a background in dev. They can step in and understand the development environment, but generally they are going to make life easier for the devs. it's an important role, but having some developer background is nice while they kick ass getting things done. Your standard sys admin will do the job but generally get a big eyes look on their face when you ask about something outside of their wheelhouse.

Most of the time I see the word people are talking about deployment automations. But DepAuts doesn't sound as good.

A person who specializes in deployment automation, a company that has a culture in investing in deployment, a team that specializes in deployment automations.

Deployment automation is an engineering task that can be designed, implemented, deployed by an engineering team. It could be an internal Software Delivery product

Yup, our ops call themselves DevOps and SREs in the same meeting, not doing any of it.

I agree that DevOps becoming a job title is a perversion of the term. That applies equally to an operator or a developer calling themselves "DevOps".

As the article mentions, DevOps is a methodology. To quote the author, "The most concise definition of DevOps is that it is applying agile/lean methods from source code all the way to production."

There is, of course, a mirror of the situation you're describing. With people that are relatively competent developers "also doing Ops", but doing it badly.

The article is a description of how to make schema changes less painful and less risky.

How is your comment relevant to that?

I have a problem with the title. They could’ve named it: SLQ schema management.

Dev that do Ops is usually a terrible idea.

It depends on the person and mindset.

I switched from dev to ops fulltime (as in not "DevOps") and I'm perfectly at home here. If anything, I'm the one bridging the gap between us and the development teams. My team thinks I'm an ops person who does development, but I don't really find that to be true.

Why do you say that?

I've worked at a couple places that had developers build their own environments before I got there (I'm more of a systems engineer).

There was no thought to high availability, security, scalability, reliable backups, etc.

I'm not saying all devs are like this, but that's just been my experience.

This. Honestly Ops is a different mindset that devs, the tldr version is devs don't really know / care about running things in production. I don't blame them it's just different set of skills.

> devs don't really know / care about running things in production

I disagree with this entirely. Devs _you have workd with_ might not have cared but it doesn't make the statement universally true. As a counter argument, some of the best software developers I've worked with were also very good at operating and debugging production software and the reverse has also been true.

I also don't buy that the two are a different mindset (at least in the domains I work in and care about). In my experience the very best people (whether they're working "dev" or "ops" roles or something in the middle care about the entire development and deployment lifecycle of the software they work on. Building a good experience in software includes thinking about reliability and availability and planning a reliable and performant deployment also requires that to be thought of in the application layer at some point.

A developer who does not know/care about running things in production is not a developer. These are not different skills. Security, high availability, reliability, these are concepts that hold as much weight at the application side as they do on the systems side. Two sides to the same coin.

> A developer who does not know/care about running things in production is not a developer.

Behaviour depends on how incentives and constraints are structured.

Traditionally, operations had to keep things running and cared little about new functionality. Developers had to deliver new functionality and cared little about keeping things running.

Requiring developers attend 3am outage calls changes incentives, as does requiring operations to own (or get out of the way of) software delivery pipelines.

Reply on news.ycombinator.com