Serverless is quite a buzz word this year, isn’t it? It’s a shiny new term that caused many debates and even conflicts among developers. In fact, at the moment you are reading this (assuming in 2017), there are already many meet-ups and conferences dedicated to the serverless architecture, its benefits, and pitfalls. So, what is serverless architecture all about? Like for the many new concepts in technology these days, there is no straightforward answer to this question.
Before defining what serverless is, let’s first define what serverless isn’t so we can skip confusion that this word itself insinuates. This term doesn’t mean that there are no servers, just that physical, as well as virtual infrastructure, is hidden from a developer. This means that the developer is basically using some third-party to handle infrastructural problems for her. She expects from that third-party to enable resources that are necessary for her application or function (more on this later) to execute in a proper manner.
By now, we as a community agreed that when some application is serverless, it uses one of the two concepts:
- Backend as a Service (BaaS) concept – This application depends on third-party service that is running on the cloud.
- Function as a Service (Faas) concept – This application depends on a custom code that has been run in short-living containers.
These concepts are converging. For example, some of the solutions that started as a BaaS ended up being FaaS (Auth0). Also, BaaS solutions usually have FaaS integrated somewhere in their architecture because of a need to create custom backend functionalities.
Serverless architecture pushes towards further shredding of the backend architecture. In the similar way that microservices broke down big monolith services into smaller ones, with a specific purpose, serverless architecture aims to break down microservices in even smaller units. For example, let’s take a look at the solution that we provided for the previous post. We used the database called –
blog, with a collection called –
user. This collection contained document for each user. In this solution, backend acted as a certain service, which provided CRUD operations for the frontend part of the application.
Serverless architecture would push into the direction of separation all those CRUD features into finer grained parts with defined functionality. Each of these features would still have exposed API, but it would be executed into smaller “service”.
Mongo Atlas is basically Mongo’s response to this new and rising world. In its essence, it is Database as a Service (DaaS), i.e., MongoDB hosted on the cloud. The general idea is that a developer no longer needs to take care of database management and to have an operating and distributed database cluster. Also, this way you can use all MongoDB features inside of serverless architecture.
Manage a Cluster
The first step on your MongoDB Atlas journey would be creating an account on MongoDB cloud service. Once you do that, cluster creation dialog will be automatically opened.
While doing this, I was very inspired, so I named my first cluster –
FirstCluster. Also, since guys at MongoDB were cool and gave me some free coupons, I created the cluster on one of the servers in Frankfurt, for 0.09$ per hour. There is a free option if you want to test MongoDB Atlas so you can create Free Tier cluster. You can deploy only one Free Tier cluster per Atlas project.
After that, the number of nodes for cluster has to be set. If you need to know more about clusters, nodes and configuring MongoDB, check out one of my previous articles.
And finally, to fully deploy first Atlas cluster, you have to select username and password that will be used for administrative purposes, and click Deploy.
And voila, the Atlas cluster is created:
Connect to a Cluster from Mongo Shell
Next thing you want to do is to connect to the newly created cluster. There are multiple ways to connect to this cluster, from Mongo Shell or from code. In this example, I will show how to connect to the Atlas cluster using Mongo Shell. Before we proceed, there are a few tasks we need to do beforehand. The first task is, of course, having Mongo installed on your computer. You can read how you can do that here.
The second task is having to add your IP address to clusters whitelist. That is done by clicking Add Current IP Address. If you want to connect to the cluster from a different machine, you can click Add Entry and enter the IP of that machine. Once that is out of the picture, click on Connect with the Mongo Shell. There, you will be provided with the connection string that you can use for connection from the shell.
If you have doubts how to connect to MongoDB server, check out one of my previous posts. One note is that you have to enter the password you’ve created once you were setting up the cluster. Here is how I’ve done it:
Once I’ve done that, I was able to do everything as before, like creating a database, using it, adding collection and finally adding documents to that collection.
Connect to a Cluster from Application
Surely, you will probably want to connect to the cluster from one of your applications. This is also simplified and all you need to do is use simple connection string which is provided once you click on Connect your Application.
In that section, you can find examples of how you can connect to your Atlas cluster using one of Mongo Drivers.
Mongo Atlas has done a great job moving all MongoDB features into the cloud. If you are in a need for document NoSQL database in your serverless architecture, Atlas is a good choice.
Read full MongoDB Serial here.
Read more posts from the author at Rubik’s Code.