4 ms·

Hard disagree but Mandy Rice-Davies applies. Some interpretation of DevOps may be BS, e.g. >> Need a database? File a ticket with DevOps. That does seem like

Hard disagree but Mandy Rice-Davies applies. Some interpretation of DevOps may be BS, e.g. >> Need a database? File a ticket with DevOps. That does seem like a bit short of the mark. E.g. that should be automated provisioning in 2018, never mind in 2022. Counter points as to why DevOps is not BS: Today there's just an acceptance that you version your code in VCS, it wasn't always that way. "Hey, this doesn't look right, i know you said you based your change on gui-app.latest-final2.zip but was that Steve or Laura's version of latest-final2?". If you didn't work through this period you'll struggle to believe how common it was for shipping products not to be fully up to date in VCS or not to have VCS at all. DevOps changed this. Continuous integration? No there were people hired as "merge masters" or "build managers", i promise i am not making this up. DevOps changed this, the idea that you wouldn't do at least CI or perhaps CD is unexpected today. Deployment automation? Sure, you email it to the ops team, send a few more emails with attachments late on Friday with ammendments and hope that they deploy the right one. Automated deployment as far as the developer was concerned. The ops person on the other end? Sure they had a batman's belt full of hand crafted tools and scripts but it was definitely pets not the cattle DevOps has made us strive for. Testing automation? The testers sit on level 3 not next to dev on level 4, there's about 4 banks of desks over by the cupboards, that's all the testers. They have lotus notes databases with checkboxes to confirm when they test something. If they find an issue a regression report will arrive with the dev team in under a week. I could go on an on. Platform teams are great when used correctly. You can say something similar about DevOps.

mikkergp 4y ago
>> Need a database? File a ticket with DevOps. > That does seem like a bit short of the mark. E.g. that should be automated provisioning in 2018, never mind in 2022. Serious question, as I think this has been part of my thought process in the challenges of platform engineering: what does it mean to automatically provision a database? I can think of lots of different examples that are insufficient in one way or another (I think I'm mostly talking UX here, and how many questions the user has to answer in one way or another / infrastructure as code, not should the user have to apt-get install postgres, which should I think rather obviously be automated.) But if infrastructure as code is defined as automation, this can conflict with the developers who don't want to learn terraform and thus still leads to "file a ticket with devops"
- deleted 4y ago
  [deleted]
- CraigJPerry 4y ago
  If we’re talking in the context of an organisation which has or is considering having a devops team and / or a platform team, like in the article then yeah i agree you’re not going to be apt installing a db. There will be some mandated platform choices so that the org has a fighting chance of managing complexity and knowledge/skills within the db platform team. I’d expect you’ll have to specify in a web form or maybe an api call that you need a document db / oltp / olap and you want it in region A and of size medium and you want an indefinite expiry date on this lease. I wouldn’t expect to have much more freedom than that, e.g. backups, point in time restore options etc will all be standardised. I’d expect to be immediately given an appropriate pre-built instance that had been provisioned and kept warm waiting for the next request of a db of these specs. That allows the developer minimal friction but also allows the db platform team to say we provision a postgres for document db use cases not a mongodb because it simplifies platform ownership (and we just mail a link to some docs explaining how to use a postgres as a document db to the user account that requested the instance).
l0b0 4y ago
Just some anecdotes around VCS use… At uni back in ~2000 was the first time I ever heard of version control. It was a bit of a curiosity, nobody seemed to be using it. In 2004, engineering at the place I worked (you've heard of it) were developing PL/SQL in production with no VCS. In 2007, I worked in IT at the same place. They were developing in SharePoint without VCS. When I asked if I could use VCS, I was told to use a 1996 or so Visual SourceSafe which was more temperamental than Subversion. The first place I worked that used VCS was in 2008, and only because the devs had started using it against the wishes of the principal developer. The world moves fast and slow at the same time.

mikkergp 4y ago

>> Need a database? File a ticket with DevOps. > That does seem like a bit short of the mark. E.g. that should be automated provisioning in 2018, never mind in 2022. Serious question, as I think this has been part of my thought process in the challenges of platform engineering: what does it mean to automatically provision a database? I can think of lots of different examples that are insufficient in one way or another (I think I'm mostly talking UX here, and how many questions the user has to answer in one way or another / infrastructure as code, not should the user have to apt-get install postgres, which should I think rather obviously be automated.) But if infrastructure as code is defined as automation, this can conflict with the developers who don't want to learn terraform and thus still leads to "file a ticket with devops"

deleted 4y ago
[deleted]
CraigJPerry 4y ago
If we’re talking in the context of an organisation which has or is considering having a devops team and / or a platform team, like in the article then yeah i agree you’re not going to be apt installing a db. There will be some mandated platform choices so that the org has a fighting chance of managing complexity and knowledge/skills within the db platform team. I’d expect you’ll have to specify in a web form or maybe an api call that you need a document db / oltp / olap and you want it in region A and of size medium and you want an indefinite expiry date on this lease. I wouldn’t expect to have much more freedom than that, e.g. backups, point in time restore options etc will all be standardised. I’d expect to be immediately given an appropriate pre-built instance that had been provisioned and kept warm waiting for the next request of a db of these specs. That allows the developer minimal friction but also allows the db platform team to say we provision a postgres for document db use cases not a mongodb because it simplifies platform ownership (and we just mail a link to some docs explaining how to use a postgres as a document db to the user account that requested the instance).

l0b0 4y ago

Just some anecdotes around VCS use… At uni back in ~2000 was the first time I ever heard of version control. It was a bit of a curiosity, nobody seemed to be using it. In 2004, engineering at the place I worked (you've heard of it) were developing PL/SQL in production with no VCS. In 2007, I worked in IT at the same place. They were developing in SharePoint without VCS. When I asked if I could use VCS, I was told to use a 1996 or so Visual SourceSafe which was more temperamental than Subversion. The first place I worked that used VCS was in 2008, and only because the devs had started using it against the wishes of the principal developer. The world moves fast and slow at the same time.