In this video, walk through a high-level overview of how microservices works. Learn about the essential components needed to implement this architecture style, including key concepts such as service registration and discovery.
- [Narrator] In this video, we will define what Microservice Architecture actually is. We will use the acronym, MSA, to refer to this architecture style moving forward. There is not one single authoritative definition of MSA, so we will review how several thought leaders and experts define microservices. We will also go over some essential characteristics of MSA.
"Microservices are small, autonomous services "that work together." Sam Newman, author of Building Microservices. "Microservices architecture as a service-oriented "architecture composed of loosely coupled elements "that have bounded contexts," Adrian Cockcraft. "Microservices refer to a architectural approach "that independent teams use to prioritize "the continuous delivery of single-purpose services." Pivotal.
"Microservices are an architectural style that structures "an application as a collection of loosely coupled, "fine-grained services that communicate "using lightweight protocols." Wikipedia, paraphrased. The first essential characteristic of MSA is componentization via services. Basically, we want each service to run in its own process.
This can be a container, like Docker, or a virtual machine, such as an EC2 instance on Amazon web services. We want each service to be independently scalable and deployable. Primarily, we want different teams to be able to push features without having to worry about effecting other teams. Additionally, we want each service to be decoupled and cohesive.
In other words, we don't want a code change in one service to affect another service. Finally, all the code that performs a function should generally be in the same place. Let's define a component. A component is a piece of software that you can replace or update without really effecting the code around it. So if we make an entire service a component, we can replace or update that service without disrupting the other services that depend upon it.
Then we can build systems by plugging together these independent services. You can think of it in the same way that you stack various code libraries to build out functionality in a module. Let's take a look at an example. We will be using Amazon web services, or AWS, in this example. In this case, each service runs in its own EC2 instance.
Each EC2 instance is a isolated virtual machine. Since each service runs in its own process, we can scale each service independently. We can organize EC2 instances into a Auto Scaling group. That way, as demand increases, we could automatically spin up new instances of that service to handle that increased demand.
This is what we call Horizontal Scaling. Additionally, we are able to deploy a new version of each service, independently. In this example, we are using Jenkins, a common, open-source automation server to handle deployment. Each service will have its own scripts and process to build, test and deploy a new version.
- Installing Yarn, Yeoman, and JHipster
- Benefits of microservices
- Costs of using microservices
- JHipster microservice architecture
- Creating an API gateway
- Importing, reviewing, and running code
- How JHipster integrates with Docker
- Managing multiple microservices
- Deployment cloud solutions