MongoDB Shootout: MongoDB Atlas, Azure Cosmos DB and Doing It Yourself

Transcription

1 MongoDB Shootout: MongoDB Atlas, Azure Cosmos DB and Doing It Yourself

2 Agenda and Intro Click for subtitle or brief description

3 Agenda Intro Goal for this talk Who is this David Murphy person? The technologies and how they work What are the techs Feature Matrix Where they fit Pros and Cons General, Upgrading, Scaling Up/Down, Sharding, Geo, ect Other thoughts Should you have a support contract over these? What about other services like ObjectRocket, how do they compare? 3

4 Goals: What you should walk out with Understanding about what is IaaS, DevOps, and DBaaS Pros and Cons of each style as they apply to the techs What is MongoDB Atlas What is Azures CosmosDB Some DevOps ways to run MongoDB at scale Deciding which meets your needs & make concessions that work for you 4

5 Who is David Murphy MongoDB Practice Percona Roadmap Stakeholder for all MongoDB Technical Owner for MongoDB projects Lead Architect and Support Ecosystem Advocate and so on. Previous: Lead & Orginal Object Rocket (DBaaS) MongoDB Master Alumni Mysql & NoSQL Architect for Electronic Arts (Makes FIFA) 5

6 The technologies and how they work MongoDB Atlas, CosmosDB, and DIY

7 What are the techs: MongoDB Atlas Pay-per-hour infrastructure and management cloud tools on clouds Prevents Cloud lock-in Metrics Dashboard Backups (extra cost) ~44% more than DIY on same cloud No support for MongoDB itself Automated User Management Upgrading 7 Scaling Automated

8 What are the techs: Azure Pay per operation SaaS Only on Azure, but can talk with other networks Limited dashboard (size, requests) Backups 2 automated, 4 hour increments Cost per use case, no general cost No support for MongoDB itself Automated Scaling 8 Indexing

9 What are the techs: DYI DevOps using Kubernetes or similar Works both in house and any cloud Uses DataDog or PMM to metrics Backups need to be configure PerconaLabs/mongodb-consistent-backup Infrastructure Costs + DevOps No support for MongoDB itself Automated Deployment Scaling(via monitoring + ansible) 9

10 Where they fit *This depends on your use case but * MongoDB Atlas: Azure Cosmos: Small companies testing out a new app/system letting developers focus on developing Serverless Mindset Index everything Simple CRUD only (no aggr) Low frequency with scaling Multiply-geo simplified DYI: DevOps teams Mature Production team Integration with existing solutions 10

11 Feature Matrix Feature Azure CosmosDB DIY / DevOps Automated Provisioning Automatic Scaling 8/10 7*/10 Upgrades N/A 0*/10 Full MongoDB API Compatible 5/10 CRUD MongoDB API Compatible Point in Time Backups 0**/10 Cost Per Server TRUE N/A TRUE Cost Per Action N/A TRUE N/A Recurring Cost Per-Case Software Invest SSL / Encryption 10*/10 Metrics / Debugging 7/10 2/10 Overhead 11 MongoDB Atlas

12 Automatic Scaling This is the ability to have automated ways around scaling up and down. While useful one could conclude this is to help you automate the tasks of doing this not deciding when to do it. CosmoDB s the clear winner, if you need more use more and done Atlas helps automate the up & down on request but you decide when DIY you need to be the one to build the worker, logic, and automation. However with this one you COULD decide to make this 100% automated 12

13 Automatic Upgrading This is more about push button upgrading from 3.2->3.4 or 3.4 -> 3.6 There is no clear winner as they each have pros and cons CosmosDB - No upgrades needed as it runs its own thing, downside not all features work at all times. Atlas - This is native and well done, but for large nodes hold risk as backing out not deeply supported and riskier for larger deployments. DIY - Most customizable to match companies need but also 100% needs to be build by DevOps team 13

14 Full MongoDB API Compatibility The key word here is FULL, and only CosmosDB falls down here. While CosmosDB is API compatible it s only 100% on CRUD such as Insert/Update Delete Query When you get into indexes (automatic in Cosmos db), sharding, aggregation and more CosmosDB is different and means application changes DIY and Atlas are 100% aligned to community MongoDB 14

15 Overhead This is more of a meta topic around what is the pain point you take on. CosmosDB This is hard to justify because how many operations will you need? In normal mongo you didn t care, jus that the server could keep up Atlas At 44% more than running your own instances this price adds up over time, and does not reduce like DIY will, could mean more $$$ long term. DIY People! and processes all cost money to build and maintain. This is mostly front loaded so you will pay less long term if done right. 15

16 Metrics / Monitoring CosmosDB This is more like any cloud service the resource (api calls) you have used and available/used space. You won't understand why something was slow. Atlas Good basic monitoring covering many of the Mongo main metrics and some system level ones. DIY Using something like PMM or prometheus you can have hundreds of metrics and graph them based on your use case, as such this is the clear winner. 16

17 Sharding Considerations CosmosDB N/A Atlas As Atlas is based in the cloud you should shard fast and often, keeping the size of nodes down to better absorb any latency spikes. DIY As adding/removing shards are not automatic (unless via ansible type systems) you should keep an eye on things but people tend to keep GB per server. The ratio of member to disk is more about your use case than some random cloud assumption. 17

18 Index Management CosmosDB N/A everything is indexed by default Atlas When the profiler is enabled its suggest indexes that must may create DIY This offers you the most control by using tools like pt-mongodb-query-digest you can use the profile to find expensives queries to re-write or better index. Using this will ansible could allow for some automatic indexing, but we suggest you avoid background indexes where possible as they are less efficient. 18

19 Data Geo Locality CosmosDB Multiple Master, and regional cloning available Atlas Location based sharding using zones or tags Single region per replica set No Multiple Master DIY No Multiple Master Zone and Tag support for sharding and replica set Multiple region replica set allowed 19

20 Other Thoughts Other services to consider from full DBaaS providers to support vendors

21 Several Nines While somewhere between a Atlas or MongoDB Clould Manager with a DIY this is a paid offering that does act as a great shortcut to features without removing customization. Provides Provisioning Provides Basic Monitoring Provides Multiple Backup Solution automation Does not have automatic provisioning or indexes Less metrics than PMM for monitoring 21

22 ObjectRocket This is more like a blend of Atlas and Cosmos DB, here we have normal mongo in a very strict design but with automatic scaling, and a team to monitor thing for you. Automatic Scaling 24/7 Support and Consulting help No hardware to manage Limited Monitoring Automatic Backups No multiple DC support No full admin access by default 22

23 Thank You Sponsors! 23

24 SAVE THE DATE! April 23-25, 2018 Santa Clara Convention Center CALL FOR PAPERS OPENING SOON! 24

25 Thank you for attending. Check out my other talks in the App, some help explain things like PMM mentioned here.