While developer experience gets a lot of press, there are four stakeholders when you provide a database service. So we can call these DX, UX, MX and OX for developer, user, management and operations experience:
- developers want the DBMS to stay out of their way. Schema is one example because waiting for a schema change gets in the way. Note that NoSQL databases have less schema rather than being schema-less because indexes are schema. I am curious whether less schema leads to a great developer experience in the long run for large scale projects given the risk of an unmanaged schema and poorly understood data. The developers who were able to move fast early in the project can create much tech debt for those who arrive years later.
- users of the services that depend on the database want great QoS - high uptime, low and predictable latency for queries, low chance of lost data. They just want to use your database-backed app without problems.
- management wants to minimize cost while getting great QoS.
- operations wants to be able to sleep when they are oncall (self-healing database, auto failover, etc). It helps if the database isn't in chaos mode during working hours as that gives them freedom to get their work done.
The other stakeholders don't get to choose.
ReplyDeleteIn my context (large company, runs DBMS on prem) they are part of the discussion, it isn't their decision alone.
DeleteA hypothetical example, the growth team decides they want to use MongoDB which isn't on the list of DBMS currently run at scale within the company.
Optional -- everyone currently on the growth team leaves to another project, nobody is willing to join the growth team because this one-off usage of a DBMS is now tech debt.
The growth team is now oncall 24x7 for their use of MongoDB (self-service) because the operations team won't support it -- picking up small, one-off DBMS projects doesn't scale.
Legal tells the growth team the license (AGPL or SSPL) isn't allowed in production. There will be much discussion and there is no guarantee of a good outcome.
Reliability team schedules them for a reliability review to confirm that backups, monitoring, HA, DR, failover (unplanned and scheduled maintenance) are OK.
Security team schedules them for a security review to confirm that things like GDPR, data deletion, monitoring/prevention for access to data and more will be respected.
Growth team has to meet with the budget team to get HW for this. That includes a prediction of HW growth over the next X months.
The DR team begins to meet with them to understand how this new service behaves and can be managed during disasters including how to bring it up and down when resources are limited (cold start at scale is exciting).
There is another context that I never experienced, although sales people would mistakenly assume it was true. That context was "big company == CIO or some VP decides". It was funny to be asked for the contact info of such a decider after saying no thanks to some sales pitch. Funny in part because decisions were pushed down the org chart - it was rarely up to the VP. And funny in part because if there were such a decider, they wouldn't appreciate that I was increasing the amount of email and voice mail spam they received.
Delete