DEV Community: MongoDB

MongoDB Enterprise Running on OpenShift

MongoDB — Fri, 13 Apr 2018 00:00:00 +0000

In order to compete and get products to market rapidly enterprises today leverage cloud-ready and cloud-enabled technologies. Platforms as a Service (or PaaS) provide out-of-the-box capabilities which enable application developers to focus on their business logic and users instead of infrastructure and interoperability. This key ability separates successful projects from those which drown themselves in tangential work which never stops.

In this blog post, we'll cover MongoDB's general PaaS and cloud enablement strategy as well as touch upon some new features of Red Hat’s OpenShift which enable you to run production-ready MongoDB clusters. We're also excited to announce the developer preview of MongoDB Enterprise Server running on OpenShift. This preview allows you to test out how your applications will interact with MongoDB running on OpenShift.

Integration Approach for MongoDB and PaaS

Platforms as a Service are increasingly popular, especially for those of you charged with building "cloud-enabled" or "cloud-ready" applications but required to use private data center deployments today. Integrating a database with a PaaS needs to be done appropriately to ensure that database instances can be deployed, configured, and administered properly.

There are two common components of any production-ready cloud-enabled database deployment:

A modern, rock-solid database (like MongoDB).
Tooling to enable telemetry, access and authorization, and backups (not to mention things like proactive alerting that integrates with your chosen issue tracking system, complete REST-based APIs for automation, and a seamless transition to hosted services.) For MongoDB, this is MongoDB Ops Manager.

A deep integration of MongoDB Ops Manager is core to our approach of integrating MongoDB with popular PaaS offerings. The general design approach is to use the "separation of concerns" design principle. The chosen PaaS handles the physical or virtual machines, CPU and RAM allotment, persistent storage requirements, and machine-level access control, while MongoDB Ops Manager controls all aspects of run-time database deployments

This strategy enables system administrators to quickly deploy "MongoDB as a Solution" offerings within their own data centers. In turn, enterprise developers can easily self-service their own database needs.

If you haven't already, download MongoDB Ops Manager for the best way to run MongoDB.

MongoDB Enterprise Server OpenShift Developer Preview

Our "developer preview" for MongoDB on OpenShift can be found here: https://github.com/jasonmimick/mongodb-openshift-dev-preview. The preview allows provisioning of both MongoDB replica sets and "agent-only" nodes (for easy later use as MongoDB instances) directly through OpenShift. The deployments automatically register themselves with an instance of MongoDB Ops Manager. All the technical details and notes of getting started can be found right in the repo. Here we'll just describe some of functionality and technology used.

The preview requires access to an OpenShift cluster running version 3.7 or later and takes advantage of the new Kubernetes Service Catalog features. Specifically, we're using the Ansible Service Broker and have build an Ansible Playbook Bundle which installs an icon into your OpenShift console. The preview also contains an example of an OpenShift template which supports replica sets and similar functionality.

A tour and deploying your first cluster:

Once you have your development environment ready (see notes in the developer preview Github repository) and have configured an instance of MongoDB Ops Manager you're ready to starting deploying MongoDB Enterprise Server.

Clusters can be provisioned through the OpenShift web console or via command line. The web console provides an intuitive "wizard-like" interface in which users specify values for various parameters, such as MongoDB version, storage size allocation, and MongoDB Ops Manager Organization/Project to name a few.

Command line installs are also available in which parameter values can be scripted or predefined. This extensibility allows for automation and integration with various Continuous Integration and Continuous Delivery technologies.

A future post will detail cluster configuration and various management scenarios, such as upgrades, performance tuning, and troubleshooting connectivity, so stay tuned.

We're excited to introduce simple and efficient ways to manage your MongoDB deployments with tools such as OpenShift and Kubernetes. Please try out the developer preview and drop us a line on Twitter #mongodb-openshift or email bd@mongodb.com for more information.

Modern Distributed Application Deployment with Kubernetes and MongoDB Atlas

MongoDB — Thu, 05 Apr 2018 00:00:00 +0000

Storytelling is one of the parts of being a Developer Advocate that I enjoy. Sometimes the stories are about the special moments when the team comes together to keep a system running or build it faster. But there are less than glorious tales to be told about the software deployments I’ve been involved in. And for situations where we needed to deploy several times a day, now we are talking nightmares.

For some time, I worked at a company that believed that deploying to production several times a day was ideal for project velocity. Our team was working to ensure that advertising software across our media platform was always being updated and released. One of the issues was a lack of real automation in the process of applying new code to our application servers.

What both ops and development teams had in common was a desire for improved ease and agility around application and configuration deployments. In this article, I’ll present some of my experiences and cover how MongoDB Atlas and Kubernetes can be leveraged together to simplify the process of deploying and managing applications and their underlying dependencies.

Let's talk about how a typical software deployment unfolded:

The developer would send in a ticket asking for the deployment
The developer and I would agree upon a time to deploy the latest software revision
We would modify an existing bash script with the appropriate git repository version info
We’d need to manually back up the old deployment
We’d need to manually create a backup of our current database
We’d watch the bash script perform this "Deploy" on about six servers in parallel
Wave a dead chicken over my keyboard

Some of these deployments would fail, requiring a return to the previous version of the application code. This process to "rollback" to a prior version would involve me manually copying the repository to the older version, performing manual database restores, and finally confirming with the team that used this system that all was working properly. It was a real mess and I really wasn't in a position to change it.

I eventually moved into a position which gave me greater visibility into what other teams of developers, specifically those in the open source space, were doing for software deployments. I noticed that — surprise! — people were no longer interested in doing the same work over and over again.

Developers and their supporting ops teams have been given keys to a whole new world in the last few years by utilizing containers and automation platforms. Rather than doing manual work required to produce the environment that your app will live in, you can deploy applications quickly thanks to tools like Kubernetes.

What's Kubernetes?

Kubernetes is an open-source system for automating deployment, scaling, and management of containerized applications. Kubernetes can help reduce the amount of work your team will have to do when deploying your application. Along with MongoDB Atlas, you can build scalable and resilient applications that stand up to high traffic or can easily be scaled down to reduce costs. Kubernetes runs just about anywhere and can use almost any infrastructure. If you're using a public cloud, a hybrid cloud or even a bare metal solution, you can leverage Kubernetes to quickly deploy and scale your applications.

The Google Kubernetes Engine is built into the Google Cloud Platform and helps you quickly deploy your containerized applications.

For the purposes of this tutorial, I will upload our image to GCP and then deploy to a Kubernetes cluster so I can quickly scale up or down our application as needed. When I create new versions of our app or make incremental changes, I can simply create a new image and deploy again with Kubernetes.

Why Atlas with Kubernetes?

By using these tools together for your MongoDB Application, you can quickly produce and deploy applications without worrying much about infrastructure management. Atlas provides you with a persistent data-store for your application data without the need to manage the actual database software, replication, upgrades, or monitoring. All of these features are delivered out of the box, allowing you to build and then deploy quickly.

In this tutorial, I will build a MongoDB Atlas cluster where our data will live for a simple Node.js application. I will then turn the app and configuration data for Atlas into a container-ready image with Docker.

MongoDB Atlas is available across most regions on GCP so no matter where your application lives, you can keep your data close by (or distributed) across the cloud.

Requirements

To follow along with this tutorial, users will need some of the following requirements to get started:

Google Cloud Platform Account (billing enabled or credits)
MongoDB Atlas Account (M10+ dedicated cluster)
Docker
Node.js
Kubernetes
Git

First, I will download the repository for the code I will use. In this case, it's a basic record keeping app using MongoDB, Express, React, and Node (MERN).

bash-3.2$ git clone git@github.com:cefjoeii/mern-crud.git Cloning into 'mern-crud'... remote: Counting objects: 326, done. remote: Total 326 (delta 0), reused 0 (delta 0), pack-reused 326 Receiving objects: 100% (326/326), 3.26 MiB | 2.40 MiB/s, done. Resolving deltas: 100% (137/137), done. cd mern-crud

Next, I will npm install and get all the required npm packages installed for working with our app:

\> uws@9.14.0 install /Users/jaygordon/work/mern-crud/node\_modules/uws \> node-gyp rebuild \> build\_log.txt 2\>&1 || exit 0

Selecting your GCP Region for Atlas

Each GCP region includes a set number of independent zones. Each zone has power, cooling, networking, and control planes that are isolated from other zones. For regions that have at least three zones (3Z), Atlas deploys clusters across three zones. For regions that only have two zones (2Z), Atlas deploys clusters across two zones.

The Atlas Add New Cluster form marks regions that support 3Z clusters as Recommended , as they provide higher availability. If your preferred region only has two zones, consider enabling cross-region replication and placing a replica set member in another region to increase the likelihood that your cluster will be available during partial region outages.

The number of zones in a region has no effect on the number of MongoDB nodes Atlas can deploy. MongoDB Atlas clusters are always made of replica sets with a minimum of three MongoDB nodes.

For general information on GCP regions and zones, see the Google documentation on regions and zones.

Create Cluster and Add a User

In the provided image below you can see I have selected the Cloud Provider "Google Cloud Platform." Next, I selected an instance size, in this case an M10. Deployments using M10 instances are ideal for development. If I were to take this application to production immediately, I may want to consider using an M30 deployment. Since this is a demo, an M10 is sufficient for our application. For a full view of all of the cluster sizes, check out the Atlas pricing page. Once I’ve completed these steps, I can click the "Confirm & Deploy" button. Atlas will spin up my deployment automatically in a few minutes.

Let’s create a username and password for our database that our Kubernetes deployed application will use to access MongoDB.

Click "Security" at the top of the page.
Click "MongoDB Users"
Click "Add New User"
Click "Show Advanced Options"
We'll then add a user "mernuser" for our mern-crud app that only has access to a database named "mern-crud" and give it a complex password. We'll specify readWrite privileges for this user:

Click "Add User"

Your database is now created and your user is added. You still need our connection string and to whitelist access via the network.

Connection String

Get your connection string by clicking "Clusters" and then clicking "CONNECT" next to your cluster details in your Atlas admin panel. After selecting connect, you are provided several options to use to connect to your cluster. Click "connect your application."

Options for the 3.6 or the 3.4 versions of the MongoDB driver are given. I built mine using the 3.4 driver, so I will just select the connection string for this version.

I will typically paste this into an editor and then modify the info to match my application credentials and my database name:

I will now add this to the app's database configuration file and save it.

Next, I will package this up into an image with Docker and ship it to Google Kubernetes Engine!

Docker and Google Kubernetes Engine

Get started by creating an account at Google Cloud, then follow the quickstart to create a Google Kubernetes Project.

Once your project is created, you can find it within the Google Cloud Platform control panel:

It's time to create a container on your local workstation:

Set the PROJECT_ID environment variable in your shell by retrieving the pre- configured project ID on gcloud with the command below:

export PROJECT\_ID="jaygordon-mongodb" gcloud config set project $PROJECT\_ID gcloud config set compute/zone us-central1-b

Next, place a Dockerfile in the root of your repository with the following:

FROM node:boron RUN mkdir -p /usr/src/app WORKDIR /usr/src/app COPY . /usr/src/app EXPOSE 3000 CMD [npm, start]

To build the container image of this application and tag it for uploading, run the following command:

bash-3.2$ docker build -t gcr.io/${PROJECT\_ID}/mern-crud:v1 . Sending build context to Docker daemon 40.66MB Successfully built b8c5be5def8f Successfully tagged gcr.io/jgordon-gc/mern-crud:v1

Upload the container image to the Container Registry so we can deploy to it:

Successfully tagged gcr.io/jaygordon-mongodb/mern-crud:v1 bash-3.2$ gcloud docker -- push gcr.io/${PROJECT\_ID}/mern-crud:v1The push refers to repository [gcr.io/jaygordon-mongodb/mern-crud]

Next, I will test it locally on my workstation to make sure the app loads:

docker run --rm -p 3000:3000 gcr.io/${PROJECT\_ID}/mern-crud:v1 \> mern-crud@0.1.0 start /usr/src/app \> node server Listening on port 3000

Great — pointing my browser to http://localhost:3000 brings me to the site. Now it's time to create a kubernetes cluster and deploy our application to it.

Build Your Cluster With Google Kubernetes Engine

I will be using the Google Cloud Shell within the Google Cloud control panel to manage my deployment. The cloud shell comes with all required applications and tools installed to allow you to deploy the Docker image I uploaded to the image registry without installing any additional software on my local workstation.

Now I will create the kubernetes cluster where the image will be deployed that will help bring our application to production. I will include three nodes to ensure uptime of our app.

Set up our environment first:

export PROJECT\_ID="jaygordon-mongodb" gcloud config set project $PROJECT\_ID gcloud config set compute/zone us-central1-b

Launch the cluster

gcloud container clusters create mern-crud --num-nodes=3

When completed, you will have a three node kubernetes cluster visible in your control panel. After a few minutes, the console will respond with the following output:

Creating cluster mern-crud...done. Created [https://container.googleapis.com/v1/projects/jaygordon-mongodb/zones/us-central1-b/clusters/mern-crud]. To inspect the contents of your cluster, go to: https://console.cloud.google.com/kubernetes/workload\_/gcloud/us-central1-b/mern-crud?project=jaygordon-mongodb kubeconfig entry generated for mern-crud. NAME LOCATION MASTER\_VERSION MASTER\_IP MACHINE\_TYPE NODE\_VERSION NUM\_NODES STATUS mern-crud us-central1-b 1.8.7-gke.1 35.225.138.208 n1-standard-1 1.8.7-gke.1 3 RUNNING

Just a few more steps left. Now we'll deploy our app with kubectl to our cluster from the Google Cloud Shell:

kubectl run mern-crud --image=gcr.io/${PROJECT\_ID}/mern-crud:v1 --port 3000

The output when completed should be:

jay\_gordon@jaygordon-mongodb:~$ kubectl run mern-crud --image=gcr.io/${PROJECT\_ID}/mern-crud:v1 --port 3000 deployment "mern-crud" created

Now review the application deployment status:

jay\_gordon@jaygordon-mongodb:~$ kubectl get pods NAME READY STATUS RESTARTS AGE mern-crud-6b96b59dfd-4kqrr 1/1 Running 0 1m jay\_gordon@jaygordon-mongodb:~$

We'll create a load balancer for the three nodes in the cluster so they can be served properly to the web for our application:

jay\_gordon@jaygordon-mongodb:~$ kubectl expose deployment mern-crud --type=LoadBalancer --port 80 --target-port 3000 service "mern-crud" exposed

Now get the IP of the loadbalancer so if needed, it can be bound to a DNS name and you can go live!

jay\_gordon@jaygordon-mongodb:~$ kubectl get service NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.27.240.1 <none> 443/TCP 11m
mern-crud LoadBalancer 10.27.243.208 35.226.15.67 80:30684/TCP 2m
</none>

A quick curl test shows me that my app is online!

bash-3.2$ curl -v 35.226.15.67 \* Rebuilt URL to: 35.226.15.67/ \* Trying 35.226.15.67... \* TCP\_NODELAY set \* Connected to 35.226.15.67 (35.226.15.67) port 80 (#0) \> GET / HTTP/1.1 \> Host: 35.226.15.67 \> User-Agent: curl/7.54.0 \> Accept: \*/\* \> \< HTTP/1.1 200 OK \< X-Powered-By: Express

I have added some test data and as we can see, it's part of my deployed application via Kubernetes to GCP and storing my persistent data in MongoDB Atlas.

When I am done working with the Kubernetes cluster, I can destroy it easily:

gcloud container clusters delete mern-crud

What's Next?

You've now got all the tools in front of you to build something HUGE with MongoDB Atlas and Kubernetes.

Check out the rest of the Google Kubernetes Engine's tutorials for more information on how to build applications with Kubernetes. For more information on MongoDB Atlas, click here.

Inclusion at MongoDB World

MongoDB — Mon, 02 Apr 2018 00:00:00 +0000

In June, we’ll kick off the fifth edition of MongoDB World, our global user conference. We continue to strive to make this conference not just a fun and interactive learning experience, but also an event that is welcoming to all. Here’s how:

Diversity Scholarship

MongoDB’s Scholarship program seeks to support to members of groups who are underrepresented in the technology industry. This includes, but is not limited to, Black, LatinX, women, low-income, and LGBTQ.

Diversity Scholarship recipients receive*:

Complimentary admission to MongoDB World
Complimentary admission to a pre-conference workshop
Invitation to a lunch session with other Scholars
Speed mentoring with MongoDB speakers at the event
A MongoDB certification voucher applicable for both developer and DBA certification exams
Six-month access to on-demand MongoDB University courses
Lifelong membership in the online MongoDB Diversity Scholars community
A feature in a blog post

If you’re a member of any of the-above mentioned groups, you qualify to apply for a scholarship. The application is here and the deadline to apply is May 4.

Apply for a Diversity Scholarship

If you cannot or do not want to apply, but would still like to contribute to scholarships for others , make sure to sign up for MongoDB World. You have the option to donate towards the Diversity Scholarship and can still have an impact by giving someone the opportunity to attend.

Female Innovators

Know a technologist who identifies as a woman who should attend MongoDB World? Nominate her!

Nominees get a complimentary conference pass* and an invitation to a guided discussion over lunch in the Women and Trans Coders Lounge. Self-nominations are also encouraged. The nomination deadline is April 27.

Nominate a Female Innovator

Women and Trans Coders Lounge

The Women and Trans Coders Lounge aims to amplify the voices of non-binary people, women, and trans people of all genders within our engineering community. It’s run in part by MongoDB’s Women and Trans Coders group. During MongoDB World, stop by to network, share your thoughts in a guided discussion, or sit in on a Make it Matter session.

Affinity Group Happy Hours

Join us for cocktails and mocktails, run by MongoDB’s employee resource groups, on June 26. You’ll be able to attend a happy hour hosted by the Black Network, the MongoDB Women’s Group, and the Queeries (MongoDB’s LGBTQ group). All happy hours will also serve mocktails and nonalcoholic beverages.

Black Network Happy Hour

Meet members of the MongoDB Black Network and other conference attendees who identify as Black during the Black Network Happy Hour.

LGBTQ Happy Hour

End the first day of MongoDB World by joining fellow MongoDB users who identify as members of the LGBTQ community for a drink at the bar.

Women in Tech Happy Hour

You’re invited to connect with Female Innovators, conference speakers, and other women in tech at the Women in Tech Happy Hour.

Accessibility

Our goal is to make MongoDB World accessible to all. Contact us if you need accessibility accommodations.

Code of Conduct

All conference attendees are expected to agree with and abide by the code of conduct.

We look forward to seeing you on June 26-27 in NYC. Over the course of two days, you’ll be able to engage with MongoDB users and industry experts from around the globe. And you’ll walk away with the tools that enable you to build your giant ideas.

Event Details:

Date: June 26-27, 2018

Location: New York Hilton Midtown, 1335 6th Ave, New York, NY 10019

mongodbworld.com

* Please note that travel and lodging is not included in the Diversity Scholarship and Female Innovators awards. Recipients are responsible for their own accommodations.

Stack Overflow Research of 100,000 Developers Finds MongoDB is the Most Wanted Database

MongoDB — Tue, 13 Mar 2018 00:00:00 +0000

It’s well established that developers want to work with a database that offers flexibility, versatility, and ease of use. Scalability and reliability certainly don’t hurt either. For an increasing number of developers, MongoDB is the desired solution to meet all these requirements. And for the second year in a row, this has been validated by the opinions of those who matter most — developers themselves.

Today, we’re excited to announce that, for the second year in a row, MongoDB is the most wanted database in the Stack Overflow Developer Survey 2018, the world’s largest developer survey with over 100,000 respondents.

Steady Increases in Popularity

Since its debut, MongoDB’s popularity among developers has steadily increased. This popularity has been driven primarily by the platform’s ease of use and flexibility; more recently, the release of the fully managed database service MongoDB Atlas has made it easier than ever to run the database in any of the major cloud platforms.

MongoDB continues to innovate, listening and reacting to the demands of developers from small startups to the largest of enterprises. New and exciting features to the platform include change streams, which push real-time data updates to downstream applications, retryable writes, which enhance reliability without increasing complexity, and the announcement of multi-document ACID transactions, coming in version 4.0 later this year.

Why MongoDB?

MongoDB’s document model offers developers massive increases in productivity by allowing developers to store data in a way that is consistent with how they think and create applications. Additionally, MongoDB’s native replication and horizontal partitioning give developers the confidence and freedom to concentrate on differentiating code without having to be concerned about challenges associated with data locality, reliability and scalability. Lastly, MongoDB offers the freedom to run consistently all the way from local development environments to the largest mainframe deployments. The database can be deployed on-premises, in a hybrid cloud, or in any of the public clouds.

How can you benefit from this news?

Hiring managers seeking talented developers may do well to review some of the additional statistics included in today’s release. One interesting statistic can be found in the chart entitled “How Developers Assess Potential Jobs”. If you are a hiring manager and you’re looking to attract top talent, considering the most wanted database platform might be a way to enhance the attractiveness of your opportunities.

Javascript and Python developers reviewing the Stack Overflow report will be encouraged as these development environments continue to grow in popularity. Popularity of web application stacks like MEAN or MERN have provided Javascript developers with frameworks for building applications quickly.

Not using Javascript or Python? MongoDB offers full support for these and all popular development languages. Want to use Golang with MongoDB? A fully supported MongoDB Golang driver has reached Alpha stage in development, giving even more options to developers to build with the latest and most popular languages.

In summary

Developers are the new Kingmakers and their opinions are vitally important. The results of the Stack Overflow survey are an exciting validation of MongoDB’s efforts to build a resilient, flexible, and easy-to-use platform wanted by developers the world over.

Are you looking to learn more?

MongoDB University offers free courses for beginners, developers, database administrators, and operations personnel. Get online education about MongoDB Atlas, Compass and other products to help developers build great modern applications.

Want to build right away with MongoDB? Get started today with a 512 MB database managed by MongoDB Atlas here.

Optimizing for Fast, Responsive Reads with Cross-Region Replication in MongoDB Atlas

MongoDB — Mon, 12 Mar 2018 00:00:00 +0000

MongoDB Atlas customers can enable cross-region replication for multi-region fault tolerance and fast, responsive reads.

Improved availability guarantees can be achieved by distributing replica set members across multiple regions. These secondaries will participate in the automated election and failover process should the primary (or the cloud region containing the primary) go offline.
Read-only replica set members allow customers to optimize for local reads (minimize read latency) across different geographic regions using a single MongoDB deployment. These replica set members will not participate in the election and failover process and can never be elected to a primary replica set member.

In this post, we’ll dive a little deeper into optimizing for local reads using cross-region replication and walk you through the necessary configuration steps on an environment running on AWS.

Primer on read preference

Read preference determines how MongoDB clients route read operations to the members of a replica set. By default, an application directs its read operations to the replica set primary. By specifying the read preference, users can:

Enable local reads for geographically distributed users. Users from California, for example, can read data from a replica located locally for a more responsive experience
Allow read-only access to the database during failover scenarios

A read replica is simply an instance of the database that provides the replicated data from the oplog; clients will not write to a read replica.

With MongoDB Atlas, we can easily distribute read replicas across multiple cloud regions, allowing us to expand our application's data beyond the region containing our replica set primary in just a few clicks.

To enable local reads and increase the read throughput to our application, we simply need to modify the read preference via the MongoDB drivers.

Enabling read replicas in MongoDB Atlas

We can enable read replicas for a new or existing MongoDB paid cluster in the Atlas UI. To begin, we can click on the cluster “configuration” button and then find the link named _ "Enable cross-region configuration options." _

When we click this, we’ll be presented with an option to select the type of cross-replication we want. We'll choose _ deploy read-only replicas _:

As you can see above, we have our preferred region (the region containing our replica set primary) set to AWS, us-east-1 (Virginia) with the default three nodes. We can add regions to our cluster configuration based on where we think other users of our application might be concentrated. In this case, we will add additional nodes in us-west-1 (Northern California) and eu-west-1 (Ireland), providing us with read replicas to serve local users.

Note that all writes will still go to the primary in our preferred region, and reads from the secondaries in the regions we’ve added will be eventually consistent.

We’ll click "Confirm and Deploy", which will deploy our multi-region cluster.

Our default connection string will now include these read replicas. We can go to the "Connect" button and find our full connection string to access our cluster:

When the deployment of the cluster completes, we will be ready to distribute our application's data reads across multiple regions using the MongoDB drivers. We can specifically configure readPreference within our connection string to send clients to the "closest replicas". For example, the Node native MongoDB Driver permits us to specify our preference:

readPreference	Specifies the replica set read preference for this connection.

| The read preference values are the following:

For our app, if we want to ensure the read preference in our connection string is set to the nearest MongoDB replica, we would configure it as follows:

mongodb://admin:@cluster0-shard-00-00-bywqq.mongodb.net:27017,cluster0-shard-00-01-bywqq.mongodb.net:27017,cluster0-shard-00-02-bywqq.mongodb.net:27017,cluster0-shard-00-03-bywqq.mongodb.net:27017,cluster0-shard-00-04-bywqq.mongodb.net:27017/test?ssl=true&replicaSet=Cluster0-shard-0&authSource=admin?readPreference=nearest

Security and Connectivity (on AWS)

MongoDB Atlas allows us to peer our application server's VPC directly to our MongoDB Atlas VPC within the same region. This permits us to reduce the network exposure to the internet and allows us to use native AWS Security Groups or CIDR blocks. You can review how to configure VPC Peering here.

A note on VPCs for cross-region nodes:

At this time, MongoDB Atlas does not support VPC peering across regions. If you want to grant clients in one cloud region read or write access to database instances in another cloud region, you would need to permit the clients’ public IP addresses to access your database deployment via IP whitelisting.

With cross-region replication and read-only replicas enabled, your application will now be capable of providing fast, responsive access to data from any number of regions.

Get started today with a free 512 MB database managed by MongoDB Atlas here.

Improving MongoDB Performance with Automatically Generated Index Suggestions

MongoDB — Thu, 01 Feb 2018 00:00:00 +0000

Beyond good data modeling, there are a few processes that teams responsible for optimizing query performance can leverage: looking for COLLSCANS in logs, analyzing explain results, or relying on third-party tools. While these efforts may help you resolve some of the problems you’re noticing, they often require digging into documentation, time, and money, all the while your application remains bogged down with issues.

MongoDB Atlas, the fully managed database service, helps you resolve performance issues with a greater level of ease by providing you with tools to ensure that your data is accessed as efficiently as possible. This post will provide a basic overview of how to access the MongoDB Atlas Performance Advisor, a tool that reviews your queries for up to two weeks and provides recommended indexes where appropriate.

Getting Started

This short tutorial makes use of the following:

A demo data set generated with mgodatagen
A dedicated MongoDB Atlas cluster (the Performance Advisor is available for M10s or larger)
MongoDB shell install (to create indexes)

My database has two million documents in two separate collections:

If an application tries to access these documents without the right indexes in place, a collection scan will take place. The database will scan the full collection to find the required documents, and any documents that are not in memory are read from disk. This can dramatically reduce performance and cause your application to respond slower than expected.

Case in point, when I try to run an unindexed query against my collections, MongoDB Atlas will automatically create an alert indicating that the query is not well targeted.

Reviewing Performance Advisor

The Performance Advisor monitors slow-running queries (anything that takes longer than 100 milliseconds to execute) and suggests new indexes to improve query performance.

To access this tool, go to your Atlas control panel and click your cluster's name. You’ll then find "Performance Advisor" at the top.

Click the link and you'll be taken to the page where you'll see any relevant index recommendations, based on the fixed time period at the top of the page.

In this example, I will review the performance of my queries from the last 24 hours. The Performance Advisor provides me with some recommendations on how to improve the speed of my slow queries:

It looks like the test collection with the field "name" could use an index. We can review the specific changes to be made by clicking the "More Info" button.

I can copy the contents of this recommendation and paste it into my MongoDB Shell to create the recommended index. You’ll notice a special option, { background: true }, is passed with the createIndex command. Using this command ensures that index creation does not block any operations. If you’re building new indexes on production systems, I highly recommend you read more about index build operations.

Now that the recommended index is created, I can review my application's performance and see if it meets the requirements of my users. The Atlas alerts I received earlier have been resolved, which is a good sign:

Noticeable slowdowns in performance from unindexed queries damage the user experience of your application, which may result in reduced engagement or customer attrition. The Performance Advisor in MongoDB Atlas gives you a simple and cost-efficient way to ensure that you’re getting the most out of the resources you’ve provisioned.

To get started, sign up for MongoDB Atlas and deploy a cluster in minutes.

Training Machine Learning Models with MongoDB

MongoDB — Thu, 18 Jan 2018 00:00:00 +0000

Over the last four months, I attended an immersive data science program at Galvanize in San Francisco. As a graduation requirement, the last three weeks of the program are reserved for a student-selected project that puts to use the skills learned throughout the course. The project that I chose to tackle utilized natural language processing in tandem with sentiment analysis to parse and classify news articles. With the controversy surrounding our nation’s media and the concept of “fake news” floated around every corner, I decided to take a pragmatic approach to address bias in the media.

My resulting model identified three topics within an article and classified the sentiments towards each topic. Next, for each classified topic, the model returned a new article with the opposite sentiment, resulting in three articles provided to the user for each input article. With this model, I hoped to negate some of the inherent bias within an individual news article by providing counter arguments from other sources. The algorithms used were the following (in training order): TFIDF Vectorizer (text preprocessing), Latent Dirichlet Allocation (topic extraction), Scipy’s Implementation of Hierarchical Clustering (document similarity), and Multinomial Naive Bayes (sentiment classifier).

Initially, I was hesitant to use any database, let alone a non-relational one. However, as I progressed through the experiment, managing the plethora of CSV tables became more and more difficult. I needed the flexibility to add additional features to my data as the model engineered them. This is a major drawback of relational databases. Using SQL, there are two options: generate a new table for each new feature and use a multitude of JOINs to retrieve all the necessary data, or use ALTER TABLE to add a new column for each new feature. However, due the the varied algorithms I used, some features were generated one data point at a time, while others were returned as a single python list. Neither option was well suited to my needs. As a result, I turned to MongoDB to resolve my data storage, processing, and analysis issues.

To begin with, I used MongoDB to store the training data scraped from the web. I stored raw text data as individual documents on an AWS EC2 instance running a MongoDB database. Running a simple Python script on my EC2 instance, I generated a list of public news articles URLs to scrape and stored the scraped data (such as the article title and body) into my MongoDB database. I appreciated that, with MongoDB, I could employ indexes to ensure that duplicate URLs, and their associated text data, were not added to the database.

Next, the entire dataset needed to be parsed using NLP and passed in as training data for the TFIDF Vectorizer (in the scikit-learn toolkit) and the Latent Dirichlet Allocation (LDA) model. Since both TFIDF and LDA require training on the entire dataset (represented by a matrix of ~70k rows x ~250k columns), I needed to store a lot of information in memory. LDA requires training on non-reduced data in order to identify correlations between all features in their original space. Scikit Learn’s implementations of TFIDF and LDA are trained iteratively, from the first data point to the last. I was able to reduce the total load on memory and allocate more to actual training, by passing a Python generator function to the model that called my MongoDB database for each new data point. This also enabled me to use a smaller EC2 instance, thereby optimizing costs.

Once the vectorizer and LDA model were trained, I utilized the LDA model to extract 3 topics from each document, storing the top 50 words pertaining to each topic back in MongoDB. These top 50 words were used as the features to train my hierarchical clustering algorithm. The clustering algorithm functions much like a decision tree, and I generated pseudo-labels for each document by determining which leaf the document fell into.Since I could use dimensionally reduced data at this point, memory was not an issue, but all these labels needed to be referenced later in other parts of the pipeline. Rather than assigning several variables and allowing the labels to remain indefinitely in memory, I inserted new key-value pairs for the top words associated with each topic, topic labels according the clustering algorithm, and sentiment labels into each corresponding document in the collection. As each article was analyzed, the resulting labels and topic information were stored in the article’s document in MongoDB. As a result, there was no chance of data loss and any method could query the database for needed information regardless of whether other processes running in parallel were complete.

Sentiment analysis was the most difficult part of the project. There is currently no valuable labeled data related to politics and news so I initially tried to train the base models on a data set of Amazon product reviews. Unsurprisingly, this proved to be a poor choice of training data because the resulting models consistently graded sentences such as “The governor's speech reeked of subtle racism and blatant lack of political savvy” as having positive sentiment with a ~90% probability, which is questionable at best. As a result I had to manually label ~100k data points, which was time-intensive, but resulted in a much more reliable training set. The model trained on manual labels significantly outperformed the base model, trained on the Amazon product reviews data. No changes were made to the sentiment analysis algorithm itself; the only difference was the training set. This highlights the importance of accurate and relevant data for training ML models – and the necessity, more often than not, of human intervention in machine learning. Finally, by code freeze, the model was successfully extracting topics from each article and clustering the topics based on similarity to the topics in other articles.

Conclusion

In conclusion, MongoDB provides several different capabilities such as: flexible data model, indexing and high-speed querying, that make training and using machine learning algorithms much easier than with traditional, relational databases. Running MongoDB as the backend database to store and enrich ML training data allows for persistence and increased efficiency.

A final look at the MongoDB pipeline used for this project

If you are interested in this project, feel free to take a look at the code on GitHub, or feel free to contact me via LinkedIn or email.

About the author - Nicholas Png

Nicholas Png is a Data Scientist recently graduated from the Data Science Immersive Program at Galvanize in San Francisco. He is a passionate practitioner of Machine Learning and Artificial Intelligence, focused on Natural Language Processing, Image Recognition, and Unsupervised Learning. He is familiar with several open source databases including MongoDB, Redis, and HDFS. He has a Bachelors of Science in Mechanical Engineering as well as multiple years experience in both software and business development.

Migrating your data from DynamoDB to MongoDB Atlas

MongoDB — Fri, 05 Jan 2018 00:00:00 +0000

There may be a number of reasons you are looking to migrate from DynamoDB to MongoDB Atlas. While DynamoDB may be a good choice for a set of specific use cases, many developers prefer solutions that reduce the need for client-side code or additional technologies as requirements become more sophisticated. They may also want to work with open source technologies or require some degree of deployment flexibility. In this post, we are going to explore a few reasons why you might consider using MongoDB Atlas over DynamoDB, and then look at how you would go about migrating a pre-existing workload.

Get building, faster...

MongoDB Atlas is the best way to consume MongoDB and get access to a developer-friendly experience, delivered as a service on AWS. MongoDB’s query language is incredibly rich and allows you to execute complex queries natively while avoiding the overhead of moving data between operational and analytical engines. With Atlas, you can use MongoDB’s native query language to perform anything from searches on single keys or ranges, faceted searches, graph traversals, and geospatial queries through to complex aggregations, JOINs, and subqueries - without the need to use additional add-on services or integrations.

For example, MongoDB’s aggregation pipeline is a powerful tool for performing analytics and statistical analysis in real-time and generating pre-aggregated reports for dashboarding.

Additionally, MongoDB will give you a few extra things which I think are pretty cool:

Document Size - MongoDB handles documents up to 16MB in size, natively. In DynamoDB, you’re limited to 400KB per item, including the name and any local secondary indexes. For anything bigger, AWS suggests that you split storage between DynamoDB and S3.
Deployment flexibility - Using MongoDB Atlas, you are able to deploy fully managed MongoDB to AWS, Google Cloud Platform, or Microsoft Azure. If you decide that you no longer want to run your database in the cloud, MongoDB can be run in nearly any environment on any hardware so self-managing is also an option.
MongoDB has an idiomatic driver set, providing native language access to the database in dozens of programming languages.
MongoDB Atlas provides a queryable backup method for restoring your data at the document level, without requiring a full restoration of your database.
MongoDB Atlas provides you with over 100 different instance metrics, for rich native alerting and monitoring.
Atlas will assist you in finding the right indexes thanks to Performance Advisor. The Performance Advisor utility is on all the time, helping you make certain that your queries are efficient and fast.

Getting Started

In this tutorial, we'll take a basic data set from an existing DynamoDB table and migrate it to MongoDB Atlas. We'll use a free, M0 cluster so you can do this as well at no cost while you evaluate the benefits of MongoDB Atlas.

This blog post makes a couple of assumptions:

You've installed MongoDB on the computer you'll be importing the data from (we need the mongoimport tool which is included with MongoDB) You've signed up for a MongoDB Atlas Account (the M0 instance is free and fine for this demonstration)

To begin, we'll review our table in AWS:

This table contains data on movies including the year they were released, the title of the film, with other information about the film contained in a subdocument.

We want to take this basic set of data and bring it into MongoDB Atlas for a better method of querying, indexing, and managing our data long term.

First, ensure your application has stopped your writes if you are in production to prevent new entries into your database. You'll likely want to create a temporary landing page and disable new connections to your DynamoDB. Once you've completed this, navigate to your table in your AWS panel.

Click "Actions" at the top after you've selected your table. Find the "Export to .csv" option and click it.

Now you'll have a CSV export of your data from DynamoDB, let's take a quick look:

$ more ~/Downloads/Movies.csv
"year (N)","title (S)","info (M)"
"1944","Arsenic and Old Lace","{ ""actors"" : { ""L"" : [{ ""S"" : ""Cary Grant"" }, { ""S"" : ""Priscilla Lane"" }, { ""S"" : ""Raymond Massey"" }] }, ""directors"" : { ""L"" : [{ ""S"" : ""Frank Capra"" }] }, ""genres"" : { ""L"" : [{ ""S"" : ""Comedy"" }, { ""S"" : ""Crime"" }, { ""S"" : ""Romance"" }, { ""S"" : ""Thriller"" }] }, ""image_url"" : { ""S"" : ""http://ia.media-imdb.com/images/M/MV5BMTI3NTYyMDA0NV5BMl5BanBnXkFtZTcwMjEwMTMzMQ@@._V1_SX400_.jpg"" }, ""plot"" : { ""S"" : ""A drama critic learns on his wedding day that his beloved maiden aunts are homicidal maniacs, and that insanity runs in his family."" }, ""rank"" : { ""N"" : ""4025"" }, ""rating"" : { ""N"" : ""8"" }, ""release_date"" : { ""S"" : ""1944-09-01T00:00:00Z"" }, ""running_time_secs"" : { ""N"" : ""7080"" } }"

Looks good, let's go ahead and start using MongoDB's open source tools to import this to our Atlas cluster.

Import your data Let's start moving our data into MongoDB Atlas. First, launch a new free M0 cluster (M0s are great for demos but you’ll want to pick a different tier if you are going into production). Once you have a new M0 cluster, you can then whitelist your local IP address so that you may access your Atlas cluster.

Next, you'll want to use the mongoimport utility to upload the contents of Movies.csv to Atlas. I'll provide my connection string, which I can get right from my Atlas control panel so that mongoimport can begin importing our data:

Now I can enter this into my mongoimport command along with some other important options:

mongoimport --uri "mongodb://admin:PASSWORD@demoabc-shard-00-00-a7nzr.mongodb.net:27017,demoabc-shard-00-01-a7nzr.mongodb.net:27017,demoabc-shard-00-02-a7nzr.mongodb.net:27017/test?ssl=true&replicaSet=demoabc-shard-0&authSource=admin" --collection movies --file ~/Downloads/Movies.csv --type csv --headerline
2017-11-20T14:02:45.612-0500 imported 100 documents

Now that our documents are uploaded, we can log into Atlas with MongoDB Compass and review our data:

This is cool but I want to do something a little bit more advanced. Luckily, MongoDB’s aggregation pipeline will give us the power to do so.

We'll need to connect to our shell here; I can press the "CONNECT" button within my Atlas cluster’s overview panel and find the connection instructions for the shell.

Once I am logged in, I can start playing with some different aggregations; here is a basic one that tells us the total number of movies released in 1944 in our collection:

db.movies.aggregate(

    // Pipeline
    [
        // Stage 1
        {
            $match: { year : 1944 }
        },

        // Stage 2
        {
            $group: { _id: null, count: { $sum: 1 } }
        },
    ]
);

With DynamoDB, we would have had to connect our database cluster to Amazon EMR, adding cost, complexity, and latency.

You can configure backups, ensure network security and configure additional user roles for your data all from the MongoDB Atlas UI.

Building a voice-activated movie search app powered by Amazon Lex, Lambda, and MongoDB Atlas - Part 3

MongoDB — Sun, 26 Nov 2017 00:00:00 +0000

Introduction

This is Part 3 of our Amazon Lex blog post series. This tutorial is divided into 3 parts:

Part 1: Lex overview, demo scenario and data layer setup

Part 2: Set up and test an Amazon Lex bot

Part 3: Deploy a Lambda function as our Lex bot fulfillment (this blog post)

In this last blog post, we will deploy our Lambda function using the AWS Command Line Interface and verify that the bot fully works as expected. We’ll then review the code that makes up our Lambda function and explain how it works.

Let’s deploy our AWS Lambda function

Please follow the deployment steps available in this GitHub repository. I have chosen to use Amazon’s SAM Local tool to showcase how you can test your Lambda function locally using Docker, as well as package it and deploy it to an AWS account in just a few commands. However, if you’d like to deploy it manually to the AWS Console, you can always use this zip script to deploy it in pretty much the same way I did in this MongoDB Atlas with Lambda tutorial.

Let’s test our Lex bot (end-to-end)

Now that our Lambda fulfillment function has been deployed, let’s test our bot again in the Amazon Lex console and verify that we get the expected response. For instance, we might want to search for all the romance movies Jennifer Aniston starred in, a scenario we can test with the following bot conversation:

As the screenshot above testifies, the Lex bot replies with the full list of Jennifer Aniston’s romance movies retrieved from our movies MongoDB database through our Lambda function. But how does our Lambda function process that request? We’ll dig deeper into our Lambda function code in the next section.

Let's dive into the Lambda function code

Our Lambda function always receives a JSON payload with a structure compliant with Amazon Lex’ input event format (as this event.json file is):

{
  "messageVersion": "1.0",
  "invocationSource": "FulfillmentCodeHook",
  "userId": "user-1",
  "sessionAttributes": {},
  "bot": {
    "name": "SearchMoviesBot",
    "alias": "$LATEST",
    "version": "$LATEST"
  },
  "outputDialogMode": "Text",
  "currentIntent": {
    "name": "SearchMovies",
    "slots": {
      "castMember": "jennifer aniston",
      "year": "0",
      "genre": "Romance"
    }
  }
}

Note that the request contains the bot’s name (SearchMoviesBot) and the slot values representing the answers to the bot’s questions provided by the user.

The Lambda function starts with the exports.handler method which validates the bot’s name and performs some additional processing if the payload is received through Amazon API Gateway (this is only necessary if you want to test your Lambda function through Amazon API Gateway but is not relevant in an Amazon Lex context). It then calls the dispatch() method, which takes care of connecting to our MongoDB Atlas database and passing on the bot’s intent to the query() method, which we’ll explore in a second. Note that the dispatch() method uses the performance optimization technique I highlighted in Optimizing AWS Lambda performance with MongoDB Atlas and Node.js, namely not closing the database connection and using the callbackWaitsForEmptyEventLoop Lambda context property. This allows our bot to be more responsive after the first query fulfilled by the Lambda function.

Let’s now take a closer look at the query() method, which is the soul and heart of our Lambda function. First, that method retrieves the cast member, movie genre, and movie release year. Because these values all come as strings and the movie release year is stored as an integer in MongoDB, the function must convert that value to an integer.

We then build the query we will run against MongoDB:

var castArray = [castMember];

var matchQuery = {
    Cast: { $in: castArray },
    Genres: { $not: { $in: ["Documentary", "News", ""] } },
    Type: "movie"
  };

  if (genre != undefined && genre != allGenres) {
    matchQuery.Genres = { $in: [genre] };
    msgGenre = genre.toLowerCase();
  }

  if ((year != undefined && isNaN(year)) || year > 1895) {
    matchQuery.Year = year;
    msgYear = year;
  }

We first restrict the query to items that are indeed movies (since the database also stores TV series) and we exclude some irrelevant movie genres such as the documentary and news genres. We also make sure we only query movies in which the cast member starred. Note that the $in operator expects an array, which is why we have to wrap our unique cast member into the castArray array. Since the cast member is the only mandatory query parameter, we add it first and then optionally add the Genres and Year parameters if the code determines that they were provided by the user (i.e. the user did not use the All and/or 0 escape values).

The query() method then goes on to define the default response message based on the user-provided parameters. This default response message is used if the query doesn’t return any matching element:

var resMessage = undefined;
  if (msgGenre == undefined && msgYear == undefined) {
    resMessage = `Sorry, I couldn't find any movie for ${castMember}.`;
  }
  if (msgGenre != undefined && msgYear == undefined) {
    resMessage = `Sorry, I couldn't find any ${msgGenre} movie for ${castMember}.`;
  }
  if (msgGenre == undefined && msgYear != undefined) {
    resMessage = `Sorry, I couldn't find any movie for ${castMember} in ${msgYear}.`;
  }
  if (msgGenre != undefined && msgYear != undefined) {
    resMessage = `Sorry, ${castMember} starred in no ${msgGenre} movie in ${msgYear}.`;
  }

The meat of the query() method happens next as the code performs the database query using 2 different methods: the classic db.collection.find() method and the db.collection.aggregate() method. The default method used in this Lambda function is the aggregate one, but you can easily test the find() method by setting the aggregationFramewor_k variable to _false.

In our specific use case scenario (querying for one single cast member and returning a small amount of documents), there likely won’t be any noticeable performance or programming logic impact. However, if we were to query for all the movies multiple cast members each starred in (i.e. the union of these movies, not the intersection), the aggregation framework query is a clear winner. Indeed, let’s take a closer look at the find() query the code runs:

cursor = db.collection(moviesCollection)
      .find(matchQuery, { _id: 0, Title: 1, Year: 1 })
      .collation(collation)
      .sort({ Year: 1 });

It’s a fairly simple query that retrieves the movie’s title and year, sorted by year. Note that we also use the same { locale: "en", strength: 1 } collation we used to create the case-insensitive index on the Cast property in Part 2 of this blog post series. This is critical since the end user might not title case the cast member’s name (and Lex won’t do it for us either).

The simplicity of the query is in contrast to the relative complexity of the app logic we have to write to process the result set we get with the find() method:

var maxYear, minYear;
for (var i = 0, len = results.length; i < len; i++) { 
    castMemberMovies += `${results[i].Title} (${results[i].Year}), `;
}

 //removing the last comma and space
castMemberMovies = castMemberMovies.substring(0, castMemberMovies.length - 2);

moviesCount = results.length;
var minYear, maxYear;
minYear = results[0].Year;
maxYear = results[results.length-1].Year;
yearSpan = maxYear - minYear;

First, we have to iterate over all the results to concatenate its Title and Year properties into a legible string. This might be fine for 20 items, but if we had to process hundreds of thousands or millions of records, the performance impact would be very noticeable. We further have to remove the last period and white space characters of the concatenated string since they’re in excess. We also have to manually retrieve the number of movies, as well as the low and high ends of the movie release years in order to compute the time span it took the cast member to shoot all these movies. This might not be particularly difficult code to write, but it’s clutter code that affects app clarity. And, as I wrote above, it definitely doesn’t scale when processing millions of items.

Contrast this app logic with the succinct code we have to write when using the aggregation framework method:

for (var i = 0, len = results.length; i < len; i++) { 
    castMemberMovies = results[i].allMovies;
    moviesCount = results[i].moviesCount;
    yearSpan = results[i].timeSpan;
}

The code is not only much cleaner and concise now, it’s also more generic, as it can handle the situation where we want to process movies for each of multiple cast members. You can actually test this use case by uncommenting the following line earlier in the source code:

castArray = [castMember, "Angelina Jolie"]

and by testing it using this SAM script.

With the aggregation framework, we get the correct raw and final results without changing a single line of code:

However, the find() method’s post-processing requires some significant effort to fix this incorrect output (the union of comedy movies in which Angelina Jolie or Brad Pitt starred in, all incorrectly attributed to Brad Pitt):

We were able to achieve this code conciseness and correctness by moving most of the post-processing logic to the database layer using a MongoDB aggregation pipeline:

cursor = db.collection(moviesCollection).aggregate(
      [
        { $match: matchQuery },
        { $sort: { Year: 1 } },
        unwindStage,
        castFilterStage,
        { $group: {
            _id: "$Cast",
            allMoviesArray: {$push: {$concat: ["$Title", " (", { $substr: ["$Year", 0, 4] }, ")"] } },
            moviesCount: { $sum: 1 },
            maxYear: { $last: "$Year" },
            minYear: { $first: "$Year" }
          }
        },
        {
          $project: {
            moviesCount: 1,
            timeSpan: { $subtract: ["$maxYear", "$minYear"] },
            allMovies: {
              $reduce: {
                input: "$allMoviesArray",
                initialValue: "",
                in: {
                  $concat: [
                    "$$value",
                    {
                      $cond: {
                        if: { $eq: ["$$value", ""] },
                        then: "",
                        else: ", "
                      }
                    },
                    "$$this"
                  ]
                }
              }
            }
          }
        }
      ],
      {collation: collation}

);

This aggregation pipeline is arguably more complex than the find() method discussed above, so let’s try to explain it one stage at a time (since an aggregation pipeline consists of stages that transform the documents as they pass through the pipeline):

$match stage: performs a filter query to only return the documents we’re interested in (similarly to the find() query above).
$sort stage: sorts the results by year ascending.
$unwind stage: splits each movie document into multiple documents, one for each cast member in the original document. For each original document, this stage unwinds the Cast array of cast members and creates separate, unique documents with the same values as the original document, except for the Cast property which is now a string value (equal to each cast member) in each unwinded document. This stage is necessary to be able to group by only the cast members we’re interested in (especially if there are more than one). The output of this stage may contain documents with other cast members irrelevant to our query, so we must filter them out in the next stage.
$match stage: filters the deconstructed documents from the $unwind stage by only the cast members we’re interested in. This stage essentially removes all the documents tagged with cast members irrelevant to our query.
$group stage: groups movies by cast member (for instance, all movies with Brad Pitt and all movies with Angelina Jolie, separately). This stage also concatenates each movie title and release year into the Title (Year) format and adds it to an array called allMoviesArray (one such array for each cast member). This stage also computes a count of all movies for each cast member, as well as the earliest and latest year the cast member starred in a movie (of the requested movie genre, if any). This stage essentially performs most of the post-processing we previously had to do in our app code when using the find() method. Because that post-processing now runs at the database layer, it can take advantage of the database server’s computing power along with the distributed system nature of MongoDB (in case the collection is partitioned across multiple shards, each shard performs this stage independently of the other shards).
$project stage: last but not least, this stage performs a $reduce operation (new in MongoDB 3.4) to concatenate our array of ‘Title (Year)’ strings into one single string we can use as is in the response message sent back to the bot.

Once the matching movies have been retrieved from our MongoDB Atlas database, the code generates the proper response message and sends it back to the bot according to the expected Amazon Lex response format:

if (msgGenre != allGenres) {
                resMessage = `${toTitleCase(castMember)} starred in 
                the following ${moviesCount>1?moviesCount+" ":""}
                ${msgGenre.toLowerCase()} movie(s)${yearSpan>0?" over " 
                + yearSpan +" years":""}: ${castMemberMovies}`;
} else {
    resMessage = `${toTitleCase(castMember)} starred in the following 
    ${moviesCount>1?moviesCount+" ":""}movie(s)${yearSpan>0?" over " 
    + yearSpan +" years":""}: ${castMemberMovies}`;
}
if (msgYear != undefined) {
    resMessage = `In ${msgYear}, ` + resMessage;

callback(
    close(sessionAttributes, "Fulfilled", {
        contentType: "PlainText",
        content: resMessage
    })
);

Our Jennifer Aniston fan can now be wowed by the completeness of our bot's response!

Wrap-up and next steps

This completes our Lex blog post series and I hope you enjoyed reading it as much as I did writing it.

In this final blog post, we tested and deployed a Lambda function to AWS using the SAM Local tool.

We also learned:

How a Lambda function processes a Lex request and responds to it using Amazon Lex’ input and out event format.

How to use a case-insensitive index in a find() or aggregate() query

How to make the most of MongoDB’s aggregation framework to move complexity from the app layer to the database layer

As next steps, I suggest you now take a look at the AWS documentation to learn how to deploy your bot to Facebook Messenger , Slack or to your own web site.

Happy Lex-ing!

_About the Author - Raphael Londner _

Raphael Londner is a Principal Developer Advocate at MongoDB, focused on cloud technologies such as Amazon Web Services, Microsoft Azure and Google Cloud Engine. Previously he was a developer advocate at Okta as well as a startup entrepreneur in the identity management space. You can follow him on Twitter at @rlondner

Building a voice-activated movie search app powered by Amazon Lex, Lambda, and MongoDB Atlas - Part 2

MongoDB — Mon, 13 Nov 2017 00:00:00 +0000

Introduction

Before you read this article, take a look at Part 1 for a brief overview of Amazon Lex and instructions to set up our movie database with MongoDB Atlas, our fully managed database service.

As a reminder, this tutorial is divided into 4 parts:

Part 1: Lex overview, demo scenario and data layer setup

Part 2: Set up and test an Amazon Lex bot (this post)

Part 3: Deploy a Lambda function as our Lex bot fulfillment

In this blog post, we will set up our Lex bot in the AWS Console and verify that its basic flow works as expected. We’ll implement the business logic (which leverages MongoDB) in Part 3 of this post series.

Amazon Lex bot setup instructions

In this section, we will go through the whole process of creating our SearchMovies bot while explaining the architectural decisions I made.

After signing in into the AWS Console, select the Lex service (in the Artificial Intelligence section) and press the Create button.

Select the Custom bot option and fill out the form parameters as follows:

Bot name: SearchMoviesBot

Output voice: None

Session timeout: 5

COPPA: No

Press the Create button at the bottom of the form.

A new page appears, where you can create an intent. Press the Create Intent button and in the Add intent pop-up page, click the Create new intent link and enter SearchMovies in the intent name field.

In the Slot types section, add a new slot type with the following properties:

Slot type name: MovieGenre

Description: Genre of the movie (Action, Comedy, Drama…)

Slot Resolution: Restrict to Slot values and Synonyms

Values: All, Action, Adventure, Biography, Comedy, Crime, Drama, Romance, Thriller

You can add synonyms to all these terms (which strictly match the possible values for movie genres in our sample database), but the most important one for which you will want to configure synonyms is the Any value. We will use it as a keyword to avoid filtering on movie genre in scenarios when the user cannot qualify the genre of the movie he’s looking for or wants to retrieve all the movies for a specific cast member. Of course, you can explore the movie database on your own to identify and add other movie genres I haven’t listed above. Once you’re done, press the Save slot type button.

Next, in the Slots section, add the following 3 slots:

genre

Type: MovieGenre

Prompt: I can help with that. What's the movie genre?

Required: Yes

castMember

Type: AMAZON.Actor

Prompt: Do you know the name of an actor or actress in that movie?

Required: Yes

year

Type: AMAZON.FOUR_DIGIT_NUMBER

Prompt: Do you know the year {castMember}'s movie was released? If not, just type 0

Required: Yes

Press the Save Intent button and verify you have the same setup as shown in the screenshot below:

The order of the slots is important here: once the user’s first utterance has been detected to match a Lex intent, the Lex bot will (by default) try to collect the slot values from the user in the priority order specified above by using the Prompt texts for each slot. Note that you can use previously collected slot values in subsequent slot prompts, which I demonstrate in the ‘year’ slot. For instance, if the user answered Angelina Jolie to the castMember slot prompt, the year slot prompt will be: ‘Do you know the year Angelina Jolie’s movie was released? If not, just type 0

Note that it’s important that all the slots are marked Required. Otherwise, the only opportunity for the user to specify them is to mention them in the original utterance. As you will see below, we will provide such ability for Lex to identify slots right from the start, but what if the user chooses to kick off the process without mentioning any of them? If the slots aren’t required, they are by default overlooked by the Lex bot so we need to mark them Required to offer the user the option to define them.

But what if the user doesn’t know the answer to those prompts? We’ve handled this case as well by defining "default" values: All for the genre slot and 0 for the year slot. The only mandatory parameter the bot’s user must provide is the cast member’s name; the user can restrict the search further by providing the movie genre and release year.

Last, let’s add the following sample utterances that match what we expect the user will type (or say) to launch the bot:

I am looking for a movie

I am looking for a {genre} movie

I am looking for a movie released in {year}

I am looking for a {genre} movie released in {year}

In which movie did {castMember} play

In which movie did {castMember} play in {year}

In which {genre} movie did {castMember} play

In which {genre} movie did {castMember} play in {year}

I would like to find a movie

I would like to find a movie with {castMember}

Once the utterances are configured as per the screenshot below, press Save Intent at the bottom of the page and then Build at the top of the page. The process takes a few seconds, as AWS builds the deep learning model Lex will use to power our SearchMovies bot.

It’s now time to test the bot we just built!

Testing the bot

Once the build process completes, the test window automatically shows up:

Test the bot by typing (or saying) sentences that are close to the sample utterances we previously configured. For instance, you can type ‘Can you help me find a movie with Angelina Jolie?’ and see the bot recognize the sentence as a valid kick-off utterance, along with the {castMember} slot value (in this case, ‘Angelina Jolie’). This can be verified by looking at the Inspect Response panel:

At this point, the movie genre hasn’t been specified yet, so Lex prompts for it (since it’s the first required slot). Once you answer that prompt, notice that Lex skips the second slot ({castMember}) since it already has that information.

Conversely, you can test that the ‘Can you help me find a comedy movie with angelina jolie?’ utterance will immediately prompt the user to fill out the {year} slot since both the {castMember} and {genre} values were provided in the original utterance:

An important point to note here is that enumeration slot types (such as our MovieGenre type) are not case-sensitive. This means that both "comedy" and “coMeDy” will resolve to “Comedy”. This means we will be able to use a regular index on the Genres property of our movies collection (as long as our enumeration values in Lex match the Genres case in our database).

However, the AMAZON.Actor type is case sensitive - for instance, "angelina jolie" and “Angelina Jolie” are 2 distinct values for Lex. This means that we must define a case-insensitive index on the Cast property (don’t worry, there is already such an index, called ‘Cast_1’ in our sample movie database). Note that in order for queries to use that case-insensitive index, we’ll have to make sure our find() query specifies the same collation as the one used to create the index (locale=’en’ and strength=1). But don’t worry for now: I’ll make sure to point it out again in Part 3 when we review the code of our chat’s business logic (in the Lambda function we’ll deploy).

Summary

In this blog post, we created the SearchMovies Lex bot and tested its flow. More specifically, we:

Created a custom Lex slot type (MovieGenre)

Configured intent slots

Defined sample utterances (some of which use our predefined slots)

Tested our utterances and the specific prompt flows each of them starts

We also identified the case sensitivity of a built-in Lex slot that adds a new index requirement on our database.

In Part 3, we’ll get to the meat of this Lex blog post series and deploy the Lambda function that will allow us to complete our bots’ intended action (called ‘fulfillment’ in the Lex terminology).

Meanwhile, I suggest the following readings to further your knowledge of Lex and MongoDB:

Lex built-in slot types

Case-insensitive indexes

_About the Author - Raphael Londner _

Building a voice-activated movie search app powered by Amazon Lex, Lambda, and MongoDB Atlas - Part 1

MongoDB — Sun, 12 Nov 2017 00:00:00 +0000

Introduction

This tutorial is divided into 3 parts:

Part 1: Lex overview, demo scenario and data layer setup

Part 2: Set up and test an Amazon Lex bot

Part 3: Deploy a Lambda function as our bot fulfillment logic

Since this is Part 1 of our blog series, let’s dig right into it now.

What is Amazon Lex?

Amazon Lex is a deep learning service provided by AWS to power conversational bots (more commonly known as "chatbots"), which can either be text- or voice-activated. It’s worth mentioning that Amazon Lex is the technology that powers Alexa, the popular voice service available with Amazon Echo products and mobile applications (hence the Lex name). Amazon Lex bots are built to perform actions (such as ordering a pizza), which in Amazon lingo is referred to as intents.

Note that each bot may perform multiple intents (such as "booking a flight" and “booking a hotel”), which can each be kicked off by distinct phrases (called utterances ). This is where the Natural Language Understanding (NLU) power of Lex bots shines — you define a few sample utterances and let the Lex AI engine infer all the possible variations of these utterances (another interesting aspect of Lex’ AI engine is its Automatic Speech Recognition technology, which allows).

Let's illustrate this concept with a fictitious, movie search scenario. If you create a SearchMovies intent, you may want to define a sample utterance as “I would like to search for a movie”, since you expect it to be what the user will say to express their movie search intention. But as you may well know, human beings have a tendency to express the same intention in many different ways, depending on their mood, cultural background, language proficiency, etc... So if the user types (or says) “I’d like to find a movie” or “I’d like to see a movie”, what happens? Well, you’ll find that Lex is smart enough to figure out that those phrases have the same meaning as “I would like to search for a movie” and consequently trigger the “SearchMovies” intent.

However, as our ancestors the Romans would say, dura lex sed lex and if the user’s utterance veers too far away from the sample utterances you have defined, Lex would stop detecting the match. For instance, while "I’d like to search for a motion picture" and “I’d like to see a movie” are detected as matches of our sample utterance (I would like to search for a movie), “I’d like to see a motion picture” is not (at least in the tests I performed).

The interim conclusion I drew from that small experiment is that Lex’ AI engine is not yet ready to power Blade Runner’s replicants or Westworld’s hosts, but it definitely can be useful in a variety of situations (and I’m sure the AWS researchers are hard at work to refine it).

In order to fulfill the intent (such as providing the name of the movie the user is looking for), Amazon Lex would typically need some additional information, such as the name of a cast member, the movie genre and the movie release year. These additional parameters are called slots in the Lex terminology and theye are collected one at a time after a specific Lex prompt.

For instance, after an utterance is detected to launch the SearchMovies intent, Lex may ask the following questions to fill all the required slots:

What's the movie genre? (to fill the genre slot)

Do you know the name of an actor or actress with a role in that movie? (to fill the castMember slot)

When was the movie was released? (to fill the year slot)

Once all the required slots have been filled, Lex tries to fulfill the intent by passing all the slot values to some business logic code that performs the necessary action — e.g, searching for matching movies in a movie database or booking a flight. As expected, AWS promotes its own technologies so Lex has a built-in support for Lambda functions, but you can also "return parameters to the client", which is the method you’ll want to use if you want to process the fulfillment in your application code (used in conjunction with the Amazon Lex Runtime Service API).

Demo bot scenario

Guess what? This will be a short section since the scenario we will implement in this blog post series is exactly the "fictitious example" I described above (what a coincidence!).

Indeed, we are going to build a bot allowing us to search for movies among those stored in a movie database. The data store we will use is a MongoDB database running in MongoDB Atlas, which is a good serverless fit for developers and DevOps folks who don’t want to set up and manage infrastructure.

Speaking of databases, it’s time for us to deploy our movie database to MongoDB Atlas before we start building our Lex bot.

Data setup and exploration

To set up the movie database, follow the instructions available in this GitHub repository.

Note that in order to keep the database dump file under GitHub's 100MB limit per file, the database I have included isn’t complete (for instance, it doesn’t include movies released prior to 1950 - sincere apologies to Charlie Chaplin fans).

Now, let’s take a look at a typical document in this database (Mr. & Mrs. Smith released in 2005):

{
    "_id" : ObjectId("573a13acf29313caabd287dd"),
    "ID" : 356910,
    "imdbID" : "tt0356910",
    "Title" : "Mr. & Mrs. Smith",
    "Year" : 2005,
    "Rating" : "PG-13",
    "Runtime" : "120 min",
    "Genre" : "Action, Comedy, Crime",
    "Released" : "2005-06-10",
    "Director" : "Doug Liman",
    "Writer" : "Simon Kinberg",
    "Cast" : [
        "Brad Pitt",
        "Angelina Jolie",
        "Vince Vaughn",
        "Adam Brody"
    ],
    "Metacritic" : 55,
    "imdbRating" : 6.5,
    "imdbVotes" : 311244,
    "Poster" : "http://ia.media-imdb.com/images/M/MV5BMTUxMzcxNzQzOF5BMl5BanBnXkFtZTcwMzQxNjUyMw@@._V1_SX300.jpg",
    "Plot" : "A bored married couple is surprised to learn that they are both assassins hired by competing agencies to kill each other.",
    "FullPlot" : "John and Jane Smith are a normal married couple, living a normal life in a normal suburb, working normal jobs...well, if you can call secretly being assassins \"normal\". But neither Jane nor John knows about their spouse's secret, until they are surprised to find each other as targets! But on their quest to kill each other, they learn a lot more about each other than they ever did in five (or six) years of marriage.",
    "Language" : "English, Spanish",
    "Country" : "USA",
    "Awards" : "9 wins & 17 nominations.",
    "lastUpdated" : "2015-09-04 00:02:26.443000000",
    "Type" : "movie",
    "Genres" : [
        "Action",
        "Comedy",
        "Crime"
    ]
}

I have highlighted the properties of interest to our use case. Each movie record typically includes the principal cast members (stored in a string array), a list of genres the movie can be categorized in (stored in a string array) and a release year (stored as a 4-digit integer).

These are the 3 properties we will leverage in our Lex bot (which we will create in Part 2) and consequently in our Lambda function (which we will build in Part 3) responsible for querying our movies database.

Storing these properties as string arrays is key to ensure that our bot is responsive: they allow us to build small, multikey indexes that will make our queries much faster compared to full collection scans (which regex queries would trigger).

Summary

In this blog post, we introduced the core concepts of Amazon Lex and described the scenario of the Lex bot we’ll create in Part 2. We then deployed a sample movie database to MongoDB Atlas, explored the structure of a typical movie document and identified the fields we’ll use in the Lambda function we’ll build in Part 3. We then reviewed the benefits of using secondary indexes on these fields to speed up our queries.

I have only scratched the surface on all these topics, so here is some additional content for those of you who strive to learn more:

How Amazon Lex works

MongoDB documentation on indexes and multikey indexes

Index Tuning and Evaluation using MongoDB webinar by Daniel Farrell

I hope this introduction to Lex has drawn enough interest for you to continue our journey with Part 2!

About the Author - Raphael Londner

Building a NodeJS App with MongoDB Atlas and AWS Elastic Container Service - Part 1

MongoDB — Mon, 30 Oct 2017 00:00:00 +0000

Building apps has never been faster, thanks in no small part to advancements in virtualization. Lately, I’ve been exploring better ways to build and deploy apps without having to worry about ongoing front-end work, such as patching Linux machines, replacing them when they fail, or even having to SSH into systems.

In this two-part tutorial, I will share how to build a Node.js app with MongoDB Atlas and deploy it easily using Amazon EC2 Container Service (ECS).

In part one, we'll cover:

Using Docker for app deployment
Building a MongoDB Atlas Cluster
Connecting it to a Node.js-based app which allows full CRUD operations
Launching it locally in a development environment.

In part two, we'll get our app running in a Linux container on AWS by installing some tools, configuring a few environment variables, and launching a Docker cluster.

By the end of this two-part tutorial, you'll see how to work with Node.js to start an application, how to build a MongoDB cluster for the app, then finally, how to use AWS to deploy that app in containers.

A Quick Intro To Docker

(Already know about Containers & Docker? Skip ahead to the tutorial.)

Docker makes it simple for developers to build, ship, and run distributed applications across different environments. It does this by helping you “containerize” your application.

What's a container? The Docker website defines a container as "a way to package software in a format that can run isolated on a shared operating system". More broadly, containers are a form of system virtualization that allows you to run an application and its dependencies in resource-isolated processes. Using containers, you can easily package application code, configurations, and dependencies into easy-to-use building blocks specifically built to run your code. This ensures that you can deploy quickly, reliably, and consistently regardless of the deployment environment, and allows you to focus more on building your app. Moreover, containers make it easier to manage microservices and support CI/CD workflows where incremental changes are isolated, tested, and released with little to no impact to production systems.

Getting started

In the example we'll walk through in this post, we're going to build a simple records system using MongoDB, Express.js, React.js, and Node.js called mern-crud. We'll combine several common services on the AWS cloud platform to build a fully functional, containerized application with auto-scaling and load balancing. The core of our front end will be run on Amazon EC2 Container Service (ECS).

In part one, I'll set up our environment and build the application on my local workstation. This will show you how to begin using MongoDB Atlas along with Node.js. In the second part we'll wrap everything up by deploying to ECS with coldbrew-cli, an easy ECS command line utility.

Below you'll find the basics of building an application that will allow you to perform CRUD operations in MongoDB.

Requirements:

AWS Account
IAM Access Key
coldbrew-cli
MongoDB Atlas Cluster (M0, the free tier of Atlas, is fine)
Docker (on local computer)
mern-crud github repo
git
Node.js installed locally with Boron LTS (v6.11.2)

Amazon EC2 Container Service (ECS) allows you to deploy and manage your Docker instances using your AWS control panel. For a full breakdown of how it works, I recommend checking out Abby Fuller's "Getting Started with ECS" demo, which includes details on the role of each part of the underlying Docker deployment and how they work together to provide you with easily repeatable and deployable applications.

Configure AWS and coldbrew-cli

AWS Environment Variables

Get started by signing up for your AWS account and creating your Identity and Access Management (IAM) keys. You can review the required permissions from the coldbrew-cli docs. The IAM keys will be required to authenticate against the AWS API; we can export these as environment variables in the command shell we’ll use to run coldbrew-cli commands:

export AWS_ACCESS_KEY_ID="PROVIDEDBYAWS
export AWS_SECRET_ACCESS_KEY="PROVIDEDBYAWS

This permits coldbrew-cli to use our user rights within AWS to create the appropriate underlying infrastructure.

Getting started with coldbrew-cli

Next, we'll work with coldbrew-cli, an open source automation utility for deploying AWS Docker containers. It removes many of the steps associated with creating our Docker images, creating the environment, and auto-scaling the AWS groups associated with our Node.js web servers on AWS. The best part of coldbrew is that it's highly portable and configurable. The coldbrew documentation states the following:_coldbrew-cli operates on two simple concepts: applications (apps) and clusters.

An app is the minimum deployment unit.
One or more apps can run in a cluster, and, they share the computing resources._We'll use this utility to simplify many of the common tasks one would have to do when creating a production ECS cluster. It will handle the following on our behalf:
Creating a VPC (You may specify an existing VPC if needed)
Creating Security Groups
Setting up Elastic Load Balancing & Auto Scaling Groups
Building the Docker Containers
Building the Docker Image
Pushing the Docker Image to ECR repository
Deploying image to containers Manually, all of the tasks listed above would take a nontrivial effort. To install coldbrew-cli, we can download CLI executable (coldbrew or coldbrew.exe) and put it in our $PATH.

$ which coldbrew
'usr/local/bin/coldbrew

Prepare our app and MongoDB Atlas

ECS will allow us to run a stateless front end to our application. All of our data will be stored in MongoDB Atlas, the best way to run MongoDB on AWS. In this section, we’ll build our database cluster and connect our application. We can rely on coldbrew commands to manage deployments of new versions of our application going forward.

Your Atlas Cluster

Building an Atlas cluster is easy and free. If you need help doing so, check out this tutorial video I made that will walk you through the process. Once our free M0 cluster is built, it’s easy to whitelist the IP addresses of our ECS containers so that we can store data in MongoDB.

I named my cluster "mern-demo”.

Downloading and configuring the App

Let's get started by downloading the required repository:

$ git clone git@github.com:cefjoeii/mern-crud.git
Cloning into 'mern-crud'...
remote: Counting objects: 303, done.
remote: Total 303 (delta 0), reused 0 (delta 0), pack-reused 303
Receiving objects: 100% (303/303), 3.25 MiB | 0 bytes/s, done.
Resolving deltas: 100% (128/128), done.

Let's go into the repository we cloned and have a look at the code:

The server.js app is reliant on the database configuration stored in the config/db.js file. We'll use this to specify our M0 cluster in MongoDB Atlas, but we'll want to ensure we do so using user credentials that follow the principle of least privilege.

Securing our app

Let's create a basic database user to ensure that we are not giving our application full rights to administer the database. All this basic user requires is read and write access.

In the MongoDB Atlas UI, click the "Security" option at the top of the screen and then click into “MongoDB Users”

Now click the "Add new user" button and create a user with read and write access to the namespace data is being written to within our cluster.

Enter the user name (I will select mernuser)
Click the "Show Advanced Options" link
Select role "readWrite" in the "Database" section "merndb", and leave “collection” blank
Create a password and save it somewhere to use in your connection string
Click "Add User"

We now have a user ready to access our application's MongoDB Atlas database cluster. It's time to get our connection string and start prepping the application.

Linking our Managed Cluster to our App

Our connection string can be accessed by going to the "Clusters" section in Atlas, and clicking the "Connect" button.

This section provides an interface to whitelist IP addresses and methods to connect to your cluster. Let's choose the "Connect Your Application" option and copy our connection string. Let's copy the connection string and take a look at what we need to modify:

The default connection string provides us with a few parts that require our changes, highlighted in red below:

mongodb://mernuser:demopass@mern-demo-shard-00-00-x8fks.mongodb.net:27017,mern-demo-shard-00-01-x8fks.mongodb.net:27017,mern-demo-shard-00-02-x8fks.mongodb.net:27017/merndb?ssl=true&replicaSet=mern-demo-shard-0&authSource=admin

The username and password should be replaced with the credentials we created earlier. We also need to specify the merndb database our data will be stored in.

Let's add our connection string to the config/db.js file and then compile our application.

Save the file, then import the application’s required dependencies from the root directory of the repository with the "npm install" command:

Let's whitelist our local IP address so we can start our app and test it's working locally before we deploy it to Docker. We can click "CONNECT" in the MongoDB Atlas UI and then select "ADD CURRENT IP ADDRESS" to whitelist our local workstation:

We can now test the app and see that it starts as expected:

$ npm start
> mern-crud@0.1.0 start /Users/jaygordon/work/mern-crud
> node server

Listening on port 3000
Socket mYwXzo4aovoTJhbRAAAA connected.
Online: 1
Connected to the database.

Let's test http://localhost:3000 in a browser:

The hardest part is over, the next part is deploying with coldbrew-cli, which is just a few commands. In part two of this series, we’ll cover how to launch with coldbrew-cli and then destroy our app when we're finished.

If you’re new to managed MongoDB services, we encourage you to start with our free tier. For existing customers of third party service providers, be sure to check out our migration offerings and learn about how you can get 3 months of free service.