After watching this video, you will be able
to recognize the impact of cloud native microservices on application design,
describe stateless microservices, and compare monolithic and microservices architectures. To fully leverage DevOps, you need to think
differently about application design. You need to be thinking about cloud native
microservices. This image shows an application that is designed
as a collection of small microservices. Each one of these services independent
of the others. Each service a particular domain of the
application. You may have gathered from the names of the
services that this example is a ride-sharing service. There are drivers, payments, trip management,
and notifications. These are all small services that are single-purpose
based around a business domain. Notice the lines going from one service to
the other. These are pointing to the REST APIs (representational
state transfer architectural style Application Programming Interface). No service is accessing another service’s
database. In fact, databases aren't even included in
the picture. This is a cloud native design using microservices. It is a collection of stateless services. Cloud native means, "born on the cloud," taking
advantage of the horizontal scalability that the cloud has to offer. These services are following the guidelines
set forth in "The Twelve-Factor App," which describes how cloud native applications should
behave. This was first created in 2011 by the Heroku
team. Heroku was one of the first platform-as-a-service
implementations and it paved the way for cloud native platforms that we have today. Applications are designed as a collection
of stateless microservices. Stateless doesn't mean that the application
doesn't have state. It means that the services don't maintain
the state, any hidden state. The state is persisted in a database, each
service maintains its own state in a separate database or persistent object-store. Separation of state is important. If services were to share state you wouldn't
have microservices. You would just have a distributed monolith. Resilience and horizontal scaling are achieved
through deploying multiple instances. Once you break your application down into
multiple independent services you can scale them independently as needed. For example, I can scale up the notification
service without scaling up the other services. This takes advantage of the seamless, endless
horizontal scaling of the cloud platform. Instead of debugging and patching, failing
instances are just killed and respawned. We often use the expression that instances
are "cattle not pets." Don't get too attached to your instances. We scale them out as needed and we scale them
back when not needed. Once you break up that application into lots
of little microservices, you need to leverage DevOps pipelines to help manage continuous
delivery of these services. The term microservice was coined by Martin
Fowler and James Lewis. They said, "microservice architectural
style is an approach to developing a single application as a suite of small services,
each running in its own process..." These are not just threads. These are full processes running independently,
"...and communicating with lightweight mechanisms, often an HTTP resource." We now use REST APIs, these lightweight
mechanisms. Fowler and Lewis want on to say, "These services
are built around business capabilities and independently deployable by fully automated
deployment machinery." You saw that each service in the ride share
application was built around a business capability, such as driver service, or passenger service,
and notification service. These services are independently deployable. For example, I can upgrade the notification
service without redeploying everything else. It is particularly important that microservices
enable everything to be independently deployed. How does this work with a monolith compared
to working with microservices? Suppose you have a monolith that has calculations,
copy capabilities, and to-dos. When you deploy this application, you have
to deploy all the components together. We can split those out into multiple instances
of independent microservices. If I need to increase my capacity to perform
calculations, I can scale out those three instances and maybe make ten. I would not have to scale out the to-dos or
the copy capabilities. It's very important to be able to scale them
independently to make the best use of cloud resources. Each microservice would have its own database
where it is keeping track of its own state. I could deploy them independently and change
the database independently. I would only need to change and coordinate
with my team to accomplish this because other services are using REST APIs to communicate. They are not selecting over each other’s
tables in the database. Suppose I am working on an e-commerce website,
which is a monolith, and I want to change the customer table. I would probably need to coordinate with people
on the order team and the shipping team to change the customer table because they depend
on it for orders and shipping. With a microservice, there is no need to coordinate
with other teams because you are simply calling my REST API. You do not care what my table looks like. You come in through the API. I could change from using a SQL database to
a NoSQL database and you would never know. You ask for customer data, I give you customer
data. That is the one difference between a monolith
and microservice architecture. With microservices, each service is loosely
coupled and communicates through a REST API. In this video, you learned
Cloud native architecture is a collection of independently deployable microservices. Stateless microservices each maintain their
own state in a separate database or persistent object-store. Microservices are loosely coupled services,
designed for scalability and communicate with APIs.