1
00:00:07,669 --> 00:00:11,959
After watching this video, you will be able
to recognize the impact of cloud native microservices

2
00:00:11,959 --> 00:00:15,500
on application design,
describe stateless microservices,

3
00:00:15,500 --> 00:00:18,760
and compare monolithic and microservices architectures.

4
00:00:18,760 --> 00:00:23,640
To fully leverage DevOps, you need to think
differently about application design.

5
00:00:23,640 --> 00:00:27,369
You need to be thinking about cloud native
microservices.

6
00:00:27,369 --> 00:00:32,390
This image shows an application that is designed
as a collection of small microservices.

7
00:00:32,390 --> 00:00:35,750
Each one of these services independent
of the others.

8
00:00:35,750 --> 00:00:39,440
Each service a particular domain of the
application.

9
00:00:39,440 --> 00:00:42,749
You may have gathered from the names of the
services that this example is a ride-sharing

10
00:00:42,749 --> 00:00:43,749
service.

11
00:00:43,749 --> 00:00:47,129
There are drivers, payments, trip management,
and notifications.

12
00:00:47,129 --> 00:00:52,949
These are all small services that are single-purpose
based around a business domain.

13
00:00:52,949 --> 00:00:55,750
Notice the lines going from one service to
the other.

14
00:00:55,750 --> 00:00:57,410
These are pointing to the REST APIs (representational
state transfer architectural style Application

15
00:00:57,410 --> 00:00:57,910
Programming Interface).

16
00:00:57,910 --> 00:01:00,989
No service is accessing another service’s
database.

17
00:01:00,989 --> 00:01:04,729
In fact, databases aren't even included in
the picture.

18
00:01:04,729 --> 00:01:07,070
This is a cloud native design using microservices.

19
00:01:07,070 --> 00:01:09,869
It is a collection of stateless services.

20
00:01:09,869 --> 00:01:14,310
Cloud native means, "born on the cloud," taking
advantage of the horizontal scalability that

21
00:01:14,310 --> 00:01:16,600
the cloud has to offer.

22
00:01:16,600 --> 00:01:20,659
These services are following the guidelines
set forth in "The Twelve-Factor App," which

23
00:01:20,659 --> 00:01:23,970
describes how cloud native applications should
behave.

24
00:01:23,970 --> 00:01:26,799
This was first created in 2011 by the Heroku
team.

25
00:01:26,799 --> 00:01:31,800
Heroku was one of the first platform-as-a-service
implementations and it paved the way for

26
00:01:31,800 --> 00:01:33,920
cloud native platforms that we have today.

27
00:01:33,920 --> 00:01:38,990
Applications are designed as a collection
of stateless microservices.

28
00:01:38,990 --> 00:01:41,140
Stateless doesn't mean that the application
doesn't have state.

29
00:01:41,140 --> 00:01:44,859
It means that the services don't maintain
the state, any hidden state.

30
00:01:44,859 --> 00:01:50,130
The state is persisted in a database, each
service maintains its own state in a separate

31
00:01:50,130 --> 00:01:52,270
database or persistent object-store.

32
00:01:52,270 --> 00:01:54,130
Separation of state is important.

33
00:01:54,130 --> 00:01:56,999
If services were to share state you wouldn't
have microservices.

34
00:01:56,999 --> 00:01:59,609
You would just have a distributed monolith.

35
00:01:59,609 --> 00:02:04,319
Resilience and horizontal scaling are achieved
through deploying multiple instances.

36
00:02:04,319 --> 00:02:08,819
Once you break your application down into
multiple independent services you can scale

37
00:02:08,819 --> 00:02:10,900
them independently as needed.

38
00:02:10,900 --> 00:02:16,230
For example, I can scale up the notification
service without scaling up the other services.

39
00:02:16,230 --> 00:02:21,730
This takes advantage of the seamless, endless
horizontal scaling of the cloud platform.

40
00:02:21,730 --> 00:02:26,209
Instead of debugging and patching, failing
instances are just killed and respawned.

41
00:02:26,209 --> 00:02:29,700
We often use the expression that instances
are "cattle not pets."

42
00:02:29,700 --> 00:02:31,400
Don't get too attached to your instances.

43
00:02:31,400 --> 00:02:35,690
We scale them out as needed and we scale them
back when not needed.

44
00:02:35,690 --> 00:02:40,730
Once you break up that application into lots
of little microservices, you need to leverage

45
00:02:40,730 --> 00:02:45,990
DevOps pipelines to help manage continuous
delivery of these services.

46
00:02:45,990 --> 00:02:49,950
The term microservice was coined by Martin
Fowler and James Lewis.

47
00:02:49,950 --> 00:02:55,129
They said, "microservice architectural
style is an approach to developing a single

48
00:02:55,129 --> 00:03:00,660
application as a suite of small services,
each running in its own process..."

49
00:03:00,660 --> 00:03:01,750
These are not just threads.

50
00:03:01,750 --> 00:03:07,200
These are full processes running independently,
"...and communicating with lightweight mechanisms,

51
00:03:07,200 --> 00:03:09,560
often an HTTP resource."

52
00:03:09,560 --> 00:03:13,230
We now use REST APIs, these lightweight
mechanisms.

53
00:03:13,230 --> 00:03:17,939
Fowler and Lewis want on to say, "These services
are built around business capabilities and

54
00:03:17,939 --> 00:03:22,659
independently deployable by fully automated
deployment machinery."

55
00:03:22,659 --> 00:03:26,640
You saw that each service in the ride share
application was built around a business capability,

56
00:03:26,640 --> 00:03:30,549
such as driver service, or passenger service,
and notification service.

57
00:03:30,549 --> 00:03:32,720
These services are independently deployable.

58
00:03:32,720 --> 00:03:37,090
For example, I can upgrade the notification
service without redeploying everything else.

59
00:03:37,090 --> 00:03:44,450
It is particularly important that microservices
enable everything to be independently deployed.

60
00:03:44,450 --> 00:03:48,720
How does this work with a monolith compared
to working with microservices?

61
00:03:48,720 --> 00:03:54,530
Suppose you have a monolith that has calculations,
copy capabilities, and to-dos.

62
00:03:54,530 --> 00:03:59,910
When you deploy this application, you have
to deploy all the components together.

63
00:03:59,910 --> 00:04:05,440
We can split those out into multiple instances
of independent microservices.

64
00:04:05,440 --> 00:04:09,689
If I need to increase my capacity to perform
calculations, I can scale out those three

65
00:04:09,689 --> 00:04:12,160
instances and maybe make ten.

66
00:04:12,160 --> 00:04:16,019
I would not have to scale out the to-dos or
the copy capabilities.

67
00:04:16,019 --> 00:04:20,470
It's very important to be able to scale them
independently to make the best use of cloud

68
00:04:20,470 --> 00:04:21,970
resources.

69
00:04:21,970 --> 00:04:26,830
Each microservice would have its own database
where it is keeping track of its own state.

70
00:04:26,830 --> 00:04:30,320
I could deploy them independently and change
the database independently.

71
00:04:30,320 --> 00:04:33,760
I would only need to change and coordinate
with my team to accomplish this because other

72
00:04:33,760 --> 00:04:36,680
services are using REST APIs to communicate.

73
00:04:36,680 --> 00:04:40,630
They are not selecting over each other’s
tables in the database.

74
00:04:40,630 --> 00:04:45,030
Suppose I am working on an e-commerce website,
which is a monolith, and I want to change

75
00:04:45,030 --> 00:04:46,410
the customer table.

76
00:04:46,410 --> 00:04:51,330
I would probably need to coordinate with people
on the order team and the shipping team to

77
00:04:51,330 --> 00:04:55,040
change the customer table because they depend
on it for orders and shipping.

78
00:04:55,040 --> 00:05:01,010
With a microservice, there is no need to coordinate
with other teams because you are simply calling

79
00:05:01,010 --> 00:05:03,040
my REST API.

80
00:05:03,040 --> 00:05:05,570
You do not care what my table looks like.

81
00:05:05,570 --> 00:05:06,880
You come in through the API.

82
00:05:06,880 --> 00:05:12,190
I could change from using a SQL database to
a NoSQL database and you would never know.

83
00:05:12,190 --> 00:05:15,420
You ask for customer data, I give you customer
data.

84
00:05:15,420 --> 00:05:19,840
That is the one difference between a monolith
and microservice architecture.

85
00:05:19,840 --> 00:05:26,030
With microservices, each service is loosely
coupled and communicates through a REST API.

86
00:05:26,030 --> 00:05:29,990
In this video, you learned
Cloud native architecture is a collection

87
00:05:29,990 --> 00:05:33,469
of independently deployable microservices.

88
00:05:33,469 --> 00:05:38,530
Stateless microservices each maintain their
own state in a separate database or persistent

89
00:05:38,530 --> 00:05:40,673
object-store.

90
00:05:40,673 --> 00:05:45,660
Microservices are loosely coupled services,
designed for scalability and communicate

91
00:05:45,660 --> 00:05:47,004
with APIs.