Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
From Manual to Automatic: Revolutionizing Cloud Native Stack Deployment with Argonaut
1.5k Plays1 year ago
In this episode Bhavin and Ryan interview Surya Oruganti, Founder of Argonaut. This episode covers the complexities and challenges production Kubernetes environments encounter, how teams are often wrangling with infrastructure and pipelines rather than enabling teams to focus on developing value. Surya helps explain why these problems led him to create the Argonaut project and platform to get teams off and running with full cloud native stacks with all the bells and whistles like GitOps ready to go.
- 00:30 Intro
- 07:22 News
- 00:17:18 Interview with Surya
- 01:02:04 Takeaways
K8s Bytes Slack ! - https://kubernetesbytes.slack.com/
Try Nom Nom today, go to https://trynom.com/kubernetesbytes and get 50% off your first order plus free shipping.
News
- https://blog.aquasec.com/2023-nautilus-cybersecurity-report-insights-revealed
- https://siliconangle.com/2023/06/29/causal-ai-company-causely-raises-8-6m-automate-operations/
- https://www.youtube.com/@PlatformEngineering/playlists?view=50&sort=dd&shelf_id=1
- https://twitter.com/i/spaces/1vOxwMygjoMGB?s=20 https://www-portainer-io.cdn.ampproject.org/c/s/www.portainer.io/blog/announcing-k2d.io?hs_amp=true
- https://tanzu.vmware.com/content/blog/vmware-tanzu-mission-control-self-managed-announcement
- https://www.opensourceforu.com/2023/07/netapp-launches-spot-ocean-cd-revolutionising-kubernetes-delivery/
Surya and Argonaut Links
- https://www.argonaut.dev/
- https://www.linkedin.com/in/suryaoruganti/
- https://twitter.com/suryaoruganti
- https://www.linkedin.com/company/argonautdev/
- https://twitter.com/argonaut_dev
Recommended
Transcript
Podcast Introduction
00:00:03
Speaker
You are listening to Kubernetes Bites, a podcast bringing you the latest from the world of cloud native data management. My name is Ryan Walner and I'm joined by Bob and Shaw coming to you from Boston, Massachusetts. We'll be sharing our thoughts on recent cloud native news and talking to industry experts about their experiences and challenges managing the wealth of data in today's cloud native ecosystem.
00:00:29
Speaker
Good morning, good afternoon, and good evening wherever you are. We're coming to you from Boston, Massachusetts.
Personal Anecdotes
00:00:34
Speaker
Today is July 5th, 2023. Hope you're doing well and staying safe. Let's dive into it. July 5th, Bobbin, I hope you enjoyed your fourth. You know, tell me what's good. Hopefully you have a good time.
00:00:46
Speaker
Yeah, it was fun and all, I guess. But Boston didn't get the memo that it's not supposed to rain on the 4th. People are supposed to be outside, have barbecue. And yeah, it was raining for I think three fourths of the day. I saw I didn't go I didn't make it to the fireworks show at 10 30pm last night. But
00:01:04
Speaker
saw videos this morning and they didn't look good like it was so much there was so much fog in the sky like you could barely see the fireworks it was just some some random lighting in the distance at that point yeah yeah it was not fun
00:01:16
Speaker
But again, scroll through a lot of Instagram, right? So there was the traditional reading of the declaration from the old state house and the parade with everybody dressed up as patriots and things like that. Again, didn't see that in person. But it was there. I guess I had a good 4th of July long weekend for myself, just helped out a few friends who were moving.
00:01:40
Speaker
I caught up on some chores and then just took a day off. That's it. Oh, yeah. We're moving this weekend. Oh, that's I mean, you're a good friend. But, you know, it's always a pain. Yeah, it was like I think it took us five or six hours. And then we were so tired by the end of it. Like we everybody just wanted to skip like even a beer that we were supposed to have after like going to say hopefully they paid you in food or libations. Yeah.
00:02:04
Speaker
Yeah, but not one dude, like just hire movers. Just hire movers. You ask your friend and Bobbin's like, how about I just pay some movers for you and we can hang out instead. That's good. How about you, Ryan? How was your food? It was good. I spent some time with my father and daughter over the weekend, which it was actually a lot nicer then. Sunday was a bit rainy, but all things considered.
00:02:28
Speaker
I drove to New York on the 4th actually to hang out with some family and it was much nicer there. So I didn't get caught in the rain other than driving through it a bit. So I can't complain too much. Although it's funny now that you mentioned it, the 11 plus years I've been in this area.
00:02:45
Speaker
I've never been to like the festivities in Boston on July 4th I think mostly because huge events in major cities I'm just like I don't know just like too many people you know I love Boston like I really do and I just go on like the down the downtime and I yeah
00:03:03
Speaker
For me, it's just like, I will have to go find parking, maybe walk a couple of miles just to get to the thing. I don't even bother driving. I mean, now that the Sumner tunnels close, I think tonight, right? I'm just planning my airport trips now. Like, if you fly before I do, like just let me know how much time it takes. I'm thinking I'll take a detour through Everett. Maybe hopefully that gets me there sooner, but yeah, I'm not looking forward to traveling the next two months.
00:03:29
Speaker
And I have like a walk trip and a personal trip during that time. So yeah, it's going to be interesting and not in a fun way. So you just go in and just think of the worst case scenario. That way it only gets better from there, right? Uh-huh. Your expectation, like really low, really low, as low as it can go. Like you're going to get stuck and then like your, your driver's going to get ticket and you like walk down the wrong road. Like just, just start there.
00:03:53
Speaker
Yeah. And then figure it out. Nice.
Episode Preview and Advertisements
00:03:56
Speaker
All right. So we have a cool episode today before we jump in there and introduce our guest. Let's dive into some news. Why don't you kick us off, Bobbin?
00:04:04
Speaker
If you've ever had a puppy and raised it to become a big dog, you know that changing food and finding the right food is hard to get right. Ultimately, you want them to feel good and act happy and be okay with what they're eating. They're part of your family, after all. I have an eight-year-old golden retriever named Roscoe, and he's always had a sensitive stomach, so finding the right food is kind of a pain. That's where Nom Nom comes in.
00:04:28
Speaker
Nom Nom's food is full of fresh protein that your dog loves, and the vitamins and nutrients they need to thrive. You can actually see proteins and vegetables like beef, chicken, pork, peas, carrots, kale, and more in the ingredients.
00:04:44
Speaker
So here's how it works. You tell them about your puppy, the age, breed, weight, allergies, protein preferences, chicken, pork, beef, and they'll tailor a specific amount of individually packaged Nom Nom meals and send them straight to you. If you're ready to make the switch to fresh, order Nom Nom today and go to https forward slash forward slash trynom.com slash Kubernetes Bites.
00:05:08
Speaker
and get your 50% off of your first order, plus free shipping. Plus, Nom Nom comes with a money back guarantee. If your dog's tail isn't wagging within 30 days, Nom Nom will refund your first order. No fillers, no nonsense, just Nom Nom.
00:05:26
Speaker
Look, I don't know about you, but inflation has been a doozy this past year, year and a half. And just in April, motor vehicle repairs weigh up, frozen vegetables, if you're into that kind of thing, and pet food. I have a golden retriever at home. I can't keep doing this, or at least I have to be better with my finances. And look, we get it. The market is complicated and confusing. And to many of us, it simply doesn't make sense. In fact, where do we even start? Take all of the guesswork out of it.
00:05:56
Speaker
with The Motley Fool's Stock Advisor. The Motley Fool has been around for over 25 years and has been spot on in recommending some of the world's most important companies before they hit big time. I'm talking about Amazon, Tesla, Netflix, and Starbucks all before they exploded in value. And they're easy to use and super informative service Stock Advisor. You can join the ranks before they potentially find the big thing.
00:06:25
Speaker
After all, their average stock recommendation is up over 400%, and that's of April 10th, 2023. And no need to be intimidated by the financial jargon or market complexities, as the name suggests, these guys don't make themselves too serious.
00:06:42
Speaker
Now, finances, that's a different story. Their friendly and relaxed approach has helped over 700,000 people move closer to their financial independence, all while beating the market and having fun. New members can access the stock advisor for only $89 for the first year, a full $110 off the full list price.
00:07:03
Speaker
Don't sit on the sidelines and think about what could have happened. Visit fool.com slash podcast and use code Kubernetes Bites or visit the link in the show notes. This is $110 discount off the $199 per year list price. Members will renew annually at the current list price and until then Kubernetes Bites send you.
News and Updates
00:07:22
Speaker
Yeah, so talking about news, as we saw in the last episode, again, another couple of slow weeks for us and at least the cloud native ecosystem. But just a few things that I wanted to highlight, Aqua security released their cyber security report for 2023. And they had a few good insights that spoke about like the first one being, they saw an increase of software supply chain attacks. Again, we all know what those are, but
00:07:48
Speaker
the attacks grow more than 300% year over year. So obviously that's becoming a hot topic. And it's the different layers that with the microservices architecture or with the cloud native stack, we have so many layers in the application tier or in the infrastructure layer.
00:08:05
Speaker
that's proving challenging to secure and it's interdependency between different components makes it really appealing to attackers. So even if you miss that one spot, like all you need is the weakest link in the chain and you can break through. So software supply chain attacks was like the number one thing. They also have a list of the top 10 vulnerabilities in from 2022. So if you were not in the same organization 2022, maybe take a look at those.
00:08:31
Speaker
Make sure your organization has fixed those CVs and are not exposed. Basically, all those 10 were focused around the ability to do remote code execution into your environments. Once they get in, they run some code, which is not good.
00:08:47
Speaker
I think one of the key things that I found interesting was 50% of the attacks in this year's reports focused on defense evasion. So even the hackers and the attackers are getting smarter. They know what the typical defense systems are and how they get recognized by these security tools. So they have found ways to
00:09:07
Speaker
go around it and make sure that they're not detected even if they get in. Learning from the techniques that we have in place to secure ourselves. Sounds like AI now is producing and learning from it. Yeah, I can't say I'm surprised, though, given how much this market has grown. We're going to see an uptick in how people try to exploit it. Yeah, I can't say enough about trying to get security mindset first early on.
00:09:35
Speaker
Yeah, like we'll link to the blog and the report that they published. So please read through it. We'll link to a couple of the previous episodes in security too. I think there's a lot of good nuggets in there too. Perfect. And talking about AI, right? Like a new company called Causely, they call themselves a casual AI company. They raised $8.6 million in their seed funding. They are building a platform that automates end-to-end detection, prevention, remediation of critical defects.
00:10:03
Speaker
This is a line from their website. So it looks like a marketing line. They do have a module, which they call Causely for Kubernetes applications. It's now in early access. So again, if you want to try it out, you can. I'm not sure, like, again, it's just seed round, right? Like, so they're just getting started finding that product market fit. But at least the co-founders look like they are CEO entrepreneurs in our ecosystem.
00:10:26
Speaker
have started, founded companies and sold them to AWS and IBM and those guys. So, something to keep an eye out for, whatever with the term AI pops up, I make sure that we include it on a show notes in terms of the funding grounds.
00:10:41
Speaker
And then in addition to these two, not really news, but just links that I wanted to share with our listeners, the PlatformCon event that happened maybe last month has all of their sessions now posted on YouTube. So if you weren't able to attend the live sessions, which I wasn't, you can go and catch up on recordings. And then over the 4th of July weekend, I guess Kelsey Hightower decided to do a Twitter space where he talked about what Kubernetes did to him.
00:11:06
Speaker
And if you follow him on Twitter, you'll see a few interesting tweets over the last couple of days. So I am, I think 40 minutes into the two hour Twitter space. So I'm listening to it, but listening to it. But I just wanted to share it with our listeners as well.
00:11:21
Speaker
Yeah, absolutely. Some good nuggets there. Some interesting nuggets. I guess we could probably bring them up on a totally different show. Maybe just do an episode on exactly what he's talking about or something. Yeah, that would be fun. Maybe get him on. There we go. That'd be great too. No, that's it for news for me. Ryan, audio.
00:11:38
Speaker
Absolutely. So just a couple for me. The one was portainer.io. They announced K2D.io, which is basically a K3S alternative, so to speak. It's a lightweight Kubernetes distribution kind of targeted at low computing power environments, IoT, those kind of things. But
00:11:58
Speaker
There's another option out there besides K3S. I know those types of distributions have been in the uptick as we move things to the edge and all that. Really interesting stuff. The article on here talks about their own testing and what machines they put on, how much memory and all that stuff. If you're into that, go check it out.
00:12:17
Speaker
While you were talking about it, I was curious, why are they calling it K2D? We know the K8S, we know what it means. What is K2D? If they wanted to use four-letter word, why just make it a three-letter word and add that to, and it's actually Kubernetes to Docker, it's not a word. That's my only participation or comment on your news. In the article it says, K2D is not Kubernetes. It says it's an API translator.
00:12:43
Speaker
So alternative to K3S, but yes, not Kubernetes. It's a different type of way of doing things. But yeah, absolutely. Good point. The next one I have is from folks over at SUSE, Elemental Cloud Native OS Management in Kubernetes. Basically, Elemental is a toolkit.
00:13:08
Speaker
aims at delivering minimal enterprise Linux and with OCI and all that kind of stuff. So if you're kind of looking at or probably using Rancher or something like that, maybe something to go check it out. Anyway, I thought it was pretty cool. Also fan of the elemental name, I guess. I like that little rings true.
00:13:29
Speaker
The other one is, I don't know if this is old news or new news, but mission control self-managed from VMware Tanzu. It was an announcement blog, but I basically taken the mission curl SaaS deployments of managing Tanzu and everything and doing it in a way that we can deploy it on-prem or in sort of sovereign kind of
00:13:51
Speaker
deployments and getting the same sort of experience that you got out of the mission control SaaS on-prem. So interesting stuff there, definitely. I think is telling to maybe how companies are definitely looking at where people are running their Kubernetes, so whether it's on-prem or in the cloud or giving them options. And I agree, right? It's not a new thing. I think I went to the last VMware Explorer last year. They announced it in early access or private beta. But it's available now, I think.
00:14:18
Speaker
Yeah, it's now generally available. I think if you have a VMware.com account, you can download those binaries and deploy it.
00:14:24
Speaker
Yeah, cool. So if you're a VMware shop, maybe that's for you. And then the last one, which I did talk about with some coworkers last week, which was NetApp, they launched Spot Ocean CD, basically Kubernetes delivery on top of their Spot kind of delivery already. So kind of taking advantage of how CD plays into the process of how
00:14:51
Speaker
the advantages of spot and ocean and all those things kind of tied together. So if you're already using that kind of thing, we're interested in what spot is and you're kind of in the Kubernetes game and doing continuous delivery, definitely go take a look at the stuff and kind of dig into it. I think it's quite interesting. I've always been really interested in the spot technology. I think it's a really great one. There's not a ton that like
00:15:15
Speaker
you know, compares directly. So to build something on top of that, I think I like that extensibility to how they're using it and how that app's doing that. So go take a look at that. And that's all I had. Awesome.
00:15:27
Speaker
Awesome. The last thing we do want to bring up here is it's a little bit of our own news. Let's go. We have added a Slack workspace. So that's kubernetesbytes.slack.com. If you're a previous guest or listener, come check it out. We have places for you to introduce yourself, talk with us, suggest episodes. That's one place we want to definitely really hear from you. If you're wanting to join our
00:15:54
Speaker
Slack workspace and have ideas that you want to get to us and want to really hear about something, please go say hello and check it out. We also have a LinkedIn page now. So come, you know, be friends with us professionally, I guess. No, I think I like the Slack idea, right? Like we have been talking about it for a while. It just helps bring the community together. Like we have
00:16:14
Speaker
kept these episodes. I know more than 50 episodes as vendor neutral, so we're not there to sell anything. We just decided to make it a place where listeners who are part of the CNCF community or the cloud native community can join in, talk to each other, maybe
00:16:29
Speaker
they have challenges, and maybe somebody else from the community has already solved them. So use that as a place to just collaborate. Just get to know more people. I'm pretty sure we might end up creating a new Slack channel called Job Listing. So if you're looking for a job, and if you are a vendor who's hiring, maybe we can use this Slack channel to bring the two together. But yeah, again, it's brand new. We want to see how it evolves, how it grows. We'll make sure that we have a code of conduct, I think.
00:16:59
Speaker
Be respectable to anyone who is on the Slack channel. But apart from that, feel free to join in. We'll put the link in the show notes, but it's just communitiespipes.slag.com. Join in and let's talk.
00:17:11
Speaker
Absolutely. And we're excited to see you there.
Guest Introduction: Surya Oregonti
00:17:13
Speaker
Speaking of excited, we do have a great guest, Surya Oregonti. I'm hopefully saying that correctly. He's the founder of Argonaut. We're going to talk all about what Argonaut is and kind of the challenges that it's trying to solve in the community and kind of why you started to build this technology. So without further ado, let's get Surya on.
00:17:31
Speaker
All right, Surya, welcome to Kubernetes Bites. It's great to have you here. Why don't you introduce yourself and kind of give a brief overview of kind of who you are, what you do, and what's going on. Thanks for having me. I'm Surya. I am the founder of Argonaut. Just a quick history. I started my career like over a decade ago at Microsoft. I was working on Bing Ads.
00:17:54
Speaker
I was working on the pricing of ads and predicting the probability with which a user would click on an ad, all the creepy stuff. But it was very cool work in the sense that it involved large-scale optimization, a lot of pretty cool machine learning there. Then it was also a very fast-paced environment where we would have super large number of experiments that are going on with a very mature AB testing framework, etc, like peak AB testing.
00:18:24
Speaker
And then after that I moved to a very different domain because I wanted to also move to a startup. And I was building a first-of-its-kind electric scooter. I was leading the software and connectivity hardware, like hardware efforts as well, like touch screens and such. And then, yeah, the startup experience was really, really good, right?
00:18:45
Speaker
work with a lot of really smart people and it was also a huge amount of ownership and responsibility. So I loved that and I sort of went increasingly smaller in terms of the companies that I chose to work with and I worked with a couple of enterprise AI startups after that in the retail and HR tech space and after that I
00:19:09
Speaker
decided to start with a company of one. The smallest of them. Yeah. And currently I'm building Argonaut.
Argonaut's Mission and Challenges
00:19:20
Speaker
Argonaut is an internal developer platform that helps you automate and manage infrastructure and app deployments to clouds like AWS and GCP.
00:19:30
Speaker
That's an interesting background, right? Like going from Bing ads to electric scooters to AI in the human tech resource space. Wow. And just doing that over a decade. So I'm sure you had a lot of fun. I know you said Argonaut is that internal developer platform. Can you expand a bit more on that? Like what does it do? How does it help?
00:19:51
Speaker
Right. So basically, our mission is to make software operations painless for engineering teams so that teams can generally focus more of their engineering efforts on building stuff that their users want, their customers actually pay them for, as opposed to just keeping the lights on, et cetera. Now, that's basically the core of what we do. Now, specifically, given that Argonaut is an internal developer platform and
00:20:20
Speaker
We aim to be the one place that engineering teams can go to manage their app deployments and cloud infrastructure. That's putting it very concisely. And that involves a lot of different things.
00:20:35
Speaker
The way we go about it is we provide some intuitive abstractions and automation of software operations so that teams can generally get started very quickly and also not have to spend too much time configuring stuff and just trying to get things to work. Now, if we actually concretely look at the workflow that users have with and without, traditionally,
00:21:03
Speaker
Companies have application deployment teams which have their business logic and user-facing features and all of that. Then there is the platform team which actually enables these pieces of code to be deployed in a secure scalable manner with all the collaboration requirements and compliance requirements etc. are taken into consideration.
00:21:30
Speaker
Now, if you just break that down, that involves a lot of steps. And each of those steps has its own best-of-read kind of solution that works for that particular stage. Now, essentially, the role that we play is that of an orchestrator.
00:21:50
Speaker
and we stitch all of these things together, all of these different steps and stages so that anyone who's using the product can have a full understanding of what's going on. Just tying that together, these steps that I'm referring to would look like provisioning cloud infrastructure, using things like infrastructure as code, et cetera, picking run times,
00:22:18
Speaker
building code, generating artifacts, scanning and securely storing them, and then eventually deploying them. Then you have the data activities where you have observability and costumes. All of these are things that we bring together as opposed to teams having to build them in-house over a period of time.
00:22:40
Speaker
Yeah, I mean, this is something I feel like we've heard a lot of even from Detroit and even in Amsterdam, right, the complexities that I think the more layers we add on to Kubernetes and everything you need to actually have a fully fledged sort of working thing, it takes a quite amount of time, a quite a lot of different skill sets. And this is something I think we're seeing more and more of.
00:23:04
Speaker
Now, what I'm curious is a bit of your origin story about why you decided to make a company of one. Was it your personal experience doing these exact things or did you also see other companies or maybe users or coworkers struggling through this process? Give me a little bit about that. It's actually a bit of both. If you look at a team like Microsoft,
00:23:30
Speaker
a lot of people just working on this particular problem and making sure that people like most of the application engineers, et cetera, don't even have to think about a lot of these problems, right? You just somehow, magically it just works. And then there are like a million fairies sitting under the hood and just weaving their magic through.
00:23:55
Speaker
And it's actually a fairly complex problem, right? And so that sort of gave me an exposure for what a fairly seamless kind of process would look like. And then as I was working with startups,
00:24:09
Speaker
it increasingly felt to me to also build, you know, pretty much the entire stack out that includes, like I was responsible for managing software and product teams over time, right? And, you know, it was always this very interesting trade off where I would have like a lot of user facing features, et cetera, that we would want to be delivering.
00:24:34
Speaker
And then we would be continuously bogged down by the inefficiencies, et cetera, that we see. And we internally had to build for. That was great. Building that once was a great experience. And then it turns out in pretty much every place that I was working with, the same thing had to build from scratch.
00:24:55
Speaker
And also over the last few years, right, with the advent of Kubernetes and generally everyone starting off their journeys on the cloud as opposed to, you know, a decade ago, where it was closer to a decade ago, where it was more of, you know, you manage your own hardware, etc. Yeah. And
00:25:16
Speaker
Given the shift, the shape of the solution also started looking similar. So essentially we had like underfunded teams and we had like a lot of things to deliver on and the shape of the solution looked similar and we had to build this out from scratch at every single place. So this was a very inefficient mix and that's sort of what led to, you know,
00:25:43
Speaker
figuring out, hey, why don't we just do this, solve it as a product, and make it available for as small as team as possible, and then enable them to have the same kind of efficiency and rigor that larger organizations can afford.
00:26:02
Speaker
Yeah. And head them scale. OK. Yeah. So that's really how it came about. I forget who we talked to, Bob. Maybe you said this, but we had an analogy about once you get big enough where you're operating in a large kitchen, everybody has a different task at hand. And that's the magic that happens that you take for granted until you're on a smaller team and trying to do it all yourself. You have all those skill sets now that you must all do from scratch to finishing and plating and all those things. I thought that analogy was pretty good.
00:26:32
Speaker
Yeah, I feel like this is a really cool space to be in, and it's exciting to see what Argonaut's up to.
00:26:39
Speaker
And so, Surya, the problem that you've identified definitely exists in the ecosystem today. Startups, especially, who are starting with their journey need a tool so that they can spend time on delivering business value and differentiation and actually make their beer taste better and not focus on actually delivering an infrastructure stack. But I want to also talk about the other perspective, where larger enterprises, not everybody can be a Microsoft, but
00:27:08
Speaker
since you have been at Microsoft, I'm sure there was not just a single IDP or a single platform. Each team, each business unit might have its own platform that they're using. And when I talk to customers as part of my day job, again, everybody likes to talk about platform engineering and that one solution, but that's not true, right? You might have 10 different platforms, quote unquote, that you use to deliver developer services to your end users, which in case are developers. How does Argonaut fit this use case? How can it help bigger enterprises
00:27:37
Speaker
which already have these different teams and different organizations working on individual platforms.
00:27:46
Speaker
a couple of different facets here. I'll preface this with the fact that we deal with mid-market customers and not too much enterprisey at this point. Because of that, we've avoided this problem for a little while. However, there are a few things that we're putting together in place to ensure that we don't
00:28:12
Speaker
When we run into these situations, we don't hit against a wall. Primarily, one of the core things that we do is try to make everything on industry standards. In some cases, there are no standards as such, at which point we pick the most popular
00:28:35
Speaker
tool of choice for that particular problem and go with that. Now, this affords us a good standardizing layer, which means that things can flow in and out of the system, out of the Argonaut boundary very easily. Now, for instance, this could be things like the fact that
00:28:56
Speaker
we use Argo CD to power our GitOps related deployments. There are like two players who are sort of the more popular ones in this space. And we picked the one which we thought was more flexible and was generally a little more broadly adopted.
00:29:14
Speaker
This is Flux and Argo, basically? Yes, Flux and Argo. And so that's one example. And then when it comes to infrastructure as code, there are a couple of different providers that work. We've chosen Terraform because it's sort of the de facto. And pretty much everyone else has very unique propositions, and they're very interesting. And we'll probably expand out to support more providers over a period of time, et cetera.
00:29:42
Speaker
So as a product, we are trying to ensure that our boundary is fairly permissive. And along those lines, we are also making it modular. So making sure that as a product and as something that promises to cover the entire breadth of these operations, especially for something like a startup,
00:30:09
Speaker
we are required to do a lot of things, starting from automatically generating CI configurations on top of CI and CD configurations on top of your provider to automatically generating infrastructure from templates, Terraform templates that we provision, et cetera. Now, a lot of larger organizations do not want this and do not need this.
00:30:37
Speaker
because they have some kind of processes in place already. Maybe for new initiatives, they might refer to this kind of an option, which is sort of big out of the box. But, you know, we do have the flexibility of just choosing a part of
00:30:56
Speaker
of the entire stack to work with, which makes it much easier for adoption, right? No, I think it makes sense, right? Like startups definitely need the most help because they don't have five or 10 years of platform engineering teams that have been around and built something internally that's...
00:31:12
Speaker
custom and native to how things work inside that enterprise. Startups are definitely figuring things out. And with this modular architecture, again, they can start with a single cloud provider. They can start with Terraform. They can start with Argo CD and get up and running. And then, as you said, they can plug and play. They can maybe switch things around if they wanted to try out a different infrastructure stack. So I think that the description makes sense. Where this tool is mainly focused toward startups, enterprises can still use it if they're starting something new.
00:31:40
Speaker
and want to use some of these newer cloud-native technology stacks. Thank you. That makes sense. Something that we do see people using us for is the onboarding onto Kubernetes. When you
Argonaut's Solutions for Kubernetes
00:31:58
Speaker
don't have something to begin with and then you're starting off on that journey,
00:32:02
Speaker
for one particular product area or one particular environment as a pilot or whatever. And that's sort of where we make things very easy by essentially being an IDP, which also does things. Like it's not just a view layer, but it's also an action layer. So it's a mix of those two that we bring to the table.
00:32:29
Speaker
Now, you mentioned onboarding onto Kubernetes as being one of the main use cases. What are some other ones? I know bootstrapping startups or small companies, do you see people using this type of tool in a specific way? Say they're new to cloud deployments and they want to get started on GCP. Give me a little bit more about the use cases.
00:32:50
Speaker
Right, so if you look at how the landscape looks like today, right? And let's look at like the smallest of startups, which we are just starting off. You have maybe like a front-end repo, a back-end repo, maybe just one repo for both, right? And one service for both more importantly.
00:33:13
Speaker
When you have something like that, pretty much everything becomes overkill. Even if you're just looking to deploy to something like an ECS or something, it starts becoming more hassle than actually just getting that first line of code out there. It's a very weird problem because where the landscape looks like,
00:33:39
Speaker
There is something that is really well suited for the smaller teams, smaller, like lesser complexity. And then there's something else that works entirely for a different place in the spectrum.
00:33:54
Speaker
So when folks are starting off, you usually have something like some kind of an app runner, like a Heroku or something like that. People start off on that. And then eventually there are additional requirements that come in, like storage buckets and queues and managed services around Kafka, et cetera.
00:34:13
Speaker
So when all of these start piling in, that is when folks realize, okay, we probably should move to a full flowered or something like that. In some cases, people start off with something like a beanstalk or just a container runner, and then realize that they have workload limitations, they have capacity limitations, etc. They are looking for a more fully fledged solution.
00:34:39
Speaker
So that's actually one very common use case that we see, where folks are just migrating onto the most powerful substrate that you can get to, which is Kubernetes. And in many cases, it's also not explicitly, hey, we want to get to Kubernetes. It's like, I'm going to sort of solve
00:35:04
Speaker
solves that ceiling limitation while also providing a fairly flexible and easy to use interface. So that's one. The second one is actually a little more interesting, and this is not something that we had designed for.
00:35:23
Speaker
It's funny to see people use it this way. They'll always use it differently than you designed. Since we also provide this kind of a cloud abstraction layer.
00:35:36
Speaker
Companies, essentially, in their first couple of years use AWS or something, or GCP, use their credits. And then, eventually, they're like, OK, we are getting another $100,000 for free. Let's just switch. And given that Argonaut sort of normalizes that layer, it makes it very easy. And we saw a bunch of customers doing this, which was very interesting to note, but not something that we had foreseen when we had started buildings out.
00:36:06
Speaker
So you're talking about using multiple clouds in this case, because you're sort of a layer on top? Yes and no. So it's not really multiple clouds at the same time, but essentially shifting from one cloud to another cloud.
00:36:22
Speaker
Okay, yeah, so making it easier because it's the common layers on top of it. Right. Well, you could use it in any way, like the product doesn't really limit you, but that's what we saw people doing primarily. Yeah, I know a use case. Yeah, exactly. I mean, I feel like that use case is something we talked about when cloud first came out is like cloud enables you to do these kind of things, but then the reality was
00:36:44
Speaker
You got locked into a cloud because of all the specific tooling, right? So maybe this is sort of a, you know, we're seeing kind of a realization of how to do these kinds of things. It's interesting, but yeah. Gotcha. So I know you said the one keyword and I'm surprised that Ryan didn't pick it up. Like you said people are using Heroku and I also saw. I always talk about Heroku because I used it in the past.
00:37:08
Speaker
And I really enjoyed it, but it definitely was, you know, it's like, you know, the commonalities and the parts that are missing are quite interesting to where we're at now. Yeah. And on your documentation, Surya, you have a section dedicated to how users can move away or migrate from Heroku onto Kubernetes. Is that happening? Is that like, are people like Ryan who have used Heroku in the past now thinking about Kubernetes and how are we helping them?
00:37:30
Speaker
Yeah. Um, so that, that actually is happening a little bit, um, uh, primarily because, uh, of what Heroku is doing to itself rather than, uh, what we are, what we are doing to pull, um, we're just making it easy for people who are looking for alternatives. Right. Um, so.
00:37:53
Speaker
Heroku, while it has an amazing developer experience, can't be beat. Because when you have complete control over everything from the runtime to the user experience layer in terms of what workload you can build on top of it, et cetera, and all the ways in which you can interface with it, as opposed to explicitly taking a delineation on, hey, we will be working modularly with
00:38:22
Speaker
Kubernetes and platform ABC, whatever. There is a more integrated experience that you can provide, and Heroku does a great job. And app runners are great for that reason. And one of the reasons why smaller teams also start off on that.
00:38:37
Speaker
So, that's definitely there. So, in terms of what we do to make that easy, we support the same build packs that Heroku does. So, you can, you know, you don't even have to worry about containerization as step one. It's not a blocker, really, right? And then we
00:38:57
Speaker
We are sort of limited by the half an hour that AWS and GCP take to spin up Kubernetes clusters. But apart from that, it's almost as simple as what you would do with Heroku, where you essentially push to deploy.
00:39:16
Speaker
On the other side, we do have a lot more flexibility, especially when given that we have the full power of things like Ingress controllers and API gateways, et cetera. So there are some weird use cases where you need specific certificates to be used because of certain requirements.
00:39:39
Speaker
business case requirements, et cetera. And all of those kinds of things are much easier to do when you're dealing with something like Argonaut. Okay, makes sense. And I think Ryan found this out when he was going through your documentation where you say,
00:39:53
Speaker
teams or organizations don't realize that they are spending 30% of their time on infrastructure wrangling. Again, to me, personally, that feels like a lower bar, a low percentage. I've seen around the 70% mark where, again, this number doesn't apply to just the new stack, the Kubernetes way of doing things, but traditional infrastructure admins as well, where 70% or more than their time was gone on just keeping the lights on, making sure that the infrastructure is up and running. With this new way of doing things with Kubernetes, with all the cloud native technology,
00:40:24
Speaker
Where do you think this last time is and like, what does this actually mean? How can we give them the time back and expand a bit more on that?
00:40:34
Speaker
I can talk about it in like two ways, right? One is what the workflow looks like and where the time is going in. And the second is like what can we do about it, right? So if you look at where the time goes, so things like setting up and managing environments, they take time, especially the stable environments. And then
00:40:58
Speaker
If you want to build out tooling which enables things like preview environments or like spinning up environments on demand, that's a whole other ballgame. Because you require overlays, you require specific things to be fixed and specific things to be configurable. Domain names, etc. like DNS etc. are always going to be a little bit of a pain.
00:41:22
Speaker
So just setting up this kind of stack is a multi-month, if not a multi-year effort for a team. So there's just one part of it. Getting visibility into deployments, and especially cost visibility, is sort of not a thing at this point. We're just, as an industry, just starting off on that journey, where we have really good cost visibility into
00:41:50
Speaker
and attribution into where specific cloud dollars are being spent. And even today, for instance, it's very hard to get a handle on egress costs, egress costs, bandwidth related stuff.
00:42:09
Speaker
on even the major clouds. Then debugging is another piece that it's a bit of a mess, but it's also fairly templated in an organization. So in the sense that every organization has a bunch of
00:42:31
Speaker
a specific type of failure modes or a specific set of failure modes and you go through that checklist and you're usually okay. But discovering that and putting that together is going to be a bit of a challenge. Then maintenance is like a biggie, which sort of sneaks up on you. This is what I see most people not accounting for on day one, which is,
00:42:57
Speaker
you know, Kubernetes versions keep getting deprecated like every year, a year and a half. And then with that API changes, et cetera, come in. Your application stacks, all the tool sets that you depend on, right? Starting from ingress controllers to certificate management to everything else.
00:43:17
Speaker
All of those require continuous upgrades to essentially be secure and for teams to leverage the best and greatest. That again takes a significant amount of time. So what we try to do is essentially understand all of these and put in mechanisms to
00:43:44
Speaker
For instance, automate a lot of these processes out. For instance, when it comes to Kubernetes cluster version upgrades, we have mechanisms to detect what APIs, if any deprecated APIs are being used and by what tools, figure out an upgrade part for them.
00:44:05
Speaker
and then automatically manage the cluster upgrades as well. Sort of possible easily because we don't just provide a view layer, but we also control the workloads on top to an extent. So those kind of things are capabilities that we deliver on from day one, which sort of makes teams a lot more efficient. OK, so I'm not is basically allowing these admins or DevOps admins to
00:44:35
Speaker
not just automate day zero operations, but also help them simplify some of the day two operations like debugging and monitoring with their observability and visibility stack. So, okay, that makes sense like being that platform, right? It's
Support and Future Plans
00:44:49
Speaker
helping day zero and day two operations.
00:44:51
Speaker
but I wanted to know about the tech stack itself. I know we love Kubernetes on this podcast, it's Kubernetes Spites, but rarely do organizations have just one infrastructure or application stack. They might have a combination of apps running on EC2 instances. Maybe they have modernized some applications to be serverless even. Can Argonaut help me orchestrate Lambda functions, for example, just using this IDP or is it just restricted to Kubernetes?
00:45:19
Speaker
Right. So we we do not deal with.
00:45:25
Speaker
direct virtual machines, but we do deal with Lambdas and Kubernetes as the substrates that we support at this point. We've been tying around with providing Knative, for instance, as a first-class citizen, where it's still on Kubernetes, but it's also a little bit of a different beast.
00:45:49
Speaker
the kind of interactions that developers would have with a K-native enabled Kubernetes cluster is going to be slightly different. So we are going to be adding these over time, but at this point, until we saturate this out, we're probably going to stick with Lambdas plus Kubernetes as- Well, you have so many employees. I don't know why you just keep- Come on, keep-
00:46:21
Speaker
We want more. Depends. We're definitely open to all of these enhancements and we've thought about it, we've talked about it internally. It's just a matter of sequencing this out in terms of value and impact. Absolutely.
00:46:40
Speaker
I want to switch gears a little bit and talk about what happens when you see teams tackle things on their own. A little bit about anti-patterns, and I know we talked about this in our intro call a little bit. What are some of the things that you find, these DevOps teams or teams putting together these pipelines themselves, create poor practices or anti-patterns that you see in that ad hoc approach where someone with
00:47:07
Speaker
somewhat of a skill set or a really good skill set over here kind of put everything together. What does that look like? Well, the thing with the anti-patterns, the most common anti-patterns is that these are enabled because
00:47:24
Speaker
they're just the easiest way to do things. And in some cases, it's not the wrong thing to do. On day one, you don't want to be set, before you write your first line of code, you don't really want to be setting up a very vast Terraform script with Kubernetes spun up and all of that. You first want to get to an MVP and product market fit before you start looking deeper into tightening these nuts and bolts.
00:47:53
Speaker
So there are usually very good reasons for this and the reasons also tend to be, you know, a path of like history kind of thing, right? Where it's the evolution and what is right at each
00:48:10
Speaker
local phase in the evolution of the company might not necessarily be optimal if you just look back, right? So it's easy to call them out as identifier terms, but to be fair, there's usually a reason why that happens. That said, that's something that we try to tackle and we try to
00:48:30
Speaker
ease for our customers, because we try to get the end state, but with the ease of not having to worry about the path-related dependencies. Would you say that it's more of a team start off on a path to get something out the door, to kick the tire, so to speak?
00:48:52
Speaker
And then it's harder to backpedal out of that once they've kind of developed a way of doing things, right? And I've seen this in sort of security practices too, where security is always like, well, just get me the RBAC and everything else that just makes my thing work, but they put less thought into it. And then it's they have to figure it out afterwards. Is it similar to that? Exactly. So it even starts more basic than that, right? Like a bunch of custom, like a bunch of prospects, they even
00:49:22
Speaker
I have conversations where the current deployment practice is essentially for a team of 20 to 50 engineers to actually just go to an EC2 instance, do a Git pull and do an NPM start or something like that.
00:49:39
Speaker
it works until it doesn't. It stops working when you have a lot of people trying to do this in parallel. That's sort of when it starts breaking down at which point. It's also a little difficult to move out of because
00:49:58
Speaker
When you're used to this kind of a model, because of the flexibility it affords, you also start looking at, hey, here are some shared files between my front-end and back-end for, let's say, some interfaces or some API signatures or whatever. Because that is enabled, there is some kind of auxiliary coupling that happens. So moving out and containerizing it actually becomes an effort.
00:50:26
Speaker
So this is something that I've seen multiple times over, especially when working with startups, et cetera. It's definitely faster when you're getting started than containerizing and moving with it. But you sort of pay the price down the line.
00:50:47
Speaker
Then the other anti-pattern is when teams internally realize that this is happening. Then they dial 11 on the other side and build overly complex architectures, which is more of an emulation of what internet scale companies require rather than what is required for them at
00:51:14
Speaker
for the next few years. Potentially, that is again a fairly costly affair because of
00:51:24
Speaker
things like introducing service measures when you have five to 10 services. It's both an overhead in terms of management and also in terms of the net costs that you'll end up having to pay for the same effective resource utilization. That's a second kind of thing that we notice. And as a part of,
00:51:53
Speaker
our interactions with companies. We also try to talk to them about what the pros and cons of what they're trying to do is and potentially suggest the right kind of approach given an understanding of their requirements. So it's a little bit of a consultative thing as well if the customers choose to do that so that we can provide our perspective and then they can figure out what they want to do.
00:52:20
Speaker
Got it. Makes sense. So really, it's like, you know, process in terms of certain situations can lead to like some practices that are hard to pull out of. Another part of it is inefficiencies, which sort of lead to, you know, have have a direct impact on cost and kind of how things are handled there. And thirdly, it's just about like planning and communication.
00:52:38
Speaker
I feel like, you know, that's probably quite common in a lot of teams. I know I've been part of teams just like that, especially earlier on, but it's good to see these kind of things, you know, are sort of known now, at least, or at least hopefully better known now. Yeah. Excellent summary. Yeah, I'm good at this. And yeah.
00:53:03
Speaker
The fact that we shine a light on a lot of these is actually the step one to resolving this. As an industry, I think we're getting to a good place there, but we also have a little ways to go and it's always. That's fair. Moving on. I know when we spoke last time, we spoke about Dagger.io and I didn't know about Dagger.io and nothing existed.
DevOps Processes and Innovations
00:53:32
Speaker
Can you talk more about what it is and how does Argonaut use it to actually help solve some of the CI challenges for customers? Right. So diagonal.io is an amazing project, specifically because it works as a CI abstraction layer, a CI agnostic layer where you can define your workflows, you can define your
00:53:58
Speaker
CI workflows without being tied to a CI provider. So it's great that way. And you write it in code. There are a bunch of SDKs available for it. We are internally, predominantly, Golang. So we use the Golang SDK for it. It's great because you can write once and deploy it anywhere.
00:54:24
Speaker
There are two benefits, one for teams that are generally adopting it, where you can essentially do the same thing, run the same thing on your local as you would run on, let's say something like GitHub Actions or GitLab or Jenkins or whatever. There is that translation, which makes it easier for testing and for faster iterations.
00:54:48
Speaker
That's great. Now for us, it adds another level of value because we can write that logic once for our customers and have it available on multiple CI provider. We don't have to replicate our logic, we don't have to replicate and maintain differences and so on. That makes it super easy.
00:55:15
Speaker
It also enables for us things like a drag and drop UI builder for CI, where you can just drag a few nodes and connect them together, et cetera. So things like that, because we can internally generate that as code and pass it on. There's a lot of the teams to use the CI tool directly once DIGO is used, or do they have to use DIGO afterwards? Or is it just the abstraction that helps you deploy different ones?
00:55:46
Speaker
I'm unfamiliar with the tool. I love it, by the way. I learned it talking to you last time. It's very cool. Right. And by the way, this is by the same folks who started Docker. So it's essentially standardization, but for CIs. I think that philosophy is definitely reasonable.
00:56:08
Speaker
I forget who it was. There is no, someone who said, there is no problem in computer science that cannot be solved with another level of intuition. Yeah.
00:56:24
Speaker
To answer your question, you would be reliant on the dagger.io SDKs because you're essentially defining all your logic as not YAMLs that are specific to GitHub action language or GitLab CI language or what have you. But you're essentially writing them in Golang. And you are using the dagger.io primitives and the SDK to do it. And so the end user, a customer in your case would have to also do that.
00:56:53
Speaker
We actually do that for our customers and we enable drag and drop UI builders and stuff like that to make it easier for them. But they can choose to do that as well. The integration point is essentially like a
00:57:10
Speaker
a stub that you would be plugging into your GitHub workflows so that it actually runs. That's about it. Okay. Makes sense. Well, we do want to give you the opportunity to let people know where they can find out more and stuff like that. But before we do that, we have a small part of our show that we basically asked chatgbt to come up with a question about the topic that we're talking about with our guests, which is you today.
Humorous Segment
00:57:33
Speaker
And we asked this question about sort of a DevOps and automation environment, and it said, given the complexities of managing multiple cloud environments, if you were to compare DevOps and a multi-cloud environment to a roller coaster ride, what would be the most thrilling, the most terrifying, and the most unexpected parts of the ride?
00:57:52
Speaker
So you can answer it, or we also let Chad GPT answer it itself. I'll take a stab at it, but I'd be curious to understand what Chad GPT says as well. The most terrifying thing is almost certainly network costs.
00:58:08
Speaker
Okay. When you're dealing with inter-cloud communication, etc. Sometimes even inter-availability zone and inter-region costs can skyrocket. And that kind of problem only
00:58:23
Speaker
compounds with multi-cloud scenarios. It's very important that you design for these from day one property. The thrilling part is to actually be able to leverage the best of multiple clouds. Specifically, for instance, Azure has a managed open AI service, which is great. From what I hear, it's more performant than
00:58:53
Speaker
the OpenAI offering directly that consumers would directly get. The ability to mix and match something like that with something like BigQuery, which is, again, unique and amazing in its own right, and potentially the stability of some of the services that you get from AWS. Having the ability to mix and match these things is amazing.
00:59:20
Speaker
And so long as you're okay with the side effects that come in. As long as you make it back to the starting point after you roll against the side. Yeah, you don't want to fall off a cliff. Yep.
00:59:37
Speaker
That would be the most exciting and the most terrifying parts of that ride. I think you nailed a couple that it actually came out with. In terms of expenses and cost, it actually said that that was the unexpected part of the ride. Basically, hidden costs and performance issues, surging and twists and turns in the roller coaster compared that to that.
01:00:02
Speaker
The terrifying part it said is security and compliance. It said, you know, it's like the drop, the sudden drop in the roller coaster. Eat your applications, secure costs of platforms. And then the thrilling part, it actually talked about initial setup and deployment, right? The exciting sort of climb to the top that it said. So I think you hit on a couple of things that it also hit on, which is, you know, it's just good. But I have a question. Like if it's unexpected, the costs are always categorized as unexpected. What point can we see that they are expected?
01:00:33
Speaker
Well, you know that the costs are unexpected because you don't know the magnitude of it, but you know that there are going to be there. You don't know if it's going to be a thousand bucks or like a million. Yeah. And you're like, didn't know how steep that drop actually was.
01:00:50
Speaker
Cool, cool. Well, Surya, if you have anywhere you would like to send someone to find out more information where they can find you, interact with a community you might have or docs, this is the time to spit it all out. And then we'll put them in the show notes as well.
01:01:03
Speaker
Oh, amazing. So our product is free for anyone to sign up and try out. And we have a basic free tier as well. And you can access that on our website, argonaut.dev. That's A-R-G-O-N-A-U-T.D-E-V. And, you know, I'm available on
01:01:24
Speaker
Twitter and LinkedIn. And my handle is my first name followed by last name, which is Surya Auruganti. And I'd be happy to connect with anyone and give them a tour of the roller coaster ride. That's awesome, man. And again, just to recap a highlight, I think yesterday you shared on LinkedIn that Argonaut made all the way to number one on the Hacker News list. So kudos, and hopefully we keep pushing that boundary.
01:01:53
Speaker
Thank you so much. And yeah, can't make it happen without the love of all our customers. Absolutely. And Surya, thanks for coming on the show. I appreciate it. It's great being here. Thank you for having me. All right, Bob. And that was a fun conversation with Surya. I think this is sort of the second episode we've done in a row, sort of on this type of technology.
01:02:15
Speaker
I actually like that we did it that way we kind of got to see kind of the different approaches and sort of, more or less, I was more interested to see like why did they create these companies right why is this problem being solved and, you know, a challenge for other folks and I think for
01:02:30
Speaker
it's really just like that need of the abstraction, right? Things are getting quite complex. There's a lot of layers. If you're to roll your own Kubernetes or even use sort of a cloud-based sort of managed offering, you still have to kind of tack on a lot of things to make it, you know, quote unquote production ready or something you'd want to keep that full, you know, cycle of development and releasing and all that stuff. There's a lot of things you got to tack on, whether it's a service message or GitOps platforms or, you know,
01:03:00
Speaker
you know, security components or whatever it may be, there's a lot going on. So I definitely see how this tool is intensely useful when you're starting out, right? I think it's definitely, for me, you know, coming from a larger company, I think it'd be more challenging maybe to kind of weave it in. But I think both of these scenarios, it sounds like a lot of this can be a little bit flexible.
01:03:22
Speaker
So the abstraction kind of over top of those managed offerings or even your sort of, you know, wherever you want to set things up, that's, I think, key to enable kind of the full workflow wherever you want to get going. I don't know what you thought about it. No, I think I agree with you on the first point, right? Like this is, it was great that we had Cube first and Argonaut back to, on back to back episodes that talks about the theme that
01:03:44
Speaker
Kubernetes is de facto standard, Kubernetes has crossed the chasm, all those buzzwords. But we are moving towards a point where Kubernetes is boring and even the startup ecosystem is figuring out or thinking about what else we should be solving. And this is a definite pain point for new organizations and new startups that are just starting up and building their applications on the cloud native stack.
01:04:04
Speaker
If I'm a two-person company, should I spend three months just figuring out all the different open source projects and build something? Or should I just use something like an Argonaut IDP or a Cube first deployment and deploy something and just start working on an application? Yeah, unless you find pleasure from that pain or something like that. But it's not your company. So even if you find pleasure, don't work on it. Come on, guys. We can be better.
01:04:32
Speaker
But even for larger organizations, I remember when I used to work for a previous employer, they had, it wasn't called an IDP, but they had a system where users can go and request for virtual machines, which basically deployed things on their back in VMware and OpenStack infrastructures. And I left before they modernized into delivering Kubernetes clusters. So I think at that point when I was leaving, it was in a process where the developers were still requesting for virtual machines and deploying their own Kubernetes clusters.
01:05:00
Speaker
I'm sure that there are organizations that move slowly and they haven't gotten to a point where they're deploying all of these things for a developer. They're not deploying a multi-run solution with GitOps and with different components installed. I think if you are a team that's
01:05:17
Speaker
on that bleeding edge, want to adopt these new technologies. Even if you're inside a big organization, maybe these kinds of tools can help you get started faster and improve your value, like value of the work that you're doing faster. Maybe you get more investments based on that. So I think I like the approach where these vendors are going or where the past few guests are going, where let's just make things really easy for developers and see where it goes. So I'm excited. I also like the fact that
01:05:44
Speaker
There are startups that are using the cloud credits from different vendors intelligently. So like maybe they can get started on AWS and then they realize that, oh, Microsoft just gave me a hundred thousand dollars. Why not take my entire tech stack and move it somewhere else? So I think it's no easy feat, right? So I feel like you need something kind of like either build something like this or, you know, take advantage of it.
01:06:04
Speaker
I think that's taking us back to your point about abstractions. If you have an abstraction, the infrastructure layer becomes plug and play. It always comes back to abstractions. At the end of the day, any technology problems, you're just going to find out it's just an abstraction later on. We've talked about this months and months ago that
01:06:25
Speaker
you know, that problem of Kubernetes, the landscape being very complex, even too complex for scenarios where, you know, the answer is don't use Kubernetes. And I've actually seen a lot more of that come out lately. And people are realizing that don't use Kubernetes is a very realistic option that people should do. Right. Yeah. Because you can go down a very big rabbit hole unless you're kind of taking on sort of building the platform and, you know, anyway, using something like this. I feel like there's a couple different routes that the community is taking, which is like,
01:06:54
Speaker
just don't use it or, you know, solve the complexity with a tool that'll build up all the pieces, right? Or at least get you 80% of the way there. I think that's kind of the way I feel about these tools is it'll probably get you most of the way there. Um, but every organization is to be slightly different. You know, as we all know, right? Like the last mile is the, the most difficult part of any delivery or any, any application delivery, I guess, for that matter. So these tools can get you that 80%, 90% there, but you'll still have to customize things, but it's better to start
01:07:21
Speaker
at that 80% mark or that 90% mark. If somebody tells me to run a marathon, if they are dropping me at the 23rd mile, I'm like, yeah, let's do it. You have an option. Let's start a startup. We give everybody beer for the first 23 miles and then the last three miles or whatever, whatever's remaining, they can just manage on their own. That's two kinds of marathons in one, I think.
01:07:49
Speaker
Awesome. Well, anyway, fun episode and we have a bunch more fun ones coming up in the future, but I think that closes it out for this episode. Thank you for listening. And that brings us to the end of today's episode. My name's Ryan. I'm Bobbin. Thanks for joining another episode of Kubernetes Bites. Thank you for listening to the Kubernetes Bites podcast.