Driving Innovation with Kubernetes & Java

#kubernetes #java #DevRel #innovation

Ana-Maria Mihalceanu: Yes. Well, it's good to share with folks and with developers the good side of using technology, but also the not-so-good, lessons learned. Lessons learned are very useful. So I remember back in the day when I was having this situation when some Docker-composed scripts, YAMLs, needed to be transformed into Kubernetes resources. I knew that there was a plugin that could help me do that out of the box, but thanks to going to a meet-up and hearing the struggles of folks that used that one and told me, "Eh, there's this plugin but it's not 100% giving you everything, you just push a button and then it's gonna magically do exactly what you were imagining. You still have to do it. You still have to check what it generated."

And thanks to that, when I got to this part I was like, "Oh, I remember I talked with somebody who said this." So also the not...the great stuff that doesn't go that well, a certain version of a library, of a framework, of a product is good to know so that you don't go on that path, spend a lot of time, and then be disappointed that, "Well, it didn't work as expected." And it's good that you're sharing your lessons learned with serverless. There's not just one technology that is bulletproof technology against any scenario.

Eric Johnson: Right tool, right job.

Ana-Maria Mihalceanu: Exactly.

Eric Johnson: I think as a DA, we get that license to say, "That may not be the best fit. I'm not trying to sell you anything, I'm trying to help you." And that's what we always talk about, I don't have to sell serverless, I just explain it, you know what I mean? And that's probably the same for you, and it's more of a, "If I explain it right, it sells itself," as far as...and sell is probably not the right way, but you see people utilizing it. But I do get to be honest and say, "That's not a great fit, but I know something that is," and something that is a container. We're very honest, when we say, "Service is great for 95 whatever, and I can show you, but there are some more quotes that make a lot more sense in an EKS," which is our version of Kubernetes. "Koo-burr-NET-eez," so yeah, I said that right.

Ana-Maria Mihalceanu: Yes. It makes sense, it makes total sense. And similar, sometimes when you're using even the same framework, it can be the case that configured in a way that framework gives greater results for a specific type of microservice, but then another way you should use a different pattern. It's not like everything is a giant copy-paste, so it's everything and you just need to readapt and see what is useful or not, especially when it comes to patterns. So for example, for one of my talks regarding Quarkus, I'm explaining why I would choose to use the repository pattern over using the PANA entity one. In which cases, I would use the other one, or I used the other one because I saw some applicability when in some cases it worked great, in some others it didn't. So you should be aware of instead of, like, you go on your own, you try, and you see, "Oh, it doesn't do the same thing that this lady showed me in the nice demo."

Eric Johnson: Yes, "It's not perfect." 

Ana-Maria Mihalceanu: It's not perfect.

What is a Kubernetes operator?

Eric Johnson: And I think that's the expectation sometimes is code is perfect, and, you know, it's, "No." So tell me this, do you have any talks here at GOTO?

Ana-Maria Mihalceanu: Yes, I just had my talk at GOTO. It was, like, early bird this morning and it involved Kubernetes, of course, that's why the shirt and everything. So I talked about Helm and Kubernetes operators and pretty much explained when I would use one or the other so that people would be aware of the use cases or when they could choose one or the other technologies. The whole idea of this started, I think, two years ago, when I heard somebody that...well, they heard about Kubernetes operators. I was at the conference, and one of the attendees said, "Oh, this operator's thing is way greater than Helm. I'm going to use it everywhere." It's like, uh-oh, uh-oh. So that's why I got the idea of this talk so that people will not use it everywhere but only when they need it.

Eric Johnson: So tell me this, and working with serverless as I do, I know what operators are. I mean, come on. But maybe let's pretend I don't. So what is an operator? What is an operator of Kubernetes?

Ana-Maria Mihalceanu: An operator of Kubernetes is a technology that you can use with resources like stateful sets, or resources that are not stateless in terms of maintaining to automate some of your human operational knowledge. So pretty much that was the idea of operators, to add an extra level of automation on top of what was available in Kubernetes resources because Kubernetes is great with its vanilla resources. But if you want to add more self-healing to your resources, for example, very sensitive and especially stateful ones, then an operator is there to help you to automate more of your job and to delegate that automation to Kubernetes. So pretty much that, I'd say, in a nutshell, that is an operator.

I didn't demo this, I forgot about demoing this. I used to demo the operators by deleting the deployment that is managed by an operator and then the operator was spinning up the deployment again because operators have just much more power over the resources contained in it to self-heal. So if you want more self-healing, more goodness of Kubernetes, operators are great.

Eric Johnson: Ok, so it kinda sits outside and can manage...

Ana-Maria Mihalceanu: It's not necessarily outside. I would say it's a nice add-on.

Eric Johnson: Okay, a build-in, or something like that. 

Ana-Maria Mihalceanu: Yes, because it works with kubectl, it works with the dashboards that we have with different Kubernetes distributions, so it's native. And the reason why it's native is that an operator is typically comprised of custom resource definitions, and it works with a controller that is controlling those resources...

Eric Johnson: Sure, well done.

Ana-Maria Mihalceanu: ...controlling over those resources, so that deployment being recreated one after I deleted it is done by that controller that is, like, mitigating. It's looking, like, "Hey, there should be a deployment running over there," so that's how things are working. It's just another level over the regular Kubernetes API that you get, thanks to custom resource definitions. So custom resource definitions have been there for a while with Kubernetes, but this type of working with Kubernetes took an extra level for us to automate even better. I love operators in terms of doing those not-so-nice jobs of backups and restores because when learning Kubernetes, I also did the Kubernetes hard way...

Eric Johnson: "Five Things I Did Wrong," yes, I hear you.

Ana-Maria Mihalceanu: Well, it's not five things I did wrong, it was more like learning. So especially when you want to get certified, you have to learn how to do this manually. So I did this manually, and when I was doing this manually, especially on the exam for backups, restores, and all these, or upgrades, I was like, "I hope in this world there are better ways to do this than me manually in a blank Terminal, and hoping I'm not messing up some commands over here." Because I used to tremble over the backups or the restores thing. It felt like a little bit black box, you know? And operators are great in terms of not being so black box, or at least you're trusting. You're trusting that that set of resources, that they're gonna do the job.

Nowadays, it's easier to install different plugins over Kubernetes via the operators than just going yourself manually, and installing the many YAMLs like we used to do in the beginning. I don't know, no more Knative installed the old ways, the old-fashioned way. No more Istio installed via just applying a lot of YAML. You can get nice UIs and you can see...this is the great part, you can see and you don't have to do anything extra with your Kubernetes cluster to know about an operator. So it's natively coming over there, you just have to create it, or you use one that's available on OperatorHub.io.

Eric Johnson: I'm not trying to oversimplify it but I'm probably gonna do that, or just completely misunderstand, but it's an abstracted layer of management?

Recommended talk: The Automation Challenge: Kubernetes Operators vs Helm Charts • Ana-Maria Mihalceanu • GOTO 2021

Ana-Maria Mihalceanu: Yes, so that you can manage, and automate things even more with those resources that you kind of had trouble with. Because Helm charts work great, however, in terms of Helm charts, integrating over the stateful sets, for example, is something that can be partially covered via the Helm package manager. The other part with volumes, so management of the volumes side, it's something that you need an extra tool to help people with that one, while with operators you can get a little more help in working all together with the entire thing that you deployed over there.

Eric Johnson: Okay, nice. All right, so that makes sense. So how did the talk go?

Ana-Maria Mihalceanu: I think it went great. I got a lot of questions and I was about to get late for the interview.

Eric Johnson: Okay, those are the good ones. The hallway track is my favorite when you get to do that. What was the toughest question you got?

Ana-Maria Mihalceanu: A tough question.

Eric Johnson: This one right here?

Ana-Maria Mihalceanu: This one, yes.

Eric Johnson: It was the question about my toughest question, so yeah.

Ana-Maria Mihalceanu: Yes, exactly.

Eric Johnson: All right. What was the most interesting question?

Kubernetes operators vs Terraform

Ana-Maria Mihalceanu: I think an interesting question was when somebody asked about comparing operators with Terraform, so it allowed me to explain when I would use Terraform and when I would use operators so that people would understand and not be confused about the concepts, you know? That was an interesting thing to hear about. Other questions were, like, if there are any other tools, like Helm, for example, in the market to help with package management and all this stuff. These kinds of questions are people just telling about their practices, and their companies, and looking for advice, like, "How can we make it better?"

I love these kinds of discussions around culture and the DevOps culture that some company has, and how they can communicate better between the two backgrounds, the operational and the developer ones. Because let's face it, I mean, DevOps is a great practice. We've probably all, kind of, read "The Phoenix Project," or those that didn't, recommend it. But it's still something that, for many folks, it's a work in progress, and it's good to be a work in progress. It's not something that, "We achieved dev ops. We do dev ops," and that's when it stops.

Recommended talk: Expert Talk: DevOps & Software Architecture • Simon Brown, Dave Farley & Hannes Lowette • GOTO 2021

Eric Johnson: I've noticed that as well. It feels like we go through...I mean, we're constantly learning. Our industry is constantly flexing, constantly changing.

Ana-Maria Mihalceanu: Exactly.

Incorporating customer feedback via DevRel

Eric Johnson: Let me go back to something you had talked about, the process of communication, and things like that. How do you all do that inside Red Hat? How does customer feedback come in as a DevRel, and how do you handle that?

Ana-Maria Mihalceanu: Well, we talk to the community. It's pretty straightforward and, I think, pretty much the same for the rest of the folks because we're with the communities most of the time. So I'm with the community as a developer advocate and that's where we get feedback from everywhere. I would say for products, especially nowadays, it's important for them to listen to feedback not just from the customer side but also from the community side. And as you observe, there is a lot of passion for going open source throughout many companies. Red Hat has a flagship of being open source and we are open source. We like to open source stuff, and so that from my point of view is like an open conversation all the time with everybody, and every feedback counts and matters. It's not like somebody's having a priority. Sometimes you can get even more valuable feedback from folks that are not your customers.

Eric Johnson: "Why aren't you a customer?" "Here's why." Yeah, no, I agree with that.

Ana-Maria Mihalceanu: That's not my talk.

Eric Johnson: Yes.

Ana-Maria Mihalceanu: That's not my area of expertise.

Eric Johnson: Yes. No, that's what I'm saying, sometimes that is good feedback, and, "The reason I'm not a customer is because of this, A, B, and C." And those are the tough ones to take back to the teams, but  I agree with that. I'll tell you as a side note, just so you know, the first Linux I ever did was Slackware, but then I quickly got to Red Hat. I ran Red Hat quite a bit, so yes. That tells you how old I am, though, so I'm dating myself.

Ana-Maria Mihalceanu: Well, it was interesting when I announced to my family that I'm joining Red Hat. My parents are not in IT, and my uncles or my cousins have been for a short while interacting with IT. When I told my cousin, for example, that I'm joining Red Hat, she said, "Oh, the Linux company." It was like, "You know Red Hat?" I mean, I was surprised because it was the first time, I think, that I've heard my family having an opinion, like, "Oh, I know what you're gonna do next." And I was like, "Yeah, they do much more than that, but it's okay." It was a good start, and I was like, "Huh, so my family knows about this. That's a good thing."

Eric Johnson: So do they understand what you do?

Ana-Maria Mihalceanu: They know that I'm doing learning for other folks and that I am instructing other folks in how to use certain technologies, and that's pretty much it. That's where they...

Eric Johnson: Yes, ours is a hard role to tell people about.

Ana-Maria Mihalceanu: It always has been like that. It started from the developer from coding and to the upper level, and the way I used to explain it in the beginning to family...actually, my parents had to know it because I'm their kid. But with other folks, like neighbors or folks that I was meeting, I was telling, "I'm working with computers." "Oh yes, you're working with computers." It's the easiest explanation you can give. It works the best. So it works, "I'm working with computers." It's okay.

Eric Johnson: There's a level of abstraction. I'll do the same thing, "I'm a developer, I came from AWS," and you can see the glaze. "I work for Amazon," "Oh, okay. Do you deliver?" "Yes, that's what I do." Sometimes it's just easier to say yes. "Yes, I work in a distribution center."

Ana-Maria Mihalceanu: And somebody's calling you, like, "Oh, can I give you this tracking number to see what's happened with it?"

Pursuing a DevRel role

Eric Johnson: "My books are late." Okay, I don't do that. I lied just to make it easier on us, but yes, that's funny. It is a tough role to explain. So tell me this, knowing this role, I'd love to get your opinion because I have people ask. Because here's the truth, we have one of the greatest jobs on the planet, and I can see by your face that you agree. Earlier we said how fun it is, but if someone wanted to get into a DevRel role, either at Red Hat or at AWS, something like that, what is your recommendation?

Ana-Maria Mihalceanu: Well, you have to love sharing knowledge with people, so you have to love people contact, and learning constantly, and sharing that learning with folks, pretty much like the next level of curiosity in terms of technology, and knowing that you have a way to nurture that going forward. So this is not the kind of, at least from my point of view, it's not the kind of role where you learn some stuff and you stop there. It's something that you never stop, and you have to be thinking, and anticipating a little bit about what's going to happen next in our world of technology, and paying attention to the environment. Because you can get some signals where our world is like going forward, and be the connection between what can happen in the future and what's happening right now for certain products, for example.

Eric Johnson: So let me ask you a question. We've talked about the dev role, we both love doing it. Just watching you, you love doing it, you know, which is, I love seeing that. You see people do the job like, "Yeah, I do the job." But you see the people like, "Yeah, I do the job," you know? What do you recommend? I have folks all the time, "How do I get your job?" You have to wait until I'm dead to get my job, but you know what I'm saying?

Ana-Maria Mihalceanu: Okay, so that's how your contract at AWS works.

Eric Johnson: You may want to cut that, but what do you recommend to folks who wanna get into DevRel? What does that take? How should they get started?

Ana-Maria Mihalceanu:  So for somebody to get into DevRel, that's the generic answer from my perspective, I would say to have passion for continuous learning, and also, look into our IT world, what other technologies would add to your existing layer of knowledge, and how you pair those together. Talk to people, have this passion for talking to people but also listening to people and their experiences, because listening is very important. So you have to be...have some empathy with those that are coming to you and talking to you, and also, sometimes to be a little resilient in terms of accepting feedback. Because not everything, like, fairy, and nice, and, oh, everything goes smoothly.

So you have to also be prepared for some negativity or for people not to grasp certain concepts from you. It can happen. In a big audience or room, it can happen that some folks will not have the same understanding as you probably would've wanted. You know that saying, it's very difficult to keep everybody happy and make everybody happy, so same here. So you have to be prepared for that one as well. But overall it's a very rewarding job, and this is probably why a lot of folks are asking. But you have to be prepared a little bit for the long run learning to the next level of connecting things in technologies. So that's my advice, but if you feel that that's your calling and you wanna do that, interact with a lot of folks, and instruct a lot of folks on how to improve themselves, that's a good way of being.

And of course, have a passion for creating content, which is...content can be in various forms. And when you see, though, the GitHub repos, that's just one thing, but creating nice tutorials with nice steps, that's very important and takes time and patience to create those in such a way that people when they go through that tutorial, they learn something, and all the steps are well connected. Because if you don't connect all the steps, people will be confused and frustrated, like, "How do I jump from this one to this one? Is there some magic?" And then they will have disconnected concepts, and yeah, maybe abandon learning some of the technologies. That's pretty much it.

Eric Johnson: That's pretty much what you say? 

Ana-Maria Mihalceanu: That's pretty much the advice.

Eric Johnson: Well, I agree with everything you said. One of the things that I liked that not a lot of...because I've asked other people, "What do you tell them?" One of the things you said is forward-thinking, looking at what's the next thing. I think that's a really good point. It's that understanding, it's kind of reading of the tea leaves sometimes, right, of understanding what the next thing is, and to kinda be as much on that as you can. The other thing is content creation. And I tell folks, "Don't wait to get paid to do it." That's the passion is there, create a blog, create a repo, create a tutorial, much like you were saying. I mean, I know for us, when we see that it's like, "Okay, they're passionate about it," so I think that's great advice.

Ana-Maria Mihalceanu: Content creation, as you said, can start not just by having the role. I mean, we are doing this, apart from the DevRel role, for the reason of helping others not deal with the same struggles. I mean, that's how I started, by sharing stuff so that I help others now dealing with the same struggles I had. There's no point, because if the entire humanity doesn't get to struggle with the same things, we're, going forward, much faster. That's the idea of sharing. Otherwise, if we all stay in our small cubicles or square and do not share anything with anybody, it's gonna go way slower in terms of innovation.

Eric Johnson: Agreed, agreed. Well, I know we're running out of time here so I wanna tell you, first of all, thanks a lot for meeting me and chatting.

Ana-Maria Mihalceanu: Thank you. Great questions and conversation.

Eric Johnson: Yes, thoroughly, I love talking to other DAs to see what life is like, what they're doing, other technologies, hearing about that. So I wanna thank you for your time and we appreciate you taking this time to listen to "GOTO Unscripted," live from GOTO Amsterdam, right after Ana-Maria's session, which I'm sure you rocked, and appreciate. And if you wanna tell anybody, do you have any last-minute things you want to throw out?

Ana-Maria Mihalceanu: Well, please watch it. It's gonna probably be published at some point online, or download the slides because there's a lot of goodness going on there. Besides the GitHub repo, there are some links to some books, so watch out for those because they're helpful in the long run of dealing with Kubernetes and more automation. So that was it.

Eric Johnson: If someone wanted to find you on Twitter, what would your handle be?

Ana-Maria Mihalceanu: My Twitter is Ammbra1508. It's a little bit...

Eric Johnson: Oh, you might need to post that one.

Ana-Maria Mihalceanu: Yes, I know it's a little bit cumbersome but it's all comprised of some significant stuff.

Eric Johnson: Okay, very cool.

Ana-Maria Mihalceanu: So it's "Ammbra," with two Ms, and 1508, so that's it.

Eric Johnson: All right.

Ana-Maria Mihalceanu: Thank you.

Eric Johnson: Thank you. Yeah, I appreciate it. We'll see you later.

Ana-Maria Mihalceanu: And great conversation. See you later.

Eric Johnson: Yes.

Related Posts