The course is part of this learning path
Build and Packaging
Test and Validation
This training 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 containerisation - 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 containerisation
- DevOps Practitioners
- [Instructor] Okay, welcome back. In this lecture we'll provide a quick review of the MongoDB database as used by the API, night. And like the previous 2 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 no quickly review the choice of MongoDB for storing and persisting your programming language data as well as our vote counts.
MongoDB provides a feature rich schemer-less or no-sequel 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 a API's that deal with JSON formatted data and is that 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: its very easy to scale out the database using its replicacy technology, for redundancy and performance reason. In the Kubernetes Cluster demonstration given in the next course, we'll deploy and set up and MongoDB replica set. Its online documentation is excellent. It provides dynamic or flexible schemers. This accommodates prototyping and the evolution of data structures. Complex queries are supported although we aren't in need of using them for the subweb 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 set up configuration data structures, as used by our subweb 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 iniatial 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 plus 1 voting ballot.
The MongoDB service, or DMON, will be configured to start with the following parameters. Bind underscore IP is set to 0 dot 0 dot 0 dot 0. This is to allow all incoming connections, regardless of origin. Replica set is set to RS0. Which will be the name of our replica set when we deploy it in the next course into our Kubernetes Cluster. And wireTigerCacheSizeGB defines the maximum size of the internal cache.
You may have noticed that the off perimeter has not been specified. Meaning that if that the indicational connection's 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 replica set with 3 nodes. The configuration will ensure that the data is replicated across of 3 nodes ensuring that the data is redundantly available. Okay that completes this lecture on our choice of MongoDB for our backing 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 doco-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.