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…
DevOps didn’t exist when I started as a developer
21–30 of 176 posts
Re: DevOps didn’t exist when I started as a developer
#22Sidebar: 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…
Re: DevOps didn’t exist when I started as a developer
#23Earlier 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
Re: DevOps didn’t exist when I started as a developer
#24Personally 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…
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
#25Generally 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.
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
#26Earlier 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.
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
#27Personally 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.
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
#28Unfortunately, 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
#29Lots 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.
Re: DevOps didn’t exist when I started as a developer
#301. 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.