Live data from Hacker News

DevOps didn’t exist when I started as a developer

circleci.com

21–30 of 176 posts

Re: DevOps didn’t exist when I started as a developer

#21
post #7

Sidebar: does anyone else get the feeling that infrastructure as code is just cloud vendor lock-in by another name? Especially since the output of the code ends up being wild unstructured JSON/YAML files with no spec or discernible schema. My favorite is how in the Microsoft toolchain you can build a CI pipeline in a visual UI on the right that automatically updates the YAML file on the left. “We know you don’t want…

How is the opaque visual UI better? IaC doesn't unlock you from a vendor but at least you have a reproducible config file you can check in and version.

Re: DevOps didn’t exist when I started as a developer

#22
post #7

Sidebar: does anyone else get the feeling that infrastructure as code is just cloud vendor lock-in by another name? Especially since the output of the code ends up being wild unstructured JSON/YAML files with no spec or discernible schema. My favorite is how in the Microsoft toolchain you can build a CI pipeline in a visual UI on the right that automatically updates the YAML file on the left. “We know you don’t want…

If you mean in terms on Kubernetes, the idea is identical JSON would work on AWS, GCP, Azure, Digital Ocean. If you want to go cloudless, you can run k8s on your own infrastructure. And if you want to run on your own infra, the need for configuration doesn't go away. Given how open the specification is for the JSON documents, I find it difficulty in characterizing it as lock-in. The configuration JSON is highly reusable in variety of contexts, with the examples I gave above.

Re: DevOps didn’t exist when I started as a developer

#23
post #14

Earlier quoted context omitted.

You might want to look into Terraform [1], which works across multiple cloud vendors, with pluggable open-source "providers" facilitating the communication with the backend cloud platform. [1]: https://www.terraform.io/

Terraform is great but if you want to change to a different cloud provider you pretty much have to rewrite everything

Terraform is okay, if you don't value things like "loops that aren't an awful hack", but in 2019 Pulumi is significantly better and their cloud-agnostic implementation actually kinda works okay.

Re: DevOps didn’t exist when I started as a developer

#24

Personally I think DevOps is like religion. It means whatever someone wants it to mean. Some companies think DevOps means having an automated pipeline for building, testing, and shipping code. Other companies think it means micro-services. Others think it means making developers do DBA / SysAdmin work. All of these things are fine for companies to do. How you run your org is on you. But I wish companies would go deep…

my bar for "DevOps" on my (SaaS) team is that the engineers responsible for the platform the product runs on are involved in the discussions about the product we build.

everything that comes after that: pipelines, testing, release engineering, migrations, post-mortems, whatever -- it's all a result of your infrastructure engineers having a stake in the thing your company is building. I have yet to see a definition of DevOps that invoked some sort of tech stack that made any sense to me. the processes and tools emerge from a cooperation between stakeholders and a shared responsibility for the delivered product.

Re: DevOps didn’t exist when I started as a developer

#25

Generally Ive found tight feedback loops to be incredibly productive. Whether its for product, release, design, development. Having the ability to make modifications with feedback from customers, systems, business partners and colleagues changes everything.

Tight feedback loops is precisely why I dislike the current devops culture.

For me, a tight feedback loop is cycling between repl/ide/compiler/tests as quickly as possible.

A loose feedback loop is pull requests, docker, CI, terraform. Don't get me wrong - I appreciate a fast, smooth 'release' pipeline. I just hate that it's now become the 'development' pipeline.

Re: DevOps didn’t exist when I started as a developer

#26
post #23
post #14

Earlier quoted context omitted.

Terraform is great but if you want to change to a different cloud provider you pretty much have to rewrite everything

Terraform is okay , if you don't value things like "loops that aren't an awful hack", but in 2019 Pulumi is significantly better and their cloud-agnostic implementation actually kinda works okay.

We should make an effort to redefine how we use 'infrastructure-as-code', because right now Pulumi/Troposphere/Azure PowerShell and Ansible/Terraform/etc. are indistinguishable when viewed that way, despite the former being much more useful.

Infrastructure-as-verisonable-flat-configuration-files should not be thought of as infrastructure-as-code.

Re: DevOps didn’t exist when I started as a developer

#27

Personally I think DevOps is like religion. It means whatever someone wants it to mean. Some companies think DevOps means having an automated pipeline for building, testing, and shipping code. Other companies think it means micro-services. Others think it means making developers do DBA / SysAdmin work. All of these things are fine for companies to do. How you run your org is on you. But I wish companies would go deep…

> Some companies think DevOps means having an automated pipeline for building, testing, and shipping code. This seems to be the most common interpretation, but I largely agree with you on no hard and fast rule here.

It's because it ultimately does mean that.

I mean, sure, if we're being pedantic about it, devops is about the silos coming closer together, cross learning, culture and what have you, etc.

But the outcome of that the cross learning is pretty much release engineering, that includes the above and the products giving more data for helping run them, and simplicity leading to being easier to fix, and do the aforementioned things.

I also think we should just get over it and probably just adopt SRE, Release Engineer and Product. Not because I <3 google, just because the split makes a tad bit more sense.

Re: DevOps didn’t exist when I started as a developer

#28
All that’s really happened is that developers have learned or taken on the responsibility to build and deploy to production, and also be knowledgeable and responsible for the development stack, hence “full stack developer”.

Unfortunately, it’s incredibly dangerous if everyone involved doesn’t know what they’re doing.

Then kubernites and docker turn up. To make things easy?

No. They’re making the infrastructure more difficult to manage so that the developers can deploy things easier.

Developers should not be deploying. Large businesses should not be doing very regular deploys to live - it’s simply too risky without a shitload of testing.

Everyone praises startups with a few million customers that are open about their fuckups/downtime, but they are almost always because of their shitty modern deployments and lack of testing.

Crikey, look at Monzo. “We use a shit database and fucked up scaling it, but sorry your transactions failed and you looked like a twat buying your coffee”.

Try and revolutionise industries, fine. But ....

Re: DevOps didn’t exist when I started as a developer

#29
post #9

Lots of things people think of as crucial today didn't exist when I started. And the overall ratio of successful work to unsuccessful work was just as high then as it is now.

But the definition of success evolved as well. Richer experiences are expected.

Re: DevOps didn’t exist when I started as a developer

#30
DevOps is the intersection of three things.

1. Developers learning that running code is not the same thing as reliable code. Certain things must be put in at design time to allow for operations.

2. Operations people supporting development by formalizing/streamlining the deployment process to have changes occur faster, safer, and more often.

3. Aligning goals and attitudes in such a way that prevents conflict between teams. Development doesn't get to shift the costs of outage prone unmaintainable code onto an ops team. Or that ops doesn't roadblock/veto all changes.

In the bad old days, it was common for developers to act with little care for operational outcomes. The responsibility was far removed, and bugfixes didn't win many accolades. Managers want wish fulfillment and pushed developers to toss new features into the mix as fast as possible, resulting in tremendous pressure against ops teams to deploy despite increasingly crufty and debt laden code bases causing unpredictable problems. Ergo, ops teams who blocked all changes for trivial issues because they were judged only based on outages, not feature delivery.

Post reply on HN