A couple weeks ago, Amazon Web Services (AWS) launched Aurora, a new database-as-a-service (DBaaS) offering and a rather obvious shot across the bow at Oracle and other proprietary database vendors. It’s a “commercial-grade database engine at open-source cost,” according to AWS Senior Vice President Andy Jassy. Specifically, the claim is 5x the performance of MySQL, 1/10 the cost of [insert-red-logo-database-vendor-here]. Aurora is MySQL-compatible, and indeed could be intriguing for MySQL shops that are a) hitting performance walls, b) sick of paying Oracle, or c) both.
But AWS’s launch of Aurora is less interesting as an isolated product launch and more interesting in terms of what it has to say about the database and ops worlds more broadly.
Lots of folks are exploring DBaaS, which comes in many shapes and sizes. Aurora does not address any of the less appealing attributes of relational databases (delivered as-a-service or not), which can draw out to your early development cycles or increase the time and effort required to make changes down the line.
More importantly, not everyone is already running in AWS or wants to run there. What if you outsource to a different data center provider? At MongoDB we speak with lots of customers who run on AWS, but also plenty of others who use different hosting providers. Whither the solution for these well-meaning folks?
And what if you run your own data centers? Some of our largest customers have built their own DBaaS because a) they already have their own internal data centers, and b) the ROI for providing an internal DBaaS to their developers is compelling. These customers include:
- U.S. Department of Veterans Affairs
- United Health Group
- Top 10 Global Investment Bank
- Top 3 US bank
- Top 10 Global Investment Bank (a different one this time)
- Top 5 Global Telco
After building their own DBaaS, they report non-trivial results. A Top 3 US bank said they they can spin up instances of MongoDB in a secure enterprise environment in minutes, a process that used to take weeks or months.
The top 3 reasons these customers tell us that they’re pursuing internal DBaaS are:
- Compress development cycles. When companies can build products and turn around new features in weeks instead of months or years, good things happen.
- Empower developers. The ability to stand up database instances quickly helps developers experiment, go big (or fail fast), and build prototypes uber-quickly. This is how you build things no one has built before.
- Help ops. By owning the process of spinning up new database instances, ops can maintain control of the environments; standardize and enforce governance; rationalize the stack; and templatize based on best practices.
Like your apps, a DBaaS can take many shapes and sizes. For those considering building out an internal DBaaS, here are some of the areas you might want to consider:
- Technical choices. There are a lot of technical decisions to make – like what servers to use, how to size your instances, how to isolate environments for security and how to manage chargeback. We recommend customers get out in front of these evaluations early since they can often be the biggest hold-up in getting your DBaaS off the ground. To learn more about best practices taken from the customers who have built a DBaaS, read our whitepaper.
- Build vs. Buy. A DBaaS comprises many parts. Some of our customers want to build them all. Many of them want to buy some components in order to a) get a functional DBaaS up and running faster, and b) take advantage of best practices to lower the risk of messing something up. This could include tools like Docker, Chef and Puppet – tools you know already work. It may also include database-specific tools. (Sneak peek: for instance, MongoDB is coming out with software that you can run in your own data center to automate provisioning and deployment to get you much farther down the DBaaS path with a lot less time and risk. To learn more, contact us.)
- Resources and Expertise. A DBaaS is powerful but can also be a complex undertaking. Do you have the resources in-house to make this DBaaS a reality? Or would it be worthwhile to (shameless plug) engage the services of your friendly green-logoed open-source database company?
Finally, to the sysadmins, production engineers, system engineers, directors and VPs of ops, DBAs, CIOs and anyone else responsible for keeping the lights on, consider the following: DBaaS can help ops can play a powerful role. With DBaaS, ops gives developers the technology they want without sacrificing security and compliance. It gives the business faster time for prototypes and development cycles in general. And it helps separate your company from the pack.
MongoDB-as-a-Service: Top 10 Considerations
As more internal business units and project teams build modern applications on MongoDB, architects and operations teams can improve agility, efficiency, accountability and governance by offering MongoDB-as-a-Service.
This whitepaper provides the top 10 considerations you make including:
- Systems design
- Virtualization and multi-tenancy
- Management, accounting and compliance
About Graham Neray
Graham is a Senior Product Marketing Manager at MongoDB. Graham works closely with customers, partners and the open-source community to articulate why MongoDB is becoming the world's most popular database. Prior to joining MongoDB, he was a Senior Business Analyst at CSMG, a boutique management consulting firm specializing in the high tech and telecom industries.