Build and Packaging
Test and Validation
The course is part of this learning path
This course is designed to help you master the skills of designing and building cloud-native applications.
Observe first hand the end-to-end process of building a sample cloud-native application using React, Go, MongoDB, and Docker. By taking this course you'll not only get to see firsthand the skills required to create a robust, enterprise-grade, cloud-native application, but you'll also be able to apply them yourself as all code and deployment assets are available for you to perform your own deployment:
What you'll learn:
- Understand the basic principles of building cloud-native applications
- Understand the benefits of using React for frontend web development
- Understand the benefits of using Go for backend API development
- Understand the benefits of using MongoDB as a database system
- And finally, you’ll learn how to package and run microservices as lightweight containers using Docker
This training course provides you with several hands-on demonstrations where you will observe first hand how to
- Build a React-based web frontend
- Build a Go-based API
- Deploy and configure a MongoDB database
- Deploy the full end-to-end application to Docker running locally
- A basic understanding of web-based software development
- Previous exposure to containers and containerization - in particular, docker
- Anyone interested in learning how to architect cloud-native applications
- Anyone interested in using modern development tools such as React, Go, MongoDB and Docker
- Anyone interested in containerization
- DevOps Practitioners
Okay, welcome back. In this lecture, we'll provide a quick review of the MongoDB database as used by the API. Note: unlike the previous two lectures, which concentrated on the front end API implementations and for which involved custom-developed source code, there is no source code for the database implementation since we're just performing an install and configuration of MongoDB. But before we continue lets now quickly review the choice of MongoDB for storing and persisting our programming language data as well as our vote counts.
MongoDB provides a feature-rich schemaless or NoSQL approach to storing data. The main benefit of using this type of database is you can store documents or objects in their native data structures without any translation or normalization required. It is for this reason that this type of database is ideal when creating APIs that deal with JSON-formatted data and is the main reason we're using it to manage the data that our API uses.
Additional benefits considered in choosing MongoDB for our backing database are: it's very easy to scale out the database using its replicaSet technology, for redundancy and performance reasons. In the Kubernetes Cluster demonstration given in the next course, we'll deploy and set up a MongoDB replicaSet. Its online documentation is excellent. It provides dynamic or flexible schemas. This accommodates prototyping and the evolution of data structures. Complex queries are supported although we aren't in need of using them for the sample application. And an official MongoDB Go driver is now available and supports connectivity from go-based applications and for which we'll use for our connectivity requirements from the API.
The MongoDB setup, configuration, and data structures as used by our sample application are simple and easy. We'll configure a single database named LangDB which contains a single collection named languages. An example document that will be stored within our languages collection is shown here. In this case, the document represents the programming language details for the 'go' language. The initial load for the sample database will be done using the following Mongo commands. After the initial load, the document data is mostly static aside from the vote field, whose values are incremented by 1 each time a user clicks on the respective +1 voting ballot.
The MongoDB service, or DMON, will be configured to start with the following parameters:
--bind_ip is set to
0.0.0.0. This is to allow all incoming connections, regardless of origin.
--replSet is set to
rs0, which will be the name of our replicaSet when we deploy it in the next course into our Kubernetes Cluster.
--wiredTigerCacheSizeGB defines the maximum size of the internal cache.
You may have noticed that the off parameter has not been specified, meaning that authentication on connections is not required. This is, as previously mentioned, to make the demonstration deployment quicker and easier. In production, authentication is wisely encouraged and should definitely be configured and turned on. We'll explain more on this later when we get into the demonstration mode. As previously mentioned, in the next course, when we deploy our application into a Kubernetes Cluster, we'll configure the MongoDB database as a replicaSet with three nodes. The configuration will ensure that the data is replicated across the three nodes ensuring that the data is redundantly available. Okay, that completes this lecture on our choice of MongoDB for our back-end database and the features that it provides.
Go ahead and close this lecture and we'll see you shortly in the next one where we'll being demonstrating how to build, package, and deploy our cloud-native application using microservices using Docker locally. In doing so, this will allow us to prepare and validate the solution before deploying it into a Kubernetes Cluster.
About the Author
Jeremy is the DevOps Content Lead at Cloud Academy where he specializes in developing technical training documentation for DevOps.
He has a strong background in software engineering, and has been coding with various languages, frameworks, and systems for the past 20+ years. In recent times, Jeremy has been focused on DevOps, Cloud, Security, and Machine Learning.
Jeremy holds professional certifications for both the AWS and GCP cloud platforms.