We know that many of you listen to this podcast while running šāāļø or cycling š“āāļø Hey Dan!
How many of you cycled to a conference? Gerhard knows a single person that cycled 764 miles for 8 days straight from Switzerland to Spain for this yearās KubeCon EU. His name is Johann Gyger, a CNCF ambassador & a cloud consultant at Peak Scale. Johann is a cloud engineer at heart that is all in on sustainability. He is the main reason why Gerhard is super excited to talk about electric cars & Dagger at the Swiss Cloud Native Day this September.
Featuring
Sponsors
Sentry ā Working code means happy customers. Thatās exactly why teams choose Sentry. From error tracking to performance monitoring, Sentry helps teams see what actually matters, resolve problems quicker, and learn continuously about their applications - from the frontend to the backend. Use the code SHIPIT
and get the team plan free for three months.
FireHydrant ā The reliability platform for every developer. Incidents impact everyone, not just SREs. FireHydrant gives teams the tools to maintain service catalogs, respond to incidents, communicate through status pages, and learn with retrospectives. Small teams up to 10 people can get started for free with all FireHydrant features included. No credit card required to sign up. Learn more at firehydrant.io
Sourcegraph ā Transform your code into a queryable database to create customizable visual dashboards in seconds. Sourcegraph recently launched Code Insights ā now you can track what really matters to you and your team in your codebase. See how other teams are using this awesome feature at about.sourcegraph.com/code-insights
Akuity ā Akuity is a new platform (founded by Argo co-creators) that brings fully-managed Argo CD and enterprise services to the cloud or on premise. Theyāre inviting our listeners to join the closed beta at akuity.io/changelog. The platform is a versatile Kubernetes operator for handling cluster deployments the GitOps way. Deploy your apps instantly and monitor their state ā get minimum overhead, maximum impact, and enterprise readiness from day one.
Notes & Links
- Swiss Cloud Native Day 2022 speakers
- š¬ Swiss Cloud Native Day 2021
- š¬ Gurten, Bern - Swiss Cloud Native Day location
- The best bits from KubeCon EU 2022
Chapters
Chapter Number | Chapter Start Time | Chapter Title | Chapter Duration |
1 | 00:00 | Welcome | 01:09 |
2 | 01:09 | Sponsor: Sentry | 00:40 |
3 | 01:50 | Intro | 01:19 |
4 | 03:09 | Cycle trip | 03:21 |
5 | 06:30 | Sustainability | 03:24 |
6 | 09:54 | Steve Jobs on bikes | 01:33 |
7 | 11:27 | CNCF | 05:23 |
8 | 16:50 | Cloud Native Day | 05:47 |
9 | 22:37 | From engineers, for engineers | 02:16 |
10 | 24:53 | Sponsor: FireHydrant | 01:28 |
11 | 26:21 | What does it mean to be an engineer | 03:28 |
12 | 29:49 | Alfonzo?? | 01:38 |
13 | 31:27 | 6-Store | 02:32 |
14 | 33:59 | What is the pipeline for you? | 02:40 |
15 | 36:39 | Pushing pipelines too soon | 03:55 |
16 | 40:34 | How much is that environment costing you? | 02:43 |
17 | 43:18 | How to engineer systems to not go offline | 02:11 |
18 | 45:28 | What CNCF projects do you like most? | 03:41 |
19 | 49:09 | Sponsor: Sourcegraph | 01:17 |
20 | 50:26 | Sponsor: Akuity | 02:08 |
21 | 52:34 | Explain your CNCF toolbox | 04:25 |
22 | 57:00 | What are you most excited about in CNCF | 03:17 |
23 | 1:00:17 | What about CICD? | 04:25 |
24 | 1:04:42 | Any spoilers? | 02:46 |
25 | 1:07:27 | Rego? | 01:35 |
26 | 1:09:02 | Key takeaways | 02:13 |
27 | 1:11:16 | Wrap up | 02:22 |
28 | 1:13:38 | outro | 01:02 |
Transcript
Play the audio to listen along while you enjoy the transcript. š§
Last month I posted the best bits from KubeCon EU 2022 - there was a link in the show notes - and halfway through that post I mentioned about Johann, my favorite person at KubeCon EU 2022. Welcome to Ship It!
Hi, Gerhard. Thanks for having me. Iām really honored. Itās the first time being on a podcast interview, and Iāve been looking forward to it pretty muchā¦ Please also know that Iām not an English native speaker, so bear in mind that sometimes I spell things or pronounce things wronglyā¦ But letās go with that.
I think that just adds more to the charmā¦ Because I think we spoke through KubeCon, all the lunches, in the mornings, we would meet in the afternoons, I remember thatā¦ And I could understand everything perfectly well. I had a lot of fun talking to you. But the story which really just fascinated me, and which is why you were my favorite person - because you were the only one that I know to have cycled to Valencia from Bern. Like, that is crazy. I donāt know how many of our listeners tried to cycle for even like a hundred miles, or two hundred miles, but you cycled 764 miles. Thatās over a thousand kilometers. And you took eight days. Why did you do that? Thatās a crazy idea. Why did you do that, Johann?
Well, I remembered when we talked about it at Valencia, and I think at first you didnāt believe me that I cycled from Switzerland to Valenciaā¦ Now, the story is I was planning my trip to KubeCon, and flying wasnāt an option, so I checked train options, and other options, and - well, then I came up with the idea āWell, I could cycle to Valencia. It would be a great trip.ā I checked it with my wife, with my family, if that was okay, being absent for ten more days, and they said āYeah, itās okayā, and here you go. So I went, I cycled to Valencia.
[04:22] I think thatās it, right? The family has to sign off on this idea, and others have to support you. In what way did others support you, which are like outside of your family? Like, from your job for example, or the people that depend on you outside of family - what did they say when you told them āYou know what - Iām going to be away for like eight days, plus the conference.ā Like two weeks.
I just said Iām being on vacation for two weeks. I didnāt do that much noise on social media. I considered it, but it was also some sort of self time. You know, Iām this type of engineer which is a bit introvert, and I donāt have a problem with being aloneā¦ It was still some time to being on a trip alone, so I recognize that as well. But there was some pretty good feedback. I got some gifts for the journey from some close colleaguesā¦ And some guys I also think they didnāt believe me that Iām really going to cycle to Valencia. And some colleagues I just informed after the trip, and they said āWow, thatās stunning.ā
Yeah. I mean, I used to cycle when I had way more time than I have today. I used to cycle every weekend; I would take the whole weekend and I would spend the Saturday, early morning, late night, and Sunday again, as much as I could do. And I couldnāt do more than 200 miles, and even then - this was like road and mountain combined. So when I hear someone cycling such a long distanceā¦ And youāre not a professional cyclist, right? Just double-checkingā¦
No.
I donāt think you areā¦ Okay. I mean, I donāt think many listeners could cycle for 700+ miles in one go. I think many of us would just give up after the first hundred or maybe 200ā¦ Because to be in a saddle for that long is just something elseā¦ And itās not as comfortable as your chair, even if you donāt have an [unintelligible 00:06:27.18]
So I know that this is important to you, again, based on what we were talking at KubeCon; this is important for you from a sustainability perspective.
Yeah.
Can you tell us a bit more about that?
Yeah. Well, if you look around us, the recent heat waves, theyāre happening - itās really getting warmer, itās a fact. Climate scientists are telling this for a long time; we know about it, but nobody is really doing something about it. Iāve read some books, I informed myself based on some scientific facts, and - yeah, what can you do about it? There are a couple of problems, and one is fossil fuels, because we just get CO2 emissions based on those. So if you want to cut CO2 or to reduce your Carbon footprint, mobility is one of the major problems. Flying is actually pretty bad, also because in the higher atmosphere CO2 is more effective at heating up our planet.
Okay. So reducing the carbon footprint, having a more sustainable lifeā¦ Because I know that you donāt drive, which was like another surprising thing. You donāt even own a car, right? Itās bikes. One, two? Iāve seen the one, Iāve seen the Specialized, which is a very nice oneā¦
I would say like three to four bikes at the same time.
Three to four bikes. Wow. Okayā¦
[07:58] I decided not to drive anymore, because if you donāt have a car, you can also have a huge impact on the Carbon footprint. I know pretty much everybody loves his car, but if you look on the streets - itās been crazy. For a cyclist, you notice that thereās a lot of traffic going on, there are a lot of congestions and a lot of traffic jamsā¦ And we are paying a high price for our mobility. We have to solve that somehow, and if you donāt even own a car - and I know this is not possible for some places on Earth, but in Switzerland itās quite possible, because we have a good infrastructure. So it only goes with a good infrastructure. We have good train infrastructure, public transport to near everywhereā¦ So there itās possible. And thatās why we decided to go without a car.
Okay, okay. The thing which I like most about this is that you show initiative in how youāre going to handle this problem, that by the way, affects us all. The initiative is you showing us how you are solving it. A responsible person would ask āHey, how can I help solve this?ā and an optimist would say āWe can solve this.ā They are very optimistic about what theyāre going to do, but they may not have initiative.
Obviously, the pessimists and the cynics - I think theyāre like the lower ones in this ranking - are like āWe canāt solve this problem. Thatās it, it is what it is.ā And the cynics will say they donāt want to solve it. They donāt have this, and they didnāt do that, and they should be doing these thingsā¦ While you - āYou know what? Iām just going to cycle everywhere. Letās see whatās going to happen.ā I really like that. Okay, so we already established that youāre not a professional cyclist, but you love bikesā¦
Yeah, I do love bikes. Itās one of my favorite hobbies, too.
Okay. Steve Jobs was saying a very interesting thing about humans and bikesā¦ And we talked about it before we started recording. There was the condor, the human - not that efficient, but put a human on the bike and then they are the most efficient mammal in motion when they are paired with a bike. But I think you had one more. There was actually something even more efficient.
Yeah. So I read this book āHow Bad Are Bananas?ā and it gives facts about Carbon emissions for various products or activities. I was pretty astonished to find out that electric bikes are even better, because an electric motor is even more efficient as a human cycling a bikeā¦ Because you have to consider the calories, and this means food, and this, again, is not as efficient as electric support. It sounds counter-intuitive, maybe it isā¦ And you have to consider the energy to produce the battery. Itās problematic as well. But still, itās more efficient.
Okay, I already know what I want for Christmas. But thatās another conversation, with someone elseā¦ [laughs] Alright, so thank you for indulging me, especially to the listenersā¦ We talked for about ten minutes about this subject, so I would like us to switch gears and go into the cloud-native landscape, CNCFā¦ Because I know that youāre a CNCF ambassador. So first of all, how did that happen? How long have you been a CNCF ambassador, and how are you finding that?
[11:45] So the short answer is I was somewhat lucky to become an ambassadorā¦ But I can start with the longer version, which goes back to 2015, and it started actually with containers. Let me tell you that story, when a colleague of mine demonstrated to me how Docker works. He just ran a container, some command, and it was so fast I was blown away. After that, I talked ā at the time I was working for an insurance company, and there were some ops people, or infra people, and they immediately jumped on this train, like āYeah, letās do that. Letās go with containers as the universal format for production as well.ā After that, the discussion came up, āIf you have containers, how do you orchestrate those?ā
So there was a discussion whether it should be Docker Swarm, Kubernetes, or OpenShift. Finally, we decided to go with vanilla Kubernetes, which was pretty youngā¦ It was already there, but it was still a pretty young projectā¦ And to decide to go with Kubernetes at this time for an insurance company was a bold move. So that was between 2015 and 2018, and then in 2018 we thought āWell, thereās not only Kubernetes. Thereās a whole ecosystem thatās going on.ā
With two colleagues we went to New York, and we met some CNCF folks, like Cheryl Hung, and late Dan Kohnā¦ And we thought āWell, we have to do something about that as wellā, so we started our own meetup in Bern. Itās the Cloud-Native Bern Meetup. Itās a community now more than a thousand people. And if you know Switzerland, itās not that large. Itās a small place. And thatās a huge community for such a small city like Bern. And we went on, and made like 13 meetups in between, and somehow I was lucky to become an ambassador as well. The selection process is not transparent, and I think itās just because of the community work we were doing in Switzerland. I think that was the main reason for becoming a CNCF ambassador.
I really like how you start with āIt was luck, most likelyā, and then you go on to describe the last seven years of your life, why you pick Kubernetes, and you do this, and you try that, and it worksā¦ Iām sure thereās many, many problems that you have to figure out, and you have to start organizing thingsā¦ And then 30 meetups later, and Iām sure like a couple of weeks later - there you go, āItās luck. I became a CNCF ambassador. I donāt know how.ā [laughs] Well, I think the clues are in all the work that youāve been doing, and bringing people together.
As you mentioned, Bern is a small place. Beautiful, beautiful place, but a small one nevertheless. And thereās only so many people that are into tech, and into the cloud-native space. But we do know how tech-savvy and infrastructure-savvy specifically the Swiss people are. They want things to be proper, they want things to be nice, and just so. And they invest in things that have a future, are sustainable for the long-term. So I think thereās something there.
Yeah, I mean, if you compare me to some ambassadors - they are working for the big tech companies, they are influencers, I would sayā¦ Iām not an influencer, and I donāt intend to be an influencerā¦
Well, hang on, this podcast hasnāt gone live yet. Letās see what happens. [laughter]
[15:50] No, I mean, my motivation to do that is ā itās actually fun to bring people together, get engineers to talk to each otherā¦ And we also started this thing, Swiss Cloud-Native Day, which emerged out of the meetups, when we thought āWell, we could invite some famous people to Switzerland, to Bern, so that engineers donāt have to go to conferences in the United States. They can just watch them on Mount Gurten, which is the location where Cloud-Native Day is taking place. They can just come there; itās pretty local, so in a way itās also sustainable, even though speakers are flying to Switzerlandā¦ But yeah, you can see it in life, in your own city, soā¦
I really like how your values and principles are aligned, and theyāre all coming together - sustainability, the long-term vision, sustained effortsā¦ A lot of things coming together there.
So you mentioned about Swiss Cloud-Native Day, which is a one-day conference. How long has it been going on for?
So we planned the first edition in 2020, and we did some peer pressure on Twitter for getting Kelsey Hightower to Switzerlandā¦ And he actually agreed publicly on Twitter. āYeah, Iāll come.ā And we were so excited to have Kelsey, because heās such an amazing speaker. You had him on the show as well, and he did those KubeConsā¦ It was like ā we didnāt believe it.
Kelsey is something else, for sure. I know what you mean.
Iām still in contact with him, but the problem was in 2020 Covid happened, so we had to postpone. We said āWell, we donāt do it virtually, we postpone it for a year.ā So we had to talk to the sponsors, and they were okay with it, and we shifted everything to 2021. So last year we had our first edition, and from the feedback we got - I mean, itās not only myself, itās like a team of around 6 to 10 people preparing for itā¦ I mean, itās not professionalāitās a community event, so we do it all in our spare time. Weāre enthusiasts, and we believe in cloud-native, soā¦ Yeah, it happened, and the atmosphere was vibrant. It was really one of the best experiences I had in my professional life.
Wow. Well, okay, Iām so sad that I missed the first one, but Iām not missing the second one. So thatās happening this year, in September, 14th of September?
Absolutely, yeah.
And two very important questions - are masks required, and will there be coffee?
The first question is pretty controversial, because there was a lot going on, even for ā I mean, I talked to the organizers for KubeCon as well behind the scenes; I cannot imagine what they went through. It was a difficult decision. Currently, no masks are required, because regulations in Switzerland donāt ask for them, and we also informed all the speakers and asked them multiple times if that was okay for them.
There are variants coming up, and it might be possible that we have to do a mask mandate, but at the time there was no mask mandate.
Yeah. So people ā itās voluntary, thatās what I know. The reason why I ask is because, youāre right, it is controversialā¦ And I think at KubeCon EU there was like a whole controversy around it, and follow-ups, and all sorts of things.
So I am curious to tell that story, and we will come back to that story in another episode, when we look at the facts, when people are maybe less in the heat of the momentā¦ You know, things are being said, and things are being pooled all togetherā¦ So we will go there, at the right timeā¦ But for now, I think itās important to emphasize that if, for example, your region where you are doesnāt require this; like, thereās no regulation to require this. Itās very difficult to force people to wear themā¦ Because thatās what effectively youāre doing. And some people may not be okay with that. And then I think you will fall on one side or the other, and then what do you do? Itās a very tough decision to make.
[20:26] So if you comply with your local laws, I think thatās a good first step, I think itās a good defaultā¦ And then making sure that everyone is comfortable with that decision, and giving them enough time to express their concerns, to go through those conversations so that people are not surprisedā¦ Which is why Iām asking you now, which is at least a month, maybe even more before the conference, depending on when this airs, just so that people know what is happening, why this is happeningā¦ And I know that you have on your website - I think hereās something where you mention this, like on the CloudNativeDay.ch. And again, obviously, this can change, so thatās like another thing. But right now, youāre just complying with local regulations, masks are not required, they are voluntary, everyone can wear them, or anyone can wear themā¦ But thatās where we stand on this. Okay.
Yeah, absolutely. And we will only add a mask mandate, but we wonāt remove it, like it happened at KubeCon, where they planned to remove it and then re-added it because of the feedback. We wanted to be an inclusive event, and itās a pretty hard job. I think this is one of the toughest decisions at the moment as an organizer, whether youāre requiring masks or not.
And maybe an answer to your second question - of course there will be coffee. I mean, no conference without coffee.
The reason why I asked that is because these two are linked. It may not seem that theyāre linked, having masks and having coffee, but if you are forcing masks, and the catering staff says āNo, Iām not going to wear a maskā, what do you do? What do you do if people let you know āWeāll be thereā, like the baristas, or whatever the case may beā¦ The people that provide the coffee, the food, all that. If they donāt want to wear masks, but they have to, what do you do then? Anyways, we will come back to this. I donāt think there will be baristas at this conference, because this is a small one, as you mentionedā¦ Community-run, enthusiasts, people doing it in their free time, which Iām a big fan of. I really understand the power of that. People doing it because they believe in it, not because theyāre paid to do itā¦ So I really like that story and I really like that angle.
Also, I like the engineers angle, because this is a conference from engineers, for engineers, because itās run by engineers.
Yeah.
So can you tell us a bit more about that? Who are the organizers? I mean, itās you, but youāre like ā okay, we already established, youāre not a professional cyclist. CNCF ambassador, conference organizer, but also engineer. So tell us a bit more about that, and about your colleagues that youāre organizing this conference with.
Yeah, Iām really enthusiastic about engineering. So if I would have to describe my professional life in one word, it would be like engineering. It doesnāt even matter itās computer science and not civil engineering; itās just engineering. I love this stuff, and Iām doing this ā I mean, I got a degree in computer science.
And the other colleagues are also from different companies around Bern. So when we started the meetup group, it was actually Phillip and I. Phillip is working at an insurance company in Switzerland, and heās also the guy who co-founded this meetup. Heās like more from the infrastructure, Iām more like from the software engineering background. So I developed applications for quite some time, and Iām still developing, but itās more like infrastructure right nowā¦ We also went into this DevOps movement, but we thought āYeah, cloud-native is a bit more catchier for engineersā, because DevOps is also more about process, and how to work together, and methodologyā¦
Engineers like to talk about technology, to be honestā¦ So the group of organizers grew, and we thought āWell, we need representants from the major companies in Switzerlandā, so we reached out to SBB, which is this federal transportation system, or Swisscom, which is one of the major telco providers in Switzerlandā¦ So we formed a group that major companies are being on the committee.
So you mentioned that youāre an engineer at heartā¦ What does that mean to you? What does it mean to be an engineer?
I mean, I love problem-solving. Itās like solving puzzles all the time. Once you get into the zone ā itās pretty difficult to get into the zone, but the experience of getting into the zone, and then time just goes byā¦ I love it.
What was the last problem when you felt this way?
Yesterday.
Okay. What did you do? Tell us about it.
So currently Iām working on supply chain security, and I dug into Sigstore, which is an amazing project, by the way. And Iām doing Go programming at the moment, and I had some problem to solve with my Go libraryā¦ So I wrote some extension so that we can promote container images from one registry to the other. Pretty much the same way as Alfonso told us at KubeCon about promoting images for Kubernetes releases, but itās like for a company Iām working for.
The difficulty is there are quite some libraries, like Go content registry, and then thereās [unintelligible 00:27:42.08] Sigstore, and they are kind of difficult to handle. So you have to dig your way through a solution. Everything was working, I started ā I mean, I tried to do test-driven development, which is not that easy if you really try to practice itā¦ And I wrote my unit tests, everything was okay, they were green, I was happy, I did some refactoring, it was still green, and then I tested it in production and boom, it failed because I didnāt consider the authentication of the registry, so Iām not done with it yet.
[28:21] Okay. I know what you mean. When things come together you keep digging and think āOh, I have it. Oh dang it, no! I forgot about this one thing.ā And then the deeper you go, the more you start appreciating how all those elements come together. And when you have that moment, when everythingās clear, you see the whole picture; itās almost like seeing the matrix. You see how things combine, you have that mental image of how everything interacts, you have an image of all the potential failures that can happen, and you donāt have to obviously cater for every single one of them, but let it fail, let it crash, whatever the case may beā¦ Be very deliberate about what you will handle, and what you wonāt handleā¦ And again, the happy path, keep focusing on that, while making the failures very clear when they happen again.
So the engineering - how do you build good systems? How do you build something thatās reliable, something that will keep doing what itās supposed to do, in the simplest way possible, forever? I really like that moment, I really, really do.
Yeah, I think itās an art. I once called myself also like a software artist; I donāt think Iām the best programmer, I also donāt think Iām the best engineer, but still, I love it.
Yeah. So thereās a small correction which I have to makeā¦ [laughter] When you say āAlfonsoā, I know exactly who you, because you mean always Adolfo. [laughs]
Oh, Iām so sorry.
No, thatās good, because in your brain I know your connection that youāve madeā¦ And I keep telling you, āDo you mean Adolfo?ā āAh, yes, yes, I do mean Adolfo.ā
Sorry. Yeah, I mean Adolfo, of course, yeah. I consistently get that wrong, and I donāt do it on purpose, so sorry to Adolfo.
Sorry to Puerco, because he also goes by the name of Puercoā¦ So Adolfo GarcĆa Veytia, the full name, episode 53, where heās talking about securing K8s releases. Adolfo, we really enjoyed, both of us, talking to you at the Chainguard booth. Priya was there, and I think a couple others were there, but I remember the four of us talking and that was a great conversation. And Johann says āAlfonsoā, he means Adolfo, okay? Just so that you know. He has a very special name for you, and I really like that. No one else will call you Alfonso except Johann. Thatās a great one.
So really, my apologies, andā¦ Adolfo is actually ā now I got it right, okay?
Yes, thatās it. [laughs]
He also loves cycling, so he does it there in Canada, and in the United States, and heās enthusiastic about that one as well, and he knows what it means to do multi-journey trips.
Kindred spirits. Kindred spirits right there. Okay, so now he needs to find a name for you that only he calls you thatā¦ [laughter] And youāre even. I think thatās what needs to happen. Okay. So you mentioned Sigstoreā¦ How do you use Sigstore in your day-to-day?
So I would say ā or maybe it was a tweet from Chris, when he tweeted 2022 is like the year of the SBOM. And itās all about supply chain security; we had these attacksā¦ And quite some companies emerged, and they are trying to tackle this problem. One thing I especially like is specifications, and thereās like the Salsa specification, which is an amazing point to start to harden your pipelines, essentially. So it gives you a framework, it gives you levels, it gives you instructions, what to doā¦ And if you start doing that, you will soon find out that Sigstore is the underlying technology which enables all those recommendations.
[32:24] Yeah. And how do you use it day-to-day? How do you use Sigstore and SBOMs in your day-to-day? Where do they fit in?
So we started to harden the pipelines. And a colleague of mine and me tackled this problem, and we thought about āWell, weāre already building containersā¦ Letās create those attestations, those manifests, sign them, and put them into a content registry as wellā, and thatās what we did.
So we didnāt do this only with provenance from Salsa, but also for the SBOMs. If you have a look at vulnerability management, what youāre currently doing is youāre scanning your images, for instance, and you check it with a vulnerability database in one step. And whatās going on right now is this step is becoming two steps. First you create the SBOM, with all the components of your image, and then in a second phase you are scanning or checking against vulnerability databases. And this is a way more powerful possibility, because it gives you more options.
You can check for instance just the SBOM and check whatās being deployed in production; you just have to know which artifact is being deployed in production, you donāt have to scan it at runtime and then get the SBOM and check it against a vulnerability database.
Okay. So when you say āintegrating with pipelinesā, hardening your pipelines, what is the pipeline for you, and what are you running through this pipeline?
Yeah, pipelines, itās one of my favorite topics. I do CI/CD for a pretty long time. I remember when the book came out, in 2010, from Jez Humble and Dave Farley, Continuous Deployment, and they established this metaphor of the deployment pipeline. I did it before 2010, but they gave it a name and some instructions how to do it, and I was pretty amazed.
So what is a deployment pipeline? Jez Humble says itās ā I donāt know if I can quote him correctly, but you have some idea, orā¦ Yeah, itās the ability to get essentially changes no matter which type of change into production in a safe manner.
Okay.
And you do it with stages, or steps. So the pipeline gives you feedback; early on it gives you quick feedback, and afterwards it gives you slower feedbackā¦ Nowadays, I think deployment pipelines are pretty much commodity, even though people still confuse continuous deployment with continuous delivery, for instance. They donāt know the difference.
What is the difference? Letās go for that.
Yeah, continuous deployment is if you go into production in a fully-automated way. So your pipeline is fully automated you donāt have [unintelligible 00:35:25.04] deployments in between. Continuous delivery has those safeguards where people can say when to go into production. Itās also automated almost all the way down, but deployment to production, for instance, can depend on some people deciding to go into production and push that button.
Yeah. Okay. Which one do you mostly use, and why, out of the two? Do you use them both, orā¦?
Yeah, 5 to 10 years ago it was more like continuous delivery, because ā yeah, change, and bringing that change into enterprisesā¦ And now Iām striving for continuous deployment, because I think itās one of the best ways to ship software.
[36:14] Yeah, pretty much. And do you go to staging environments or other environments before you go to production, or do you go straight into production?
No, itās with ā I mean, Iām talking now about enterprise customers Iām working for, and it always has staging environments. Itās a requirement to have those in between, and to do some quality work in between.
Yeah. Have you ever pushed into production a change in the continuous deployment pipeline that went through staging fine, but then there was a problem in production? Have you had that happen? And why was that?
Yeah, security was one thingā¦ I donāt have an example at hand, but it happened to me. There werenāt enough tests, for instance; that happened, too. So thatās some examples which happenedā¦ And then you go into production, or ā what I didnāt have, I have to admit, is production load or something like that. Itās more like wrong assumptions or a lack of a certain type of test.
It can fail in production, and you can also test in production. The question is what youāre doing after you fail in production. What the deployment pipeline gives you is the abilities to revert and go back to the previous day that worked, and thatās a powerful thing. So we have to be able to react upon that, but even that one can fail. I think a colleague of mine had it just yesterday. I was working on some infrastructure, and I removed some code from the pipelines, and he told me āYeah, well, thereās a pipeline failing. I donāt know why. I thought it was because of my changeā, and it wasnāt. I mean, he reworded it, and it was still failing. It was actually because of my change; I didnāt notice. So my bad, I did mistake and I immediately rolled it back. It wasnāt a critical component, but still, it shouldnāt happen; or you should monitor it and go back if thereās a problem.
Yeah. Whenever I think of continuous deployment, if there is another environment before production, I think of it as ā again, my perspectiveā¦ A lot of work that needs to happen to get it as close to production as possible, knowing that it can never be production because of the amount of traffic. So production will always have a special amount of traffic, thereās always something special about production. And then Iām trying to think āWhat can I do to push straight into production?ā And then I try to configure everything and approach everything in a way that I know that this will go into production, so then what is the smallest amount of change, how can I ship slices of a feature or slices of whatever Iām doing, whether itās a fix, so that itās always out there, it always goes straight into production, and I can start figuring out āAm I going in the right direction?ā
Because whenever thereās like another environment, now you have to keep it in sync, thereās data, and we know how difficult that is. So if you need to test something, test it locally, sure, if you need to.
I think having a production which spans more than one system, so that you can basically take one of ten - or one of two, whatever they case may be - down, update itā¦ So this is like the canary deployment - I prefer those approaches, because youāre always checking; whatever youāre doing, youāre checking your assumptions (because thatās what they are) against the real thing. Not something which is pretending to be the real thing. There is a lot of hidden work, in staging or in other types of environments, where if you invest all the time into making sure that youāre changing the Go out into production, the blast radius is as small as possibleā¦ Thatās my preference, letās put it that way.
[40:19] Itās not what I think is better, itās what I prefer; and Iāve always had good success with it. So I know that most enterprises will not go for that. They say āNo, no, we canāt do that. We canāt sign off whatever regulation we need to sign off on. We need to have this other environment.ā
But then the question is āSo how much is that environment costing you?ā And I donāt mean to run it, I mean to operate with these two things, or maybe even more things. So what do you think about that, Johann?
I think one has to distinguish between corporates, and startups and small companies, because startups and small companies - they have a system which is notā¦ I mean, it may be large, but then theyāre not a startup anymore. I would prefer to do it that way as you told as well, but itās not viable for corporates, because they are not ready yet to do that, and they donāt want customer impact, or think that thatās a bad thing.
But at the same time, they are accepting maintenance windows over the weekends. So the whole system for a corporate is not working, like e-banking or something like that, for a whole weekend. And if I try to do e-banking exactly this weekend, then I think āOh no, I would have liked to do my tasks. Now I canāt. I have to postpone it.ā Thatās some sort of an outage too, so why not having smaller outages, but keeping them minimal?
And I also like culminating or aggregating changes into one big change is a much higher risk than just doing it continuously. I fully agree with you.
But I think thatās the thing - if you have an outage, itās an incident. So if you have to update something, and as a result of you updating that thing youāre causing an outage, you have an incident. Youāre not updating anything, youāre not doing anything good. Youāre actually doing something bad. So why is your system designed and running in a way that you pushing a change is creating an outage? Thatās the problem.
Absolutely.
Not the fact that youāre pushing out updates. So how do you architect truly resilient systems, that change without them going offline? And Iām thinking about humans. Biology and humans are fascinating, where the cells change every seven years. You never die when you regenerate. So youāre continuing to function, all the body functions donāt get affected, but youāre regenerating continuously and constantly, and youāre always a better version (hopefully) of yourself. Smarter, more experienced, hopefully keeping those workouts, cyclingā¦ Whatever you do to keep healthy and energized.
So why shouldnāt a system that is like a well-engineered system - because weāre talking about engineering - what does it mean to engineer systems so well that it will not go offline? What do you need to do so that it doesnāt go offline?
Yeah. When we talk about high availability or stuff like that, we donāt have a second hard. I fully agree with you. We donāt have a failover hard, or two hards running concurrentlyā¦
We should, if you ask meā¦ [laughter] I think we should.
So we can inspire ourselves from biology, itās always a good thing. You mentioned it, application architecture - how do you design a redundant system? How do you architect it? It has some costs, but I think we should do it nevertheless. Architects should be able to design those systems. There are good guidances, like The Twelve-Factor App, which tells you how to design your system, keeping it stateless, and so on. Handling state is always the hard part.
[44:26] Yes, for sure.
Writing stateless systems is one thing, and you can scale them horizontally, thatās not a problemā¦ But handling state is a huge challenge, I would say.
Yeah. But I think even for thatā¦ For example if you had read replicas, you can continue operating in a degraded way. For a bank, what would that mean? Well, for a bank - you know what, no. Thatās too long. Iām not going to open that can of worms. Iām not going to open it because I know thereās so many things; there are regulations as well, penalties, all sorts of things. And then people say āOkay, we have to do this, we have to do thatā and people are just scared. But I see a lot of fear there, and I see a lot of like āThis is too hard. Letās just do what weāve always done. Maintenance windows - okay, job done.ā And then you know someone has to be around during those maintenance windows. Anywaysā¦ For another podcast maybe. Not another podcast; for another episode, maybe.
So what projects from the cloud-native landscape do you like most? And it should be the ones that you use day in, day out. I think weāve already established it is Kubernetesā¦
Yeah, absolutely. I like Kubernetes, even though there was recently a blog post, I think it was also on Hacker News, why Kubernetes is not recommended for startups, because it has some complexity. And Iāve also heard about Fly.ioā¦ So letās come back to one thing, and itās containers. Containers are a good thing, and they really ā they were a game-changer. Kubernetes is one way to run containers, but there are many other ways, like serverless solutions, then public cloud providers have their platforms, there are PaaS solutionsā¦ So in essence, itās containers.
Yes. We agree on that.
Thereās some really nice things about Kubernetes, and they are not that complex. Like, Kubernetes supports deployment strategies, for instance, pretty well. You just have to know how to do it, and then itās actually pretty easy. I mean, it supports rolling updates out of the box. You can just do it.
And apart from containers and Kubernetes, Iām working a lot with TerraForm. I think itās also for infrastructure as code provisioning the best solutionā¦ Even though TerraForm has some flaws, in my opinion. What I donāt like about it is that you have to manage separate state. If you compare it to GitOps tools, they donāt maintain separate state. You just have the state in Kubernetes, and then you have the desired state in a Git repository. And this makes TerraForm handling a bit more difficult, but I think itās still the best solution thatās available for infrastructure as code.
When I was using TerraForm I was committing the state file in the repository. And it wasnāt great, but at least I could see the state there. So even before GitOps became as mainstream as it is today, there was something about committing the state of whatever is managing your infrastructure. In that case it was TerraForm.
I think in 2019, something like that, maybe 2018, we used to do this. I remember that. And I was thinking āHmā¦ I wish this was not as difficult.ā But also because you had like two sets of changes most often, you had a lot of unrelated changes when it comes to TerraForm reading the state from the resources it was managingā¦
[48:07] But the thing about TerraForm which always got me was the plugins. Oh, my goodness me. The amount of pain that I had upgrading plugins, and they stopped working, and I didnāt pin it correctly, and āOh, now I have to change my configā¦ā That was painful for me. Or the API that the plugin is using has changed, so you have to upgrade the pluginā¦ That was the one thing which was a pain point for me. But tell us more about you, because it is about you.
Yeah, absolutely. I mean, the problem with changing APIs - youāre using some provider, typically for like a public cloud, and the public cloud [unintelligible 00:48:42.06] is changing APIs, and you run into some problems. This can happen pretty oftenā¦ But itās not the problem of TerraForm, itās actually more a problem of the provider of the APIs, and this makes it hard to handle.
So TerraFormā¦ What else is in your toolbox, in your favorite cloud-native toolbox?
Yeah, I used to worked with GitLab and GitHub about as well. One can discuss whether these are cloud-native technologies. I mean, what is cloud-native? There is a definition, but it makes it still hard to graspā¦
What is cloud-native to you? Letās start there, thatās a good one.
Itās nowhere mentioned, but I think Kubernetes or the way how Kubernetes works, and containers, is a major part of it, and itās generalized. I mean, cloud-native is mostly about application architecture to leverage the possibilities that you have in cloud environments. Thereās the cloud-native landscape, which mentions tons of projectsā¦ A lot of innovation is going on. First there was Kubernetes, then there was GitOps, and then you have the whole monitoring part, with Prometheus, and Jaegerā¦ I mean, there are so many areas to cover. To me, itās the modern way to tackle application architecture for modern cloud infrastructures. And open source is a very important thing as well, and also that thereās a neutral ground with the CNCF, and we donāt have to face proprietary technology anymore.
Yeah. Do you use something day-to-day which is not in the cloud-native landscape? Something that is dependable, something that works for you? And I donāt mean like your code editor, or anything like that. Something for your applications, when you run them, for your stateful servicesā¦ Is there something which is outside of this space?
[54:27] Maybe my development environment. Iām doing Go development, and previously I was like a Java developer and got some proficiency thereā¦ But Iām still using the JetBrains IDE, and I think itās still the best one available. I see so many people using Visual Studio Code, and itās nice. Itās really nice. But if you know the possibilities and the power of a JetBrains IDE, itās just a different level.
You still havenāt changed my mind, Iām not giving up my Vim. [laughter] Not now, not ever. I think where we start in our careers - like you mentioned, Java - and if you spend a significant amount of time in a specific community, I think to some extent that determines your development environmentā¦ Because you become familiar with something, and you like it, and you just find ways that work for youā¦ And then after 5-10 years later, the chances of you switching are slim, because you already ā like, you do things automatically, you donāt even think about it, and if someone asks you, āHey, how did you do that?ā āI donāt know, I just did it. Itās magic. My editor did it for me.ā And itās actually you doing things, maybe hitting some keys, some shortcuts, clicking some buttons, whatever the case may be.
The point is that I think a lot of people that do infrastructure work, theyāll be like Vim, or Vi, or Nano maybeā¦ Emacs of course, you do have to do thatā¦ The point being, depending on where you start, you may start going in a certain direction, and then changing that becomes so expensive that you may never have the chance; time, opportunity, whatever the case may be.
So JetBrains IDE - I remember some people were using it. GoLand as well. I think thatās somewhat related.
Yeah, itās one part of their tool suite, yeah. I actually started with Eclipse, and that was when I finished my studies. And a colleague early on told me āYeah, well, as a Java developer, you have to switch from Eclipse, which is open source, to a proprietary toolchain.ā It didnāt fit into my mental model, so I stuck with Eclipse, but eventually, I changed. And I have to say, I also use Vi or Vim, but itās more like for if Iām on the terminal and I have to quickly edit some text file. But for development, itās still GoLand, and so on.
Okay. If we switch gears a little bit now and we go away from our development environments, because Iām sure we can talk about it for at least another hour, and then I can start showing you my Vim plugins, and āOh, look at this, how it integrates with that in Nvimā and āAh, thereās like a huge differenceā¦ā Thereās actually a pretty good episode which I was looking up recently, āWhy we love Vimā, and Iām sure thereās a few others on the Changelog. That was #450. But I think IDEs - they do have their place as well, so Iām very accommodating when it comes to themā¦
I used to be more like in one camp versus the other, but not anymoreā¦ Because I did come to appreciate some of the things ā like, seeing someone use GoLand, or seeing someone use JetBrains professionally, you realize thereās something there. Thereās some craft that happens. Weāre being artists with our editors, and itās a very personal thing. So if you use a palette knife, or a brush, or a chisel, it is what you do. Itās still art at the end of it.
Okay, so switching gears - what are you most excited about in the cloud-native landscape this year? Is there something coming, or something new? I mean, we already mentioned supply chain, we already mentioned SBOMsā¦ Is there something else besides those that you are excited about?
[58:14] Yeah, so besides supply chain tools, I already mentioned Sigstore, which is really amazing work. It still has some rough edges, I have to say, but itās getting there. And I think Cilium is doing a pretty good job as well. They are starting to solve the service mesh problem from a different perspective, which might be another game changerā¦ Because services meshes - they have been around; there are quite some solutions, like Linkerd, and Istio, and Consul from HashiCorp, but theyāre not being widely adopted, in my opinion. I might be wrong, but I think they add another layer of complexity onto Kubernetes, for instance.
Cilium solves this at the kernel level. Theyāre replacing the IP table stuff thatās going on with eBPF, which is a lot more flexible, and they have a lot of ā how do I put itā¦? New possibilities are opening up to solve problems.
Okay. Well, Iāll make sure to dig into that when I talk to Liz and Thomas in a future episode, because I think thereās something there. I think eBPF grew in very many directions, unexpected ones, and I think service mesh is, as you mentioned - it has always been, from my perspective as well, a controversial space, because it adds a lot of complexity, and very few are able to pull it off successfullyā¦ But it is a space worth watching, for sure.
And I really like what you mentioned, because from your perspective, based on the projects that youāre involved with, based on the people that you know, itās like, youāre experienced, but still, within an area. And I like that regional feedback from what youāre seeing, where youāre at; I really like that perspective. I think those are really valuable. Because based on where we are in the world, we each see things slightly differently, based on our communities, based on the people that we work with or knowā¦ So okay, thatās a good one.
What about the CI/CD space? Is there something in the CI/CD space that youāve been using for maybe a while and it works well? I mean, is it GitLab, because you mentioned it, or is there something else?
Yeah, I donāt work directly with it anymore, but I used to work with it for several customers. It was like ArgoCD, or letās say GitOps tools, Flux as well, they share the GitOps engine, soā¦ I mean, thereās this GitOps approach, and itās a pretty amazing tool. And whatās not being solved yet is how to combine GitOps with deployment pipelines. Thatās an open question, in my opinion. Thereās no solution to that. But what GitOps excels at is they do not only concentrate on delivering or shipping software, itās also running software. So this part of the software development process, so to speak, is not being covered. I mean, you just deploy, and then the pipeline is over. So what do you do if something fails in production? Do you just redeploy? And GitOps is actually the tool which excels at this problem.
What do you like most about GitOps?
Itās declarative. So I was skeptical about declarativenessā¦ Is that even a word? I donāt knowā¦ A couple of years ago, when I tried to understand the design principles of Kubernetes, for instance - and itās purely declarative; I loved it. And on top of that, itās a natural step forward. You just tell what youād like to have, but not how. And the system tries to find out what to do. Itās much more powerful, because you can essentially automate operational tasks with that.
[01:02:10.17] Yeah. Something that continuously converges, as you mentioned, is really powerful. You donāt have to tell it what to do and keep doing this. You just tell it āThis is what I want you to doā, and itāll figure it out for you. Youāre right. That mind shift is really important, the imperative versus declarative.
I remember Ansibleā¦ Ansible felt very imperative to me. āRun this, then run that, then takeā¦ā No, no, no. None of that. Just tell it āThis is the state of the world. Just make it so.ā
Exactly. I mean, your infrastructure has to support it, and thatās not an easy task. But if the system itself can figure out how to self-heal itself, you get more automation and itās much more powerful and flexible, I would say.
Yeah.
I also like about GitOps that the desired state is maintained in a Git repository, hence the nameā¦ And it gives you full traceability. You donāt do manual actions, everything is automated; I like that one as well about GitOps.
We set up a system - it was for a finance institution - which had to be PCI-compliant, and they couldnāt do deployment pipelines because it would push it into production, and this was prohibitedā¦ So GitOps actually solved that problem with this firewall in between, where you just deploy indirectly by committing into a config repository.
Yeah, the pull versus push model - I think thatās also a really important distinctionā¦ Where your CI/CD pipeline doesnāt deploy anything, it just makes a commit and thereās something that watches what is the desired state, and then it applies that desired state. But you donāt reach out into production and tell it āRun this thingā directly. Itās the indirect, āThis is the state that I wantā, it sees the state, it updates it, and then it applies it. I think thatās one of my favorite features, where you donāt push changes, you basically pull them, and itās a very nice way of scaling things. So when you add another system, you donāt have āOh, I have to update my pipeline to basically start pushing into this other target.ā The target just knows, you just configure it āHey, just keep watching this, and when thereās a change, pick it up and apply it.ā
Absolutely, yeah. I think thatās a pretty powerful concept.
Are there any projects that you can talk about or want to talk about? Projects that youāre involved with, projects that are exciting, projects that are going well, or the ones which you wish would go better?
So how does my professional look like? Iām not being paid as an open source contributor by some big tech, so I have my own company and Iām basically consulting customers in, for instance, adopting a cloud-native journey. So do you mean that type of projects, like custmers Iām working with?
Yes. Without mentioning any names, obviously. Things that are going wellā¦ And you donāt even have to mention the industry.
Yeah, Iām mainly working in the finance industries, and also public sector. I can tell that. And what Iām doing right now - I already mentioned it, for one company, which is in the finance sector. They have a public cloud strategy; they want to move everything into the cloud, from on-premises solutions. Theyāreā facing a couple of challenges, of course, and they also have huge security requirements. And one thing is, as I already mentioned, the whole Salsa thing, where we try to rethink the whole supply chain security part. So thatās one of the major projects Iām working on right now.
[01:06:13.08] Thereās also quite some TerraForm stuff involved in the public sector. So letās say - I specialized in consulting customers that are trying to adopt public clouds, or cloud-native concepts. Itās more in the public cloud sector right now - how do you get into the public cloud safely? So Iām working in the public sector there as well, with like āHow do we automate everything, like provisioning, cloud accounts, and so on?ā What controls do we add? And thereās a plethora of solutions that you can choose from. Policy-as-code, for instance, is such a thing, which is really great. You can use OPA, you have different [unintelligible 01:06:56.09] languages, like Rego, or CUEā¦ We havenāt leveraged everything of that yet, but we are starting to dig into those solutions, and they are pretty powerful. OPA, for instance - it helped us to add guardrails to our infrastructure pipeline, so that we donāt delete resources, for instance.
Okay. Yeah, I havenāt used OPA, but it keeps coming up. How are you finding Rego? Because many people complain about just how difficult it is to use it. When I looked at it, it just looks a bit funkyā¦ But I havenāt used it myself; it was just like from afar.
So it wasnāt me personally who wrote the Rego stuff, but the guys who did it actually said āYeah, itās pretty hard until itās up and runningā¦ Or if you can copy it from somewhere else.ā But once it is in place, itās really nice.
So you would describe it as ā or what Iām hearing is it has a steep learning curve, but once you go past it, itās fine. Itās like any other thing - once you learn it, itās easy.
Yeah. What we havenāt solved yet is like [unintelligible 01:08:09.00] using CUE or Rego to check those manifests, and we havenāt decided yet which way we want to go down. I remember you mentioned CUE, so I wonder which solution we will take for this specific problem. But at least we can choose from several solutions.
There is a recent talk that Iāve seen from FOSDEM 2022ā¦ Marcel and Paul are giving it, about CUE. I forget the exact title. But if you look it up, āFOSDEM 2022 CUEā, youāll see how they ā I really like the Kubernetes example which they give, with the schema, and how they enforce certain constraints to what gets deployed in Kubernetes and how they can add certain defaults as wellā¦ I thought that was interesting. So thatās the one which I would recommend watching next.
Okay.
As we prepare to wrap this up, what is a key takeaway for our listeners?
Sustainability, I would say. Think about sustainability. Iām not a missionary, I donāt want to preachā¦ As you said.
Youāre just doing it. I really like that, yeah.
Just do it.
If I wasnāt as excited, I donāt think we would have told this story. But when I heard it, I was like, āWow, thereās something there. I have to tell that story.ā It was okayā¦ You didnāt think it was a big deal, and I loved that. You were like, āItās no big dealā¦ It took me eight days, so itās okay. Yeah, I cycled like a thousand plus kilometeresā¦ā Actually, 1,230. I did the maths; 1,230 kilometers.
[laughs] And apart from sustainability - yeah, if youāre an engineer, youāre a puzzle solverā¦ I mean, this is the greatest puzzle we have to solve, like āHow do we tackle global warming?ā
[01:10:00.21] Now, that is a problem worth solving, for sure. I hope that this point - weāre not still thinking that itās not real, I hope. Some will, but that number is less and less by the day. So if we can all agree that itās a problem worth solving, Iām very curious to hear others how they solve itā¦ Because I know that we have such a big role to play on the infrastructure side, on the apps side, we can make them more efficient, we can autoscale them, or maybe only use as much as we needā¦ We can do so many things there. We can use ā maybe be more conscious about the languages that we choose. Some are more energy-efficient than the others.
There was a great talk, and a keynote - the KubeCon EU keynote from Intel, where they ranked the various languages, and they explained the Carbon footprint that they have. Now, Iām not suggesting everyone switch to Rust or C, because they are the most energy-efficient onesā¦ Go is fine, Java too. Surprisingly, Java too; very, very efficient. But thereās something to be said about those, and thereās something to be said about the small choices that we make everydayā¦ Including that burger, which I may not have today, after our talk. I know thatās like the worst food you can possibly haveā¦ To maybe cycling more, versus using the car.
Well, thank you for today. It was a great pleasure to tell this story, to re-live a bit of that fun. We did cycle when we were in Valencia, all the way from our hotels, our respective hotels, where we were staying, all the way to the beach. That was a long one. I think it was about like an hour.
It was fun.
It was fun, thatās what I wanted to say. Especially at night. That was the best. Those scooters - they were so fast, whizzing past us at night, and like ding-ding! The electric scooters - they were maniacs.
Yeah, absolutely.
We were trying to have a conversation, which by the way - maybe not the best idea at 12 oāclock at night, as you cycle, on a cycle laneā¦ They werenāt that wide, but still, it was a lot of funā¦ And thank you for coming on today, thank you for the great conversations at KubeCon, and Iām very much looking forward to meeting you again at Swiss Cloud-Native Day, 14th of September. Everyone welcome, by the way. Anyone listening to this, if youāre around, if youāre local to Bern, France, Italy, Germany, close enoughā¦ You donāt have to cycle, by the way; itās not a requirement. You can take the train, or the plane. Thatās okay, too. Iāll be flying, by the way. I hope to see you there.
Thank you, Johann. Thank you for today.
Yeah, thank you very much for having me. And yeah, Cloud-Native Day in Switzerland - if you want to check out Tim Hockin, for instance, one of the fathers of Kubernetesā¦ We have Thomas from Isovalent talking about Cilium service mesh, Priya from Chainguard, which Iām pretty much excited aboutā¦ We have also a Rust guy, Tim McNamara, whoās doing a Rust programming workshopā¦ So that will be, I hope, amazing.
Yes. Thank you very much for that. ArgoCD workshop - thatās the one which Iām thinking, like āOh, that sounds very interesting.ā Will they be in German, or will they be in English, the workshops?
They will be in English, I think. Itās left up to the workshop speakers, but all of them are capable of doing those in English. They will be in English, yeah.
Okay, excellent. Well, Iām looking forward to meeting yāall there. See you in a few weeks, a month, or two, based on when this comes out. See yāall, see you, Johann.
Yeah, pretty excited about it. Thank you. Bye!
Our transcripts are open source on GitHub. Improvements are welcome. š