can anyone please give me a high level difference between MongoDB Cloud Manager and Mongodb Atlas. My main aim is to monitor mongodb instances in AWS.
Thanks.
Cloud Manager is used when you want to manage your own infrastructure (you spin up the nodes where MongoDB runs) but still have the benefits of automated backups and monitoring.
Atlas goes one step further by automating everything for you including provisioning the infrastructure. It's a true database as a service fully managed by MongoDB. They hide the complexity of managing servers so all you have to worry about it using MongoDB. It's interesting to note they use AWS (with plans to support Azure and Google) to spin up nodes, perform monitoring, and backups.
The Major difference between Atlas and Cloud manager is that :
Cloud manager is used for monitoring your database deployment and providing the automated back ups in the self hosted environment.
While MongoDB Atlas is used when your deployments are hosted on the MongoDB Servers. So each and ever task is managed by the MongoDB staff. This is basically the database as a service. In case you encounter any issue all you need to open a case with the mongodb and they will help in the investigations of the issue occurred.
Here is an up-to-date answer to this question which explains differences between Atlas, Cloud Manager and also the Ops-Manager:
MongoDB Atlas handles all the complexity of deploying, managing, and healing your deployments on the cloud service provider of your choice (AWS, Azure, and GCP). Atlas pricing details are here 4.
Cloud Manager is a platform for managing MongoDB on the infrastructure of your choice. Cloud Manager pricing details are here 7.
Ops Manager automate, monitor, and back up your MongoDB infrastructure.
Here is the original article and additional resources in the MongoDB community forum: https://www.mongodb.com/community/forums/t/cloud-manager-vs-ops-manager-vs-atlas/42624
Related
My application requires MongoDB to run. I was wondering if you could explain the limitations of using a single ec2 instance to deploy a database.
What would be a couple other options that wouldn't require ec2?
There are two basic options:
Run your own instance of MongoDB on EC2, or in a container.
Use a managed service such as MongoDB Atlas or DocumentDB
The first option provides you with more control of the application and its runtime environment, and more flexibility in configuration.
The downside is the overhead imposed in the management of the solution: Upgrades, scaling, performance, configuration changes, security patches. And this applies to the underliying operating system as well.
I see a MongoDB service in Microsoft Azure but that deploys a VM and installs MongoDB in that. I am guessing this will not auto scale and also charge me for the entire VM and MongoDB management (not just for my usage).
Is there any managed MongoDB as a service available in Microsoft Azure which will:
a) Auto scale. b) Charge me only for my usage.
I see MongoDB container image by Bitnami but I might have to deploy this on Helm.
What are my options here?
mongo db atlas is managed mongo, you can use that, but it wont be billed through Azure Subscription and it wont appear on your subscription. But it can be deployed to the same azure region your resources live in
I want to deploy Strapi on GKE (Kubernetes), I have a docker-compose file, and I think I can use kcompose to create the deployment.
My questions is, has anyone used Mongodb Atlas + GKE or should I deploy Mongo on my own?
The question is more opinion based. It all depends on your needs.
If your needs match one of below you should stay with MongoDB:
Your app runs on-prem and contracts or privacy statements dont allow you to store data with a 3rd party.
You need large storage but not much query power.
There is other privacy/compliance issues.
Your app does not have internet access (firewalls, isolated environments)
You are running 3rd party applications that require a very old version of MongoDB
Here are some MongoDB Altas advantages:
Easily deploy, modify, and elastically scale their database clusters with a few clicks or an API call
Gain complete visibility into the performance the database and the underlying instances
Focus more on development, with built-in operational and security best practices such as geographically distributed, auto-healing clusters, and always-on authentication and encryption.
The best way would be if you will check how work with MongoDB Atlas on GCP looks alike. You can check this tutorial.
I am building my own webapp which requires a huge database. I want to build and manage my own Mongo database on AWS rather than using Mongo Atlas. Which will be more cost saving? And whether I should go for Mongo Atlas? What will be its advantage over my own database?
There are pros and cons for both approaches:
Running MongoDB on AWS
Pros:
Complete control over how you run the database and how resources are allocated on the server. This could even be together with an application server on the same EC2 instance depending on your traffic and load. This might help with cost saving if your database is huge but isn't likely to see much traffic.
Cons:
You will be responsible for ensuring database availability and applying security patches as and when they are available. You may also have to setup firewalls and protect the EC2 instance and database in other ways that would be trivial to do on a hosted service like Atlas.
Data sharding and clustering can be a real pain to manage by yourself.
Running on Atlas
Pros:
Completely managed service where you don't have to be concerned about performance optimization or scalability. You pay for the services and Mongodb takes care of the rest.
You can focus on building a great application instead of spending your time on administering the database and the EC2 instance on which the database runs.
Cons:
You will be constrained by the options offered by Atlas. For most use cases this should be fine, but if you really want a specific change, it would be difficult to implement it if Mongodb doesn't already support it as a part of Atlas.
Think running your application on EC2 vs buying a server on-premise and running your application on that.
Being a managed service, costs might also be higher if your database does not see much traffic.
HOSTING yourself: You can get one or more AWS ec2 instances(which are VMs) where you can install and run Mongo DB yourself and manage it like you wanted to, making sure that you spin up more instances when the workload becomes large and there are instances up and running at all times to enable high availability.
Cost (high) - Management responsibilities (lots) - Full MongoDB functionality
MongoDB Atlas is a managed service, you don't need to worry about management tasks like scaling of your database and high availability when a single/more instances die... You pay a very low cost for it - this is run by MongoDb themselves on AWS, Azure, Google cloud;
Cost (low) - Management responsibilities (some) - Full MongoDB functionality
Now AWS has its own Mongo compatible database called DocumentDB - this is also a managed database, so you don't need to worry about scalability, high availability etc. This is only available on AWS so super simple and convinient.
Cost (low) - Management responsibilities (minimal) - Limited MongoDB functionality
Can you use mongodb and redis/memcached with azure?
I'm guessing no but just want to make sure.
It turns out they do support things other than .net, are they using linux servers then?
You can very easily run mongodb in Windows Azure. I presented this at MongoSV - video here.
EDIT: In December 2011, 10gen published their official MongoDB+Azure code on github. This contains a project for replica-sets, as well as a demo ASP.NET MVC application (taken from the Windows Azure Platform Training Kit) that uses a replica set for its storage.
Standalone servers are straightforward, except you have to deal with scale-out: you can't have multiple instances of a standalone server simultaneously, so you'll need to plan for this: take all but one out of the load balancer, or only launch mongod if you can acquire the Cloud Drive lock.
Replicasets are doable, as I demonstrated at MongoSV. However, I didn't cover the intricacies of graceful shutdown of a replicaset to ensure zero data loss.
You can run memcached as well - see David Aiken's post about this. Note: Now that the AppFabric Cache service is live, you should look into the pros/cons of using that over memcached. Cost-wise, AppFabric Cache should run much less, as you don't have to pay for role instances to host your cache. More info about AppFabric Cache here.
You now also have the option of running Redis in Windows Azure on Linux virtual machines ! In the case of Redis, this would allow you to use the "official" build instead of the "unsupported" Windows build ... For MongoDB, both choices seem equally valid (running on Linux virtual machines, "plain" Windows virtual machines, or using 10gen's package to run on "managed" VMs (Cloud Services).
FYI, there's now a Redis installer for Windows Azure available from MS Open Tech (my team). Here's a tutorial on how to use it: http://ossonazure.interoperabilitybridges.com/articles/how-to-deploy-redis-to-windows-azure-using-the-command-line-tool
[UPDATE] Azure now supports MongoDB and Redis.
http://azure.microsoft.com/blog/2014/04/22/announcing-new-mongodb-instances-on-microsoft-azure/
http://azure.microsoft.com/en-us/services/cache/
In the Azure Store you can now select Redis Cloud as an add-on.
Heres the Azure store description:
"Redis Cloud is a fully-managed cloud service for hosting and running Redis in a highly-available and scalable manner, with predictable and stable top performance. Tell us how much memory you need and get started instantly with your new Redis database."
PUBLISHED DATE 3/31/2014
You can access the store by selecting the "New" button in the Azure portal then "Store". I have yet to use it but it looks promising.
Azure now has a first-party Redis service, currently in preview:
http://azure.microsoft.com/en-us/documentation/articles/cache-dotnet-how-to-use-azure-redis-cache/