Ep. #129, Standardizing Orchestration with Surya Oruganti of Argonaut

Brian Douglas: Welcome to another installment of Jamstack Radio, on the line we've got Surya Oruganti. Welcome to the podcast, how are you doing?

Surya Oruganti: Thanks, Brian. I'm doing well. How are you?

Brian: I am doing perfectly fine. You're on the podcast to talk about Argonaut, but usually I have folks introduce themselves to the podcast. Do you want to tell people who you are and what you do?

Surya: I am Surya, I am currently building Argonaut. But I started my career about 11 years ago at Microsoft, and I started off on Bing Ads. I was working on the pricing of ads and the prediction of the probability with which users would click on a particular advertisement and stuff like that. This involved large scale optimization and machine learning, and it was a very cool environment to work in, it was very fast paced.

We'd be running a ton of experiments each day, and that was also a very mature framework for running things like A/B tests, et cetera. After that I moved, like I wanted to, to startups and I also moved to a slightly different domain. I built the first of its kind electric scooter that you can sit and ride on, et cetera. I was leading the software and connectivity, hardware related efforts there. Connectivity, hardware includes things like touch screens and stuff.

Brian: Was this one of those scooters you pick up in the city and just go ride around, or was this like you buy the scooter and then it happened to have a software play?

Surya: This is something you buy and you own. This was meant for the Indian market so it was also very low cost, but high functionality and high bar kind of a product so it was a very interesting mix, too, both to develop for and to product manage for.

Brian: Was it successful?

Surya: Yeah, so it's currently valued at a half a million dollars and there are tens of thousands of them being owned and used every day. Yeah, I think it's going well.

Brian: Yeah, sorry to derail you. I got curious about the scooter thing, but I know you've done way more past the scooter stuff. So yeah, continue.

Surya: Sounds good, not a problem. I'm always happy to talk about this one. Specifically I like talking about this because it was also my first run at a startup. I was working there and I loved the amount of ownership and responsibility that I got to take on, so that was really great.

It was also very refreshing. In a larger company you're usually focused more on the depth of a particular smaller problem statement, and in the case of a startup there was a lot of breadth that we'd be dealing with as well, and that was great.

After this, I worked at a few more startups, increasingly smaller in size, but these were enterprise AI related startups in the retail and HR tech space. After all of this, I decided to startup on my own and I'm building Argonaut. Just a quick thing about Argonaut, it's an internal developer platform that helps teams automate and manage infrastructure and application deployments on their cloud.

We are essentially trying to make our software operations painless so that engineering teams can focus on building features and add customer value, instead of spending months and years on building a software orchestration platform.

Brian: Yeah, which is a common... I worked at a Microsoft owned company, GitHub, and trying to navigate as a non-engineer... Well, sorry, I'm an engineer but I wasn't an engineer by title at GitHub so I didn't go through all the proper training of how to deploy and orchestrate things on my own.

But their systems they built were all in house built and you had to be there when they were built to understand how they worked. So I appreciate things that you're building, which is Argonaut, to give that same experience but a little more clear for companies that are not Microsoft and GitHub and et cetera.

Surya: Right. That's actually the origin of how I got about started building on Argonaut, which is really large companies have the luxury of spinning up a decently sized infrastructure team which makes it efficient, which automates all of this kind of stuff. You push a code and there are automatic checks done and whole bunch of processes which kick in, and eventually you see everything that is running.

Now, not everyone has the luxury of spending so much time and so much effort on just this piece because they're usually and rightly so, focused on building features that their customers will end up using and paying for. So what we decided to do is to essentially standardize this kind of a product, standardize this kind of orchestration, productize it and make it available for pretty much anyone to use and benefit from this kind of automation.

Brian: Yeah. It's a pattern that you see. Folks who work at larger organizations, and even if you come out of a startup that sees success, even the scooter company, you solve all these problems that are not the main business problem which is building these operation platforms for your DevOps, your hosting and platforms.

Sometimes you get lucky and you get someone who comes out of that company that builds it for everyone else, and I appreciate you working on Argonaut to then share that experience with other folks because it's one of those things you don't realize you're going to have a problem with the orchestration or all these things that you deploy until you do.

For having that experience that you're sharing with other folks through this platform, yeah, there's not an on ramp. So what's the story? I did see YC in your background as well, what's the story of you made the decision to do Argonaut, what's the origin story there?

Surya: So firstly, you hit the nail on the head with the previous thing that you stated which is you don't have a problem until you do. This kind of thing sneaks up on you because one day things will be working, and the next day everyone's head is on fire. I've been through that a couple of times. Just going back a little bit, I've always been straddling engineering and product throughout my career, and I worked as a product manager, I led product engineering, UX design teams over 11 years.

At the startups I worked at, one of the things that I've consistently been responsible for is the software infrastructure side of things, apart from a few other pieces. I've helped build that from scratch a few teams and that's actually how I got started with the idea of Argonaut as well because--

In the last few years, especially as companies are beginning to scale, et cetera, there is some kind of a convergence that's happening in terms of the kind of toolset, in terms of the kind of processes, et cetera that end up being utilized.

What I'm talking about specifically are the fact that pretty much everyone now takes the cloud for granted, right? Like hyperscalers like AWS, GCP, Azure, et cetera. When you're building on top of that, usually the cloud providers give you a ton of building blocks like Lego that you can assemble in any kind of manner so that it fits your use case, and that's great and it's the most generic form of compute and storage and all the basic blocks that are afforded to you. It's amazing.

However, over the last few years, something interesting has been happening which is convergence into, let's say, Kubernetes as one kind of a runtime. Pretty much everyone, beyond a certain scale, and when some kind of complexity threshold, et cetera, is reached people start adopting Kubernetes. Now, that's like a nice standardizing layer, and then there is the rise of generally cloud native technologies and a standardization of deployment processes as well in terms of what is desirable.

All of these mean that the kind of internal tooling that we build out ends up taking this similar shape across different companies, and here's the kicker, inevitably this is something that has to be built from scratch in house and it's also done by a team which is usually underfunded because it's not a money making function, overworked because it's a small team that has a large set of things to actually put together.

So it's a very interesting problem, and a tough spot. This is not even talking about the fact that there's a high amount of skill and knowledge that is required just in terms of information, in terms of what the best practices are, et cetera, which will not come and bite you somewhere down the line. So all of these mean that there is a reasonably large investment that is required before something happens, before teams can actually start having a mature deployment pipeline and workflow orchestration. That's how the whole thing got started, and that was the set of pain points that we set out to solve for.

Brian: Cool. Yeah, so how do folks start using Argonaut? And how's the ideal person to reach for this?

Surya: Right. So at this point we are primarily looking at startups, and startups basically with some kind of a complexity, some kind of a desire to scale. Typically our customers are engineering teams of sizes about 10 to 50, 60 people in size, and these are folks who have a desire to scale, end up building on top of something like AWS or a GCP.

One example of the kind of users that we end up seeing is an IoT company, they provide end to end IoT device management solutions and they've grown from just a handful of people on the team and just a handful of services that they were managing, to 10 plus environments that they manage across multiple cloud accounts, across multiple clouds.

They've grown about 10X in team size as well, all without having to have anyone dedicated for DevOps or infrastructure platform engineering in house because Argonaut takes care of a lot of the work for them. Now, that's just one example, and this is interesting because of continuously streaming data and high availability and uptime requirements. We do have customers in a variety of domains, starting from healthcare to fintech to IoT to good ole SaaS.

Brian: Yeah, and so it's that someone is already using a cloud provider and wants a better interaction using Argonaut?

Surya: We actually see a couple of different on ramps when people starting wanting to use some kind of a product like this. One of the common ones is something like a Heroku or one of the other PaaS providers. They're usually a little limited, at least in their current state, and when there are requirements for a lot of other managed services. Let's say database SKUs, something like a Redis or a Kafka, or more ML based workloads.

So when all of these kind of requirements come in, then usually we see a desire to move to a full cloud, a hyperscaler like an AWS, a GCP or an Azure. At that point there is a complete rewrite that is going to be required, or a complete rearchitecting of their infrastructure and that's usually very time consuming and cumbersome, and just straight up disruptive to that development flow.

So that's one place where we see a lot of people opting to use something like Argonaut because we just provide... Think of it as the equivalent of a universal kind of experience, but for your entire stack where you can have flexibility to define pipelines how you want and set up infrastructure in your cloud without having to understand the nitty gritty of how to set up maybe an IDS instance or a managed Redis instance or something along those lines. We just help package all of that together.

Another interesting case is when people want to shift from doing just deployments onto VMs, EC2 instances, GC instances, to something like a Kubernetes because they've hit some kind of a complexity.

So that's another place. A third case that we do see is when folks start trying to look for DevOps engineers and things like that when they want to make their first hire because they're hitting some kind of a complexity.

At that point we've had a few cases where folks just use Argonaut instead of getting someone on board who will then take a few months to build out all of these kind of tooling, they just use Argonaut to get started and reduce the amount of overhead and bring in a lot of efficiency and developer experience to their team.

Brian: Okay, cool. I was asked earlier, because I didn't know if there was a connection, I didn't quite get it from the site, between the Argo tool which is in the CNCF and Argonaut. Is that the play with the name, or is there no connection?

Surya: There isn't really a connection, but it so happens that we do use Argo under the hood to do Git Ops deployments for our customers, on our customer's behalf. So essentially a managed Argo is a part of our offering, and one of five other things that we do.

Brian: Okay, excellent. Yeah, because I'm familiar with the project Argo. I don't do DevOps but I'm familiar with the cloud providers and stuff, and I run a company that has engineer so I know what the pieces are but I don't particularly know how to do any of that. But it seems like a tool like Argonaut would actually be beneficial in my current setup, my current state. I'm curious, did you do research? Why the importance of 10 engineers to 50+? Is it that at that point is when things get harder? What's the significance around the number 10?

Surya: The 10 is a simple proxy for a couple of things. One is the complexity that starts creeping in due to collaboration and collaborative requirements. Before that, it's usually a very tight knit team and everything is just a ping away. At around the 10 people mark, you need some kind of system in place which will ensure that things are going smoothly.

One example of that could be when people start off, this is not a great practice but it's exceedingly common. Let's say we are on AWS and folks spin up EC2 instance, log into an EC2 instance, do a Git pull for their latest branch and do an NPM start or whatever to run their app. That's an exceedingly common practice, but obviously this starts failing when you have a bunch of people and the decision making and the deployment mechanisms and processes are more distributed.

That is one part of it. The other part of it is the fact that when you have a bunch of different services that you need to coordinate and orchestrate, and also when there's a maturity to the pipeline that you're bringing in, that's when things start getting complex and you end up having to spend a lot more time, a deceptively large amount of time actually, just making these systems work.

I can go into an illustrative workflow if that helps. Just an illustrative workflow here is if you want to deploy an application, first you check in your code, then it needs to be built somewhere, and you ideally want to have your CI, et cetera, set up to do this for you. Then that generates artifacts, either container images or binaries or what have you.

Then these need to be stored in a particular location and they need to be scanned for security operations, and also you want to be running tests on top of that. Now, after all of this is done, it's not complete yet because you'll have to provision your cloud infrastructure across different environments. You'll probably have a Dev-end prod and maybe a few other environments in the middle.

So you want to provision all of this cloud infrastructure, that includes things like databases, your storage buckets and so on. Then you also need to pick a runtime. There are a whole variety of those. You need to pick a runtime and then all your artifacts, et cetera, need to be deployed to this infrastructure in the right environment, in a scalable and consistent manner.

Then there's also this layer of secret management and internal processes like up roll mechanisms, et cetera, that start coming in. Then after all of this is setup, your users can start accessing things but you'll still need to do things like observability, set up observability stacks where you monitor your application for uptime, performance, errors and stuff like that.

Also, day two operations like cost visibility and optimization on top of that and so on, and general maintenance. So it ends up becoming a fairly complex beast very quickly, and all of this starts happening once you are around product market fit and have a product that your users are currently using and so on. That is the proxy for 10 engineers that I've roughly denoted.

Brian: Okay. Cool. Yeah, then you mentioned Heroku in passing, and Heroku did something really good which is abstract the AWS piece away from us, and then eventually build an entire ecosystem of developers who could just get their apps up and running pretty quickly. I think what we're seeing is a transition of Kubernetes which now becomes the runtime for most DevOps.

There's other stuff out there, but that complication of wanting Kubernetes, I was around that time, 2012, 2015, I didn't get it so I moved into the frontend and started working on stuff in other places. But now we're seeing that abstraction, now you have these tools like Argonaut that you can now have access to ready available compute and CDNs and edge networks, which is extremely powerful and I appreciate this new wave of infrastructure tooling where the every developer can also participate whether you're part of that 10 or part of the 50.

You can participate. Like when I was mentioning my time at GitHub, I was outside the circle of folks who needed to know the Devops, but every now and then I had to go reach for somebody to go ship something and I just want to reiterate, for folks who are interested in trying out this next level of DevOps, this next level infrastructure, Argonaut seems to be a great thing to try out. The question to you is how do folks get started? Is it just sign up on the website and you're good?

Surya: Yeah. We have a perfectly proper self serve motion so you can just sign up, connect a GitHub account, GitLab account, connect an AWS or GCP account, and that's just two clicks. Then it's similar to a Vercel experience, in the sense that your actual deployment by applying CGS, select which repository you want to be building and deploying from, which branch, select which environment you want to choose to deploy to and you're good to go. There is a little bit of a environment setup that you'll need to do, which essentially spins up your Kubernetes resources and sets up the network and all of that kind of stuff on AWS. That's just a few minutes.

Brian: Cool. Well, Surya, thank you so much for walking us through the Argonaut experience. Folks, definitely check it out. It seems like you're only one click away, sign up. I love the fact that you can connect your GCP, your AWS, any GitHub account and do all that orchestration there. Yeah, probably going to kick around myself and just check it out, skim through the docs. I do want to transition us to the picks.

These are things that we're jamming on, could be music, could be food related. Everything is on the table, could be tech related as well. Feel free. But if you don't mind, I'll go first. I've got two quick picks. One pick, I just actually got off a plane from Nigeria, I spoke at the open source community Africa event and talked with a bunch of Nigerians.

Every day that I was in the country I had this one dish which was called jollof. It's their main dish. I don't know if your family or if you do all the cooking, if you have a main dish that you eat all the time. I know I do. I just had oatmeal for breakfast, I eat that every morning. But jollof is breakfast, it's lunch, it's dinner, it's rice with tomatoes.

It's tomato based, and then usually some sort of spices in there. I've had jollof in the States, but when you're in Nigeria it's so much more spicier. That took me back for a bit. Have you had jollof before?

Surya: I have not, but it definitely checks all the things that I like about food. I like really spicy food, and I love the fact that it sounds nice and simple to have as well. It sounds like something that I would be able to do every day.

Brian: Okay, yeah. You should definitely look it up. See, I personally am going to try to cook it myself. It seems pretty straightforward. I say that, but I imagine there's a Nigerian or other folks who have jollof in their country thinking, "No, you can't just think you're going to do this." But maybe it is, I don't know. I'm going to look up a recipe and try to make it myself this weekend. I really enjoyed it, it was very, very good dish and I enjoyed having it for every meal when I was in Nigeria. I do have a second pick, which, I don't know, have you done any AI stuff?

Surya: I have been playing around with it for a bit, and even as a part of Argonaut there are a couple of things that we are exploring. One is to help with debugging and the other is to help with cost related visibility and stuff. But yeah, playing around with LangChain and a couple of things for a little while.

Brian: Cool, yeah. LangChain is actually my pick, we actually started leveraging it. We built a little AI tool, me and a couple interns put together basically GitHub Copilot, but not GitHub Copilot. So, basically, Open Sauce, the company that I am running right now, has a little Chrome extension that you install onto your Chrome browser, specifically for GitHub.com, and we just generate PR descriptions.

But the one thing that I've been seeing folks like Source Graph, with their coding tool which everyone should check that out, it's going to be a better version of what we're making. We're building an Ask A Repository Any Question type of tool, and the way that we've been doing this is through LangChain and embeddings. We played around with one of the machine learning models from Hugging Face, I forget which one.

But ultimately what we landed at is using LangChain and Open AI's embedding end point because we don't have to host it on a server or anything like that. It just uses LangChain and uses Open AI's endpoint. Which, honestly, it's amazing that Open AI gives all this away for folks to leverage and you don't have to train any models, the model is there.

But the idea is that it will be asking questions of repositories. By the time this podcast comes out, I don't know if it actually will be shipped, but we do have a GitHub issue that's opened. I probably should mention the issue, to be honest, if anyone wants to help support this idea. We are hitting some edge cases based on how intensive LangChain is. It's taking up a ton of compute. The AI repo for Open Sauce is number 192 if anyone wants to join the conversation.

Surya: I'll definitely be checking this out, and honestly it's amazing how fast this space is moving. Especially with the announcement of Open AI's Functions a couple of weeks ago. It just makes automation using large language models so much more natural for computers now. It actually just unlocks a whole new set of use cases. I've been itching to try out more and maybe I'll check out your issue 192 over one of the weekends.

Brian: Excellent. Yeah, do you have any picks that you want to share with the audience?

Surya: Yeah. So something that I do outside of work and I've been trying to increasingly make more time for it is board games. Specifically, I love euro style board games, strategy board games where there is an element of engine building to it and there is also an element of strategy to it. I love the fact that there is no dice involved, so it's not luck based but it's purely deterministic.

I love that because I do get to spend some time with people that I know and enjoy spending time with, while just unwinding and it's also a nice activity to do. So that's something that I've been increasingly looking at, and similar but slightly different and not really euro style is the wave of collaborative board games that I've been also looking at.

Things like Pandemic and Sherlock, which essentially are not competitive, where you're not working against other players but you're working as a group to figure something out or to make something work towards a common objective. This introduces an entirely new dynamic and I've been loving it, and I've been playing a few of those. I really encourage you to check it out if you have a few hours to spare with a couple of people.

Brian: Sorry, when you mention euro style board games, is that specifically a style that does not include dice or is the euro style something different?

Surya: Generally, euro style can include dice as well. But a lot of them don't, and more specifically the euro style strategy games are known for a couple of things. One, usually a reasonably complex set of rules and they take a few hours to play. But the core concept towards all of these is the fact that there is a meta to the game and there is the concept of engine building, which is you essentially have specific objectives and you put together a lot of different pieces over the course of the game so that towards the end of the game you have a good engine which will essentially generate points furthering you towards the objective. It involves a little bit of thinking and it's pretty fun to play.

Brian: Okay, cool. Thanks for enlightening me. I've definitely played games, and folks who are way more into board games than I am, I love hanging out with them because then they can fast track me into the rules. As opposed to studying for probably 30 minutes before I even start the game. So it's always fun when folks are really, really excited about the game, they'll bring you along for the ride, and then you have a lifelong game you play all the time.

During the pandemic we actually leveraged my team at GitHub when I was there in the pandemic, we would do board games online and, yeah, sometimes it would take a long time, sometimes it'd be quick. There's certain games that are quick for ice breakers, and just for having an hour on a chat while we were all inside. But glad we can go outside again.

Surya: Absolutely. So just on that note, something that we had done a couple of times is our team is 10 people, and it's a very nice size of team to play something called One Night Werewolf. It's actually a very fun game to play and you can do it remotely as well and it's still interesting. So that's something you can check out if someone is listening and they're looking for ideas for a chill Friday afternoon.

Brian: Cool, excellent. Well, thanks very much for sharing the board games, but also thanks so much for sharing about Argonaut. Folks, again, check it out. I think you've got a pretty beautiful site, and also congrats on being Product Hunt of the day. I did see that on your website.

Surya: Oh, thank you so much.

Brian: Yeah, before we transition out of this conversation, could you just tell us where to find the website and how to sign up and check it out?

Surya: Yeah. We are available to check out at www.Argonaut.dev, that is A-R-G-O-N-A-U-T dot D-E-V, and it's free to sign up so you can sign up and check out the product and let me know how that goes.

Brian: Cool, sounds good. Keep spreading the jam.