 Thanks, Eric. We really appreciate you joining us for our little car ride and you maybe introduce yourself to us a little bit about your back road. Well, thank you. Thank you for having me. I'm Eric. I work at AGMIA. AGMIA is a large insurance company in the Netherlands. I myself, our solution architect working with a team that is providing Linux and Kubernetes on cloud services and cloud service providers, mainly on Azure and digital. Okay. And so as a solutions architect, that's often kind of a sales related role. Are you doing work mostly for organizations outside of AGMIA? Or is it, you know, kind of, are you doing, it's more like internal consulting or something unrelated? It should be internal consulting. Okay. But the word architect is always a bit confusing, I think in AGMIA. That's our most titles in our industry. I don't know why anybody even invented titles to have it. The fact is, I think I see myself more as a senior engineer within the team. I think a lot of people grow in their job and by doing stuff and doing things. That's my story. I do things. I like software. I like Kubernetes and in that way I grow in the job where I am. It has just has the job title solution. You're right. Right. Right. Yeah. So I think they, you know, we have a lot of people in the kind of software industry who, you know, are just kind of there as a job, right? And other people who it's also their kind of only hobby. And so, yeah. Yeah. And so I know I've played like all different kinds of roles, you know, with all kinds of different titles. And, you know, I've also had multiple roles with different titles where I was doing exactly the same thing. So, you know, it's kind of a weird field. Yeah. But, you know, so what brought you to, you know, have you, have you been an open source kind of land long? Have you mostly been kind of working in insurance companies and Kubernetes was part of your movement? Or was there something that drew you into the open source space and, you know, kind of in particular unrelated to your job? I think it's a bit in between. So I think I'm not working directly as a contributor in the open source world. I do some small contributions when we see them. I think we're mainly a user of open source software, either supported by, for example, that had or directly in simple Python packages or whatever. That is necessary to manage and maintain the infrastructure we provide our company. So mainly a user, mainly engineering, mainly deployment, and my job or my journey started in pure commercial Unix systems. Oh, okay. 264. Oh, all right. Yeah. I even did some fax FAMS, which is a long, long time ago. Yeah. I did Sun, mostly not AIX, but I actually ran or worked on a system that had AIX Oracle instance back in. But I didn't touch that part. I mostly was like SunOS and, yeah. I know of what you speak. SunOS 4. Yeah. I actually had a Spark 10 on my desk, which I was pretty excited about for a while. Me too. Yeah. Yeah. But I did a lot of stuff on that. Different times. Yeah, exactly. Exactly. Well, then I became a Windows programmer for a long time, randomly. So, you know, you go all over the place. Yeah. So, but so when you, so, but you kind of grew up around Unix, right? Unix, Linux. Yeah. I even started in the Linux kernel .9 or so. Okay. .99. Yeah. And from there on, I started doing everything when I entered the enterprise. There wasn't Linux. Right. Right. Or open source. Or even open source. No, that was banned. Yep. I remember that. Yeah. But nowadays, I think the complete journey from there to where we are now, I've been, I've been there. And most of the time in the AIX Linux and nowadays Kubernetes community internally. And it's, and so, so, so you had a lot of experience with like proprietary systems and what, what do you feel like is different with the kind of the open source software systems? I'm going to guess maybe you prefer them, but you know, what, what is it about them that you feel like is different or, you know, that may be better or sometimes worse? Well, let's start. I prefer them. They had a lot of reasons for it. But what the difference, the main, I think the main difference between them is that if you look at open source, if you look at the speed of innovation, that's so much different than the commercial software. The fact that I can help look at the software, understand how it works helps me use the software in all the commercial software we used down the lane. The problem was, okay, it's a big package. It's complex. It's, I don't understand it. And I can use probably 10 or 20% of it. Right. Open source software. There are so many people that are working around it. I can contact them. I can ask them for help. I can look at the documentation. I can contribute. That's the main difference from my side, the usability. There is a downside, of course. There's always a downside. It's choosing because there is so much open source software. What is the best solution? Which step I would do? Where do I go from where I am? How do I migrate? Commercial software vendors at least help you with that. You need to invent that yourself. That means that you need team and team members that have the knowledge and the opportunity, the time and also the will to do that. Right. To really dig into it. Yeah. To really dig into it. Yeah. You said a couple of things that I thought were interesting. I think especially for non-technical people all together, but then also people who aren't deeply technical, I don't think people realize that the trade-offs that we make when we're developing basically anything, all the time that you just make trade-off, trade-off, trade-off. And I think one of the things that you were kind of commenting on is the fact that you can really dig into a piece of open source software. You can align your trade-offs with their trade-off choices. Definitely. Which is huge and can be a huge advantage that I think people don't, like I said, unless they're deeply technical, they don't realize it can really make a big difference. As you were kind of saying, that 20 to 20 percent usage versus, I don't know, maybe 70 percent. I don't think you ever get to 100, but you can definitely take advantage of that, like I said, similar mindset. You can make your software think or have the same ethos kind of as the software you're relying on, which really makes a big difference. Definitely, definitely. Yeah. So I thought that was, it's an interesting take. I don't think I've ever really kind of thought about that before. It's like one of the advantages of open source. But that's really cool. And so you're mostly now kind of doing open source with Kubernetes or with OpenShift. And so where do you typically work in that space? Are you providing like platforms? Are you actually changing things in the bottom of OpenShift? Are you running applications? We as a team provide platforms to the Armea IT organization. Okay. We provide namespace as a service in essence, which is just a simple service that provides the application teams the space to deploy their applications on Kubernetes, specifically on OpenShift. Okay. And do you provide like a set of tech stacks kind of that are the preferred model or something? We initially just started with, here's the namespace, do your thing. Oh, yeah. That works. But that only works for teams that do have a high engineering grade. They know what they're doing. They have their knowledge inside. And they are enthusiastic to think about how they want to use the platform. So we are growing every day. And one of the conclusions on our side is, okay, we have a diversified set of engineers. It's not only a highly skilled engineer. It's also people that do have a lot of interest in technology, but maybe not specifically on Kubernetes. So to help them adapt the same technology, we need to provide different services. So in the near future, we will probably start helping them in a different way. A lot of discussions internally. For example, should you, for example, provide teams of people that enable them, enabling teams? Or should you diversify in your portfolio? The route I'm taking is at least both, I think. Yeah, diversification. That's what's happening. I think diversification in the portfolio is good to help low engineering teams ensure that they don't need to think about technology, just help them with deploying an application. But also the other way around, teams that do one... Like the control? Yeah. Provide them with the functionality to have that control, to do it themselves. Right. So that's the route we're taking now. And it will take time, but we're looking forward. So the development teams that you support, did many of them use container technologies before? No. So they're their first exposure to Kubernetes? No. So their first exposure is with Kubernetes and OpenShift, two containers at all? Yeah, directly. So as mentioned, we, for example, have a team that provides Pega as a local platform. They are very good in Pega, but they are probably not as good in technology. That's not their thing. But we also have, for example, .NET Core teams. Those teams are heavily involved in development code. They know CI-CD pipelines. They know all the stuff. And they want, for example, functionality like DAPR, they are thinking like service meshes should help us. That kind of teams have different needs than the Pega teams, for example. Right. Interesting. And so when they're kind of moving to these containerized services, are you finding that, like, do you also need to educate them about how they need to re-architect applications or change how they approach applications? Sometimes, yeah. Yeah, sometimes. Re-educate. It's more helping them adapting to that different environment, helping them understand what the differences are. I think most of them understand and everybody knows that we need to go to cloud. Right. That discussion is already finished. But what it means to go to cloud, what it means to go cloud-native, it's a totally different story. Yeah, it's a totally different story, yeah. And so when you, I was going to ask you, when they're moving, are you mostly getting adoption through new applications or are you also seeing, or is there a lot of migration work as well? Both. There's a lot of migration work. There's a lot of lifecycle management in the sense that current application evolve. We also see a lot of independent software vendors nowadays move from traditional deployments in Windows or Linux to Kubernetes-based deployments. Basically, probably, because development in a platform like Kubernetes is much easier. Right. Well, particularly the deployment side, I mean, it's like on my laptop, right, I try very hard not to essentially install anything. I just put everything in a container that I ever use so that I don't have to deal with the conflicts. I don't have to deal with upgrades where I don't want them, things like that. And I think containers have been, at least for me, I've been using containers since, what, 2012, I think. That's early. I started with containers in 2015 or so. Yeah. Well, it helped that I was working at Red Hat, so that whole Linux thing was kind of right there. But the, oh boy, I hate to block the box. It is Amsterdam. Yeah. I saw a bunch of people do it. I was like, really? People do not like you in Boston for doing that. No, it is definitely an affront to all that is good and holy according to most drivers. Just do it here. Be bold and be brave. Yeah, exactly. Yeah, so with kind of the open source world or whatever, is there a particular part of kind of that Kubernetes and OpenShift landscape or whatever that you really think is going to be, you know, kind of world changing? Aside from cloud native in general for your kind of engineering teams, like, you know, is serverless really going to be really a godsend for them or, you know, kind of thinking about event-driven architectures or, you know, what it's going to enable, you know, that's going to be really awesome. I think the combination of a set of functionality will be game changing. It's not one specific change in the common period. At least not that I know of. What I now see is that the possibility to move a lot of functionality to the infrastructure, provided for example by Dapper, provided by service meshes, provided by KDA, those functionalities ensure that developers can focus themselves on building functionality. Right. For our organization, that's a big game-changing. Kubernetes in itself is the cloud platform of the future. Not even the future. It is here right now. Adding CRDs like KDA, like Dapper is the next step, the fruit of the labor that developers can use to mainly look at functionality and not anymore on the technology part. Right. Depending on the organization, do you see a lot of your development teams sharing functionality and do you think that this move to a little bit more like a service-oriented architecture or using containers in this way, will this increase the opportunities for less teams to rewrite the same code? Hopefully. Hopefully. There are a lot of good thoughts about that. The platform engineering movement, of course, the backstage, IDPs, all things and all functionality that will help, but it also means that teams need to grow in their own maturity. They need to see what is possible, what can be shared between other teams. So yeah, I think that will be the next step there and that will help us and other teams be more productive. Yeah, no, I definitely agree with that. That also means that they need to grow in maturity. They need to do the first step. First, they need to understand containers. They need to understand developing in that cloud-native environment. Yeah. And kind of really adopting, I regularly use the word ethos, but the philosophy behind it and the approach, because you can do a lot of things just putting it into a cloud-native environment that really are not going to enable any of those things. All you did was a port. I've seen that. Oh, yeah. I've hacked that myself, but at least I know that I'm doing something horrifying, but I think that's another big hurdle for a lot of people. It's not just, oh, now I'm running my web server and my database in a container. I need to construct my architecture differently, which can take a while. But I've seen that that step is necessary. I think I can tell everybody that you don't need to do that, but they will do it. Yeah, at least once. At least once and find out that that is not the good way to do it. People need to learn, and most of the time learning the hard way. So, yeah, we will help them. Yeah, we are seeing those kinds of patterns, and hopefully we will learn. Right, right. To pitch the show, right? So that's kind of the idea, like with Cube by example, is we try to give these learning paths, whatever, that really talk a lot about kind of the philosophical aspect and trying to change how you're thinking. You're not just using a new technology. One of the common ones I see for that is I've talked to people about Kubernetes and they're like, why do I need this big honking piece of software to run my environment? And I'm like, well, have you used containers much? And they're like, no, I haven't. I'm like, use some containers, get used to them, and then you will discover how quickly you need something to orchestrate them because you can't keep track of where they all are, what's current, what's... It's really interesting. I think the prior art on this is essentially if you had an environment that used like golden image VMs, which is also kind of a game changer, but changes how you think about what you're doing as well. That had a lot of trouble in and of itself. And I think containers are like, let's multiply that by a factor of 50. Which is always kind of interesting. The fact of the matter is Kubernetes itself is hard. And finding people that do understand it and knowing it is a lot harder. Yeah, yeah. I deal with it because I teach at a university and I deal with this with students every day. I have to start them with, okay, why don't we just run everything on physical hardware? And I talk about the retail season or tax season or something that shows them big spike. And so you have to buy all hardware. And then I kind of walk them into density around virtual machines. Then I'm like, okay, but that's still got all this overhead. Then I walk them into containers. And usually they kind of sort of get it when I get to the container part. But it's like... I'd love to be in that class. Yeah. It's like what I think, especially I think both of us kind of grew up with a lot of this. And I think... I don't recognize how complex it is now because I've been slowly getting it added to my plan over the years. And you're looking at somebody now and they're like, here's this huge, monstrous, complicated... Good luck. You can learn it on your own. It'll be fine. You will swim. We will see. True. It is a journey and you need to do a part of the journey to understand why we are where we are. Right. And I think it's like a lot of things. You have to feel some of the pain to be able to understand the solution. But at the same time, especially in corporate enterprise or whatever, how often can you afford to let somebody deal with the pain? Right? That's true. That's a big concern. I think the enterprises, at least the enterprises I know, are keen on control. They want to provide, they want to deploy applications in such a way that folds... There are no folds. There are no problems. But the fact of life is that there are always issues. That there are always problems. Yeah. Yeah. And I think it's... It's good for people to feel some of the pain. You know, we were talking in another interview earlier. One of my things that I really dislike about how we hire in the industry is like, oh yeah, I need a person who has Python for 10 years and has used module A and B and C. And it's like, no, what you need is somebody who knows how to code and then you need to give them an opportunity to learn the environment in which you're in. Yeah, do it. I know how to write a for loop. I can figure out how to do it in Python, whether I know the language or not. I might be a little slow to start. But I think it's true for a lot of, especially these kind of high level technologies, you know, if we go out and just try to hire only Kubernetes experts, you're not going to hire anybody. No, no, no. No. And so I think that's one of the big challenges I think with our industry. Part of it is that a lot of the times the kind of hiring arm of the organization doesn't really understand what they're hiring and so they can't use their skill set to most effectiveness because they don't entirely get what they're trying to hire. But it's also difficult. Oh yeah. When we talk to potential employees and have a discussion with them you must write down what you expect from somebody. And that's a set of bullets. It's not more but it never grasps the real crux of what you're looking for. That's the first step. And then you have an interview with somebody. It's 10 minutes or 15 minutes or 30 minutes to interview somebody and then you need to decide, okay, is he good enough for us? Does he want to grow? What kind of person do we talk about? It's so love to do it. I love to talk with a lot of people but it's not. I think that has both that has two sizes of metal on the side of the potential employee and of course the hiring the one that needs somebody interacting with each other grasping what we really need and then the other part I'm not sure what it is in America but in the universities and the schools here in Europe at least in the Netherlands the ones that come from school do not really have skills in the sense that they know something they learn to adapt but they need to change when they go to the organization it's a totally different environment. It's one of the things that we actually try to cover in some of the classes we teach it's like generally speaking if you do a computer science or even a data science major you learn how to code but you don't really know software building which is not the same thing we've kind of introduced these classes where we do projects for third parties and we make sure that the projects that they do the student team has to deploy something by the end of the semester and part of the class is them gathering requirements and expectation setting for the client and making sure that they deliver they set an expectation and then they deliver on that expectation and one of the things the students have a really hard time with is like I can't tell you at the beginning of the semester what it means to get an A what I can tell you is is that if the client feels like you met their expectations you get an A and so that means you have to understand what they are expecting you to build and then build it and then deploy it which is all things that don't really have anything to do with computer science which is interesting part of what makes teaching those classes difficult I'm not sure what the approach is here in the Netherlands it sounds different I had a guy did a which is in Dutch stasia I'm not sure what the English word is he had an assignment to do something for a specific organization but he is put there he has a he has a guy that guides him through it but in the end it's all about the assignment and not about having a good discussion on what the organization itself needs it's a different approach I think it probably depends on the school I would say the way we are doing this is not particularly standard for software or computer science programs in the US either because at the end of the day you go to a university because you are expecting to go more into the academic side of whatever that field is it's a different subject matter to learn how to go do it in practice the challenge I don't think it's a bad thing to teach it the problem is there is an expectation mismatched by some of the students and by what they are walking away with whatever different let's figure it out in this corner we need to go to the right yeah I was meandered a little bit off of our normal path because it's funny as I get better at the route it takes less time because there is less of me trying to figure out where I am going where you are a lot of issues here in Amsterdam it's exciting I'm not sure if it's different in Boston it's pretty similar we don't have the bikers but we have pedestrians in the same vein we have bikers too but not to this volume so that will be unique for Netherlands probably it's good to see thank you so much for your time I appreciate doing our little drive around Amsterdam interview I hope you enjoyed it I hope you enjoyed to talk too not too many harrowing experiences I hope I'm still in one part