 Hello, everyone, and welcome to Michigan, where the pizza square and everyone comes with a nice little reference map. Now, it feels a little weird to cover this on the last day, as this is a little bit more of like an intro presentation. But as 60%, 65% of KubeCon attendees are new to KubeCon, and many here are being new to the whole idea of Cloud Native, we thought we could give a quick little teal yard to help folks sort of understand some fundamentals and bring a little bit of home, a little bit of Michigan, a little bit of Detroit into it. We both grew up here and spent almost our entire adult lives in southeastern Michigan. No matter where we are, even though we recently moved, this is still home. Thankfully, wherever we are, we do still carry a map of the Mitten Around, and we can never really forget about our little bunny rabbit of an upper peninsula but I'm bad at shadow puppets, so I'm not going to try. Truly, over the years, whenever someone has asked us where we're from, we say Michigan and we hold up the right hand. Another interesting Michigan geography-related thing is most people say something's five, 10 miles away. In Michigan, we'll almost always measure it in minutes and say something's about five minutes away. So with that little bit of geography out of the way, let's talk about a little bit of history. Yeah, ancient history. Jeff and I have been best friends and for most of our adult lives, coworkers and or roommates, usually when one of us would get into something the other would follow, whether it be a game, a hobby, or technology, and well, the other would follow. And we, for the record, shared a nine-foot-by-10-foot room for about three months. It got close, but we are very different people. The best analogy we can use involves the mythbusters. I'm Adam and he's Jamie. But the biggest difference is we actually hang out after work hours and have dinner and stuff. We got into containerization and container orchestration pretty early while we worked at the University of Michigan. That being our background, teaching and education has been something that we're both very passionate about. And we've done a number of tutorials and lessons for different people in the community. So with that being our background and covering some of this stuff, we are really passionate about this space. And we sort of have found in terms like patterns for the stuff when it comes to teaching is, well, analogies. You take thing A compared to thing B and sort of develop a pattern from out of that. So with that, we wanted to sort of give a few Detroit, Michigan analogies to help sort of cover some of the basics. And the first, of course, being the Midwest, the thing that we really care about, food and pizza. So how is pizza declarative? Well, just think about it. You call up your favorite pizza place and tell them what you want. I want a large slice of pizza for delivery. You don't have to instruct the pizza joint how to slap the dough, apply toppings, oven temperature or even provide the directions to your house. Instead, you can call and declare what you want and fill in any required information and expect that system, the pizzeria, to resolve your declared state and deliver a hot slice of heaven. So very different from the imperative where you have to call out everything. So while declarative systems like this have existed before Cloud Native became more of a thing of what it is today, it's now much more, say, a fundamental part of everything that's being built and designed. Kubernetes has really built this way and the vast majority of tooling built on top of it follows the same pattern. Pop up, G-F-E-O. Did you know that Michigan is arguably the pizza capital of the world? Sure, there's Chicago style, there's New York style, California pizza kitchen. All of these are great places with great styles of pizza. But in southeastern Michigan, ominos, cottage in, little Caesar, Jets, all started here. Now, outside of pizza, it wouldn't be a talk about Michigan and Detroit if we didn't talk about cars that go hand in hand. I'd like to interject for a moment. What people commonly call a seatbelt is actually the three-point seatbelt or also known as the CIR Griswold restraint. All right, with that meme out of the way. Let's talk about microservices. You might not think it, but the seatbelt is an interesting concept in this regard. It's a combination of materials and manufacturing processes that, when installed properly, come together to make an invaluable safety tool. These individual components, the belt, the tongue, and the buckle, are all manufactured separately. But they follow a certain specification. Improvements to the belt don't actually require any changes to the buckle or the tongue. So long as the seatbelt API is adhered to, they can come together and function properly. That definitely seems like an example of a microservice in the physical world. And another fun story, the three-point seatbelt, was originally engineered at Volvo. Once patented, they realized that this wasn't some marketing ploy or a selling feature. It was a critical piece of safety equipment. So they opened up the patent for anyone to use and for the betterment of all. And that also does kind of sound familiar. That sounds a little like open source. So now we've talked about seatbelts. Let's go back to cars. So just like cars, just like cloud-native applications are very complex beasts. In fact, the modern car is a giant interconnected system of microservices. Many cars today have upwards of 150 microprocessors, not to mention all their various sensors and other telemetry systems in them. That's not even really taking into account like the new EVs, which are essentially what giant computer to begin with. Really, it's a complex distributed system that is dynamically responding to the demands that the user and the environment are putting on it. So while doing that, it's also trying to judge dozens of different things, maximizing traction, and of course, balancing fuel economy and performance. So similar to that in Kubernetes, when the load on your application increases, like a seasonal spike in for retailers, the cluster can respond through things like the horizontal pod autoscaler, the vertical pod autoscaler to do the same. So just like your car, listening to the various telemetry from your application, it can scale to right size up or down to balance the load. You can also tune it like flipping on sport mode or going all out for max performance. Think like running heavy high-performance computing workloads. You can allocate more resources upfront for a fast response, more power, fuel economy be damned, gotta go fast. So yes, there are a lot of moving parts and yes, it is more complex, but that gives you a lot of flexibility and being able to customize, well, the thing Kubernetes cars to meet your needs. And we can't talk about cars without talking about assembly lines. In the early days of the automotive industry, the need to churn out more cars led forward to adopt the assembly line pattern. William Pah Klan suggested having a station to focus on a single assembly task before the in-progress car would move to another specialized station. And it was super effective. As car assembly got faster, Ford actually ran into a bottleneck with paint drying in time. For the next station, sorry, they limited their available paint until a new lacquer innovation came along. That kind of sounds a little bit like some tech debt and duct tape fits. Exactly. All over. But now if you walk into a modern automakers factory, you'll see, for better or worse, significantly less people and significantly more automated machines. What people are doing there is usually monitoring the automation lines. That kind of sounds familiar. Car assembly is a perfect physical analog for software engineers being pushed to ship software as fast as possible. A need to ship cars out of a factory faster led to streamlining processes in automation. And from pressure like that came innovation. I remember in ye old days, we specialized in trying to ship core components of our software, think like a basic PHP app, and making them run in production by hand. As automation ramped up, less people became involved in making them run, and more people became involved in doing things like monitoring CI jobs and debugging why builds failed. Even now, these processes are becoming more automated, although there is an argument to be said about automation bloat. Now we ship software with Dockerfile and YAML instead of worrying about things like dependencies or an execution environment. Dependencies do still matter. Penencies do still matter. But just as automation became the norm in the automotive industry, automation is a de facto standard in the cloud native world when shipping a cloud native application. And yes, Fago. Hopefully everyone enjoyed Fago this week in the vendor room. I know I did. But what do Fago and Ford have in common? Well, both start with the letter F. Also, both are household names here in southeastern Michigan and Michigan in general. And they were both formed in Detroit in the early 1900s. Fago was formed in 1907, and Ford was formed in 1903. Fago is so predominant here for Easter I had an aunt that would baste her holiday ham in Fago Red Pop. It was actually good, it was actually good, but... All right, so brief show of hands. Who here calls that soda? Who calls it pop? Who would call it cola? Anything else? Coke. So ultimately, we're talking about a carbonated beverage. That's the definition. And we have more than four names for it. Now imagine you're trying to describe a problem with a cloud-native application to someone that has no experience with one. You'll be speaking a foreign language, talking about pods and network policies and this. This is why we need a common reference language that everyone can rally around. There are community efforts such as the CNCF Glossary, which can help beginners by being a decent reference. And also, they're open source contributors, writing, maintaining and translating the tech docs for us. And these tech writers make open source accessible and they are truly the unsung heroes. 100%. 100%. So that brings us to our next thing. Detroit versus everybody. As I'm sure many are aware, Detroit isn't looked upon as a great place with the history of Detroit, what it's been through between riots, recessions, corruption, despair. It's kind of unsurprising. And our football team, but anyway. Those that live here, think the moon of it. And so the sentiment is born from that passion and pride. So how does this sort of combative slogan really relate to cloud-native? Well, you need to look no further than Twitter and you'll see that same passion in our community, passion for better or worse. Now, it's that passion that drives us. It can cause Twitter feuds, it can cause burnout, but it can also create world-changing communities and globally transformative open source software. It's also that same passion that fuels our local communities. It is here where we often find a wealth of knowledge, people, and make long-term friendships. Jeff and I, we wouldn't be here today if it weren't for getting involved and helping run our local meetup with our other organizers, George Castro and Mario Loria. Architecture, our meetup, it wasn't the biggest one. Only everything, 30 to 35 people, but those same people came just about every single one. We were lucky, hashtag blessed. Once people attended, they kept showing up and it became much more than a meetup. A lot of us would get together outside of the meetup to do old school land parties, hang out. We had a Slack channel for daily chat where we could just sort of balance both technical and personal questions off each other. It was just a really great community. We could just check up on each other and make sure we were doing all right. So the pandemic has certainly hit events and meetups hard and by no means is it over yet, but I think we're on the upswing and can start to get together again. Nature is heat. Folks are returning to DevOps days and we're seeing more Kubernetes community events pop up. There are six KCD events or Kubernetes community events between now and the end of the year and eight are on the schedule between now and KubeCon EU next year. There are also around 270 cloud native meetups listed on the CNCF community page. Now some of these are dormant but I encourage you to look, get involved. It only takes one person to roll a ball down a hill and if that ball is stuck, maybe it needs a gentle nudge but find your peers and try to get involved. So the title of this talk is Cloud Native 101 Motor City Edition and we had a couple of overt goals with the little time we were given. First, if we were able to walk off the stage and y'all chuckled, maybe learned something about Detroit, we'd consider it jobs done. Besides analogies, we're both major believers that learning while having fun yields the best results. Look no further than the program chairs, cosplaying, you understand. But even basic cloud native concepts can be difficult to fully grasp when you're new. Second, Southeastern Michigan is amazing and it should be celebrated, it should be showcased. It's often the butt of many jokes and it really shouldn't be. But there was a third goal and it wasn't just making people hungry with pictures of pizza and pop. In the least narcissistic way, it was meant to show you all a glimpse into our cloud native journey. You've probably heard it multiple times, open sources made of people. But so often do we see the finished pizza in a box and not how the dough got slapped out or the saucer toppings added. I am really starting to get hungry. But I can most assuredly say, I would not be anywhere near close to where I am in life, physically, mentally or emotionally, without many of the folks in this room. But most importantly, the person next to me. Even introverts need other people to achieve their full potential. So, this is Detroit. This is Michigan. This is our community and everyone does have something to add and share. You may not be able to find your own Bob or Jeff, but find, own and share your culture. Make connections with people and everyone will be better for it. Thank you. Thank you.