Driving Innovation with Kubernetes & Java

Technology can advance faster if we share our knowledge. That’s the mission of a developer advocate. Ana-Maria Mihalceanu, developer advocate at Red Hat, talked to Eric Johnson, principal developer advocate at AWS, about her passion for learning, sharing knowledge, Java and Kubernetes. Discover what a Kubernetes operator is and when to use it vs Terraform.

---

Why Java?

Eric Johnson: Hi, my name is Eric Johnson, and we're here in Amsterdam for GOTO Amsterdam. And this is "GOTO Unscripted," and I'm here with Ana-Maria Mihalceanu. Ana, why don't you tell us a little bit about you?

Ana-Maria Mihalceanu: Hey, Eric, it's good to be here. I'm Ana-Maria Mihalceanu. I'm working as a developer advocate for Red Hat, and I have a great passion for Kubernetes, everything that's related to Kubernetes, and Java. So these are my greatest passions, Java and Kubernetes, and when I found ways to work together with both of them I'm the happiest developer ever.

Eric Johnson: Wow. They picked either the right person or the wrong person to interview you, so this should be fun because, one, I can't spell Java. I took a Java class, the first language I ever took. Someone said, "You should start with Java," and I was a disaster, so why Java? Why are you so passionate about Java?

Ana-Maria Mihalceanu: Well, the passion for Java started in university, when, of course, probably like many of the students in computer science, like, 10-ish years ago. We were learning first C, C++, and all those nice languages that were like dealing with memory allocation. So when I heard about Java, which doesn't have all these concerns, like thinking about memory allocation and working with pointers, I was like, "I need to give this a try because it doesn't work with pointers anymore. So that's where the Java part started, and I had a Java class that was given by a very passionate person. It's very important when you're starting with a language to get to know it from somebody very passionate. It can transfer that passion, and I just stayed like that. Well, down the road I actually programmed with others as well, with PHP. From time to time I also used Node.js. It's not that I'm not acknowledging the rest of the ecosystem as well, but Java has been my first and still my main love.

Eric Johnson: Wow. So I do a little bit of Python. I do a little JavaScript, which, you know, probably a year into it, but it's not the same as Java. And I never understood that naming, but there it is. I'm more of an architect, so I know I didn't say in my introduction, that I work for AWS. I am a developer advocate as well, so love that that's what you're doing. Tell me, and we're gonna get to the Kubernetes part. I haven't forgotten it, we're gonna come back around.

Ana-Maria Mihalceanu: You can count on me for Kubernetes.

Eric Johnson: I know how to say it, yes, "Koo-burr-NET-eez," yes. Why is the "NET" all capital, is there a reason for that?

Ana-Maria Mihalceanu: I don't know, but I love the cool t-shirt.

Eric Johnson: It is a cool t-shirt. I love that shirt.

Ana-Maria Mihalceanu: I love it very much because it has also the name of another great colleague of mine, "Burr," Burr Sutter. He's also giving a talk here at GOTO Amsterdam, so I felt like, "Yes, I'm gonna meet Burr today. I'm gonna wear this t-shirt to honor him."

Why did you choose to be a developer advocate?

Eric Johnson: Nice, very cool. All right, so tell me, developer advocate role, why developer advocate? Why did you choose to be a developer advocate?

Ana-Maria Mihalceanu: I chose to be a developer advocate less than a year ago, by the way, so I'm new to the field, but I chose this career change because I wanted to be even closer to communities, developers, and to share my knowledge with everyone as much as possible. And I saw this role as a possibility of sharing knowledge, of building new knowledge, learning new stuff, and contributing to new stuff even more than what I was doing in my previous role as an architect. I loved my previous role, I love this one as well.

And I found it, well, it's challenging but it's also very rewarding in terms of when you're building tutorials, workshops, content for folks to learn from, practices. When you're uncovering practices and you have the freedom to share them with the world, like, "Hey, look what I found," this is amazing. It's an amazing feeling as a developer advocate. And I can say that I love this role and the possibility it gives me to talk to so many people, hear about their challenges as well, and take those challenges and think about how I can use the knowledge I have and the technologies I have access to improve their life, improve what they're doing.

Eric Johnson: Love it. I was a systems architect beforehand and I have so much I wanna tell people. It's like, "We don't wanna hear it, just do your job," right? But in this role, we're encouraged to learn it and tell people about it, so I love that you said that.

Ana-Maria Mihalceanu: Exactly.

Eric Johnson: You're passionate about it and you're passionate about teaching people.

Ana-Maria Mihalceanu: Yes.

Eric Johnson: Is that where the energy comes from? Is that where the charge comes from?

Ana-Maria Mihalceanu: Yes. I recharge when I'm talking to folks when I'm hearing questions. Even the tough questions that I don't have an answer for, I need to document myself, I love those questions. I love to find out, okay, there are different scenarios I didn't think about, or others I didn't think about that I can take home, like, "Oh, let me try this, let me try this," and it's so rewarding and great. I used to do this before but at a smaller scale because, as an architect, you dedicate pretty much to a certain product or project, and you're just looking at the shape of that and maybe interacting, of course, with an end users' view, or somebody's views. But you don't get to end up with an entire world of developers with so many challenges, because companies are different. They have different challenges, and different cultures and this one is even more recharging.

Eric Johnson: The light bulb.

Ana-Maria Mihalceanu: Yes.

Eric Johnson: You see the light bulb come into somebody's eyes and it's like, "My job here is done."

Ana-Maria Mihalceanu: Yes, I'm very much happy when I get feedback when people tell me that they understand some concepts once they saw them. And that's actually what we're working on as developer advocates, to transform those concepts from the part that seems hard to grasp and something easier to understand. It's not meant to make things even more complex. There's enough complexity in this world with just doing part of the content creation so that people will understand even better those hard-to-touch concepts.

Eric Johnson: It's almost like there's not enough 100-level content, and that's what I feel like. We have to do the 400 level as well, but that's a conversation we have internally as well is, "We need to turn on more light bulbs. We need to see more people at that starting point," because you always struggle. From my endpoint, when I see someone working on something it's like, "There's a better way to do that, and just stop for a second. Let me just show you how to get started with this." For me it's serverless, or it's architecture, or there are all kinds of things, but it's that. And then you see them go, "Wow," you know, "This is awesome." Now I don't want this recorded, but I would do this for free if I had to. My wife's like, "No, no, you're not." But that's the pay, right, is seeing the light bulb come on.

Innovation through knowledge sharing

Ana-Maria Mihalceanu: Yes, and that's a great advantage of doing this role, that you can enable so many folks. And let's face it, in our previous roles, we learned from other developer advocates, and thanks to those tips. I remember myself as an attendee, and I'm still an attendee at many conferences, including this one, because I'm gonna attend some talks as well. I used to go to conferences with the idea of getting training in a more relaxed way, so I love to just have my coffee, sit in a chair, and like, "Oh, I will enjoy this."

By the way, speaking of serverless, I got to hear about Knative at Devoxx Belgium. I was like, you know, browsing the app, like, "Knative, this thing that makes serverless in Kubernetes without depending on any function. Hmm, that sounds cool." Because I was asking myself at that time, "Isn't somebody inventing something that I don't depend on a specific function or something like this? Maybe this Kubernetes thing can help." And then I got there. I got to see the first demo with Knative and it was so inspiring.

I was like, "Yeah, I got ideas now. Maybe I can fit this somewhere in what I'm doing." So this is how you go forward. This is how innovation is going forward for many products that we, all of us as humans, benefit from. It's not just the software companies that are the ones that are benefitting from all this technology shared at conferences, but also companies that are actually in a specific industry, regardless of its financial, if it's e-commerce, and all this. So it's always good to share and to learn more.

Eric Johnson: I think for us, and maybe this is a repeat of what I was saying earlier, but it's almost we're measured by how many pitfalls did I help you avoid, pitfalls that I certainly fell into. Talk serverless for a second, I started serverless when serverless was starting, right? I remember looking at it and going, "Why would you need it any other way?" And then I did all the things wrong. I have a talk called "The Five Things I did Wrong in Serverless," and I did them with passion. And so I could come to people and go, "Let me tell you what I did wrong and help you." And again, e measure that by, "How many pitfalls id I help you avoid?" And this sounds like the same thing.

Recommended talk: Leveraging Serverless in Full-stack Development • Eric Johnson • GOTO 2020

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.

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.

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

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.