Jonan Scheffler interviews DevOps Engineer, Arshad Zackeriya about how FinOps is involved with observability and how observability can help FinOps.
Should you find a burning need to share your thoughts or rants about the show, please spray them at devrel@newrelic.com. While you're going to all the trouble of shipping us some bytes, please consider taking a moment to let us know what you'd like to hear on the show in the future. Despite the all-caps flaming you will receive in response, please know that we are sincerely interested in your feedback; we aim to appease. Follow us on the Twitters: @ObservyMcObserv.
Jonan Scheffler: Hello and welcome back to Observy McObservface, proudly brought to you by New Relic's Developer Relations team, The Relicans. Observy is about observability in something a bit more than the traditional sense. It's often about technology and tools that we use to gain visibility into our systems. But it is also about people because, fundamentally, software is about people. You can think of Observy as something of an observability variety show where we will apply systems thinking and think critically about challenges across our entire industry, and we very much look forward to having you join us. You can find the show notes for this episode along with all of The Relicans podcasts on developer.newrelic.com/podcasts. We're so pleased to have you here this week. Enjoy the show.
Hello. Welcome back to Observy. I am Jonan, and I'm joined today by my friend, Zack, all the way from Singapore. How are you, Zack?
Arshad Zackeriya (Zack): Hi, Jonan. I'm doing good. How are you doing?
Jonan: I'm hanging in there. It's actually been a decent week. I got a lot done, I think. Some days it feels productive, and some days, you just have meetings all day, and you get one thing on the checklist. But I did all right this week.
Zack: For me, it was also a productive week, I would say. I completed all my tasks and planned for the next week. Today the weather is really good in Singapore. It was raining and very chilly. You know it's always hot usually.
Jonan: Is this the end of your week? You're done now.
Zack: Yes. It's already Saturday morning. [laughs]
Jonan: It's past midnight for our friend, Zack, here.
Zack: [chuckles] Yeah.
Jonan: So I appreciate you joining us on such unusual hours, but I'm jealous that you've already finished your Friday. So, what do you do over there in Singapore?
Zack: So I'm currently working as a DevOps consultant at PALO IT, Singapore. So we are a huge DevOps consultancy agency in Singapore. And we have other branches around the world like in France, Thailand, and all over the world.
Jonan: Wow.
Zack: So currently, I'm working in Singapore. We have a huge, awesome team. And I believe we are doing the DevOps in a better way. [laughs]
Jonan: Yeah, I imagine. It sounds like you keep up with modern practices pretty well.
Zack: Yes. So when you call it DevOps, everyone is talking about the tools. In the industry, they're talking about tools. But apart from that, they have culture, the practices, and processes, like you said. So I'm more than happy to be here. We are doing some awesome work here.
Jonan: That's great. I'm jealous that you get to live over in Singapore. It's beautiful.
Zack: [laughs]
Jonan: I would love to go visit again someday. I feel like this pandemic is almost wrapped up here. In just a couple more weeks, we'll be done with all this nonsense.
Zack: Yes. I'm waiting for my second jab. So I think after that I can go out and have a dine-in with my friends. So I'm waiting for my second shot. So get vaccinated. [laughs]
Jonan: Everyone get out there and get vaccinated, please. I just want events back. I want to go to a conference again. What have you been up to lately? What are you excited about right now?
Zack: So actually, when you're talking about this podcast, it's more about observability, right?
Jonan: I mean, ostensibly, yeah. We talk about all kinds of nonsense but hypothetically, yeah.
Zack: [laughs] But I love the term because when it comes to DevOps practices, and the process, and the culture, I always talk about observability in all the events and all places whenever I can because it's a very underrated area. I would say it's kind of a gray area. No one talks much, but we should give a pivotal place to observability. So even though that, I would like to talk about how the FinOps, the financial operation is involved with observability, how the observability can help the financial operation, the FinOps. So what are the gray areas? What are the gaps? How can we fill it, and how can we improve it? I'm super excited to share my thoughts about that today.
Jonan: Yeah, FinOps is actually kind of an underserved portion within an underserved topic of observability. People leave the banks behind sometimes when we talk about these things.
Zack: [laughs]
Jonan: But it's a pretty relevant thing. If you work at one of those companies that send you paychecks, you probably care about the money. So I'm interested to hear more.
Zack: Yeah, because the problem when it comes to FinOps financial people are not technical. I'm not complaining. They're not technical. We can't expect that. And the engineering team can't worry about the money because they want to deliver the awesomeness, deliver the best to their client or customers if they're based on a project-based or a product-based application that they're doing. They want to do the awesome things.
But the conflict comes when the cloud vendor or any tools they're using when the bill generates monthly, then the problem occurs. So the finance team and engineering team the conflict is, "Okay, why are you spending a lot?" because they have no idea. The problem comes because they don't understand each other. That's the main gap, I would say. So that's the gap we ought to fill. So spending and accountability is the gray area of this topic. Both teams should collaborate wherein the FinOps this issue occurred.
Jonan: There are whole consultancies like The Corey Quinn Consultancy that exist solely for the purpose of looking at your AWS bill and making it smaller because people spend outrageous amounts of money and don't stop to think about how it came to be that way.
Zack: Yes, correct, correct. There are a lot of complaints. People are complaining. I'm not just focusing on one cloud vendor. People are saying, "AWS is very expensive; we can't use it. Google Cloud is very expensive; we can't use it. Azure is very expensive." It's not. It's how you're using it. Always what you see is like rather than why you need it. I'll get an example. So you have an application. You want to host a WordPress website. So if you're hosting like a simple way of hosting and you're comparing with another hosting, some engineer is saying, "Okay, we want to host it in a Kubernetes Cluster, and we want to put a service mesh." [chuckles] It doesn't make any sense, right?
Jonan: Right, yeah.
Zack: So it's always why do you need these things? So I think that that's where this issue occurs.
Jonan: This is, I think, a product of non-technical people trying to drive some of the decisions sometimes.
Zack: Yes.
Jonan: I once had someone come and demand that I implement a feature. It was like an upload button. And they're like, "You definitely need to use Flash." And I was like, "I'm not. That's not a thing that I'm doing."
Zack: [laughs] Exactly, yeah. That's a gray area we have. If I go a bit deep into FinOps...I would like to be allowed to go deep bit, not a bit deeper, but a bit deep about these FinOps. There are operating models in FinOps: inform, and optimize, operate. So when you come to inform, there the main issue occurred, understanding spending where the engineer is saying, "Okay, my AWS bill is a couple of thousand dollars here. I'm paying this much." So they don't understand.
The best example is the indirect charges. You're spinning up a virtual machine to run your application, but there are some indirect charges. I'll give you an example like the network throughput. So there's a hidden charge and the IOPS or throughputs for the volumes. So those things we always fail to measure before we give a quotation to the customer, or just in the calculation, we're forgetting the full cost. So this is the issue.
For example, if you have an application complete with a VM, the object storage, or a CDN, we think, okay, this is the amount we are going to use, but we are not going to forecast. So slowly, I'm taking observability into this topic. So slowly, we are pointing the finger to observability in here. So later, we have some awesome stuff. So this is the main issue in the inform.
And we always complain like, what, and which and who takes accountability for those things? The developer wants to test some kind of environment. So they want to spin up dev resources and do testing. But again, the observability comes okay; what type of resources are they going to use? What type of things do they want? We have to focus those things and give those boundaries. Otherwise, any developers can go ahead and spin up, for example, AWS c52xlarge. It's damn expensive. But for testing, you can give a boundary for...you can go for a T series. So again, observation comes in.
Then let's go to the optimize. Optimize it's like where we spend a lot of money. When you get your AWS bill, AWS, or any cloud vendor bill, when you break it down, you can see, okay, I'm spending a lot for the utilization of the processes, the CPU.
Jonan: Well, so I have a question about that exact point. Because I think for a lot of people, a lot is relative, and they don't understand. How do I know what a lot is? It's all a lot. That's a big number on that bill. I don't know what is reasonable for me to be paying in any moment for CPU utilization. Comparing that to the resources that my application actually needs and what is expected for an infrastructure of my size is difficult, right?
Zack: Yes, yes. Correct. So that's a good point because maybe you're overutilizing it. Your application actually required a few amount of CPU, but you're overutilizing it. So I have a pretty cool example to share with the audience. It's super cool. The things I felt and still when I'm thinking about it, I was laughing like, okay, I should have done this better. But in the DevOps field, it's a field we keep learning, we evolve, and we move on. That's how the process is going on.
So you set some goals to optimize those. You can set some goals, okay? I’m going to reduce my bill by $100 because it's not one-day work. Within one night, you cannot do it. You have to observe, and you have to monitor everything. And you can do it one by one monthly. Okay, I'm going to set a goal. Okay, next month, I'm going to cut $100 somehow. So you go through your info and everything. You find out okay; there are some dev environments running, we don't need it. So then, when the automation comes, you automate your dev environment to stop it. So again, observability comes in.
So the third one is the operate. You plan and execute how to achieve those things. It can be automation. It can be an audit. It can be another person's job; it depends. I can't say you have to do it like this because every organization has its own thing, right?
Jonan: Yeah, of course.
Zack: So inform, optimize, and operate I think it's taking more things in the FinOps, I believe.
Jonan: So I have a point to make here that I feel like, for you, there is only a certain amount of time. I imagine that a DevOps consultant such as yourself gets paid a pretty reasonable wage. And to shave $100 off an AWS bill, if that takes you more than probably half an hour, it ends up being a net loss but only in the month that you actually put the money in because you're saving $100 going forward.
Zack: Correct.
Jonan: There is an inflection point there, though, where it becomes more expensive to shave down the bill. And I think a lot of people assume that they are there already. "Well, let's just pay the money because it's expensive to investigate and to dig down." So just real quick, do you happen to have some suggestions on reducing the cost of that investigation?
Zack: Yes. I always say, "Hire the right people. Hire the right people, with the right mindset for the right culture." because I have seen these things. I have worked in places where they are using…very overutilized. They're running a single Docker container on a C5 xlarge instance. I was like, okay.
Jonan: That sounds like me. That sounds exactly like what I would do.
Zack: [laughs] Everyone is doing that. So I took it as a challenge. I told them, "Okay, I'm going to reduce your bill." I have done that. I even highlighted in my profiles that I have reduced a couple of thousand dollars from their bill, reduced their entire infrastructure because you have to know that always, my question I always check not what but instead, why. Why do you need it? All the tools in the industry you can install together, and you can do it. But why do you need it? That's the main question. Do you really need it? When you go to buy a mobile phone…okay, I have an iPhone 11 Pro. So next time I'm going to buy the next iPhone 12, I should ask myself, do I really need to buy this? Because it's not a big difference.
Jonan: You do have to. You work in tech, so you need to be on the bleeding edge.
[laughter]
Zack: I would do for my graphic card, yes. I don't mind going from 380 to 390. I don't mind. I stand in the queues. The way I bought the PS5 is a really awesome story, man. [laughter] I paid an extra $100 to get that one, but still, it's worked for me. Because can you buy a PS5 now? Then you go, "No." You can't. PS5 is very rare to buy these days. [laughs]
Jonan: My siblings have no understanding of the things that I spend my money on. They're like, "Why would you spend…it's like a computer that is worse than your other––. I'm like, "It's a Raspberry Pi." Why would you buy that? Why would you buy that?"
Zack: [laughs] Exactly. Exactly. Exactly. So I have seen...okay, the Raspberry Pi is a good example. I'll tell another story for this. In a lot of meeting rooms, what we have done in our previous places they used to have, you know, the NUC we call it. The N-U-C, NUC, like a small computer, but it's pretty expensive. So basically what we need for the meeting rooms is OS running which we should be able to share anything. Raspberry Pi is a good solution.
Jonan: That's a really good solution.
Zack: Yeah, $50 you can get. I love how you…like my stuff; I do a lot of hobbies. I do a lot of automation using those things. So I used to buy these cheap bulk bots and do things. So again, to the question, what I'm saying is you always check what you need and why you need, so that's the main point I'm saying.
Jonan: This Raspberry Pi example is really good because those conference systems are ridiculously expensive.
Zack: Expensive, right. Okay, I don't want to mention the names, the vendors. It's expensive. [laughs]
Jonan: You pay ten grand for a conference room. I could get you a lot of Raspberry Pis for ten grand.
Zack: [laughs] Exactly. I can cover the entire office.
Jonan: Yeah, exactly. So, where do people screw up in this whole thing? This all makes sense to me. I need to get the insight on what I'm actually using because you can find the server that's running one Docker container. Because you can look at the CPU utilization and the RAM usage, and you'd be like, okay, the memory usage on this thing is like, we're idle 90% of the time. We can fix that. But then, once you are trying, people are going to make mistakes along the way, and they're going to potentially underserve parts of their infrastructure or other pieces. This is a thing that you do often, tell people how not to mess it up.
Zack: Yeah, yeah, yeah. And so I will comment with a good example. So I have seen this scenario. Okay, let's assume a NOC or SRE side. We'll talk about the SRE side. So this is not a proper SRE. So I'm just giving an example. Let's assume it's an e-commerce platform, and it's Christmas Eve like the 24th evening. So people are going and buying their presents. I don't know whether you're doing the last time shopping.
Jonan: I would never do that, yes.
Zack: Never do that, exactly. Good. Good, good. So keep it up. [laughs] When you check, a lot of the sites are very massively...the traffic comes like a very huge amount, unpredictable. So again, a good example, what we see, let’s talk about a DB instance. Let's talk about AWS RDS. RDS the engineer is saying, "Okay. The CPU level is going above now 60. It's going to crash."
So what they're going to do is they're going to put the site offline, and they're going to increase the RDS instance, and it's not going to work. They keep increasing. And again, the application side, they're seeing that okay, your CPU level of the instances is going higher. And they keep adding the instance to the auto-scaling groups and to load balances. So it's not going to work, so that's where they make the mistakes.
Rather than doing that, they should find the root cause of that. Maybe it's something else in the application level. So that's the main mistake they're making that rather than going deep inside, what they're doing is they're just increasing the infrastructure. So again, I'm saying that observability matters. If you observe very well how your application is behaving, you know okay, this function is doing very bad.
Okay, let's talk about the New Relic APM. I really love that tool. You can easily find out which function is giving the root cause. Who is the culprit?
Jonan: Exactly.
Zack: Because I have been in these war rooms. So we're finding out the main tool using these APM tools that help us to find out the root causes.
Jonan: This is my recommendation to anyone who's new to APM. Your first week on the job, you find your way into their New Relic dashboard, find the slowest transaction in the database and the slowest web transaction. And you fix both of those, you just paid your salary for the first year, and then you get a raise.
Zack: Yes, exactly. If you're working very well and if you're trying to help the organization you're working for, the next pay is very well. The company is going to increase it. So it's called the butterfly effect. You're changing something, and there's a massive impact somewhere else. So it really matters. You have to think about these lean areas to do it.
So I will share something. I did an interview with one of the candidates. So he shared with me nice stories, so I thought I will share with you all because they had these...I'm not mentioning the company name or anything, just a generic one. So they had this application and the same application, it's kind of an e-commerce application, and they have another application for the BI part. So you know BI, they need more reading. So they found out that in a general report, the site is going down. But they have already set up the read replicas in RDS, AWS RDS, and they were using AWS. And yes, they are seeing that the CPU level of the RDS is going high, and they wanted to find out what the root cause is. And then they found out in the application level; they were talking to the point of the read server. Sorry, the write, not with read.
Jonan: Oh, they were trying to read from the write instead of reading from the read replicas, which is the whole point of them existing.
Zack: Exactly, the whole point of implementing the BI for the read replica.
Jonan: So they're reading from the locked rows as they're writing to them. And that is the slowest way you can...okay.
Zack: Yes, so that's the root cause. So APMs help them find the root cause. So that's really important. When we're talking to the customer, they ask the million-dollar question. "This is very expensive. Do we need these tools to monitor our platforms?" Yes, because it's going to save your dollars in the future. Am I correct?
Jonan: Of course. These things are the things that pay for themselves, right?
Zack: Yes.
Jonan: I've made the same case about Platforms as a Service. APM tools or other observability tools are one of the best investments you can make. They may be expensive, but if you are using it correctly, you are saving so much more.
Zack: [laughs] It's like I'm putting an FD for my own self, putting an insurance, or putting a saving plan for myself because of the future. Because today you're going to do this, and tomorrow it's going to save you millions of dollars. It can be because everything started from the beginning. Maybe eBay or Amazon started from the garage level. Now you don't have to talk about that. Everyone knows that.
Jonan: But convincing a finance person of this can sometimes be difficult because they're seeing the price tag now, right?
Zack: Yes, that's where the FinOps comes in. The FinOps should be...I can't say it's a new term. It's a couple of years old, but not everybody is using it, but some organizations are using it. Those who are having the knowledge of the operations and the financial they know okay, this is really important. This ROI I can accept. I can see the future. I can release this money for this team. So that's where the FinOps comes in.
For doing the FinOps like in a DevOps culture, the collaboration matters. You have to work with all the team. This is not one person's job. I hate to say myself as a DevOps engineer because I would love to say it as a DevOps enabler because it's not my own work because day-to-day, I work with the developers, project managers, security engineers. So it's a collaboration. It's not one person's work. So again, I'm putting the responsibility on the entire team, not on the one person.
Jonan: So this DevOps enabler title I really like. This FinOps you mentioned…incorporating the finance team into the DevOps operation through this FinOps concept is one thing I think that is, as you said, a relatively new idea, and obviously, for all of the reasons you outlined, very helpful. I'm curious to know your thoughts on what is coming either for FinOps or for observability generally over the next year. It's prediction time. If you've listened to this show, you already know that I'm going to ask you this question. But I want you to make a prediction so that a year from now, we can come back, and we'd be like, "Nope, FinOps is dead. You were totally wrong, Zach. I'm so sorry."
Zack: [laughs]
Jonan: So I want you to guess what's going to happen so we can do this again and we can review it.
Zack: I would say the AIOps.
Jonan: Hmm.
Zack: So, yes, yes, yes. [laughs] I know with the sound hmm. [laughs] I can't say it's a new term, but it's kind of new. It's in the industry. But in New Relic also, there's an awesome tool like Applied Intelligence. So I have gone through that. Yes, I think it's free to try as well. Anyone can try it. So the AIOps that's the future.
Jonan: I agree.
Zack: For now, when we are talking about the oil, we talk about the Middle East because of the fields. But now, the data is everything. Data is the money, So when it comes to AIOps, we cannot forget the historical analysis, anomaly analysis. I'll give a good example of anomaly analysis. You know these days about the credit card frauds.
Jonan: Oh yeah.
Zack: Yeah. We have a lot of issues with these credit card frauds. Everywhere in the world, people are cheating. They're doing it. So imagine how the AIOps can help to prevent it. It can find, identify the fraud, how the behavior of these transactions is happening from this particular credit card number or the credit card. So this is the future, I would say. AI is going to replace a lot of service desks, SOCs, NOCs in the future. It's going to be fully automated, I would say, not very soon, but a couple of years. It's going to help our future be easier.
Jonan: I totally agree with you. I think this is kind of the next step for observability, being able to automate some of the...digging through the various...I mean, we've got all the stacks of hay, and we're going through them and finding the needles now. And doing that with robots is a good idea, except I will point out that my bank's automated fraud system recently flagged my card for no reason, just because I was in Vegas for a Hacker Conference. And I haven't traveled in two years. And I tried to withdraw a huge amount of cash from an ATM to play poker. They flagged my card for that. That's exactly the kind of anomaly that is okay with me. We need to work that piece out.
But I agree with you generally that across all of the industries in tech, all of these segments, not just observability but applied intelligence and artificial intelligence, can add value. It's a dangerous sword. I hope that we use it for good and not for evil. But yeah, you're right.
Zack: Yes, but either way, people using...we cannot stop the world, how the world is behaving, how the people are using these things for the good purpose and for the bad things. So when you talk about that thing, I would like to add a few things of observability. How can observability help the FinOps? We can check always the forecast of the utilization.
As a good example, I used to work for an e-commerce agency, a huge one in Australia. So we had huge retail customers and clients. What we did is we used to do benchmark load testings and observed through...to be honest, we used New Relic because that time it's like a couple of years ago. We used the New Relic enterprise, I believe was the model. Anyways, fine, but mainly the New Relic APM.
So we were doing the load testing. And we were optimizing that particular application to the EC2 instance. We proved that you don't need to run 10 or 100 EC2 instances to satisfy this requirement. We can do the same thing with four instances because we are going to optimize the server with these parameters in the server level. If you're talking about any programming language, Java, PHP, we can optimize those server-level configurations. That way, observability can help to save money. So on the customer side, they're saving money. From the client-side, we are also saving money.
Jonan: Because you can see rather than using a clone of your entire production infrastructure to test your load, you can extrapolate from a smaller set of servers if you have solid observability.
Zack: Exactly. So a lot of places, I have seen these startups getting failure. I'll give you one example, which is covering this area, the observability, and FinOps. One thing is the postmortems. The SRE team, we used to do a lot of postmortems, but it should be a very good postmortem. That matters because we have to be very open for the team, share with the team, have to tell what went wrong and why it went wrong. That is a must. So you need these APM tools and other tools to observe these platforms and get the best postmortem.
And this is the best part of this topic, the business module. Without a proper business module, you cannot earn money. You don't have any profit. So when you're talking about the direct proportions, yes, when your profit is going higher, sometimes your number of users or utilization is going high but fine. It's a direct proportion. But what about the inverse proportion? Your profit is not going higher, but your utilization and the number of users is going higher. It's very bad. So we asked the observability, if you have the proper observability, you know that okay, now we have 1,000 customers. But next Christmas, I should have at least 2,000 or 5,000.
Jonan: Sure.
Zack: Do you think you can run the same infrastructure for the 5,000 customers? No, right?
Jonan: But you have to estimate like an executive team. So you say, “Well, right now I have 1000, so next year I'm going to have 400,000 guaranteed." At the executive level, you just choose a number that is arbitrarily high and then draw a line on the graph. I'm teasing. All my executive friends, please know I'm joking.
Zack: [laughs]
Jonan: But those estimates you make this guess of where you're going to be, and then you can use observability to plan.
Zack: Yeah, exactly. So that's where the issue comes in. The observability matters. People think, okay, no, I'm not going to spend a lot on this observability. I don't know this new term or name. No, you have to. You have to because you cannot do the observability. You cannot satisfy this requirement without the proper tools. I talked about New Relic, APM, and stuff. Another tool is the Synthetic.
Jonan: Oh yeah. Synthetic is good.
Zack: We did a lot of things using Synthetic for this e-commerce platform. In the night, we want to calculate the error rates and stuff. So what we did is we scripted some Synthetic scripts on the New Relic Synthetic. And we automated a few tasks like add to cart, the shopping cart, and checkout. We can automate those things. We don't need to hire more engineers, so save that financial. So I think you have the tools. Simply, if I tell you that you are going to bake your own cake, you should know how much flour you want, how many eggs, and the salt or the sugar levels. So it's up to you. But make sure you're going to bake a good cake, not a half-baked cake. So that's the one I want to tell the audience.
Jonan: This is a good example. Speaking of telling things to the audience, there's the other question which we ask everyone on the show, which is, what advice you might give to yourself? Imagine rolling back your career. You've been doing this for quite a long time. What would you tell yourself now in hindsight, changes that you maybe should have made or would make today? Or someone who aspires to be in your position...There are plenty of people who would like to be doing DevOps consultant work, specifically in the financial industry. What advice would you give those people coming up today?
Zack: I would say when I found something useful, like maybe a good practice, a process or tool something, I always liked to have known it before. I always think I should have done it before, so like that. So if you're selecting a career, find a good place to improve your career so where you can improve yourself and the organization both together. So really, I'm happy with PALO IT. I can improve my career, and the company is providing me with a lot of good stuff to improve myself as well. At the same time, I'm giving to my other colleagues and the company.
So think always...Don't think it's too late, but I'm worried sometimes. Read a lot, read a lot. I'll give a good example. Think like this; I’m not suggesting that you cut trees. I love trees. I have a small garden. I can't say a garden. I have a few plants. So if you want to cut a tree within ten days, first, you sharpen your ax. You take at least three to four days, fine. Sharpen it. Then cut it within a few hours, then the cut is a very clean cut. It is properly cut rather than you chop, and it's not cut properly.
Jonan: I see what you're saying.
Zack: Exactly. So it's evolving. It's like a Temple Run game. It's never going to stop, trust me. Read, read. Listen to this podcast because I'm sharing something new, and you're talking something new. At the same time, I'm listening, and I learn something new, so these are the things. So while I work, I listen to a lot of podcasts. There are a lot of nice channels. I love your channel as well. [laughs]
Jonan: Thank you.
Zack: And New Relic has a few channels, not only this. So I saw that the developers have a different one as well, so pretty awesome. So listen to those things. Build your skills and levels, and process good practices, keep a code of conduct. Then you approach rather than you go bake a half-baked cake. That's the thing I would like to say.
Jonan: This is really good advice that I wish I would take more often. I am definitely the person who goes off half-baked.
Zack: [laughs]
Jonan: I will full-on do a live stream about Kubernetes having no idea how that works. I'll just do it.
Zack: [laughs] One more thing, don't try to put everything on Kubernetes. [laughs] Kubernetes doesn't mean you have to containerize, and you have to use Kubernetes or Istio or something like that.
Jonan: Kubernetes is very good at sharpening axes.
Zack: Yeah, very good.
Jonan: If you want to sharpen your ax, use Kubernetes.
Zack: [laughs] That's awesome.
Jonan: All right. Well, we are unfortunately out of time, but it has been an absolute pleasure having you. Thank you so much for coming on the show, Zach. Is there any parting thought you want to leave our listeners with before we head off?
Zack: I'm going to say that this is an awesome show. Support your man. Listen to this. [laughter] I would love to do another one in the future, maybe. So we'll see.
Jonan: Yeah, absolutely. I have a feeling you will be back. I appreciate your time so much. Have a wonderful day.
Zack: Yeah. Cheers. Bye-bye.
Jonan: Thank you so much for joining us. We really appreciate it. You can find the show notes for this episode along with all of the rest of The Relicans podcasts on therelicans.com. In fact, most anything The Relicans get up to online will be on that site. We'll see you next week. Take care.
Top comments (0)