Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

DevOps Comes to The Database


Published on

Preetam Jinka's presentation at DevOps Charlotte in February 2018

Published in: Software
  • Be the first to comment

  • Be the first to like this

DevOps Comes to The Database

  1. 1. DevOps comes to the database Preetam Jinka (@PreetamJinka), VividCortex DevOpsDays Charlotte 2018
  2. 2. About me ● Developer at VividCortex. We do database monitoring. ● We’re a small team with a lot of data in MySQL. We have more databases than engineers. ● Our customers have lots of different databases and it’s our responsibility to know what they’re like so we can monitor them.
  3. 3. Why is this topic important?
  4. 4. DevOps comes to the database in two ways Databases are becoming more like applications. Databases are becoming data services.
  5. 5. Databases More Like Applications
  6. 6. Databases are not like applications. Why? ● They’re stateful. ● They’re at the bottom of the tech stack and lots of things depend on them. ● They’re rigid. They don’t change often.
  7. 7. Databases are becoming more like applications. ● They’re still stateful, but we’re getting better at managing that state. ● They’re not usually monoliths at the bottom of the tech stack. ● They’re becoming more flexible.
  8. 8. Let’s talk about my favorite part the application development process.
  9. 9. How applications change over time. ● An application’s code is the result of an empty repository plus a sequence of diffs or commits. ● It’s easy to manage different versions because you can “fork” and create branches of different versions.
  10. 10. How do databases change over time? ● Let’s break things down. ● Consider the simplest database: a log. ● The log records every change that happens to the state (create a table, insert a row, update a row’s column, etc.) ● Querying means reading the entire log to figure out the final state of the database, and then answering questions. ● A database’s state can be a snapshot and a log of changes. Sound familiar?
  11. 11. How do databases change over time? ● A database’s state can be a snapshot and a log of changes. Sound familiar?
  12. 12. Can you fork databases? Yes!
  13. 13. ● Heroku PostgreSQL has had it for a while. ○ Test schema migrations ○ Load test a production database in another environment ● Amazon Aurora recently added fast cloning. ○ Takes advantage of their copy-on-write storage system. ○ “Experiment with and assess the impact of changes, such as schema changes or parameter group changes.” ○ “Perform workload-intensive operations, such as exporting data or running analytical queries” What if you don’t use Heroku PostgreSQL or Aurora? You can still implement this technique! Ability to “fork” databases is gaining popularity
  14. 14. How VividCortex takes advantage of snapshots & logs ● VividCortex uses MySQL for its time series cluster nodes. ● Each node has a consumer that reads from a Kafka log and inserts data into its local MySQL. ● Backups are done using AMI snapshots. ● This snapshotting and cloning idea was unimaginable before we had Kafka. Everything is easier now! MySQL Kafka MySQL
  15. 15. New Relic uses this technique too… with containers. Each container image has a script that checks for existing data on the underlying volume when the container starts. If the script finds no data, it pulls down a consistent snapshot from another running instance to bootstrap replication. —
  16. 16. Databases can get “more stateless” this way.
  17. 17. Giant, monolithic databases are less common ● Lots of companies and projects have tens or hundreds of databases. ● Polyglot persistence means there are lots of different kinds of databases too. ○ Use the right tool for the job. A single type of database may not be the most efficient. ● Benefits: deploy, manage, and scale more effectively.
  18. 18. That was all operational stuff. What about stuff developers care about?
  19. 19. ● NoSQL started a trend of giving developers more control. ○ DevOps started around 2008. NoSQL reintroduced in 2009. ● We have more kinds of databases now. ● Existing databases are getting features that benefit developers too. ○ Like JSON support. Developers don’t have to wait for schema migrations. Ship faster! Databases are getting more flexible
  20. 20. Databases To Data Services
  21. 21. Databases at VividCortex We use MySQL. Lots of MySQL. ● Customers database ⨉ 1 ● Environment shard databases x <10 ● Time series cluster directory ⨉ 3 ● Time series cluster nodes x >10 We’re not concerned about any single database instance.
  22. 22. Databases to data services ● As a developer, I don’t really care about the health or activity of any one particular database instance. My applications still work. ● Work centric approach: is work getting done?
  23. 23. Service level objectives (SLOs) ● High-level web services and APIs have SLOs around latency and availability ○ Ex: GET /api/v1/users should have an average latency of 10 ms ● Low-level services like EBS on AWS (gp2 volumes have 99% performance SLO, io1 have 99.9%) What about databases?
  24. 24. Database monitoring is changing.
  25. 25. “Serverless” databases are already services ● DynamoDB users probably already think about their database as a data service. ● What about MySQL users thinking about Aurora? ○ It now supports autoscaling. ○ Serverless Aurora is coming too. ○ What will they do differently?
  26. 26. What’s next? Things are changing all the time, and we’re still learning.
  27. 27. Thank you! I’m on Twitter! @PreetamJinka Check out our database monitoring!