Understanding Kubernetes & Where it Fits in Cloud Native Architectures

IT Training and Development Resources
Webinars
Understanding Kubernetes & Where it Fits in Cloud Native Architectures

So how did we end up at Kubernetes and why? Join us May 11th, as ExitCertified Cloud Instructor Mike Stapleton, delves into the history of the DevOps movement & the evolution by necessity, into modern cloud-native architectures. Anyone new to cloud-native, will benefit by learning the design principles behind it - microservices, dynamic management, automation, containers & orchestration – with a focus on the latter. Join us for a deep dive into Kubernetes, a popular open-source framework for deployment and maintenance of containerized applications.

Attend this session to:

Grasp the principles around Cloud-native architecture
Learn about container applications like Docker
Understand Kubernetes architecture & deployment
See how Kubernetes handles services like, Secrets and ConfigMaps
And much more..

View All Kubernetes

1
00:00:02.879 --> 00:00:19.020
Michelle :: Webinar Producer: Hello everyone and welcome to today's webinar titled understanding Cuban at ease and where it fits in cloud native architectures. Our speaker today is Mike Stapleton senior instructor at exit certified a software architect and engineer.

2
00:00:20.100 --> 00:00:24.120
Michelle :: Webinar Producer: Before we get started with the webinar. Let's talk about the functionalities.

3
00:00:24.660 --> 00:00:34.830
Michelle :: Webinar Producer: During the webinar. Everyone's microphones will be muted. So if you have any questions, please don't hesitate to enter them in the Q AMP a box at the bottom of your screen.

4
00:00:35.160 --> 00:00:44.940
Michelle :: Webinar Producer: Will have a dedicated question answer session at the end of the lecture. Today's webinar is being recorded and we're going to send a copy to each of you. By the end of the week.

5
00:00:45.510 --> 00:00:53.280
Michelle :: Webinar Producer: Will also share a promo at the end of the webinar, so stick around to learn more about that, without further ado, let's get started. Mike, you can take it away.

6
00:00:54.240 --> 00:01:04.500
Mike Stapleton: Hey, welcome. Thank you, Michelle. Oh, welcome to exit certified everybody. My name is Mike Stapleton and I'm here to bring you on a little bit of a journey through

7
00:01:05.100 --> 00:01:11.580
Mike Stapleton: While through history, kind of, what brought us to where we are so that we can understand some of the technologies we have available to us right now.

8
00:01:12.180 --> 00:01:18.750
Mike Stapleton: As the title was saying understanding Cooper 90s and where it fits in cloud native is where we're going to end up. Alright.

9
00:01:19.650 --> 00:01:29.550
Mike Stapleton: So let's get the show on the road. I've got a lot to talk about, let's say, so I'm gonna go a little fast and furious. Right.

10
00:01:29.940 --> 00:01:37.470
Mike Stapleton: Everything I'm going to mention here. There is much more to be discussed. There's more digging into them. But I'm really just trying to give that feeling of

11
00:01:38.040 --> 00:01:46.800
Mike Stapleton: deeper understanding. Like why. All right. What I've learned over the years is that, you know, if you just learn about something, what it does.

12
00:01:47.280 --> 00:01:57.120
Mike Stapleton: You still kind of walk away, like, you know, oh, I can do this. I can do that. It can do that, but then you're like, Well, why would I do it, you know. And why did they do it that way.

13
00:01:58.380 --> 00:02:08.700
Mike Stapleton: So yeah, going through history, looking back at the problems that we've faced and how we've developed solutions. And then how those solutions have exposed other problems is

14
00:02:09.090 --> 00:02:19.530
Mike Stapleton: I find a really good way to understand it. So in the end, what the heck is Cooper Nettie is. Why do we have it. When do we want to use it. Does it solve all of our problems. No.

15
00:02:20.430 --> 00:02:34.230
Mike Stapleton: But it's also a lot of them done. It's actually pretty darn useful does it replace clouds. No, but it definitely is happy on the cloud. So with no further ado, let's get in there right so yeah why right why Cooper 90s.

16
00:02:35.280 --> 00:02:37.290
Mike Stapleton: It's very, very popular at the moment.

17
00:02:38.970 --> 00:02:51.540
Mike Stapleton: For reasons to come, right, we also need to know what it is it right. It's great understanding what something is, but it's not a magical tool that solves all of our problems.

18
00:02:52.050 --> 00:03:06.570
Mike Stapleton: So, what is it, what is it not all those kinds of questions, right. First, what do we want right we it's it right. We want fault tolerant scalable systems built to operate as cheaply as possible. It's the bottom line.

19
00:03:07.830 --> 00:03:13.590
Mike Stapleton: How do we achieve those things will. This is where we have different tools and technologies available to us right

20
00:03:15.750 --> 00:03:24.390
Mike Stapleton: Agility whatever we build we want it to be agile. This is really important agility means different things to different people.

21
00:03:25.140 --> 00:03:36.960
Mike Stapleton: We're not talking about agile development practices. But yeah, sort of, the bottom line is when we're talking about agility. It's the ability to change. Right. We need to be able to change things.

22
00:03:37.860 --> 00:03:50.670
Mike Stapleton: Software has to be changeable business requirements change the boss comes along, says, Hey, you know, we need this new thing how fast you know can you change your software to take advantage of business opportunities.

23
00:03:51.660 --> 00:04:02.400
Mike Stapleton: New technologies come along, you've built something and then you find out there's a better way to do some part of it. You want to be able to change what you have to take advantage of those new technologies.

24
00:04:03.090 --> 00:04:12.240
Mike Stapleton: And of course, there's the typical changes that we have to deal with bug fixes patches application logic issues we have to deal with how we build in designer systems.

25
00:04:12.600 --> 00:04:23.310
Mike Stapleton: If we do them in ways that allow us to be agile. Well, we'll have a better solution because we will be able to change things and we need that right if your solution is not agile, then it becomes

26
00:04:24.150 --> 00:04:31.860
Mike Stapleton: A problem, right. Is that thing that no one wants to touch because every time they touch it, it breaks and that's just not good.

27
00:04:33.330 --> 00:04:40.530
Mike Stapleton: Another thing sometimes less obvious is the development process. We need to be able to build this system and

28
00:04:41.010 --> 00:04:44.880
Mike Stapleton: Systems are building nowadays are becoming more and more and more complex.

29
00:04:45.330 --> 00:04:54.900
Mike Stapleton: That's the reality of evolution. Right. Once upon a time, developers would just develop some little app that would run on a server. And if you wanted to support more customers, you'd

30
00:04:55.590 --> 00:05:06.810
Mike Stapleton: Run on bigger computer Sun Microsystems, way back when, made a lot of monies us selling big honkin computers. Yeah, not so much. Nowadays,

31
00:05:07.260 --> 00:05:16.590
Mike Stapleton: These simple programs over time have more and more functionality you need more and more people involved in developing it or it just takes longer and longer to develop and support.

32
00:05:16.830 --> 00:05:34.020
Mike Stapleton: And so we we need to be able to break up our problem and have it worked on in parallel by multiple people and so parallel development scaling and everything. It's not just the runtime that needs to be horizontally scaled and fault tolerant and everything we have to build a build it.

33
00:05:35.190 --> 00:05:47.970
Mike Stapleton: Yeah. Now if you want to achieve agility you what you have to do is to allow changes, you have to stop when you change something in one place. It can't force you to change things and other places.

34
00:05:49.020 --> 00:05:51.870
Mike Stapleton: If you take a developer and you teach them.

35
00:05:53.460 --> 00:06:03.870
Mike Stapleton: Whatever language for dummies, and then give them some large complex project to work on, you know, they'll work on it as best they can. They'll start hammering away and they'll

36
00:06:04.650 --> 00:06:16.050
Mike Stapleton: Be building. It's kind of like if you had children and you gave them tools to build a tree for it, they could build something right. Is it very maintainable. Is it airtight is it comfortable. Is it

37
00:06:17.220 --> 00:06:20.370
Mike Stapleton: And not so much right they just kind of hammered it together.

38
00:06:21.660 --> 00:06:29.610
Mike Stapleton: You need structure you need structure and whatever you're building to control change to allow you to change things.

39
00:06:30.060 --> 00:06:34.710
Mike Stapleton: A lot of the things we talked about and development architecture are really about

40
00:06:35.040 --> 00:06:42.810
Mike Stapleton: Trying to limit change so that we can change things again and change things, because we need to add features business requirements needed bug fixes. Right.

41
00:06:43.140 --> 00:06:48.600
Mike Stapleton: We've all seen that code or heard of that code or worked with a program where you're wondering why they never fix it.

42
00:06:49.260 --> 00:07:02.130
Mike Stapleton: So always had these problems. Everyone stuck with it ever complains, and never touch it, there's a good chance it's some kind of spaghetti code in there. No one's afraid to touch it because as soon as they do. They break some thing.

43
00:07:03.420 --> 00:07:09.270
Mike Stapleton: So I just kind of borrowed this image here from Israel calm but they're just this was from a

44
00:07:11.850 --> 00:07:20.610
Mike Stapleton: site where they were trying to show for business people. You are all organized so everything's kind of decoupled UP IN HERE, BUT THEN, THIS IS YOUR COMPUTE systems, everything's move that

45
00:07:21.990 --> 00:07:30.870
Mike Stapleton: So when we talk about spaghetti code in another way to think of spaghetti code is kind of like that box of cables. You have you tried to grab the one cable and pull it out everything comes with it.

46
00:07:32.700 --> 00:07:39.390
Mike Stapleton: Yeah, so we have to decouple things we've got to make sure whatever we're doing is decoupled. We need that.

47
00:07:40.560 --> 00:07:46.410
Mike Stapleton: Other things we require fault tolerance right things should just work it should be up, they should be running

48
00:07:47.340 --> 00:07:57.300
Mike Stapleton: I just want to point out here that fault tolerance and ha are not exactly the same thing in language they overlap a bit and how we use it but fault tolerance.

49
00:07:57.810 --> 00:08:06.330
Mike Stapleton: Things continue to operate in the event of failure. Right, whereas a che is about higher than normal uptime.

50
00:08:07.140 --> 00:08:12.720
Mike Stapleton: Traditionally ha is something we apply an operations. After we get something right

51
00:08:13.380 --> 00:08:22.260
Mike Stapleton: Boss purchases some software for system and the straighter has to set it up and manage it and then boss says by the way just has to run 24 hours a day, seven days a week.

52
00:08:23.250 --> 00:08:36.630
Mike Stapleton: Yet it runs on a computer. Computers don't run 24 hours a day, seven days a week, we put a lot of effort into trying to make computers that run 24 hours a day, seven days a week, but it's a losing battle.

53
00:08:37.710 --> 00:08:48.120
Mike Stapleton: So yeah, we want fault tolerance. We want it to accept reality of things break and just keep running. That's our goal right fault tolerance is built in.

54
00:08:49.890 --> 00:09:01.140
Mike Stapleton: Yeah, no single points of failure. Now you're gonna have no single points of failure. That also means that you have to have more components. Yeah, yeah, it does complicate things

55
00:09:02.400 --> 00:09:09.240
Mike Stapleton: It's easy to make a piece of software or just runs on a computer and walk away and say I'm done with it.

56
00:09:09.960 --> 00:09:26.640
Mike Stapleton: It's difficult to make software that runs across multiple computers and can recover from failures, but we're gonna have to have some kind of horizontal scaling. Now we're going to have to spread our workload, our processes and things across multiple machines.

57
00:09:29.070 --> 00:09:41.700
Mike Stapleton: Performance is also an issue right we have service level agreements, not just for uptime. But for performance and horizontal scaling helps with that. So yeah, often talk about scaling as part of the fault tolerance.

58
00:09:43.020 --> 00:09:54.360
Mike Stapleton: Well, we've all kind of experienced with are working from home, at least, a lot of people have experienced issues with their company VPN and things that normally a company or government organization only has a few people VP ending in

59
00:09:55.110 --> 00:10:02.670
Mike Stapleton: Now we got what 10 times 100 times 1000 times the number of people that are a VP ending in, and a lot of people are having a hard time

60
00:10:04.920 --> 00:10:07.710
Mike Stapleton: Shouldn't be should just scale.

61
00:10:11.160 --> 00:10:11.820
Mike Stapleton: We want

62
00:10:14.010 --> 00:10:19.860
Mike Stapleton: For as little cost as possible. So this is going to be a big theme here operations and operations.

63
00:10:21.120 --> 00:10:29.790
Mike Stapleton: As system administrators over the years we've had to operate stuff right again we purchase hardware we purchase.

64
00:10:30.690 --> 00:10:41.520
Mike Stapleton: Software, we have tools we have all kinds of things and then administrators have to kind of make it work and bug fix it and back it up and do all of these things right.

65
00:10:42.210 --> 00:10:51.810
Mike Stapleton: That's expensive operations is expensive. Um, so anything we can do to minimize the money spent on operations. That's a good thing.

66
00:10:53.790 --> 00:11:00.960
Mike Stapleton: Other themes out here, public clouds are out here now right don't pay for things, you're not using if you've ever worked with Amazon Web Services.

67
00:11:01.680 --> 00:11:12.720
Mike Stapleton: You'll find the word elastic all over the place because kind of one of the big differentiates of a public cloud from a private cloud, right, your own hardware and your own data center.

68
00:11:13.110 --> 00:11:26.010
Mike Stapleton: In your own data center, you're paying for it, whether use it or not. That's a reality. Right. We haven't built systems to power themselves off when we when we're not using them. Like why would you there's no real benefit.

69
00:11:27.090 --> 00:11:36.150
Mike Stapleton: But when you're on a public cloud, all of a sudden, you need to start considering not doing things when you don't need to do it because you're paying when you do things you're

70
00:11:36.570 --> 00:11:43.860
Mike Stapleton: Paying for a server when you're running it you power it off, you stop paying for it, you know, a little bit of storage and stuff.

71
00:11:44.700 --> 00:11:56.670
Mike Stapleton: So we need to change the way we do things because the environment is changing. We're moving to the cloud. We're moving to the cloud, because it gives us more flexibility more freedom more agility. That's the reality.

72
00:11:58.080 --> 00:12:09.360
Mike Stapleton: If you're not agile, it's gonna cost you unhappy customers because your product isn't as good as it could be. It's gonna be gonna have more problems more bug fixes is going to take longer to implement changes and

73
00:12:11.820 --> 00:12:12.000
And

74
00:12:13.290 --> 00:12:15.750
Mike Stapleton: Yeah so Cooper daddy's

75
00:12:16.770 --> 00:12:22.470
Mike Stapleton: I know those are the things that we want. And obviously, I'm going to get to the point where Cooper Nettie helps us with

76
00:12:23.730 --> 00:12:28.170
Mike Stapleton: A lot of those sort of maybe kind of, you know, we'll see we get there.

77
00:12:29.280 --> 00:12:38.910
Mike Stapleton: Everything in the presence built in the past. Yeah. So let's just the idea that to understand what you have now you have to look back at what what it was built on right it like everything else evolves.

78
00:12:39.690 --> 00:12:46.200
Mike Stapleton: You build things with what you have at the time and in the way that people are doing it time using technologies and everything that you have

79
00:12:46.770 --> 00:13:01.830
Mike Stapleton: So you build something and then you start to look at it, you go, Hmm, well, we have these problems with these issues and you start to come up with ideas of how you could fix those problems right so you come up with new technologies to address the problems that you have currently

80
00:13:03.270 --> 00:13:16.530
Mike Stapleton: And then the next time you build something you will incorporate the new lessons, learn the new features tools, things that you've developed. Of course there will still be problems that will expose new issues.

81
00:13:18.090 --> 00:13:26.940
Mike Stapleton: So then we'll develop new tools and technologies to deal with those issues which will, you know, and it just, it just goes around and around and around and around.

82
00:13:28.230 --> 00:13:31.980
Mike Stapleton: Cooper Nettie is is you'll see is a tool that solves some of our problems.

83
00:13:33.720 --> 00:13:34.080
Some

84
00:13:35.610 --> 00:13:39.210
Mike Stapleton: It to understand it. If we go back, way back

85
00:13:41.340 --> 00:13:58.680
Mike Stapleton: Boy, when I, when I first started we ran like everything just ran on single servers. You'd run a program on a server. And so it was a server per program. And if you wanted to perform better. You bought a bigger computer and hopefully your program was multi threaded

86
00:13:59.700 --> 00:14:13.950
Mike Stapleton: Pretty much the way it worked, right, problems with monolithic big honkin programs development is difficult. The code gets bigger and bigger and bigger, bigger and more. It's more difficult to manage multiple people in parallel, working on it.

87
00:14:16.950 --> 00:14:17.520
Mike Stapleton: And

88
00:14:18.840 --> 00:14:23.340
Mike Stapleton: Well, I guess I should say here monolithic software sold to customers. That's the other big point

89
00:14:25.230 --> 00:14:28.050
Mike Stapleton: People sold software was the thing

90
00:14:29.490 --> 00:14:34.770
Mike Stapleton: We used to have software to be version one and then a year later, you'd version two year later version three

91
00:14:36.060 --> 00:14:45.960
Mike Stapleton: One company would develop the software. They were just get it out the door as fast as possible. That was a reality, they got paid for the software.

92
00:14:47.280 --> 00:14:51.870
Mike Stapleton: And then, as a company, you bought it. Yeah, you had operated

93
00:14:55.650 --> 00:15:03.060
Mike Stapleton: You had to make sure that you could back it up. You had to support it, you had to pay for the hardware you you have to make it a che

94
00:15:04.620 --> 00:15:16.500
Mike Stapleton: Everything to keep it running monitoring all kinds of tools you needed all kinds of tools to to operate this thing, this is where system administrators come in companies would have armies of system administrators

95
00:15:18.120 --> 00:15:30.750
Mike Stapleton: One of the problems was the people developing the software didn't care about that it was not their concern. They're not the ones who operated they built the software they sold it, you bought it. Now, you had to make it work.

96
00:15:31.920 --> 00:15:38.040
Mike Stapleton: Also security issues and things like that. Not such so much the developers problem, right.

97
00:15:39.360 --> 00:15:48.030
Mike Stapleton: I guess the key thing here was developers went off and build things as cheaply and quickly as possible so as easily as possible. Good stuff is more complicated.

98
00:15:48.780 --> 00:15:56.520
Mike Stapleton: And got it out the door as fast as possible. And then we in our companies had to deal with problems. And of course, I'm talking like that's a history right

99
00:15:58.050 --> 00:16:07.860
Mike Stapleton: That's still a thing. But let's pretend it's not for now. Okay. So, yeah, you need the infrastructure you need software to manage the software.

100
00:16:09.000 --> 00:16:17.850
Mike Stapleton: Yeah, I mean, Sun Microsystems, way back when I bring them up often because I get to the Sun Microsystems system illustration for a long time.

101
00:16:19.260 --> 00:16:22.110
Mike Stapleton: Pretty well companies would always buy son.

102
00:16:22.650 --> 00:16:34.230
Mike Stapleton: Hardware and then to to add operational stuff they would use like very task Volume Manager for managing their hardware and they would use ha cluster software by Veritas and other company and

103
00:16:34.650 --> 00:16:45.870
Mike Stapleton: And that was their ecosystem for deploying things. So not only did you have to pay for the software and the hardware you had to buy extra software to manage your software right backups, all this kind of stuff.

104
00:16:46.710 --> 00:16:52.410
Mike Stapleton: And then you also need the expertise to figure all that out. So again, our system administrators and

105
00:16:53.310 --> 00:17:02.910
Mike Stapleton: They have to make things highly available again backups and performance tuning a taught like five day performance tuning classes. Yeah, me.

106
00:17:03.480 --> 00:17:13.290
Mike Stapleton: And then, of course, this is per software. So you got some software that needs a certain iOS. And so you might have some Solaris machines and you need other machines that need the

107
00:17:13.650 --> 00:17:19.500
Mike Stapleton: IBM and then there's Linux. It was kind of coming in there. And yeah, it was a Windows thing was poking its nose in

108
00:17:20.100 --> 00:17:32.820
Mike Stapleton: And. And again, you had to have the expertise for all of that all the different tools and everything that's available system administration a whole lot of hacking and ban dating things together to make stuff work.

109
00:17:33.900 --> 00:17:39.180
Mike Stapleton: As fast as possible. Get it up the doors but internally and it does the customer.

110
00:17:40.050 --> 00:17:46.140
Mike Stapleton: So the concerns here were different between the people who made the software and the people who were operating it right

111
00:17:46.860 --> 00:17:54.750
Mike Stapleton: Then all of a sudden there was software as a service, not all of a sudden, everything gonna but software as a service change things.

112
00:17:55.620 --> 00:18:06.630
Mike Stapleton: With software as a service, the company building the software is operating the software. So all the concerns about development and operation hit their bottom line.

113
00:18:08.760 --> 00:18:18.840
Mike Stapleton: Now the real reality is it's more expensive operating things than it is building it in the first place right operation costs are just continuing and they go on and on and on.

114
00:18:20.370 --> 00:18:27.300
Mike Stapleton: And a lot of the things we do in operations are consequence of things not being built into the software.

115
00:18:27.900 --> 00:18:42.960
Mike Stapleton: And having to set up ha clusters and manage ha software and redundant servers and kind of hacking together and all the brittleness and problems that caused and a lot of the times, ha clusters had more downtime, because of the ha software that's a little frustrating.

116
00:18:44.340 --> 00:18:49.980
Mike Stapleton: Hey operation is expensive. So develop better software, right.

117
00:18:50.940 --> 00:19:00.510
Mike Stapleton: Software should be fault tolerant and scalable and easy to manage and very well that will make developing software more difficult. Absolutely right.

118
00:19:00.930 --> 00:19:09.120
Mike Stapleton: But putting the money up front into better developing better software saves you a whole lot of money and makes you more agile in the long run.

119
00:19:10.380 --> 00:19:20.190
Mike Stapleton: And when you're concerned with both yeah you'll put more money into dev reality, we don't want to do operations as much as possible.

120
00:19:21.660 --> 00:19:22.440
Mike Stapleton: So the reality.

121
00:19:23.640 --> 00:19:32.670
Mike Stapleton: And if you're a software as a service company and you have that one service that you're selling to customers to to access across the network.

122
00:19:33.330 --> 00:19:44.490
Mike Stapleton: Yeah, you better have good software because downtime and problems and slow features. And I know that's company ending. If you only got the one product.

123
00:19:45.540 --> 00:19:51.960
Mike Stapleton: So you can't have that monolithic applications as they were being written. You know, okay.

124
00:19:52.320 --> 00:20:01.530
Mike Stapleton: You know, if you're selling it to customers and they got to deal with it internally, that's their problem. But if you're building this offer all of a sudden yeah that's that's not going to work. Right.

125
00:20:02.280 --> 00:20:22.200
Mike Stapleton: There's not much agility in there and many, many, many ways and a monolithic application is just a program running on a computer, all the functionalities built into the one process that makes it difficult to develop it and it makes it difficult to scale it and to manage it. Right.

126
00:20:23.790 --> 00:20:34.860
Mike Stapleton: Now if you want to that idea of building things into the software operations issues into the software so that you don't have to do operations that is

127
00:20:35.730 --> 00:20:43.350
Mike Stapleton: The foundation of DevOps really like DevOps is a lot of it depends on who you ask. If you have to developers will say it's one thing if your system administrators, alas, something else.

128
00:20:43.920 --> 00:20:49.830
Mike Stapleton: But in the end, it's, it's about building better software that basically operates itself the operational.

129
00:20:50.160 --> 00:21:01.230
Mike Stapleton: People should not be part of the machine shouldn't need people doing things to keep stuff working that functionality should be built in and we need to automate things as much as possible.

130
00:21:03.630 --> 00:21:17.580
Mike Stapleton: Like to say is the system administrators lunches being eaten by the developers, right, the traditional role of system administrators is changing, right, traditionally system administrators would be installing software and patching software and updating software and

131
00:21:18.630 --> 00:21:28.680
Mike Stapleton: Now that's still going to be, they're going to be there for a long time, but we're talking about new, new ways of building things we don't want to be doing that kind of stuff, if at all possible.

132
00:21:30.330 --> 00:21:41.520
Mike Stapleton: So yeah, it's evolving and it also depends on where you are. So if you ask administrators often DevOps will be things that helped them automate their job. And so this is where you have your DevOps tools.

133
00:21:43.560 --> 00:21:57.780
Mike Stapleton: Puppet chef and symbols. These kinds of things to automate things. But yeah, it's kind of, if I put my developer hat on, it's me trying to avoid doing any kind of system administration at all. Period. That's the goal.

134
00:21:58.830 --> 00:21:59.730
Mike Stapleton: Right, don't do that.

135
00:22:01.350 --> 00:22:10.470
Mike Stapleton: Alright so that kind of brings us towards we need a better architecture. Now there was so a was out there, which was more of the

136
00:22:11.340 --> 00:22:19.530
Mike Stapleton: More of a enterprise architecture microservices a software architecture. So you're going to decide I'm going to build some software.

137
00:22:19.770 --> 00:22:29.160
Mike Stapleton: And I needed to be fault tolerant and scalable and I want to have be agile and how I do things I want to be able to have lots of developers working on it and have it.

138
00:22:29.910 --> 00:22:47.460
Mike Stapleton: Easy to manage and everything. So you choose microservices. In the end, the idea of microservices is you take all that functionality that was built into one single program one executable one release and you would break it up into separate programs.

139
00:22:49.440 --> 00:22:55.440
Mike Stapleton: Normally decently written program had structure internally. Anyway, is just wasn't exposed to.

140
00:22:57.750 --> 00:23:13.020
Mike Stapleton: When the actual move to micro services as a developer wasn't a huge jump. If you looked at the design of an app, you would see internally. It had components we just now compile those components as separate executable.

141
00:23:14.790 --> 00:23:18.540
Mike Stapleton: As a decomposed into many deployable units.

142
00:23:19.560 --> 00:23:23.940
Mike Stapleton: To pull a deployable unit just an executable files and files and whatnot, that you can copy

143
00:23:24.660 --> 00:23:32.910
Mike Stapleton: As soon as you can break it up into more pieces you can spread those pieces around and then you could also maybe have multiple copies of it. That would be a good thing to do.

144
00:23:33.630 --> 00:23:41.280
Mike Stapleton: But you can spread it around. You can horizontally scale things and it is much more agile, because these separate executable files.

145
00:23:42.030 --> 00:23:53.970
Mike Stapleton: Now, can have their own release cycles. They're different programs. So different teams can be working on their own things not stepping on each other not having to coordinate with each other. They can even write things in different languages and whatnot.

146
00:23:56.370 --> 00:23:57.000
Mike Stapleton: Polygon

147
00:23:58.080 --> 00:23:59.220
Mike Stapleton: That's the good

148
00:24:00.360 --> 00:24:08.880
Mike Stapleton: And the bag. Yeah, in theory, your developers can choose whatever languages and everything they feel like. And because they're separate programs.

149
00:24:10.110 --> 00:24:13.140
Mike Stapleton: I say it's a bad thing because if you're the support people

150
00:24:13.920 --> 00:24:26.040
Mike Stapleton: Trying to handle all of these or if you're a developer and you're moving around teams and oh they're using go over here and they're doing all their stuff in JavaScript, and they're doing it Python in there that gets problematic, but

151
00:24:26.520 --> 00:24:37.710
Mike Stapleton: Yeah, definitely the different. They're different executable lots of little, little programs that work together to fulfill the requirements that you need of your, your application.

152
00:24:38.460 --> 00:24:42.540
Mike Stapleton: I say like a tool kit approach this kind of Unix way of doing things, originally

153
00:24:42.780 --> 00:24:50.280
Mike Stapleton: We don't write big honkin programs that do everything we make lots of little programs that people can use in the command line, and then we can stitch those programs together.

154
00:24:50.670 --> 00:25:05.490
Mike Stapleton: On the command line to do more functional things type crap, blah, blah, blah, blah. Something and Unix well microservice kind of generally. Same idea, and don't big one big honkin program, make a bunch of little programs and then we can piece it together.

155
00:25:07.050 --> 00:25:23.490
Mike Stapleton: So there's separate components developed manage right separated by API's programming interfaces, so we can interact with them. We can build other microservices later on and interact with other previous ones that were built, and yet we got separate processes. They're all distributed

156
00:25:26.370 --> 00:25:27.120
Mike Stapleton: But

157
00:25:28.710 --> 00:25:36.690
Mike Stapleton: It helps us design and be more agile fault tolerant scalable programs, but it does definitely cause issues.

158
00:25:37.020 --> 00:25:46.200
Mike Stapleton: With networking, all of a sudden, things that may have been talking in nanoseconds. Delete to each other are talking milliseconds, because they're on different machines talking across the network.

159
00:25:47.070 --> 00:25:50.700
Mike Stapleton: And not just the latency, they got to be able to find each other and they're talking across the network.

160
00:25:51.120 --> 00:25:58.380
Mike Stapleton: So you need some kind of network protocol and a rest is pretty popular protocol buffers is different technologies for communicating between the processes.

161
00:25:59.250 --> 00:26:08.970
Mike Stapleton: But you have to, you have to handle all of that. Right. They have to be able to find each other what IP address important number or we can have many of them on many machines.

162
00:26:10.290 --> 00:26:15.660
Mike Stapleton: And these individual programs need storage. We have more programs running a more machines.

163
00:26:17.730 --> 00:26:27.270
Mike Stapleton: Yeah, how do I get the right storage to the right processes in the right place. Yeah. That complicates things, everything just basically blowing up right

164
00:26:27.630 --> 00:26:40.560
Mike Stapleton: All the operations issues we had before. We still have them. If you're just micro service architecture, you just have more of them now more processes more networking more and like some more problems service discovery or not.

165
00:26:41.640 --> 00:26:49.710
Mike Stapleton: Lots and lots of operating systems because you have lots and lots of separate processes things that you need to manage and, again, of course.

166
00:26:50.340 --> 00:27:05.010
Mike Stapleton: All of the work on that and the different tools and yeah did mention microservices, they can use different languages. Well, they can have different dependencies and so developers working one micro service could decide to do it based on Ubuntu.

167
00:27:06.420 --> 00:27:09.210
Mike Stapleton: Someone else could do it based on something else.

168
00:27:11.280 --> 00:27:16.470
Mike Stapleton: It. Yeah, it gets a little painful when you're trying to do operations. Right.

169
00:27:17.790 --> 00:27:27.090
Mike Stapleton: All of these different classes and of course the different OSS different different tool sets and can you maybe you can't use the same backup software because you got Windows machines and Unix machines, Linux machines and

170
00:27:29.100 --> 00:27:34.680
Mike Stapleton: So yeah, it's a bit of the ugly and micro service. It doesn't magically make everything good and

171
00:27:36.330 --> 00:27:51.390
Mike Stapleton: Also we're scaling horizontally scaling these they can come and go. Typically, so again, how do they find each other. And if I move something if something's on one server and that server dies. I got to rely on how I got to reconnect the storage.

172
00:27:53.490 --> 00:28:07.230
Mike Stapleton: And I have to load balance across them. And when things break, I gotta stop sending traffic to them. Yeah, I just got lots more problems. It's easier to develop but it's it yeah it's not helpful from a

173
00:28:07.770 --> 00:28:13.590
Mike Stapleton: DevOps in that point of view, right. It's an architecture, we have to we have to do more to make it easy to manage

174
00:28:15.120 --> 00:28:20.580
Mike Stapleton: Now there's technologies out there that will help us a lot. Right.

175
00:28:21.780 --> 00:28:26.370
Mike Stapleton: We're all American eight containerization you can see where I'm slowly going with this, right.

176
00:28:27.480 --> 00:28:41.430
Mike Stapleton: containerization definitely is is helpful because it D couples our development environment from our operations or production environment that's it's really big useful thing.

177
00:28:43.620 --> 00:28:56.130
Mike Stapleton: Yeah, we'll have to load balance across things we're going to need something to monitor our processes running in places and launch more of them. Yeah. These are things Cooper Nettie will help us with this we get their

178
00:28:57.750 --> 00:29:03.660
Mike Stapleton: Containers. First off, containers are not VM sort of

179
00:29:04.980 --> 00:29:09.420
Mike Stapleton: It is starting to get a little blurry. If you've ever heard of cat. A containers.

180
00:29:12.240 --> 00:29:31.260
Mike Stapleton: Containers historically are just Colonel features, right. We're just taking advantage of features that are built into the Linux kernel and putting together in smart ways the Linux kernel. And yeah, when it was is working on

181
00:29:32.850 --> 00:29:44.880
Mike Stapleton: The Linux kernel has what are called names spaces. It means you know when you have an operating system you have lots of processes we can isolate the processes into their own names bases.

182
00:29:45.300 --> 00:29:51.960
Mike Stapleton: If I put a group of processes on their own network namespace. They have their own network stack. They have their own TCP IP stack.

183
00:29:53.460 --> 00:29:59.310
Mike Stapleton: Mount name spaces. I could mount file systems just for particular processes.

184
00:30:00.120 --> 00:30:06.900
Mike Stapleton: They're not mounted on the system, they are, but, you know, as far as the process is concerned, it's just mounted for that process. Right.

185
00:30:07.470 --> 00:30:19.620
Mike Stapleton: I can also stop them from seeing each other. I normally you can list the processes on your computer. Most there are different process ID, name spaces. Then they only see the other processes is there isn't the same thing.

186
00:30:20.280 --> 00:30:32.580
Mike Stapleton: When you are doing containers. We are simply taking advantage of these features to isolate processes from each other. They are all just processes running at the same time on the same machine to the one kernel.

187
00:30:34.470 --> 00:30:41.460
Mike Stapleton: Additionally, we can optionally add resource management right Linux has see groups. They came from Google.

188
00:30:42.570 --> 00:30:44.580
Mike Stapleton: See groups allow us to

189
00:30:46.170 --> 00:30:50.460
Mike Stapleton: Manage resource management. Right, so it allows us to do things like cap, the amount of memory.

190
00:30:51.810 --> 00:31:06.930
Mike Stapleton: Notice this a CAP. CAP memory, because again, they're just processes running on the same machine not VM. So I don't I don't give a container certain amount of memory. Not really, right, but I can cap it so that it uses more than it should. We can kill it off.

191
00:31:08.190 --> 00:31:15.330
Mike Stapleton: Right, we can protect ourselves some resources like CPU or a little bit more friendly CPU, we can share CPUs.

192
00:31:15.780 --> 00:31:28.170
Mike Stapleton: So that, yeah, we can have more CPU time given to some processes and other so we can balance things right. And yes, the group supports other other things like network, network I O and disk I O and

193
00:31:29.370 --> 00:31:36.150
Mike Stapleton: But when you're dealing with containers were just taking these kernel features and applying them to processes.

194
00:31:36.540 --> 00:31:48.660
Mike Stapleton: Containers is almost it's more about the tools that just build these spaces at runtime, it's running on a kernel right so you often see pictures of containers running on a container runtime.

195
00:31:49.050 --> 00:31:58.980
Mike Stapleton: The one thing that container runtime doesn't do is run your containers, which is a little that's to confusion. It just configured it really that's what that's about.

196
00:32:00.330 --> 00:32:00.780
Mike Stapleton: But

197
00:32:01.830 --> 00:32:11.670
Mike Stapleton: It's still, you know, containers containerizing software allows you to isolate them from each other and the host you're running on.

198
00:32:13.050 --> 00:32:22.560
Mike Stapleton: Right now, when you have containerized applications. They are isolated from the OS from your operating system version, your upper

199
00:32:23.190 --> 00:32:37.050
Mike Stapleton: You need to have Linux and let's let's be honest, nine times out of 10 people are using Docker. That's what we're using for our containerization if you have some machines with Docker on it and you launch a container on it.

200
00:32:38.070 --> 00:32:46.890
Mike Stapleton: It runs it gets downloaded it runs and when you stop it. It's gone right that's that's a beautiful thing.

201
00:32:48.750 --> 00:32:56.460
Mike Stapleton: It can be developed to be on Ubuntu right you have, again, this is related to microservice architectures.

202
00:32:57.210 --> 00:33:10.680
Mike Stapleton: We're trying to control the explosion of OS instances we don't have many operating systems that we need to manage. I want to have fewer servers with consistent operating system and containerization helps it because

203
00:33:11.280 --> 00:33:23.550
Mike Stapleton: The developers can develop using the tools and languages that they preferred and OS dependencies. So some developers could be developing their micro service using Ubuntu version something

204
00:33:23.790 --> 00:33:29.790
Mike Stapleton: And someone else could be choosing to do. There's with Red Hat someone else could be doing theirs, and then they do what they want.

205
00:33:32.250 --> 00:33:41.310
Mike Stapleton: But at runtime, as long as we have some machines that have Docker on them, then we can run them all together on those machines we get to have one consistent

206
00:33:42.390 --> 00:33:46.020
Mike Stapleton: OS one consistent tool chain everywhere.

207
00:33:48.210 --> 00:33:52.140
Mike Stapleton: With containers you typically have a software repository. So he makes it easier

208
00:33:52.410 --> 00:34:02.790
Mike Stapleton: And developers develop their containerized applications using the tools and everything they want the dependencies. They like they push it into a repository, and then at runtime.

209
00:34:03.330 --> 00:34:13.740
Mike Stapleton: We use our tools or container tools. Let's say docker to launch instances of that software images is what they usually call it

210
00:34:14.520 --> 00:34:22.170
Mike Stapleton: On the machine. It doesn't install right it's not installed it just runs and then it goes away.

211
00:34:22.650 --> 00:34:28.620
Mike Stapleton: Again, that's a big deal there. It's not installed. Another problem system administration wise that we've always had is

212
00:34:29.160 --> 00:34:42.930
Mike Stapleton: Yeah you install something you want to install something you patch things you make in slowly but surely the operating system gets corrupted. That doesn't happen with containers, the containers are not just isolated from the cells there an isolated from the less

213
00:34:44.940 --> 00:34:46.440
Mike Stapleton: That's all, that's all good.

214
00:34:47.670 --> 00:34:56.460
Mike Stapleton: But it does complicate things networking, especially if you're going to have a whole lot of processes running on the same machine.

215
00:34:56.760 --> 00:35:09.600
Mike Stapleton: You how do you manage them listening on conflicting port numbers and things like that. How does the outside world get to talk to these things and find them and how do you assign addresses and networking becomes complex

216
00:35:10.470 --> 00:35:17.670
Mike Stapleton: Same thing with storage, I have to whenever I'm launching containers, if they need storage, I have to attach storage and

217
00:35:18.990 --> 00:35:28.470
Mike Stapleton: It containers doesn't fix any of these problems at all right. Instead, when it comes to network in a way it makes it more complex and actually storage makes it more complex. So,

218
00:35:29.550 --> 00:35:37.320
Mike Stapleton: But it decoupled our development time from our ops time which allows us to be way more agile.

219
00:35:41.640 --> 00:35:54.660
Mike Stapleton: Yeah, and containers don't help you figure out where you're going to run the container. If you have a cluster of servers. How are you going to, you have a new container to run which server. Do you run it on

220
00:35:55.950 --> 00:36:04.620
Mike Stapleton: How do you figure that out. Right. You have to monitor things when so this is ops right if you're just using containers ops has to figure out where to launch things

221
00:36:05.040 --> 00:36:16.500
Mike Stapleton: They have to monitor the servers running the containers. What happens when that breaks, right, you're gonna have to reschedule these things that were running on that server that is no longer available on that server.

222
00:36:17.670 --> 00:36:23.820
Mike Stapleton: What are we going to do got to figure that out. Again, the networking storage is it doesn't help it with

223
00:36:24.480 --> 00:36:38.250
Mike Stapleton: service discovery, the individual micro services or processes or whatever you're running in these containers. They're just programs right running together on servers. How do they find each other, networking wise.

224
00:36:39.750 --> 00:36:42.660
Mike Stapleton: How do you configure those applications.

225
00:36:43.680 --> 00:37:01.320
Mike Stapleton: Well, as I mentioned earlier, we, we have software repository part of the good so developers push their software in well when you look when you run software. It's not just the software, you need the software and its configuration that basically gives you a running instance of something

226
00:37:02.670 --> 00:37:03.510
Mike Stapleton: So we need that.

227
00:37:05.550 --> 00:37:11.190
Mike Stapleton: Now the configuration. And of course, we want to automate all of this stuff and DevOps.

228
00:37:12.720 --> 00:37:13.770
Mike Stapleton: How are we going to do that.

229
00:37:15.450 --> 00:37:18.150
Mike Stapleton: I don't want to have operations people doing all this stuff.

230
00:37:20.100 --> 00:37:24.960
Mike Stapleton: And so containers are good microservices are good, but they have issues.

231
00:37:26.790 --> 00:37:30.420
Mike Stapleton: So this is basically we start getting into Cuban 80s.

232
00:37:31.560 --> 00:37:35.730
Mike Stapleton: Right Cooper 90s and there's other things out there to manage

233
00:37:37.020 --> 00:37:41.430
Mike Stapleton: Containers right to address some of the issues I mentioned earlier.

234
00:37:42.750 --> 00:37:49.470
Mike Stapleton: They just generally call them orchestration software. It's basically software that runs and manages your Docker environment.

235
00:37:51.000 --> 00:37:59.790
Mike Stapleton: Rather, and having administrators doing it writing scripts and that simple plan playbooks and putting recipes and or chef recipes. Yeah.

236
00:38:01.050 --> 00:38:06.270
Mike Stapleton: Yeah, we're going to read some proper software to do it. And so, Cooper 90s was developed based on

237
00:38:07.350 --> 00:38:11.640
Mike Stapleton: expertise and experience internally in Google.

238
00:38:12.780 --> 00:38:19.320
Mike Stapleton: So it comes from a you know somebody who knows what they're kind of talking about when it comes to building fault tolerant scalable deployment.

239
00:38:20.520 --> 00:38:28.050
Mike Stapleton: Now it's usually described as a platform, but I really prefer to think of it as a framework.

240
00:38:29.160 --> 00:38:39.000
Mike Stapleton: You choose Cooper Nettie because often if I if I'm, if I'm going to build a fault tolerant scalable application. I want it to be agile. That's pretty well always

241
00:38:39.720 --> 00:38:49.200
Mike Stapleton: I'm going to consider a micro service architecture. But as soon as you're going to do a micro service architecture, you got to deal with all of the explosion of the processes and development.

242
00:38:49.920 --> 00:39:04.680
Mike Stapleton: So I need sound thing. So what I'm going to do, I'm going to run my architecture and run my application my micro service architected application on Cooper daddy's cluster. And I'll have it run and manage containers and networking and storage and all the problems for me.

243
00:39:06.030 --> 00:39:13.050
Mike Stapleton: So that sense it's a framework and then I plug in what I need, as you'll see, Cooper Nettie is is unopinionated

244
00:39:14.310 --> 00:39:22.470
Mike Stapleton: And when we say unopinionated. It just means it's really flexible right software that's opinionated tells you how you're going to use it.

245
00:39:23.130 --> 00:39:34.290
Mike Stapleton: Right. It does logging the way it does logging. It does monitoring the way it does monitoring you interact with it, you know, and you can do what the developers of the software decided you can do with it.

246
00:39:34.710 --> 00:39:41.880
Mike Stapleton: It is easier to use when it's something as opinionated, because you don't have to think so much, it works the way it works.

247
00:39:44.970 --> 00:39:53.250
Mike Stapleton: But it's less flexible right in the hands of someone who knows what they're doing opinionated software starts to get frustrating, you end up fighting against it.

248
00:39:54.810 --> 00:40:00.960
Mike Stapleton: There are other opinion more opinionated frameworks out there are platforms or whatever you want to call them then Cooper 90s.

249
00:40:02.550 --> 00:40:05.940
Mike Stapleton: And that's good. If they do what you need to do. Great.

250
00:40:06.780 --> 00:40:19.020
Mike Stapleton: But if you want maximum control and you want to figure out how you're going to do everything because you want to differentiate and control everything and build the best thing you can and not have the framework, get in the way.

251
00:40:19.500 --> 00:40:24.900
Mike Stapleton: Then yeah, Cooper daddy's is very attractive because it's unopinionated. It doesn't tell you how to do logging.

252
00:40:25.710 --> 00:40:30.930
Mike Stapleton: Right. It doesn't tell you how to do monitoring fact these things aren't even built in, you need to add them.

253
00:40:31.440 --> 00:40:37.920
Mike Stapleton: Right, so you have to add centralized logging centralized monitoring you plug in all the things you want

254
00:40:38.850 --> 00:40:53.190
Mike Stapleton: That's the superpower is of Cooper 90s right but also that's it's it's problem when you're first trying to learn Cooper daddy's it's very painful because let's say oh it's toolkit approaches whole bunch of things and you build what you want out of it. Right.

255
00:40:55.230 --> 00:41:10.740
Mike Stapleton: It is API driven right so we can automate things. Yay. And it's built to integrate with cloud providers. You can do things in Cooper Nettie like if you launch a container and it needs storage Cuban 80s can go off and talk to your cloud provider and

256
00:41:12.870 --> 00:41:22.290
Mike Stapleton: Build some storage for you right if you if you're running this on Amazon Web Services. There's plugins for Cooper daddy's to integrate and I can create EBS volumes.

257
00:41:24.630 --> 00:41:29.670
Mike Stapleton: If you're using managed services corporate entities, run by

258
00:41:30.870 --> 00:41:33.270
Mike Stapleton: Cloud providers and that's usually done automatically.

259
00:41:34.650 --> 00:41:35.460
Mike Stapleton: Just kind of nice.

260
00:41:37.560 --> 00:41:41.400
Mike Stapleton: All right, a little bit about Cooper Nettie. So what is Cooper daddy's give us

261
00:41:42.210 --> 00:41:52.470
Mike Stapleton: Well, the fundamental thing that Cooper Nettie has our pods, they call it a pod pod at runtime is one or more containers and configuration of those containers right so you

262
00:41:52.950 --> 00:42:06.780
Mike Stapleton: You, you say, hey, Cooper daddy's I want to run some software because in the end. That's what it is a pod is running some software that software is an image that some developers pushed into a repository or administrator wherever you are.

263
00:42:08.310 --> 00:42:19.620
Mike Stapleton: At runtime that pod is that software running it can be multiple containers is just adds flexibility. It doesn't have to be there's good reasons for doing it. Excuse me.

264
00:42:22.110 --> 00:42:22.950
Mike Stapleton: Get some water.

265
00:42:26.880 --> 00:42:44.550
Mike Stapleton: Sorry. Yeah, one or more containers configuration for everything. As I said, storage and networking when you design a pod you tell it all. I need some storage attached and that storage again can be integrated with external API driven storage systems like cloud providers.

266
00:42:45.780 --> 00:42:57.840
Mike Stapleton: You a pod has its own network namespace that Colonel feature and other it has its own TCP IP stack. So reality a pod has its own dedicated IP address.

267
00:42:58.890 --> 00:43:02.790
Mike Stapleton: And send traffic to that IP address, you're talking to the containers that are in it.

268
00:43:04.530 --> 00:43:22.500
Mike Stapleton: And it also supports resource management. So when you're creating a pod to run some software and part of the configuration is by the way I want to limit it to a certain amount of memory. I'd like to throttle it to a certain amount of CPU, GPU shares or something.

269
00:43:24.840 --> 00:43:27.450
Mike Stapleton: Also a whole lot of other configuration and, you know,

270
00:43:28.590 --> 00:43:42.360
Mike Stapleton: Tomorrow I'm starting a four day Cooper daddy's course for system administrators. So you can imagine we're not getting it into it too much here. But yeah, that's the kind of basic keys of the pot is the fundamental unit that we have running something

271
00:43:44.160 --> 00:43:52.290
Mike Stapleton: Now as I mentioned earlier, running software isn't just about the software. It's the software and that software is configuration.

272
00:43:52.770 --> 00:43:57.630
Mike Stapleton: So Cooper Nettie has secrets and config maps. These are

273
00:43:58.020 --> 00:44:11.820
Mike Stapleton: Separate objects, who create. So you have your pod and then you have secrets and config maps part of the configuration of the pod is saying, by the way, use the secrets and config maps and it config map is just key value pairs secrets, same thing.

274
00:44:12.630 --> 00:44:22.800
Mike Stapleton: At runtime, the data that you put in these are made available to the software running in the container, either as environmental variables or they're mounted as files and directories.

275
00:44:24.810 --> 00:44:36.210
Mike Stapleton: Having the configuration separate from the containers allows you to have one image pushed in and then run many, many different copies of that of that software and the image configured in different ways.

276
00:44:36.900 --> 00:44:45.990
Mike Stapleton: kind of more like the real world to use software install it and you configure it. It's a separate beast. So now we need to we need to handle that. So secrets in config maps are available.

277
00:44:49.260 --> 00:44:56.280
Mike Stapleton: Yeah, storage, it has to help with storage and so it'll automatically mount the storage that you configured.

278
00:44:56.940 --> 00:45:13.680
Mike Stapleton: In the pod. So you say, hey, when you launch a pod, I need this storage attached and it's it's mounted software namespace is mounted as part of the containers. It's available to the containers all the containers in a pod can access the same mounts.

279
00:45:14.790 --> 00:45:15.660
So that's really good.

280
00:45:16.860 --> 00:45:22.740
Mike Stapleton: One of the key types of volumes that you command is something called a persistent volume.

281
00:45:23.790 --> 00:45:32.550
Mike Stapleton: The kind of claim to fame for persistent volumes is that they can be dynamically generated through something called storage classes.

282
00:45:33.780 --> 00:45:42.210
Mike Stapleton: A pod makes a request for persistent volume through something called a persistent volume claim. Hey, I need some storage.

283
00:45:43.080 --> 00:45:53.670
Mike Stapleton: The Cooper daddy's cluster will go looking for some storage some persistent volumes, something to mount that already exists that fulfills its requirement if it doesn't find it.

284
00:45:54.060 --> 00:46:03.540
Mike Stapleton: A Storage class can integrate again with a well so anything API driven. I say cloud integration, but any kind of API driven

285
00:46:04.680 --> 00:46:13.050
Mike Stapleton: Storage Cooper natives can make a request across the network and say, hey, make me some storage and then make it available to the pod. So it can be mounted

286
00:46:14.400 --> 00:46:19.050
Mike Stapleton: Dynamically right again don't need administrators or people involved with the storage that way.

287
00:46:20.100 --> 00:46:20.910
That's pretty cool.

288
00:46:22.740 --> 00:46:40.200
Mike Stapleton: Yeah now upon itself is transient it just disappears. It goes away, it, it, you can't shut down a pod and relaunch it when it, when you if you delete a pod. It's gone. And when it comes back, new IP address different different everything

289
00:46:41.610 --> 00:46:56.220
Mike Stapleton: So we need to horizontally scale and make sure our pods are running. So there's something called controllers built into Cooper daddy's controllers just software that's monitoring what's going on and reacts to changes.

290
00:46:57.240 --> 00:47:07.440
Mike Stapleton: There's a controller color replica set its job is just to keep some number of pods running, you can say I want five and it'll launch five and keep five running

291
00:47:07.920 --> 00:47:15.270
Mike Stapleton: And then if one of them died for some reason. It's a remember these pods can be running across a cluster of machines. I guess I should

292
00:47:16.290 --> 00:47:22.770
Mike Stapleton: Write Cooper Nettie is you have a bunch of servers and it's managing the pods across a bunch of servers.

293
00:47:23.190 --> 00:47:38.310
Mike Stapleton: And so if a server goes down, we'll all the pods on that machine are gone. If they were part of a replica set the replica set but woof. I had five. Now I got for launch another pod and so it'll keep some number of pods running help you horizontally scale.

294
00:47:39.420 --> 00:47:42.690
Mike Stapleton: They also have support something called the horizontal pod.

295
00:47:44.730 --> 00:47:45.630
Mike Stapleton: What the heck was a

296
00:47:47.010 --> 00:47:56.100
Mike Stapleton: Horizontal pod geez, I I suffer from that I forget words they use all the time, auto scaling anyway it auto scale. So, I mean, that's the point of it.

297
00:47:56.520 --> 00:48:02.490
Mike Stapleton: So the horizontal pod auto scale or its job is to based on metrics decide how many you want.

298
00:48:03.000 --> 00:48:07.950
Mike Stapleton: Right, so you could give it rules based on the amount of CPU utilization. I'd say that's the kind of key one

299
00:48:08.370 --> 00:48:22.470
Mike Stapleton: And if your pods, the number of pods, you have running gets to be you. They're too busy CPU utilization is getting too high, then the horizontal pod auto scale or will tell the replica set. Yeah, more and the launch more

300
00:48:23.640 --> 00:48:34.170
Mike Stapleton: This this achieves elasticity, right, it also saves your bacon. If you didn't set the number of pods high enough to handle the workload and all of a sudden the workload goes up and

301
00:48:36.180 --> 00:48:55.110
Mike Stapleton: So that's that's available now. It's a cluster of machines. So in the end, you only have so much compute based on the number of machines in your cluster. But if you're using a cloud managed deployment cloud managed means someone else built and is operating the cluster you're using it.

302
00:48:56.520 --> 00:49:11.400
Mike Stapleton: For example, Amazon ek is Mr. Cooper Nettie service GK he Google digital ocean Amazon. They all have managed clusters, you can just go to those cloud provider say yeah, build me a cooper natives cluster.

303
00:49:13.080 --> 00:49:24.420
Mike Stapleton: They all have auto scaling. If you want to enable it. And this is auto scaling of the cluster itself. So if the actual computers running all your pods and everything, start to get busy. They can dynamically launch

304
00:49:24.780 --> 00:49:32.670
Mike Stapleton: More servers and some of them support doing it elastic Lee. In other words, if you have more than you need. They can actually kill some off, but that

305
00:49:33.960 --> 00:49:35.670
Mike Stapleton: That's a little more painful because you have to

306
00:49:36.870 --> 00:49:41.880
Mike Stapleton: kill off pods to get rid of a server. But yeah, it's definitely a thing that can be done in support it.

307
00:49:43.890 --> 00:49:49.950
Mike Stapleton: And if you're on the cloud. You don't want to be running things you don't need. So elasticity on the clouds are really important.

308
00:49:52.980 --> 00:50:05.460
Mike Stapleton: Yeah, software lifecycle your version of your software great you launch your pods, but you're going to have to update the software at some point. Right. So what's going to happen is developers going to make new images and push them into that software repository.

309
00:50:06.120 --> 00:50:13.500
Mike Stapleton: You are going to have to kill off pods and launch pods, you do not log into a pod and patch it. Now you could

310
00:50:14.970 --> 00:50:23.340
Mike Stapleton: Write we can do almost anything we want. In the end, these are just processes running on a computer with resource management tied around them, but

311
00:50:24.540 --> 00:50:24.990
Mike Stapleton: Shit.

312
00:50:26.730 --> 00:50:33.570
Mike Stapleton: We have something called deployments in Cooper daddy's deployments create and manage replica sets a replica set

313
00:50:34.020 --> 00:50:43.830
Mike Stapleton: It launches those pods. It has a fixed configuration you told it to launch pods in a certain way, all those pods are identical configured exactly the same way.

314
00:50:44.550 --> 00:50:56.730
Mike Stapleton: With a deployment. You can change the configuration of the deployment and what it will do is it'll launch a new replica set right with new pods configured differently and say new images.

315
00:50:59.580 --> 00:51:00.720
Mike Stapleton: That allows you do upgrade.

316
00:51:02.280 --> 00:51:09.330
Mike Stapleton: Now, when you do that it supports doing rolling upgrades and hard cut overs.

317
00:51:09.900 --> 00:51:26.640
Mike Stapleton: Right, so you, you make a change to your deployment, it creates a new replica set, you have the old replica set in the new and it slowly start scaling up the new one, as it scales down the old one. So you'll have a mixture of the new and old versions of your pods running at the same time.

318
00:51:27.780 --> 00:51:36.210
Mike Stapleton: That's kind of the issue. You got to make sure your software can can handle that. And whatever changes you made are compatible.

319
00:51:38.280 --> 00:51:51.090
Mike Stapleton: If they're not, you can do a hard cut over and when you make changes to your deployment. It'll first scale. The first replica set down to zero. So, you have no pods running your software and then as soon as that succeeds, and then it locks it

320
00:51:51.510 --> 00:51:57.780
Mike Stapleton: Instantly scales up the other replica sets bang you got a whole bunch of pods that start running, running your new version.

321
00:51:59.700 --> 00:52:11.100
Mike Stapleton: And of course, in the real world. It's great to be able to do upgrades and stuff. But sometimes we regret that we have to go backwards. So yeah, we got a history, you can scale backwards.

322
00:52:14.220 --> 00:52:21.570
Mike Stapleton: At Cooper Nettie is also helps with service discovery and load balancing. We have things called Cooper Nettie services they give you a fixed

323
00:52:21.930 --> 00:52:31.590
Mike Stapleton: IP address and DNS entries. They give you at least a DNS entry technically the fixed IP addresses optional, but by default, you get an IP address and load balancing.

324
00:52:32.730 --> 00:52:49.380
Mike Stapleton: Now, it's not like it's just a kernel again when you're creating services, the DNS part. There's some DNS servers running in containers on the cluster. Yeah, but the whole networking thing and load balancing and how that works. It's just the colonel being configured to do that.

325
00:52:50.970 --> 00:53:10.470
Mike Stapleton: So some kind of software load balancer were built into the Linux kernel. Now these services by default are only accessible and your pods are only accessible inside the cluster. So if you do want to make things available, you can with services, services can be exposed outside of the cluster.

326
00:53:12.390 --> 00:53:17.850
Mike Stapleton: And that can even be integrated with external load balancers. So in in a cloud environment is pretty common.

327
00:53:18.090 --> 00:53:28.080
Mike Stapleton: That there will be an external load balancer to your Cooper Nettie cluster that the world is talking to and then those load balancers, talk to your cluster that talks to your software internally.

328
00:53:29.460 --> 00:53:38.790
Mike Stapleton: And can be all automated. I make a service type load balancer. Next thing you know, it calls the API's of my vendor and produces a external load balancer.

329
00:53:40.740 --> 00:53:40.980
Yeah.

330
00:53:42.420 --> 00:53:56.010
Mike Stapleton: Networking can get fun for sure. It also has support for staple applications Cuban 80s is kind of like easily support stateless applications. In other words, instances of your program don't have

331
00:53:57.570 --> 00:54:02.040
Mike Stapleton: Persisted storage storage is somewhere else off of those pods.

332
00:54:02.910 --> 00:54:07.860
Mike Stapleton: But we can run staple applications. A good example here is a, like a non relational database.

333
00:54:08.040 --> 00:54:21.600
Mike Stapleton: Something that's horizontally scale. So you have a bunch of separate instances of something running but each instance of that in our case container. Each container needs its own storage. So, it stores its own data separately from the other ones.

334
00:54:21.840 --> 00:54:35.070
Mike Stapleton: State full sets and Cuban 80s allows you to do that every single container gets a consistent name and gets its own storage. The it uses or can use. It's not an option.

335
00:54:36.210 --> 00:54:44.010
Mike Stapleton: P persistent volume claims are in persistent volume claims is a way for a container to request a pod to request storage.

336
00:54:45.240 --> 00:54:53.910
Mike Stapleton: Now with a normal deployment. They're all configured the same way. So they would all be all the instances will be trying to get the exact same persistent volume claim accessing the same volume.

337
00:54:54.480 --> 00:55:04.020
Mike Stapleton: With staple sets each instances of your POD OF YOUR staple set can have their own storage their own data on it.

338
00:55:06.150 --> 00:55:18.780
Mike Stapleton: Yeah, all right. Cooper Nettie is is great, but it's not the end all be all it does not help you with application development, it will not make your software more agile when you're developing it.

339
00:55:20.610 --> 00:55:26.430
Mike Stapleton: Doesn't do that right you write your programs and you push them into a repository, and then Cooper 90s runs them.

340
00:55:27.660 --> 00:55:42.810
Mike Stapleton: It's not an enterprise platform. A lot of people want to use have one big honkin Cooper natives cluster and have lots of people working on it, different teams different things and security wise trying to isolate things is problematic, to put it mildly.

341
00:55:44.100 --> 00:55:55.590
Mike Stapleton: It is much better as like an application platform. So if I have multiple applications they can have their own Cooper 90s clusters, you're going to want to have more smaller communities clusters.

342
00:55:57.330 --> 00:56:09.480
Mike Stapleton: It's unopinionated that's a good thing. But yeah, you need to figure out how you're going to do centralized logging and monitoring and alerting and integrating with other systems, that's, you know, just the way it is.

343
00:56:11.280 --> 00:56:23.730
Mike Stapleton: Yeah, Cooper daddy's does not replace cloud providers right cloud providers give you two major things something called platform services. These are useful for the developer

344
00:56:24.180 --> 00:56:34.830
Mike Stapleton: Platform services is functionality that you call across the network instead of you writing it into your program or having libraries and running it locally, you make a request to do something.

345
00:56:36.210 --> 00:56:44.070
Mike Stapleton: Like for example, image categorization. You can upload a picture and it tells you, hey, this is a picture of the kids playing and it's a sunny day and

346
00:56:44.490 --> 00:56:57.120
Mike Stapleton: Or maybe you got some you want to do voice recognition or text or voice or do some low level functionality that isn't an application on its own. It's a feature you take advantage of in your application.

347
00:56:58.320 --> 00:57:05.640
Mike Stapleton: Platform services, reduce the amount of responsibility developers have because they have less code. I mean, as

348
00:57:05.880 --> 00:57:12.780
Mike Stapleton: Whenever you're doing development. You want to develop as little code as possible, you want to be responsible for a little as possible.

349
00:57:12.990 --> 00:57:21.120
Mike Stapleton: You just basically want to write is just enough code to stitch together stuff that is other people's responsibility platform services, your

350
00:57:21.810 --> 00:57:32.370
Mike Stapleton: It's their responsibility you just use it and yeah that's really useful. Just because something is running in a container doesn't mean you can't take advantage of platform services.

351
00:57:33.480 --> 00:57:34.620
Mike Stapleton: Absolutely you can

352
00:57:36.600 --> 00:57:47.610
Mike Stapleton: This is where you get into the word cloud native right taking advantage of the factor on the cloud and features that it has yeah can help you build better software that's easier to manage. Absolutely.

353
00:57:49.470 --> 00:57:57.960
Mike Stapleton: Managed Services. Well, these are more at the application level like a database and things like that, they install and manage the software for you. You just use it.

354
00:57:59.160 --> 00:58:08.220
Mike Stapleton: Perfect example of a managed service is nice itself. Right, so I can go to a cloud provider. So yeah, I need communities, they'll back it up. They manage it. You use it.

355
00:58:09.750 --> 00:58:23.730
Mike Stapleton: Was lots of managed services that are available that helps ops right less stuff. Right. I just want a database. I don't want to back it up and make it fault tolerant scalable. I just want to use it, please. Well, yeah, you can use a managed service.

356
00:58:26.880 --> 00:58:32.490
Mike Stapleton: And all of this makes it more agile right take advantage of the features that cloud.

357
00:58:33.600 --> 00:58:34.230
Mike Stapleton: Provides you

358
00:58:36.030 --> 00:58:53.580
Mike Stapleton: It reduces risk. Yeah. Well, you need the expertise and you got to not do it wrong, right, when you're using managed services all automated right and and done by experts, the systems designed and everything and monitor not a didn't, chances are they can do a better job than you can.

359
00:58:54.750 --> 00:59:02.310
Mike Stapleton: So it's risky to do things and to be responsible for things you don't need to be so yeah you can take advantage of platform services.

360
00:59:03.570 --> 00:59:04.170
Mike Stapleton: For sure.

361
00:59:06.330 --> 00:59:14.850
Mike Stapleton: Alright, so the bottom line is Cooper Nettie does not replace the cloud, right, you can run it on the cloud. It does make your code.

362
00:59:15.570 --> 00:59:29.100
Mike Stapleton: It doesn't make your code. A lot of people think Cooper daddy's makes your code so that you can if it runs in Cooper Nettie you can run it on any cloud provider it they think it makes your stuff cloud agnostic. It doesn't any more than a VM do

363
00:59:31.290 --> 00:59:46.410
Mike Stapleton: The only way you're going to build something that's cloud agnostic is not to take advantage of platform services and things like that and end up with software that's more difficult and expensive to maintain. Because you have to do it all yourself in Cooper 90s.

364
00:59:48.270 --> 00:59:48.840
That's

365
00:59:50.190 --> 00:59:52.230
Mike Stapleton: You know price you pay

366
00:59:53.340 --> 00:59:58.860
Mike Stapleton: Cloud native is all about taking advantage of the fact that you're on the cloud and working with it.

367
01:00:00.330 --> 01:00:02.100
Mike Stapleton: That's a no, that's a

368
01:00:03.390 --> 01:00:14.700
Mike Stapleton: We don't want to get tied to a particular vendor, but in life you pay one way or another. And if you don't take advantage of the features and tools that are available to you at the time.

369
01:00:16.050 --> 01:00:29.760
Mike Stapleton: You'll just end up with a you know a product that's harder to maintain more expensive and it's just not free being cloud agnostic, not so easy to do. But cloud native definitely

370
01:00:32.580 --> 01:00:41.400
Mike Stapleton: And that's basically it. That's a no. Does anybody have any questions comments or anything was checking

371
01:00:42.660 --> 01:00:53.490
Michelle :: Webinar Producer: Since we are at the end of our webinar. I just want to draw everyone's attention to the chat window I shared all of the links to our relevant Cooper daddy's training.

372
01:00:53.790 --> 01:01:04.650
Michelle :: Webinar Producer: You can find all those links in the chat window, as well as the context for our refer a friend promo. That's the first thing you'll find in that list.

373
01:01:05.340 --> 01:01:21.900
Michelle :: Webinar Producer: Basically when you refer a friend, your, you can get yourself up to $200 amazon gift card and your referred friend will save 15% on their course you'll find all the T's and C's for that promo on our website. The links in the chat.

374
01:01:23.130 --> 01:01:28.800
Michelle :: Webinar Producer: If there are any questions do enter them in that Q AMP a box at the bottom of your screen now.

375
01:01:32.250 --> 01:01:41.550
Michelle :: Webinar Producer: And if you do need to jump off, thank you so much for taking the time out of your day to learn about Cooper Nettie is with us today. Thank you, Mike.

376
01:01:43.140 --> 01:01:53.220
Mike Stapleton: Yeah, we've got a lot. Like I said, this is a blast of stuff that I went through here like I really wish we had more time together. We could talk about these things in more detail.

377
01:01:54.240 --> 01:01:55.980
Mike Stapleton: But yeah

378
01:01:56.370 --> 01:01:57.030
Michelle :: Webinar Producer: Of course,

379
01:01:57.090 --> 01:02:07.620
Mike Stapleton: The brave. Brave New World, the old world and there'll be new solutions and it's just going to keep going and Cooper 90s is cool, but it's a tool like

380
01:02:09.060 --> 01:02:21.720
Michelle :: Webinar Producer: Another reminder for everyone who is still with us. We're going to send a copy of the recording to everyone. By the end of the week. It looks like we're just getting a ton of. Thanks. So yeah, Mike. Thank you.

381
01:02:22.680 --> 01:02:27.090
Michelle :: Webinar Producer: I think I'm going to go ahead and close it off. Now, just since we are a little bit over schedule.

382
01:02:28.530 --> 01:02:30.570
Michelle :: Webinar Producer: Okay. All right, everyone. Take care.

383
01:02:30.690 --> 01:02:31.050
Thanks.