4 ms·

>> 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

>> 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).

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).