Microservices: Get Rid of Your DBA and Send the DB into Burnout
summary
Demo uses Oracle SQL and PL/SQL and the database’s multilingual engine to run JavaScript in the DB and measures CPU and latency when a simple money-transfer is moved from a stored procedure into separate microservices. Measured results show the distributed version is about 6x slower, causes heavy context-switching and database CPU saturation, and forces replication/consistency tradeoffs. A public beta of the DB-side JavaScript is shown working but highlights when moving code out of the DB harms throughput and operational complexity.
AI-written summary · about
chapters (21)
- 0:00Introduction and context
- 1:11Monolithic databases and their issues
- 3:21Dividing databases into microservices
- 5:08Database independence and persistence
- 6:54Backup and replication strategies
- 8:42Stored procedures and complexity
- 10:31Monolithic servers vs microservices
- 12:26Demo introduction
- 15:21Stored procedures in action
- 17:32Context switching and performance
- 20:31Database context and latency
- 23:02JavaScript and database alternatives
- 24:48Demo walkthrough and issues
- 27:05Database burnout and trade-offs
- 28:51Processor efficiency and context
- 29:55Organizational implications
- 31:00Temporal data and persistence
- 32:51Multilingualism in databases
- 34:17Code separation and libraries
- 35:44Processes and cloud servers
- 36:28Conclusion and Q&A
related talks
19mYou’re Doing It All Wrong
57mPersistence layers for microservices – the converged database approach
22mSimplify data and event-driven microservices with Oracle Database
16mSurviving without a database framework
45mDesigning, building, testing and deploying microservices
12mTen Things I Hate About Microservices
44mMicroservices - the lean way (NodeJS)
46mData in a Microservices world from conundrum to options