5 ms·
We're seeing similar things at work as the postgres documentation has. We in infra-ops can give you more details about how our database clusters are designed f
by tetha 3y ago
We're seeing similar things at work as the postgres documentation has.
We in infra-ops can give you more details about how our database clusters are designed for resilience, security, safety than you want on more levels than most people in the company know exist. We also have reasoning for all of this available. This is really good to have for customer question sets during sales.
However, this doesn't tell a developer how to connect his spring boot thingy to it, and how to connect and manage his service well. In fact, 80 - 90% or more of the things we know about our database are not relevant to a simple small-scale application running queries on it. And quite a lot of the issues you can have with running your application on a rock-solid database are entirely not relevant at a DBA level. Like, the database doesn't care if your DDL modification is backwards compatible.
And that's something we're currently learning together with a foundation team at work. They are documenting on how to use it well from their side, we're learning about easy mistakes to make and document those, and help with the actionable documentation. And in hard cases we kinda have to talk what's the plan, because it's usually not smart from a DBAs perspective.
- nightpool 3y agoHow many small/new services do you have, and how many developers / teams do you have? If most of your developers are working on "small-scale applications running queries", aren't you just spending a lot of developer time on repeating the same work over and over again?
- burnished 3y agoReusable components and code generation covers this pretty well.
- tetha 3y ago20 - 30 development teams deploying 100 - 150 services in usually multiple stages. About half or a little more are rather new. And we have different angles of approach here. For example, we from infra-ops have setup a bunch of reusable and versioned template modules. These modules encapsulate all of the gritty consul/nomad/certificate handling and someone actually using our databases mostly needs to supply the module with the necessary environment variables their application needs. This in turn has been extended by a bunch of these teams to provide preset templates for spring boot, .Net, python, libpq so most applications just need to configure "I'm springdev and need to go to this database". And currently another team is looking at building our own spring boot seeds, and/or using tools like cookiecutter or backstage to provide skeleton templates including most necessary boilerplate. We've started to maintain a template nomad job for simple applications as well. With these things maturing, getting a simple service stood up can be done fairly rapidly if you know what you're doing. Setup the skeleton, throw out a couple of things you don't need, be done in an hour or so. This however doesn't solve the initial problem. It's still tricky to know how to approach this stack and it takes time to either teach people how to approach this stack, or to condense all of this into simple how-to documents and/or workflows to get systems going.