Asim Razzaq Podcast Transcript
Asim Razzaq joins host Brian Thomas on The Digital Executive Podcast.
Welcome to Coruzant Technologies, home of The Digital Executive podcast.
Brian Thomas: Welcome to the Digital Executive. Today’s guest is Asim Razzaq. Asim Razzaq is the co-founder and CEO of Yotascale, a leading cloud cost management platform trusted by enterprises like Zoom, Disney, and Okta. At Yotascale, Awesome focuses on helping large organizations optimize cloud spinning through clear, actionable insights that streamline cloud operations.
Prior to founding Yotascale, he was the head of platform engineering at PayPal, where he led the development of PayPal’s private cloud and developer platform, supporting global payments infrastructure and driving multi-billion dollar transaction volumes. Asim’s extensive background in cloud infrastructure and engineering positions him as a thought leader in scalable, cost-effective cloud solutions for enterprise clients.
Well, good afternoon. Asim. Welcome to the show!
Asim Razzaq: Thank you, Brian. It’s great to be here.
Brian Thomas: Absolutely. I appreciate you making the time hailing out of the great city of San Francisco today. Love doing these just a couple hours difference for us, but Asim, we’re going to jump right into your first question here.
Thank you. You founded Yotascale to help enterprises manage cloud costs effectively. Can you share what initially motivated you to tackle cloud cost optimization as a primary focus and what gaps you saw in the industry that Yoda scale aimed to fill?
Asim Razzaq: Yeah, I mean, that’s a great question. I consider myself a recovering engineer and continuously being in the seat of the CEO.
So ultimately what motivated was my prior jobs, right? So, I’ve been primarily a head of platform engineering, running infrastructure at scale at companies like PayPal, early stage startups, late stage startups. And certainly, saw the advent of cloud computing circa 2007 when AWS came up with S3 and now there are multiple players, of course, providing the services in the cloud.
And I think since those, obviously, early days, I had my brush with it because there’s no way you could avoid it. And in my role as a head of platform engineering, I ended up being just in that, if you will, collision path, right? So, there’s a lot of amazing things that come from cloud computing. It turned CapEx on its head, made it OpEx and just agility has been phenomenal leveraging a lot of these services.
But the challenge was the financials, the economics, and that were increasingly hard for people in my shoes. Because the monkey was constantly on our backs, right? Cause we were providing this platform, this infrastructure to teams at the edges that were consuming those services. And a lot of times the finance folks, the businesspeople, they would look at the bill and question where the money is going.
And why are you spending this money and what can we do to reduce it? So, you know, our answer a lot of times was, well, you know, I’m not spending all this money. It’s other teams that are basically consuming these services. So, they’re spending the money. And so that led to a lot of challenges, right?
Because you have to have explainability as to who’s spending what and why. And as a head of platform engineering, you have to provide those tools to those teams. So that was the observation. And really it led to a moment in my career where it was a moment of disappointment, which was you would hope that cloud computing would really fulfill this promise of agility and flexibility while hopefully making economics work as well.
But in reality, there was a big gap between the promise and the potential and the ground reality. So that’s what led me to start Yotascale. And initially, when I took the plunge to go do this this is a few years ago in circa 2016, 2017, we looked at the tooling in the market and whatever was available at the time, there was overwhelming feedback from a lot of customers that we spoke with.
One of the biggest constituents that was being ignored with respect to these tools was the application engineering platform engineering teams. So they said that, yeah, you know, some of these tools can help you slice and dice data, they can help you generate reports, but effectively it’s a finance tool.
So, it helps finance quite a bit. But then it weaponizes finance against engineering to really just chase them and really not provide a lot of actionable insights, a lot of key visibility to the engineering team to do the job that they needed to do. And so hence, that was the start of. The journey for us because we saw that gap, we wanted to make sure that a product resonated with that key constituent that I was in the past, which is platform engineering application engineering teams reeling in a lot of this cost while effectively fulfilling their day job, right, which is performance, security, reliability, shipping code, bringing value to the company.
Brian Thomas: Thank you. And you’ve obviously seen a lot in your time as an engineer working at various companies and startups. You saw some of the need and of course a good point is working for some CFOs in my past, they were very cost conscious and sometimes we did short on the infrastructure side or the engineering side.
So, I appreciate you bringing that to light and sharing a little bit more about your platform and the genesis of the idea. My pleasure.
Asim, in your role as head of platform engineering at PayPal, you managed a massive cloud infrastructure. How did that experience shape your approach to building Yotascale and the solutions you offer to other enterprise clients?
Asim Razzaq: Yeah, that was a tremendous journey. So, I was brought in to PayPal primarily for intrapreneurship. So, I had been in startups before PayPal, early stage, mid stage startups. And that was my main cup of tea, if you will. And at PayPal, there was this opportunity to build a developer platform from effectively nothing.
So, I was a co-founding member of this group of people and these visionaries who wanted to have the third wave of growth at PayPal, right? So, if you look at PayPal, they did consumer, then they did merchant, and then developer was the next big initiative that they wanted to pursue. So, it shaped my thinking many different ways, right?
So one is, there were elements of entrepreneurship in there, but a lot of constraints. So, the budget you thought you had that was allocated for this amazing bold vision was, did not end up being the budget you expected it to be. There were a lot of constraints with respect to architecture, security, and scale.
And one important thing I learned a ton at PayPal was that scale. How do you build a world class product that can be trusted. Of course, we were in FinTech, so you really cannot compromise that because people’s financial information is the most critical information that they have out there. And just the volume, the sheer volume, the number of transactions that we did was quite eye-opening for me because I’d not seen that level of scale in my earlier experiences.
And with that comes a lot of thinking into how do you build a system like that, right? How do you build a system that is reliable, build a system that is secure, build a system that is performant, but at the same time continue to innovate. And those can be challenging. So, if you fast forward to our customer segment today at Euro scale, they tend to be larger companies and they have a pretty decent size cloud footprint.
They tend to have a lot of different teams. They have a lot of different services. They have a lot of complexity. They have workloads that are containerized and there are many different variations of containers. They have microservices, they have shared services. So, you can get a sense of how complex and challenging and scale wise that can be.
So, what the PayPal journey prepped me for was that if you are building software for these enterprise customers and clients, how do you make sure that those elites are important, right? The fact that it is there’s a formability, the reliability piece of it. The security aspects of it, the scale aspect of it, I think that was that was quite instrumental because we think of ourselves as a big data company that happens to be doing cloud cost management, right?
Because we deal with a massive amount of data for our customers. And that data just requires a different level of scale engineering and design and thinking that you would typically not have if you were serving a smaller customer segment.
Brian Thomas: Thank you very much. I appreciate that, Asim. Again, you talked a little bit early in your career about the different diverse companies that you worked at different sizes, startups, et cetera.
But I think what you highlighted here is what brought it all home is working at a large enterprise like PayPal and then taking that information that is in that experience and now being able to better serve the customers that you serve in this space. So, I really do appreciate some of that background.
Asim, Yotascale provides actionable insights to its clients. Can you explain how data driven insights are used to streamline cloud operations and support decision making for businesses?
Asim Razzaq: Yeah, so, you know, as they say that prescription without diagnosis is malpractice. So that’s part of the starting challenge with respect to cloud cost management, right? So, the first step is, okay, what is the decision making based on?
And what we find is that a lot of customers are somewhat running blind in terms of how they should be thinking about the cloud cost, right? And what I mean by that is, if you cannot, as one example, if you cannot really draw the lines, the boundaries around ownership, you can have no accountability. Cause if you keep telling me as a head of platform engineering or as an application owner that my application is spending a bunch of money.
But you cannot back it up with data as to ensuring to me that it is really my application and I’m not being allocated some of their applications spend, then I will not be trusting that data. So, I think the first foundation for us is that data trust in the context of how you run the business, in the context of how you hold people accountable, in the context of how you have your ownership lines.
And that might differ for different enterprises, different companies, right? The org structures can be different. Ownerships can be different. And decisions around the business can be different. So, another example is any SaaS company will be serving customers in the production environment, and you need to understand how much each customer is costing you, especially when it comes to your cloud cost, your cloud spend.
And then that effectively will drive your decisioning around pricing. So, you don’t want to be in a situation where you’re charging a customer 500,000 and it’s costing you 5 million in cloud spend, right? That’s not a, that’s not the right lens to have. So, what we do is that we’re able to fulfill all of these different demands from the business and the stakeholders because the different stakeholders are going to look at the cloud cost from a different lens.
An engineering team is going to focus primarily on what is the cost of their application, what is the cost of their service, and what is the cost of their data pipelines that they are running. A CFO, if you just go up to that level, is going to be very concerned about profitability, about margins, about cost of goods sold.
People in finance, finance controllers, they’re going to be concerned about budgets. Like, are we coming under budget? How much spend there is with respect to all these different cost centers? What should we forecast right in terms of that? And then lines of business will have different concerns. So, if you have a GM, you’re running a product line.
Similarly, you want to understand, um, how much is a product line costing and a CTO might want to look at what is a split between production dev QA test type of environments. So, what we allow is these stakeholders to come in and exactly get the data at the right time and with the right fidelity that they need to make those decisions.
And we support this with additional capabilities like anomaly detection, right? So, a lot of times organizations have this challenge of runaway spend or runaway spikes in their cost. And nobody knows what, what we run into is, you know, there’s a spike, there’s a bill that exploded 30, 40 percent month over month.
And now you have the CSI crime scene investigation happening. This whole research as to why that happened. And inevitably you will run into scenarios where, well, you know what, there was a launch that we had, and we had provisioned all of these machines and we forgot to shut them off. Right. Or there’s a bunch of instances that are out there or compute instances that are not being utilized, they’re underutilized and we just wasting money.
So there’s a lot of different examples where you could have that runaway cost. And it’s very important that you are able to not only catch that runaway cost very early in its forming. But also notify the team that should own that that’s back to that actionable insight, right? The right team should get that notification at the right time.
And with the information that allows them to take action. Same thing for recommendations, right? If you need to right size, you are spending way too much. You are overprovisioned within your application. You need to be given that information in the context of your application, and you need to be given very precise, actionable data as to what you need to do to bring that cost down, which instances are over provisioned, basically, again, building that trust around, hey, we looked at memory, we looked at compute, we looked at storage, we looked at network.
We’ve looked at everything and we’ve looked at the profile of your application and everything tells us that you don’t need this 50 percent buffer. You only need a 10 percent buffer, so you might want to bring it down. So those are examples of that actionable insight that allow folks and people in these companies to take that decision and to take it in a timely manner before it becomes a financial disaster.
Brian Thomas: Thank you. I really do appreciate that. And, you know, as a CIO in my prior life. Dealing with that and always trying to prove our value in, in the IT world. We had to look at those types of costs around infrastructure, cloud, computing, and you know, providing this actionable data-driven insights, makes a huge difference.
And back in the day, I wish I had a little bit more of those insights to bring a better case to my CFO, so I appreciate that. Asim, as a thought leader in cloud infrastructure, what are the key elements companies need to consider to scale their cloud infrastructure efficiently while keeping costs under control?
Asim Razzaq: So, I divide this into really two things, right? One is you can be a born in the cloud company, or you could be more of a traditional company that is starting to put workloads in the cloud. And the recipe can be a little bit different. So, let me quickly try to go through that, right? If you’re a born in the cloud company, a lot of times what’s going to happen is that a lot of focus is on growth.
It’s like growth at any cost. You continue to scale and scale, scale until the point that you’re going to have that dreadful board meeting where they’re going to tell you, hey, enough growth, we need to not look at profits. We want to start thinking about our pre-IPO story. And eventually we’re going to go IPO.
Or there might be other market constraints that might be forcing you to make sure that you have those financial efficiencies. And just very quickly on the traditional company side, you were born in the data center, you’re trying to take workloads, put them in the cloud, you think it’s going to be awesome and, you know, Automatically, things are going to be efficient and you’re going to be agile.
You have to really set the right expectation. You cannot do lift and shift, and you have to think about what is the right architecture for cloud and what are the applications that should go first. So, I think we could take the discussion depending on which type of company we’re talking about, but the underlying common denominator between both of them, once you have workloads in the cloud is the following, which is you have to treat the cloud cost is a first class citizen as a key KPI.
So, a lot of focus is on performance security reliability, but cost has to be a KPI that is looked at all levels of the organization. So out of sight, out of mind. If you are not really looking at that as a KPI, then you are going to drive the behavior. That’s the kind of culture that is going to be put in play.
And there’s no product on the face of the planet that can come in and really change culture for you, right? That’s something that has to come from you. A product like Yotascale can certainly help you drive a lot of efficiencies, but if you’re not bringing that focus, leveraging the product, then it’s going to be quite challenging.
So, step number one is make sure that this type of a KPI is being discussed in all the right forums. Make sure you understand for your business what that means. And we hit on a few things like what are the levers for your business? Is it the number of logins per second that you serve? And what is the cost of that?
Is it the customers that you serve? And what is the average cost of serving each customer? Whatever the KPI is, you have to start from the top and then you can go double click on that as to who owns that and who owns the subsystems there. So, it starts with visibility. You have to shine the light on these type of challenges before you can go to any of the advanced concepts when it comes to cloud cost management.
The second thing I’ll say is make sure that in your teams, you have people who understand this, right? If people have no experience in cloud cost in their prior jobs and no experience handling that. Then again, you will continue to have the culture that is not going to be conducive to the kind of cloud cost culture that you want to set up.
So, I always advise companies that if you’re hiring engineers and you’re hiring people at engineering leadership positions, ask them if they had to take measures, what are the initiatives that they took in their prior company? Are they educated on cloud costs, right? Are they going to be able to run their infrastructure efficiently?
Not just from a point of view of performance and reliability, but also from point of view of cost, and I think it starts there. Once you have visibility, once you’re able to answer the questions that are important to your business, then it becomes less finger pointing. It becomes data driven, and that’s where you can empower the teams to say, hey, you know, your particular service is costing X. I believe the budget should be Y. Let’s make sure that it doesn’t go beyond a certain amount. And then also make them responsible. Again, the suggestion would be using a cloud cost management product, ideally, and ensure that you’re on top of, Any cost spikes, any of the recommendations, any of the inefficiencies.
Because at the end of the day, you have to drive a culture of empowerment. If you try to use a stick and you try to mandate all this stuff without empowering teams, without connecting the dots to the strategic goals, then you’re going to get the results that you usually get in those environments, right?
Which is blame games, finger pointing, and people just not, you know, their head might be in it, but their heart’s not going to be in it. So, I think that’s the advice I would give in a nutshell.
Brian Thomas: Thank you, Asim. I do appreciate that. And there is a lot that goes into it. Obviously, you need to have a good strategy when you’re working with the cloud, whether you do a lift and shift, or you’re trying to manage that hybrid environment or any other type of migration or strategy, but having the right team in place, knowing really how to run that infrastructure.
And making sure there’s clear communication. I think that’s so important with all the business leaders or stakeholders that are involved in that process. So I really do appreciate the time we had today here, Asim, and I look forward to speaking with you real soon.
Asim Razzaq: Yeah. My pleasure, Brian. It was great being on your podcast.
Brian Thomas: Bye for now.
Asim Razzaq Podcast Transcript. Listen to the audio on the guest’s podcast page.
