Currently thinking of using MongoDB and MongoDB Express as cache and interface on edge servers, solving data issues and making an overall architecture an distributed system.
The 2 containers (from Mongodb Docker) is deployed via Docker-Compose. And have been tested on Dev Envrionment.MonogoDB is the NoSql Database, and Express is the interface for access local cache.
Question:
Is it safe to deploy to Production, considering it is a third party container?
Is there any known or foreseeable issues from your expertise?
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 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
I have an express app using MongoDB up and running locally. I am looking at options to deploy and wasn't clear on how MongoDB atlas fit in. I planning on just deploying the express app and database to an ec2 instance. Is that alright? Or do I need a separate instance for mongo to run on? MongoDB Atlas offers M2, M5, M10 etc. as options for nodes. I am very new at backend and want to know if those would be separate from my EC2 instance or if those would be my EC2 instance running my express app for clients to connect to as well.
Mongo Atlas is a standalone hosted MongoDB instance. It's a separate server, or typically a cluster of several servers, that only runs MongoDB. You'd run your Express app on an EC2 instance and have it talk over the network to the Mongo Atlas instance on another server.
The advantage is that you don't have to worry about installing or handholding Mongo, about configuring a redundant Mongo cluster, about upgrades or backups. Generally, separating the database server from the application server also means easier longterm maintenance of both. If your Express server doesn't store any data itself, then it is entirely disposable in case of emergencies, while you can be assured* that the critical data stored in your database is well cared for.
* As far as your contract with Atlas stipulates that the data is being cared for…
I'm used to building web apps the 'traditional' way but am trying to wrap my head around using docker. If I run postgres in a container along with my python web app, is this the same as spinning up a digital ocean server and installing postgres from scratch? How do I handle backups, fault tolerance, etc with a postgres database that is in docker?
As an alternative, I normally use hosted postgres on Heroku or AWS. Doesn't that solve a lot of the issues I would run into when hosting postgres myself in docker? Do developers really run postgres in docker or do they typically prefer to use an external hosted service?
It's wise for the moment to only keep stateless services or one-off jobs in Docker, and not put any stateful service, like a database.
This recent article from mesosphere has more details about why this isn't yet the case.
One issue would be that orchestration technologies aren't yet up to snuff for the high requirements of stateful services. To quote:
The first challenge is resource isolation. Many container orchestration solutions in the market provide a best effort approach to resource allocation, including memory, CPU and Storage. While this may be ok for stateless apps, it may be catastrophic for stateful services, where loss of performance may result in loss of customer transactions or data.
Another is that stateful databases have been built with different assumptions than those employed by containers, and are heavily optimized for them. Again, quoting:
Most of today’s stateful database technologies were originally designed for a non-containerized world. The operational instructions are very specific to the technology and can sometimes be version specific. Trying to map generic primitives of a container orchestration platform to stateful services is usually a time consuming and error prone operation.
You could totally run your postgres instance inside Docker. But it will require some work to handle backups, fault tolerance and such.
At my company we've made the choice to not put databases inside Docker, for now at least.