From Classroom To Container: Teaching Distributed Systems With CNCF & Cloud Na... Matthias Haeussler

This talk discusses the speaker's experiences teaching university lectures on distributed systems, utilizing cloud-native technologies. As a guest lecturer and cloud-native consultant, the speaker shares insights from two decades of teaching, highlighting the evolution of computing from PC to internet to cloud and AI. They emphasize the importance of hands-on implementation in education, focusing on tools like Docker, Kubernetes, and service meshes to facilitate the learning process. The speaker also illustrates concepts such as distributed architectures, observability with OpenTelemetry, and the significance of clean API design through practical student projects. Additionally, they encourage real-world integration of technology in academic settings, reflecting on their journey and the impact of AI on education.

Thanks very much uh for coming to my talk about my experience in um teaching university lectures with um support of like cloud native technologies. Um yeah, I want to maybe introduce myself real quick. So I'm I'm definitely not like a full-time professor. Actually, I'm not a professor at all. I'm what I'm like what I call a guest lecturer. So I'm I'm teaching but I have a regular

job. My regular job is like a cloudnative uh consultant at a at a company called CGI and I'm teaching distributed systems currently at two universities in the area of Stogard. Um this is also the first time I really give a talk about that. So I've given plenty of talks about technologies and um um implementations and stuff but this is really more on the focus of the educational

background. Uh just as a quick question I know it's it's an offsh shot but is there any of my former students here in the class uh in the room. There's one. Okay. So uh I know I I the question I asked I knew there is one of my former students around. I just wanted to check if he really makes the effort to come here. I can't give

him any any bad grades anymore now since this is over. All right. So um I'm just going to jump in on the um a bit on the background how I came to all this. So I tried to make a bit of a timeline um that I'm going to talk about a few minutes. So this is like the say like the last four decades the area I spent

time with in in the area of computing. I kind of grouped this into like the PC internet cloud and AI era. It's there's probably more in between but these are probably the the most the cornerstones that affected me most. And I started teaching in 2001 pretty much right after graduated university. Uh and this was the time when like the internet became more a thing of serverside applications

um and moved away from like uh being being too static. And um I had a bit of a break in 2006 to 2010 and since 2016 I'm teaching um distributed systems um with of course more focus on on cloud-based technologies. So a bit of my technology background. Um I mean I got my gateway rucks were pretty much um Linux and Java. Um for the web engineering part

I the technology base was something that people would refer to as a lampstack with like Linux uh Apache my SQL but no PHP. I was more on the Java side. So I used um Tomcat as a as an application server. And then towards like the the more more recent area, I got into cloud native through to Docker and Cloud Foundry and and and all the other technologies

I'm going to to go into more um in a bit. So that's these are the three universities I have been teaching at. So I wanted to briefly mention that as well. And also a quick shout out to my employers for basically supporting my activity as as a as a lecturer all the time. So this started when I was still working at IBM. it continued in Novate and

nowadays I'm doing that under the uh under the flag of CGI. So back to this and probably back to the more recent kind of era. So this is basically what the the title hopefully promised. Um so there were things of course like Docker getting getting into it then um Kubernetes as as a really good platform um basically running as a distributed system and also for running distributed

systems um and and more advanced phase things like service meshes with withto selium and then open telemetry as an observability part on top. I also would want to mention just like maybe some supporting technologies. Um as I will say later on, I'm a big fan of not just theory but more like hands-on implementations. So I was very grateful for things like gitpot or or um GitHub code

spaces that made the students able to like implement all on the same ground and brought a big advantage to them and nowadays of course the support of AI um which I will show later on in this presentation as well. So first of all I want to talk a bit about what's the content of what I'm teaching. Then I want to talk a bit about um the technologies

and in the way um they helped me quite a bit. And in the end I also want to show a couple of results that um pretty much my last semester that I was teaching in the Windsor um brought along to get get you a feeling what the students kind of came up with after after such a semester. So I mentioned theory and practice and of course things

don't work without theory but um I definitely try to put a lot of the things in like hands-on implementation so that the students know how how to build the things what makes it a distributed application in terms of communication persistence containerization different deployments configuration and so on. Um on the left side I see I see the theory that I think I should definitely cover. Um but basically

the goal of of the of the class is kind of to make them interact and not just learn things like the cap theorem or the 12 factors by heart but also of course implement according those um those let's say guidelines or um or or ideas. So what else I cover is the fallacies of distributed computing, Conway's law, a bit of an intro into domain driven design also

the time is not enough to to do all that APIs of course and like cloud abstraction models and so on. So in the next three or four minutes I just going to show like my idea of and and um of of a distributed environment and and and the concepts what I'm what I'm doing there. So I normally say that a distributed system is a system who has

multiple components that are located in a different sections of the network but the most important thing is basically that they kind of try to achieve a common goal. So in the end and that doesn't only apply to university that also applies to my daily work with my clients um is that the system is about to provide a behavior or functionality that somebody can can consume and under

the hood nobody will ever think if is there a distributed system or something beneath. I mean if you open let's whatever let's say Google maps you never ask yourself how many containers are there running. I mean there are several containers running but um uh this is basically the the end result that um that that counts in the end. So why would somebody build a distributed system and

and uh cause one problem to be distributed in into many problems. So um what I basically I basically try to categorize it and say one of the things why we why you basically do that is the factor of heterogenity. you might have different stacks in terms of of uh physical hardware of operating system of frameworks and whatsoever they won't run all in the same process. So you

basically have to like um connect them also very often like uh as you can see here mainframe Linux Unix and so on different architectures provide different benefits for running things. So like mainframe for IO stuff um Unix for application service Linux maybe for for for forend servers and so on. So that would be one of of the things more higher in the stack. you might want to

run different different um implementation languages, different frameworks, different components and kind of model your um your distributed environment uh along that and also since I just mentioned Conway's law um of course distribution might also make sense to say okay I want to have a lot of people and I want to group them in a meaningful way and try to build multiple autonomous development teams to come up

with a final solution in the end on the other side um next to heterogenity there is also the aspect of like let's say robustness or resilience of such a system. So um scaling is of course a a major aspect. So if you have like um four healthy instances and one goes down your client side will still see the healthy instance. Um along with scaling comes the possibility

for load balancing. So if your clients get more you are able to serve more by providing multiple instances and distribute the traffic. Um on the other side maybe if your clients become too much so you might want to block it or if this is like a hostile attack you might want to have resilience means in there that don't let the requests pass in order to for your

system to stay healthy a me like a way in between would be like rate limiting or throttling of course security is always a bit an important aspect who is authorized to access the um and then dynamic updates to say okay um one of one of the things of high availability is also that you keep your system up to date without the client noticing that you're running running

updates. So, we can do this either in a blue green kind of way or um in a more advanced way with like um canary deployments or percentage kind of rounding. Of course, there is more but um I only have half an hour. So, these are the things I would like basically to to place my focus on. In the end, um, where I want to get is to

say to my students, please build maybe something like this, a dist an application of distributed components where we have things like dynamic updates like going from version one to version two while the overall system keeps running for a component A, then have like scaling on component D, um, have load balancing on the side of C and so on. And I give of course a lot of freedom,

but um, these are kind of the the the boundaries. I also one of the things I emphasize on is like a a polyglot infrastructure to say there are different programming languages there are different frameworks for a reason not just because they have like their own fans but um some technologies are better for certain purposes than others. So try to have a um right tool for the right

job kind of idea and this is basically how you you pull you put your system together. Then of course applying container technology um configuring things using different forms of communication using different APIs there's a whole lot in that basket and also from from the left hand from the client side basically be able to provide different user interfaces to different kind of clients. All right so this is

roughly the story of what I'm what I'm trying to do. Now question is yeah uh I think this came too early so the question would have been um what kind of technologies are out there to support that and as I already heard of a few people laughing I'm guess you're familiar with that or at least some of them this is the the cloudnative uh landscape of technologies

and um yeah of course there are a lot of things out there that can be used to build a distributed environment I'm not asking my students to take all of them I think that make a lot of sense. Um, but I want to like highlight a few that basically helped me in a in a particular way. The and maybe before that going a bit a step back

in time. I mean, the landscape didn't always look like that. I remember times when it wasn't really like um a vertical flu when it when it still put like fit into a horizontal way. Back in 2017, it was really only a handful of tools. This is really hard to imagine by now, but even before that, people had the the requirement to build a distributed system. Before the

CNCF, what I was basically using um was Netflix. And Netflix is probably known to most of you by by a streaming service. But ne Netflix also had or still has an open-source library which was later on adopted by the by the SpringCloud library. And um back then you would have basically have to place the functionality not into the infrastructure but into your application components. So for example,

ribbon was a library for clients that did load balancing. Um Eureka was something for for a service registry like at your telephone book for your services. His was something for resilience and so on. So I'm not going to read through all of those but the nature of the implementation changed quite a bit. I mean it definitely worked back then. Netflix works very well. But um the thing

is this one kind of tied the overall infrastructure into one dedicated framework and that had an impact on the selection of your um of your implementation language. Now things started to change with containers. I mean um starting with containers, it was really easy for the students to learn and play around with. I mean everybody could install easily a docker in their environment or use something web- based

and then um try to build components for front end, back end, database, make sure the connections exist, play around with the network, do the port mappings and so on. And also with that uh it became more obvious how easy it is it can be like to swap out components. Let's say we're running a similar application but in this time using different technologies and still make them stitch

together and and work as a whole system um to provide a certain functionality. So this is always a good aha moment during during teaching to see okay now now this is getting somewhere. Um of course it can also be like used to host um is that a bit early right? I still have 50 minutes. Okay, thanks. Um like a like a messaging system or like an asynchronous

asynchronous uh communication uh component in there and um yeah so this is how we normally get started. However, it is also good to show that with plain techn container technology um you have limitations. So you can do a lot of good things especially for like distributing components around making things easy to demonstrate. I mean in the end I ask for a docker compose file. So I don't

want to fiddle around with their applications. I just want to run it and see it. And this makes it really easy um for for sharing what what people have built um and um and abstract away a lot of complexity. However, if you want to do things like dynamic updates, scaling, I mean scaling is possible, load balancing becomes more difficult. Um and same goes for the updates. This

is of course where Kubernetes comes in and and and Kubernetes definitely is a big part of of the lecture itself. I mean as I said before it it runs on a diff on on a distributed architecture and it runs distributed applications. So there's a lot from that to learn and um fortunately Kubernetes comes with those API objects that facilitate that. So you have a deployment that helps

you with like uh maintaining different versions of an application and upgrading from one to the other. You have services that basically um work as um where you can register your applications on a certain endpoint. It automatically provides um scaling across the instances that you do with the replica sets. You have configuration opportunities um with config maps and secrets and then ingress and gateway API. So this if

I get through all of this in one in one semester, it's already um um I'm already quite happy. Sometimes things go faster and um we get even a little deeper. So that's where we would potentially enter then um the world of of service meshes. Um I've played a bit with um linkod and and selium and um of course this is also good to show what are what

is actually limitation of a Kubernetes environment. Do you need anything more than that? Um, and if so, uh, how can you do that? So things become possible that you say, I I have now a way more granular control over the network connectivity in all of the applications running within such an environment. So to say, yeah, I want to update an an application from version one to to

two, but I don't want this like in one big step. Maybe I want to do a percentage routing or I want something like an optin to say I I basically select the cookie and then if the cookie is set I'm going to get routed to the new version and so on. So this is definitely more on the more granular side of network control and um of course

it really helps um to open people's eyes there. Um, another thing of course security when you say well I explicitly want to lock down or like like encrypt the um the connection between two components um do that with certificates or whatever else. So this is certainly um a a really big help. Of course there are more scenarios that you can do with service meshes but um I'm

for today I'm going to I'm going to leave it with the two. Then um what is always of course a big help is the topic of of observability. I mean uh especially when you learn thing things or learn new things then seeing is believing probably counts more than than in any other in any other scenario. And um I mean most since we at CubeCon I mean you

will understand but normally if you show this to somebody and say is this a distributed system or does it look like a distributed system people won't know. I mean people in here will probably know in this conference but not so much in the in in the outside world but if you show that which is basically the same thing that then everybody will understand what's going on even

like nontech people will say okay I see different components there's there's arrows there is flows um this is obviously what is what is happening um inside such such a system and what has made life a lot of a lot easier in the in the last three or four years in is like the the the gaining popularity of and um maturity of of open telemetry. So we can

take all kinds of our polyglot applications and then instrument them with an with an uh agent implementation move things to open telemetry collector and from there pick new solutions to basically visualize the the information that that we are collecting. So um people suddenly get an idea what is what is a metric, what is a trace, what is a log. Um and if suddenly if you start visualizing

things like that and you have like a breakdown and say okay you have two colors so one is component A the other one is component B I see the individual uh time spans of of how long a certain certain service consumes. um then it's it's not going to be too difficult um to make a point and explain um what this all means. So yeah, I mean normally

we don't cover all of that. Um this is just like I always have to see how the flow of of the class goes, but it's definitely something that I just don't want to show myself and use. I really want the student encourage the students to apply it themselves. Now final part um I want to maybe talk a few minutes about about the results um or the things

that I'm that are normally expecting like um and this has significantly changed. I mean as you saw in the initial timeline and as you probably all know from your daily life um AI is is happening pretty much everywhere and so it's of course also happening um in the university lectures and this is not something I want to push back. It's it's more like something that I want

the students and encourage them to use because um why would you want to put an extra effort in in doing things um which are just basically easily possible now a couple of years back I try to basically give them an example and say I I have I I built constraints I have a rest API and I have a persistence API and you have to build the components

to fit in there. So use a UI technology, use like another technology and make sure one is like the consumer and the other one is the receiver of the same API because later on we all exchange them within a Kubernetes cluster and they had to talk to each other. This was a good learning effect that a clean API really has to be a clean API otherwise they

will not find each other even though they might sound very similar. And the same thing of course goes for the for for an area of persistence. And then in the end we got a kind of a big uh like collection of different implementations of the very same application. And of course this also helped um displaying that to the students that uh this is a way how to

um not only build things together but also try to have an aspect of making that clean and understandable in uh in terms of API design. However, nowadays this is very easy. So in u um like generating that code takes only a couple of minutes. So I had to make my um my lab tasks a bit more um more difficult. So in the last semester I particularly said

um because I knew I'm going to go I also knew I'm going to give this talk um try to pick some of the toolings out of this CNCF landscape. So of course you build a multi-ervice architecture, you put everything in Docker and so on. That's like the easy part. But then pick one of the technologies in the area of communication, of persistence, of visualization, of security, whatever

else. And build a scenario that kind of makes sense in the end. Um and and have it ready ready to demo. And um so I gave them like a spreadsheet and and uh put out a certain list to figure out, okay, what what do they want to do? And to my big uh to my positive um surprise, they didn't really stick so much to that. They really

came up with a lot of own creativity and and and built things that that were really surprising. So I have a couple of samples here. So um one and I allowed a a group of teams group of people um they said okay they're going to build this service um with an API gateway a couple of components and put everything and visualize everything in in Jergo tracing they

actually they even put open telemetry in between but they forgot to put it in that architecture diagram so I'm going to mention that but in the end um so they came up with some with a demo like this where you could easily see this is a more complex um trace few than the one I had before and as you can see the the screenshot is is from

yesterday. So it is really a very fresh um project. Um and um so if students come back with me to that I mean I I know they understood the concepts well and um they see what I can see what they are doing. In particular the um the observability part was the the part that most students jumped on which I can understand but also make me happy because

then you always have something nice um to to display. So integration of Prometheus and Graphfana was another one. Um this one was actually combining two tasks that I had given out. So I I had I think I had a task out to say build an a build build um build an application that provides a gRPC and the rest interface and connect two clients um and and make

and and see how the difference in the invocations would be. What they basically did they put observability on top and then were able able to compare the different routes to so they say okay it's the same application on top you have like the rest invocation on the bottom you have the gRPC invocation and here you can compare even the uh the timestamps of the of the various

calls so I thought this this is pretty cool um um here I have an example with integration of of keycloak and um for security and nets for messaging and Maybe this one I maybe want to show real quick live. It's not as complex as the others, but it's it's really nice to show. So I was just doing another talk an hour ago. So this is probably this

is the wrong demo here. So this is the right one. Give me a second. Okay. I say and that's what I said. I mean basically the only thing what what I want from them is a pointer to a git ripple that contains a bit of a description and and a docker compose file. So I can easily basically go in and say I'm I'm I'm going to use

that now. Um so just need to see what is the right port. It's at80. so I'm going to jump out here. So this basically is a is an application to visualize um the a concept of a of an asynchronous queue. So basically what you do is you submit a certain task in the producer and this should normally become vis visual and then the consumer picks it up.

Um and the queue basically goes empty again. Um what they built in is that you can basically stop the consumer. First of all you see that it's not like a synchronous call. It doesn't happen automatically and directly. So if you if you stop the consumer and put things in there um then you would also see that basically those things get stuck in that message and and and

wait um and whenever you start the consumer again they're going to be taken out. So I mean it's not a hell of a task but it it definitely shows they understood what it is all about um and and how you would use such an environment right so I think um as all the people around were already applauding I'm also coming to an end here um I mean

basically maybe first of all I'm going to share this later on these are the the the sources so I want to say if if my students if you ever watch this video I'm very proud of you um these are a couple of the things that I showed today. Um I'm I'm sorry I couldn't show more, but I really like what you were doing. Um and um if

you want I have I have the samples available online. This is are also the um that shows basically the contents of my lecture. So I can quickly um go on my GitHub account and I built this kind of collection that shows my lectures from the last kind of 10 years. So you can jump into these. Um I just going to pick out one randomly. And so normally

I provide this kind of uh git repo to document where we're going. So we're doing brainstorming sessions. Um then we have some theory parts. We enter the world of containers and so on. Um if you're interested in that feel free to to check it out. Also yeah I mean in final words why am I giving this talk? Why I'm saying this all? I mean um most I

guess most of you are not university teachers but and most of you will probably work in the field but I very often I see that exactly that knowledge is missing at the universities and universities are often looking for guest lectures who can speak about real world experience and um make the students apply things will help them later on to understand things a lot better. So I can

just encourage everyone to do that. I had some for myself it was really one of the best decisions in my life. Out of this out of this university class we started developing um a training for the Linux Foundation um about open telemetry which is free for everyone. Now I just um I can look it up. No lin LFS148. This is this the right one. So like we

I built this together with a couple of colleagues. But the roots of all that was in was in the uh in the in the lecture environments. I also became a certified trainer for the CKAD class. And um of course it helps a lot with with with speaking at universities. So this is a bit a big gift back to myself and um and also I'm happy to share

something back to to the community. So with that um I would like to say thanks for coming and listening.