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
Related
I have developed RESTful services with Asp.NET, Web API 2.0 and MySQL.
What are my options to deploy this in to the Cloud? I don't want a complete EC2 instance or Azure Virtual Machine.
Are there any cloud platform services where I can only get IIS server and a MYSQL database?
See below for good links on Azure and AWS options. Since you mention IIS, Azure may be your best bet. Keep in mind you should try and keep your API and DB in the same cloud data center to improve performance and reduce cost for ingress and egress.
From an Azure perspective:
Take a look at their MySQL as a service offering (in preview)
And then you can host your code in a couple of ways.
Asp.Net in an App Service
An Azure Function
Using a combination of the above you can leverage PaaS and avoid having to manage your own VMs.
Further, look in to using a consumption plan to pay for only what you use.
From an AWS perspective
Use Amazon RDS (MySQL)
Use Lambda to host your API
Again, here you wont need to manage servers either.
If I've understood the docs properly, azure service fabric-based apps/microservices cannot be installed together with their service-fabric operational environment in one "packaged installer" step. For example, if I want to deploy a set of microservices on premises at a company that is running a typical windows server 2012 or VMWare IT center, then I'm out of luck? I'd have to require the company to first commit to (and execute) an installation of an azure app service fabric on several machines.
If this is the case, then the Azure Service Fabric is only an option for pure cloud operations where the service fabric cluster can be created on-demand by the provider or for companies that have already committed to azure service fabric. This means that a provider of classical "installer-based" software cannot evolve to the azure service fabric advantages since the datacenter policies of the potential customers is unknown.
What have I missed?
Yes, you always have to have a cluster to run Service Fabric Applications and Microservices. It is however not any more limited to a pure cloud environment, as of September last year the on-premise version of Azure Service Fabric for Windows Server went GA (https://azure.microsoft.com/en-us/blog/azure-service-fabric-for-windows-server-now-ga/) and that lets you run your own cluster on your own machines (whether physical or virtual, doesn't matter) or in another data center (or even at another cloud provider).
Of course, as you say, this requires your customer company to either have their own cluster or that you set one up for them (https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-cluster-creation-for-windows-server). They will also need to have the competence to manage that cluster over time. It could be argued though that this shouldn't be much more difficult than managing a VMWare farm or setting up and managing say a Docker container host(s).
For the traditional 'shrink-wrapped-DVD-installer-type' of software vendor this might not be as easy as just supplying an .exe and some system requirements, i agree with you on that. If the customer can't or don't wan't to run their own cluster and cloud is not an option then it definitely adds additional complexity to selling and delivering your solution.
The fact that you can run your own cluster on any Windows Server environment means that there is no real lock-in to Azure as a cloud platform, I think that this is a big pro for SF as a framework. Once you have a cluster to receive your applications then you can focus on developing that, this cannot be said of most other cloud-based PaaS frameworks/services.
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
We have our own mongo replica set setup in aws ec2, it is running all good. Now, what we want is to get MMS setup to monitor and backup the replica set. It seems that MMS will only monitor and backup the mongo instance that was deployed by the MMS.
Is there a work around for this?
As of the mid-October 2014 release of MMS, monitoring & backup has been integrated with deployment via the automation agent (http://blog.mongodb.org/post/99991498968/mongodb-management-service-re-imagined-the-easiest-way). There currently isn't an option to attach MMS to existing MongoDB deployments, however you can watch/upvote MMS-1991 in the MongoDB issue tracker for updates.
Is there a work around for this?
One option would be to deploy a new replica set using MMS and migrate your data to the managed deployment.
If you have an MMS group created with the pre-automation version, the "classic" MMS groups do not have support for automation and the agents can be installed independently. Note that the classic version of MMS is closed to new users.
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/