Too Many Projects, Too Little Time: Deliver MongoDB-as-a-Service

Sign up for updates

What do a leading investment bank, a PaaS for mobile app developers and one of the largest US government departments all have in common? Each one needed to power a new wave of applications with a single database. Of course it didn’t make sense for each database instance to run on its own infrastructure. So they decided to build a shared service to standardize the way multiple applications and project teams consumed the database. That database was MongoDB. And what they built was MongoDB-as-a-Service.

These organizations are not alone. MongoDB is the fastest growing database community on the planet. As more companies move from initial pilots to full scale production, IT groups are challenged to bring order to chaos. They need to maintain consistent operational best practices and enforce corporate governance mandates and BU accountability across multiple projects.

This is where delivering MongoDB-as-a-Service comes in. One pool of shared resources – running in a private data center or in a public cloud – serving multiple tenants, each with unique workload requirements.

Building something like this from scratch isn’t easy. But you don’t have to reinvent the wheel either. We’ve assembled best practices from multiple “as-a-service” projects to create the top 10 considerations to delivering MongoDB-as-a-Service.

So what are the top 10 things to think about? You should download the whitepaper, but as a summary:

Step 1: Identify Common Workload Requirements
Presents checklists you can use to capture both current and future database loads and technology specs. This provides input to the infrastructure you need to provision.

Step 2: Hardware & OS Selection
Identifies the general-purpose building blocks you should use to power the service.

Step 3: Virtualization Strategy Helps guide you to the virtualization technology that will get the most out of your hardware.

Step 4: Enabling Multi-Tenant Services
What do you need – maximum density of tenants per server, or maximum isolation between tenants? It doesn’t have to be either/or. You can blend multiple approaches to meet the demands of multiple apps.

Step 5: Enforcing Security Isolation between Tenants
Guidance on how to maintain strict isolation between each project, with full account and auditing control.

Step 6: Meeting Service Level Agreement (SLA) Requirements How can you be sure you can deliver continuous availability to your customers? How can you scale those apps that need it, when they need it? This section shows you how.

Step 7: Managing the MongoDB Service
You need to provision new services fast. You need proactive monitoring to identify potential issues before an outage brings all your apps down. You need to ensure each teams’ data is safe and can recover from disasters. We present the management platform you need to accomplish all of these things.

Step 8: Cost Accounting & Chargeback There is no such thing as a free ride….you deliver value for money, so now its time to make sure the project teams pay for what they consume.

Step 9: Define the Implementation Plan Where to start? You need the right people on board. This section helps you track down the (willing?) volunteers

Step 10: Production-Grade DBaaS
You need your MongoDB instances to be certified, secure and supported. We have just the thing.

If the above has piqued your interest, fill in a few details and download our new whitepaper now: MongoDB-as-a-Service: Top 10 Considerations.

comments powered by Disqus