#055 – From Enterprise Java to Kubernetes and AI-Driven Infrastructure with Dan Hicks (Boomi)

Itiel Shwartz: Hello everyone and welcome to another episode of Kubernetes for humans podcast. I’m Itiel Shwartz and today with me we have Dan Hicks. Dan, happy to have you.

Dan Hicks: Thank you for having me. Appreciate it.

Itiel Shwartz: So Dan, maybe share us a bit about yourself. Who are you? Where do you work? How did you get into tech? When did you start using Kubernetes? And and then we’ll continue from there.

Dan Hicks: Sure. So like you said, my name is is Dan Hicks. I am in the Philadelphia, Pennsylvania region in the US. and I currently work for Boomi. and I’m currently

Itiel Shwartz: Wow, 1 second. Dan, not not necessarily everyone knows Boomi. Like [snorts] yeah, you know, like I work at Facebook, right? Which is a bit easier. So who is Boomi and then like

Dan Hicks: Yeah, so so Boomi um traditionally uh I will say it was a an integration uh or an iPaaS, integration platform as a service service, excuse me. but now, you know, we’ve um we’ve you know, grown at great lengths to to be uh basically a an entire enterprise platform, uh a modern iPaaS for AI activation. So um everything from uh AI agents to be able to integrate all your data together, uh data management, API management, uh agent management and integration and automation.

Itiel Shwartz: Sounds like like the right right company at the right time, basically.

Dan Hicks: Oh yeah, we’re we’re growing uh hugely right now. It it it’s it’s a good good time and a busy time.

Itiel Shwartz: Okay, and and we can talk about issues and incident in a second that caused us to delay this call for like for two times. Even it was more on on my side. but before that, sorry, I cut you in the middle like Give us a brief on your history like when did you get into tech? What’s your journey? Kubernetes, SRE, platform.

Dan Hicks: Yeah. so originally I started off as a Java developer in my career about 20 forever years ago. uh during the I would say towards the end of the uh the dot-com bubble. So uh fresh out of college working at one of these uh dot-coms that was basically worthless, making no money with the promise of you know, a gazillion stock options that were worth absolutely nothing and then everything burst. but my my Java career went uh you know, in that time it was all about enterprise Java and such and I did a lot of consulting work primarily in the pharmaceutical industry. both contract and full-time with various pharmaceuticals working on enterprise Java um and such and that’s kind of how I got introduced to um even prior to Kubernetes, but just containerization technologies. We were a a JBoss shop and I ended up uh 2013 time frame at the Red Hat Summit where uh OpenShift was announced. The first OpenShift announcement and just started to, you know, being there as a Java developer and seeing all these containerization technologies there and I found it interesting and um and from there went to, you know, always keeping that in the back of my head is that, you know, that’s the technology that we should really be, you know, deploying our applications as. It seems very flexible and such and I ended up going more in the Kubernetes um I found OpenShift well to be very opinionated. Like most things Red Hat in my opinion. It’s not necessarily a bad thing, but um I went more the more the open route with with Kubernetes and such and and learning Kubernetes and just taking a lot of courses and it just seemed to to click with me. the way that that I thought about software and how software needs to run and be scalable and resilient and stuff. and then about uh yeah, I joined Boomi 8 years ago as a Java developer. but um say about 3 years ago I um reached a personal decision that that I kind of wanted to step away from Java after so many, you know, a few decades there. And there was an opportunity internally to move into our platform engineering team. more on the infrastructure side of things. And that’s where I really found myself uh being able to thrive more in this um containerized world and being able to define have the freedom and to uh define some architectural choices of where we want to go uh in our engineering department and how we want to host our applications and uh Kubernetes was a natural fit. specifically, you know, specifically we in AWS uh EKS, but but I tend to be a purist in Kubernetes and and and utilize the that things that that would could be supported in a multi-cloud fashion.

Itiel Shwartz: So so let’s let’s stop for a second because you said quite a lot of interesting stuff and Sure. disclosure, I also started my career Java development in at eBay uh back in the day. So I’m with you. I can say that Java is like my my favorite language. It’s not even a I don’t think it’s even like the top three. but I do have a lot of respect for enterprise level Java. Like if you need things that will work at scale in a big company, Java has a lot of uh like insights. advantages, sorry. But if you can, maybe like share a bit about like why doing the transition? From, you know, like it is uh it is quite like a big shift, right? Like in the end. So maybe if you can, and I’m sure that some of our listeners are also Java developers, maybe or Python developers or Go developers. So why doing that? And like what were the pros, the cons? [sighs]

Dan Hicks: Yeah. I mean it really was a uh it was a 100% personal decision. Now I mean there were opportunities within my company to do this, which was nice. and there were there were opportunities given to me because of personal choices, but it was you know, I had worked over 20 years you know, Java developer and, you know, moving up to technical leads and architects and, you know, all the different titles and such, but um you know, always always in code. Not that infrastructure is any different. you know, we want we all want to do infrastructure as code and everything and it’s still code, but it was just I wanted a a basically a career change. Yeah, I still wanted to be in technology, but but I had I felt I had done all I could do with Java. and wanted a new challenge in my life and thankfully I’m at a company that supported that change and gave me that opportunity. So be- you know, wanting that change and being able to stay where I am at a company that I that I like, uh you know, I decided to take that chance and over the past 3 years I think I’ve um I’ve taken it taken it straight on and and even advanced already uh in that career uh change and and I’m loving it. I think it was a a good choice. and learning all kinds of new stuff, but still applying still being able to apply those same architectural and technical principles that I’ve I’ve learned throughout my entire career just in a different way.

Itiel Shwartz: So so you know, like I think So what is the differences? Like what are the key differences of being like a developer, like Java developer, compared to what you’re doing today? Same both similarities and differences if you don’t mind.

Dan Hicks: The concept for similarities, the concepts are are the same. you need to, you know, whether you’re building a Java application or you’re building the infrastructure that those applications are going to run on, you still need to worry about all of your ilities, your scalability, your reliability, your resiliency, supportability, all of that. It is just you’re coming at it from a different perspective. The first, you know, as a Java developer or any application developer, you need to be able to support that in your code. On the infrastructure side, you need to be able to to deploy these things into, you know, services or managed services or cloud providers or or wherever in in a way that and then software that can support uh that scalability and and configure it to to be like that. So it they’re very similar, the same concepts. I think where where they’re I’m trying to think of some differences. I mean it’s The differences are, you know, in Java, you know, you’re you’re coding your object orientation or or whatever. You’re you’re you’re you’re building that to be supportable and maintainable by your team over a period of time. On the infrastructure side, it it seems to evolve a lot quicker. There’s constantly changes in in technologies, you know, whether be in in Kubernetes itself or the technologies that that can support Kubernetes. There’s It’s a lot faster change there going on there than than what might happen in your code. And that that’s kind of exciting.

Itiel Shwartz: Okay. That’s interesting. Like like the customer itself are also different, right? Like how like in general this is external or not really?

Dan Hicks: I think it depends on how your I guess how your SRE team or your DevOps is is structured. You know, there are some paradigms in companies where your your application teams are there on the front lines and on call. And then there’s other ones where you have a more centralized SRE team. So I think it depends, but but you know, it’s I feel a little more on the front lines now to you know, to the customer impact, you know, it’s a little closer to to being out there in front and hearing, you know, all the problems and the successes, too. We we like to hear the successes, too. So you’re a little out there more out there in front than as a Java developer and application developer, but those concerns still need to stay there. You always need to have, regardless of where you are in an organization. But it it this this point especially gets lost. I find in engineering organizations is you need to have a customer-centric view. You need to understand. Every developer needs to understand, you know, not just what you need to do from a requirements perspective, but understanding why the customer needs it and having more customer empathy helps with your code or helps with how you host things and deploy things.

Itiel Shwartz: I’m with you. I’m with you. So so maybe like share a bit about like the things that didn’t work well in that transition or in general. Like I said that one of the reason that are we were supposed to talk I think it was a month ago and in Commodore we also had like a lot of like good things that are happening. Some of them resulted in less good things and yeah, I think like in every R&D organization and you need to be able to to cope with problems, issues, right? Bugs and so on. So like how does it work for you? How did the transition if any change your point of view of like troubleshooting of issues or or what’s your take here?

Dan Hicks: Well, there’s you know, after you know, working in Java for 20 years, you start to to know a lot and or you know, working in any anything for 20 years, you become an expert on it and sometimes you know, there someone comes with a bug or a problem or something not working a certain way and you have an immediate answer because you’ve been there and you’ve experienced it all. The biggest change for me was that, you know, I didn’t you know, I’m coming in. I know Kubernetes, sure, but I may not know I may not know networking as well. It’s not something I needed to ever think of as Java developer. So understanding networking, understanding, you know, more cloud-based technologies and you know, like VPCs and all that. It’s it’s something that I struggled with and and but that’s something that falls under my purview now to to understand. So there’s a a learning curve there. Even in Kubernetes, it’s like, you know, you take all the training and and on a very surface level, you do your deployments and you have all your kubectl commands or Helm commands and all that, but there’s some deep things in Kubernetes that can get you in trouble. Yeah, net network especially around networking network policies and stuff. It it and you know, latency that’s occurring and being able to observe that and and figure that out because you’ve got two layers there. You have your Kubernetes networking layer and then you actually have your physical “physical” network underneath that. It it’s Those are where the difficult problems to diagnose may lie. You know, just just an example, you know, things start to get slow slow down and it has nothing to do with the application, nothing to do with the scaling. Everything looks good there and and you find that, you know what, CoreDNS is taking longer. You know, being able to find, you know, simple things like that and and very very simple solution. Scale it up.

Itiel Shwartz: Exactly. It’s like once you go to the network layer and nothing is easy, right?

Dan Hicks: Exactly. And there’s some even between the cloud providers AWS EKS or Azure AKS or whatnot, there’s subtleties that that drift from standard Kubernetes like, you know, cube proxy settings and things that, you know, you’re not going to find in a in a Kubernetes training course at all. You’re going to find them when there’s a problem. You know, hopefully you find them before they are a problem, you know, through proper testing and and stress testing and performance testing and chaos testing and all of that. Hopefully that’s where you find them. Thankfully that is where we were finding these issues. So you know, having a strong it’s important to don’t just trust Kubernetes. You do need to test everything there. You need to do performance and stress testing. You need to do chaos testing. What happens if I’m deployed in AWS? What happens if I lose an availability zone? What happens to my cluster? And you can build your application to be resilient to that and have proper topology spread and all that fun stuff that that you learn out of the manual and put this in your descriptor and and that’s great and everything. Okay. What happens if you lose an availability zone to the control plane? What happens to cube proxy? What happens to the things that you don’t have direct control over? You expect those things to work, but they’re not always going to. You shouldn’t always have that expectation. And that’s something we have found as a team here what at getting in the chaos testing is sometimes Kubernetes doesn’t behave the way it tells you it will.

Itiel Shwartz: That that is for sure. Again, like I think everyone that worked with complex enough Kubernetes knows knows that like knows that truth.

Dan Hicks: Yeah, so the fundamentals are the same. Going back to the Java development, the fundamentals are the same. You still need to have, you know, some kind of framework like, you know, whatever is appropriate for your organization. Test-driven development or what you know, feature-driven or whatever whatever your framework is it you know, and fits in your organization. It’s important to keep those fundamentals whether you’re on the application development side or the infrastructure side, they still apply.

Itiel Shwartz: I’m with you. So maybe share a bit about how if any AI changed your past year. If it’s like tools or Claude Code or Cursor. Like did anything change and if so, what?

Dan Hicks: A lot changed. And it’s an interesting very fast journey there. You know, I’ve been involved in looking at and trying all kinds of different AI development agents and you know, there’s there’s a quite a bit of them out there. And I try to get beyond, you know, the what I call marketing architecture. Get get beyond the marketing architecture and actually see how these things work and how, you know, get into the details. Not just reading what what’s on their websites and what’s in the expo halls and such. And do some deep dive proof of concepts on these things. And I’ve tried, you AWS Q which is now called Kiro. I’ve tried Cursor. I’ve tried Claude. I’ve looked at one of the things that that I’ve been looking at and we’ve been evaluating are AI DevOps agents and and SRE agents and such to help with, you know, reducing time to resolutions and such and how can we use AI for that. Currently I’m I’m full in on Claude as an assistant. Not as a it’s not doing my stuff for me, but it’s it’s reducing the toil. You mean? So, you know, if I’m creating let’s say I’m creating an architecture vision, prioritize architecture vision. I just and and I hook up voice control. So, I just sit here and talk to the computer. I feel like I’m in Star Trek sometimes to be honest with you. Like I’m

Itiel Shwartz: I never tried to to talk with the computer. Yeah, it works well? I

Dan Hicks: Yeah, it speeds it up, you know, let I don’t have to I can talk in a very stream you know, stream of consciousness way. And one of the one of the things that slows me down is when it comes to to the to to what I work on is okay, I need to document this or I need to have it presented in a way to my team or my leadership. And I have all these ideas in my head. And the slowest part of my work is trying to organize that for other people to be able to consume. And that’s where AI and and right now with Claude is helping me. I could just talk I’ll just talk about this is what I want to do these are the things that are all in my head and it doesn’t matter what order I spit it out and it’s going to put it in a good order for me. And organizes thoughts in a consumable fashion. and then I’ll go back and move stuff around and tweak stuff to be more specific in certain areas and such, but it reduces the toil and it reduces the things that you know, I know what I need I know what I’m doing. I know what I need to get out on paper. I know need to present to people or or whatnot. And I use it as an assistant to help me organize my thoughts. And that that’s that’s the best way of using it. I don’t I don’t think these these tools are a means to replace I don’t even want to say developers are a means to replace critical thinkers. You need to have Yeah, critical thinking is is a is necessary for anyone in that in a technical position. And that that’s that’s the number one skill set that you need to have regardless of your level. You could be a junior developer, you still need to know how to think critically. And these these AI tools can help you organize your thoughts and get rid of the manual efforts involved with them, but you still need to know what you need to ask it. And and it’s it’s not a replacement.

Itiel Shwartz: Well, I agree. So, we are like kind of like running out of time. Maybe give us a bit on like your prediction. Where are we going as an industry in cyber natives? what’s your take on the future? [sighs]

Dan Hicks: I think um That’s a good question. Where we’re going with Kubernetes? I think I think Kubernetes gives us the ability to scale. Yeah, I mean yeah, Kubernetes gives us the ability to scale of course, but we have so many thing specialized workloads that are coming out now, especially with AI. Oh, you need certain types of compute and you’ve got all these cloud companies coming and and hardware coming out with new chipsets and things to help you know, reduce power consumption and increase tokens and all this stuff. Well, Kubernetes gives you that flexibility to have any kind it abstracts that compute from you. So, I think it’s a really important technology in the in the world that we’re moving into and gives you that flexibility. One of the things that that I’m sure my teammates are tired tired of me talking about but that I that I absolutely love is Karpenter. The Karpenter auto scaler I think was a game changer in Kubernetes that you can just say these are my compute and memory and networking require and storage requirements and you give me what I need. And you don’t have to worry about node pool planning or optimization. It does it and it does it very well. So, when you have all these different types of compute requirements it makes it so much easier to do and that’s that’s where we’re headed. There’s so many there’s going to be I predict there’s going to be so many different types of chipsets and and and and all that kind of hardware out there to choose from. And Kubernetes is is just going to make that easier. You tell it this is the this is the compute I need and go out and find it for me. And it gets rid of a lot of the compute planning and such and and I think that’s that’s where it’s going to help. you know, whether you’re training models or or whatever. within Kubernetes I think it can really scale to what we need in this in this world that we’re moving into. What is this?

Itiel Shwartz: Okay. Okay, I think with that I’ll say like one one thing that even though I really like Karpenter in Komodor we see how Karpenter is not there yet when it comes to doing everything for you. Like we usually see we that you know, for Komodor customer we’re able to top off on top of Komodor 2030% more, but I think the future is there like auto scaling, auto right sizing. This is where we’re going as an industry. And then it’s been a pleasure having you at the show.

Dan Hicks: I appreciate it. Thanks for having me.

[Music] Kubernetes for Humans.

This is an AI generated transcript of the conversation