Salman Paracha, Founder & CEO at Katanemo Labs, joins Corey at Screaming in the Cloud to discuss his vision for the future of SaaS application development. Salman and Corey discuss what led him to take the leap into founding a start-up, and Salman shares how he believes the future of SaaS application development is at an inflection point. Salman also explains why it’s critical to focus on the outcome your customers experience over infrastructure, and shares his vision for future developers looking to build the next wave of SaaS applications. 

About Salman

Building high-growth, high-tech software products that affect the lives of millions of customers. 15+ years of experience in building successful products and highly effective teams. I am deeply interested in bringing the power of the cloud to end customers, large scale data problems, and delivering scalable services on commodity hardware.

Links Referenced:

• Katanemo: https://www.katanemo.com/
  


• LinkedIn: https://www.linkedin.com/in/salmanparacha/
  


• Email: mailto:salman@katanemo.com


• Twitter: https://twitter.com/salman_paracha
  
  
  

Transcript

Announcer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.

Corey: Welcome to Screaming in the Cloud. I’m Corey Quinn. And this promoted guest episode of Screaming in the Cloud is brought to us by our friends at Katanemo, who is—when you talk to small startups, like, “Who should we talk to?” They invariably look around the room, figure out who they should throw directly into the grist mill, and in this particular case, they have selected Salman Paracha, who is the founder and CEO. Salman, thank you for joining me.

Salman: Hey, thanks for having me. Second time.

Corey: It is. And every time we talk, it seems like there has been an interesting progression in your career. Originally, when we first started talking, you were the GM of the serverless application repository at AWS, and of AWS SAM, the Serverless Application Model that most people know because of the giant psychotic squirrel running around the expo hall at events. Then you went to be a group VP at Oracle Cloud, and now you look around the landscape and decide, you know, what I’ve done my entire career? Worked at big companies where everything is, you know, convenient in certain ways. And that sucks. I want everything to be three times harder, at least, so I’m going to go start a startup of my own. Presumably. I’m assuming that is the thought process that led you here. What’s the actual story behind why you decided to leave giant corporate entities and go to a small startup?

Salman: Thanks for that intro. The primary reason to sort of pursue this dream was something was pulling at me for the past four to five years. As a person who considers himself a builder, the most happiest I am when I’m actually trying to ship software out for customers. And so, I’ve been pulling on this thread for a very, very long time, that the world of the modern reference architecture, as it goes more microservices and explodes in the face of developers, has gotten to a point that we are now being inundated with all these micro-primitives, if you would, on infrastructure that actually slow the rate of innovation down. And why hasn’t there been a move and reversion to the other side?

And so, as I looked around, and at my time at Serverless particularly, where we were trying to champion this idea of serverless compute where you don’t manage your servers, I kind of was ruminating on this notion of how do you get to zero infrastructure? And the idea that how can we actually orchestrate out all the complexity behind the scenes and you can truly focus on what your application does. And in that part of the journey, I’ve been chatting with developers across swath of industries and varying degrees of sophistication if you would, and the thing that emerged is that the most complex, perhaps the most complex piece to build in the cloud is a SaaS application. And there’s inherent complexity in sort of thinking through the various concerns of the shapes and sizes of your customers that you’re serving, the security and safety controls that you have to give them, the operational burdens that you take to serve a very large customer versus a very small customer who is perhaps in your free tier.

And so, I was pulling on this thread for a very long time, even at my time, somewhat, at AWS, having—I chatted folks like Twilio and Slack at that time, and I said, “I think there has to be a much, much better way.” It cannot be more; it has to be less, and that less is actually getting us closer to what we believe is the future of cloud infrastructure, which is no infrastructure. So, that’s it. I mean, I think the core thesis was, “Hey, if I’ve operated at this intersection of hyperscale cloud infrastructure and SaaS applications for the past 20 years, what is the compression algorithm that I can apply and give to developers so that they can truly focus on building something phenomenal without having to worry about the complexity of the infrastructure, the security of the scaling of the operational, and the access logs, and all that stuff that they have to today focus on?” And then I’m very fortunate to have had a phenomenal team that have joined and humbled me in my journey here.

Since last year, we have folks across the spectrum who have built these things at scale and at Lyft, at Dropbox, at Meta, at AWS, at Cloudera, and et cetera. And so, we’ve been really fortunate that we have a very firm belief of where we want to take the future of infrastructure and who we want to serve in that market segment. And I said to myself, I don’t think I’m getting any younger. My parents, my South Asian parents, perhaps they’re going to be more happy to see me sort of fight it out and battle it out versus just naturally climb the corporate ladder. Nothing wrong with that, of course.

Corey: It’s not too late to go be a doctor. I say that as someone who grew up in a Jewish home where there were certain expectations and pressures placed upon me that I continue to disappoint four decades later.

Salman: Yeah, so anywho [laugh], on that front, so I think I’m kind of living to the expectations I had for myself 20 years ago when I joined the workforce, and I now have the great fortune to build alongside these amazing builders and see what we can unlock for the developer community.

Corey: One of the challenges with the approach that I found historically has been Heroku did something very similar and then everyone tried to build the next Heroku, except for the company that bought Heroku, they were content to let that thing sit and never think about it again, for whatever reason. But another example would be something like NPM, the Node Package Manager, where it abstracts away stupendous complexity. You tell it to npm install for some project and it just starts scrolling huge amounts of text past and doing all kinds of work and your computer fans start screaming, and you’re like, “Wow, it’s doing an awful lot of fascinating stuff underneath the hood, and I really hope this works. If it breaks halfway through, I haven’t first idea where to look under the hood to make sure that this actually works and doesn’t break my application.”

The problem that I have historically with the things in this space is it requires a certain element of trust. That said, looking at the things you’ve done before, the places you’ve been, I don’t have to explain that to you. You have clearly spent your entire career in environments where mistakes matter because they’re going to show very quickly to an awful lot of customers if they wind up getting out there. That feels to me like it’s a significant competitive advantage versus, not to be disparaging, but a couple of founders fresh out of a boot camp who have never worked in the industry before, but they have an idea, gosh darn it, this is what they’re going to build.

Salman: You know, you’ll find builders, and you’ll have builders surprise you. And I, you know, salute all those who come out and start something new. I have a whole bunch of respect for that, just the courage that takes it. But there’s an advantage that the team has, and we’re very fortunate on having that advantage, having seen things break. And I think we’re at this inflection point, perhaps now that there’s been an incredible amount of effort done in the open-source community relative to [dis-established 00:06:56 ] standards.

Like if you imagine, what, 25+ years ago, when HTTP and HTTP 1.1 came out, that created an explosion of people hosting these web services and HTTP-based applications. I think we’re at the point where we can preserve the developer experience, preserve the operator experience, but never have to sort of have you tinker in the bowels of the infrastructure … to build a SaaS application. And I think that the interesting part of this is knowing how successful these projects can be, but also how complex they can be to manage. But if you (the developer) can just focus on dev experience and operator