Screaming in the Cloud - The Growing Dominion of Cloud Providers with Raj Bala

Episode Date: March 2, 2023

Raj Bala, Founder of Perspect, joins Corey on Screaming in the Cloud to chat about his experiences working in the world of cloud and why he made the shift from Gartner Analyst to Founder. Raj asks the question, “Is AWS truly customer-obsessed?” in the face of their business practices, and challenges the common notion that analysts don’t need to have lived experience with a product to criticize it. Raj and Corey also explore the absurdity of Azure naming conventions, how cloud providers are creating roadblocks to multi-cloud, and the response of the greater public as cloud providers become more and more powerful. About RajRaj Bala, formerly a VP, Analyst at Gartner, led the Magic Quadrant for Cloud Infrastructure and Platform Services since its inception and led the Magic Quadrant for IaaS before that.  He is deeply in-tune with market dynamics both in the US and Europe, but also extending to China, Africa and Latin America.  Raj is also a software developer and is capable of building and deploying scalable services on the cloud providers to which he wrote about as a Gartner analyst.  As such, Raj is now building Perspect, which is a SaaS offering at the intersection of AI and E-commerce.Raj's favorite language is Python and he is obsessed with making pizza and ice cream. Links Referenced:Perspect: https://perspect.comformer2.com: https://former2.comTwitter: https://twitter.com/raj

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. Today's episode is brought to you in part by our friends at Minio, the high-performance Kubernetes native object store that's built for the multi-cloud,

creating a consistent data storage layer for your public cloud instances, your private cloud instances, and even your edge instances, depending upon what the heck you're defining those as, which depends probably on where you work. Getting that unified is one of the greatest challenges facing developers and architects today. 3 compatibility, enterprise-grade security and resiliency, the speed to run any workload, and the footprint to run anywhere. And that's exactly what Minio offers. With superb read speeds in excess of 360 gigs and a 100 megabyte binary that doesn't eat all the data you've got on the system, it's exactly what you've been looking for. Check it out today at min.io slash download and see for yourself. That's min.io slash download, and be sure to tell them that I sent you.

Welcome to Screaming in the Cloud. I'm Corey Quinn, and I've been looking forward to having this particular guest on the show for a while. Today, Raj Bala is an entrepreneur at his new thing, Perspect, and we're going to get into that. But before we go to where people are, it's often helpful to understand where they came from. Raj, welcome to the show. Thank you, sir. Glad to be here. Before this, you spent, well, basically it was forever in tech time as a VP, Distinguished Analyst at Gartner, where you were responsible for, well, so many things, I'm sure, that people would love to cast at your feet by way of blame. But you owned, I think we're calling it the Sips Magic Quadrant now? Correct. Correct. That is it.

Yeah, that was the effectively annual horse race of the large cloud providers and some companies who flatter themselves by considering themselves the same. But it's the one day a year when that thing comes out and you wind up with a bunch of cloud providers plastering it all over their website, proudly displaying a graphic that more or less distills down into demonstrating how AWS is beating them in various ways, which from my perspective never made a whole lot of sense. But that's probably why I don't work in large enterprises, for the most part. It's so funny, because it's so true, right? I mean, that's what happens is they plaster it all over their sites, you see a bunch of press releases, we get to take a big sigh of relief that the thing's finally published and then on to the next magic

quadrant. Your background is fascinating to me just because you tend to break what I've come to think of as the analyst mold, where the background for a number of analysts has been, oh yeah, I used to work at a big analyst shop and I worked my way up through it right out of college. But you have a background doing software engineering yourself, and that suddenly explains a lot of things I've seen over the years where there's clear glimpses of someone who actually understands how the technology fits together and what it does under the hood is weighing in on a lot of these analysis pieces. Because otherwise, it just feels like it turns into this constant debate between more or less you get to mediate which side of a particular issue sounds the most credible. Yeah, I think I

would have a hard time deeply criticizing any of these cloud providers if I had not taken their services for a spin myself. And that largely involves using their APIs, deploying products, trying out what they claim and see if they're actually true. So when AWS made all these claims around Graviton, they said, oh, it's 20% better price performance or it's 40% better price performance now with Graviton 3. I said, well, let me actually try. So let me actually do the benchmark myself and let me see if it's the case. So in AWS's case, lo and behold, it's actually true. I would, no one was more surprised than I was at that moment because

they were so shady around disclosing any actual benchmark numbers. It's okay, you're hiding something here. I think let's figure out what it is. And ever since then, every time I've tried to race Graviton against anything comparable, there's really been no contest. Yeah. Yeah. I mean, so me personally, if I'm asked to criticize a company, I need to be able to say that I've used the product. I need to be able to say that I've got experience building on the product. And I think that is a bit unique in the analyst space. It definitely seems to be, just because whenever I've brought things up in conversations with companies doing the whole analyst briefing with me, I will kick the tires on the thing and ask them questions, and they never seem to have prepared talking points ready to go on any of those things. Like, okay, we're going to have to circle back with you, and then they bring an

engineer or six to the conversation, and it almost feels like they're surprised that someone has actually used the thing. And they'd never considered that a customer would use it without working there or something. I get that it's hard to take something you're too close to and expose it to the world, but it just seems like they're at these giant companies. There have to be some smart people with engineering chops who have never worked with this particular product or service tell them to go build and that becomes an awesome user study but i never see it happening yeah it's pretty rare so over the years as you've been putting together the magic quadrants what have you seen that's emerged that

for better or worse isn't going to be captured via just building the animated GIFs that show the quadrant motion over the course of years and various things in it, or a detailed reading of the reports? When you're writing something, if you're anything like I am, very often you'll intend a certain thing and mean for it to be taken a certain way, but then people read it and their takeaways in some cases can seem to be almost tangential to the point you were trying to make. Do you find that you are seeing things or reporting on things over the years that are not being taken in the same way or are misreading what your experiences have been as you write them? Yeah, there's one thing in particular I think that isn't being noticed, and it is this. It is that as customers get more and more aligned to a single cloud provider, they end up falling under their dominion.

These cloud providers, because the nature of the cloud is not necessarily on you know, on-prem, you deploy a bunch of things that might involve, you know, Microsoft and SQL Server and Oracle and a bunch of different things on-prem, you've got your arms around all this stuff. In the cloud, you're kind of giving up all that stuff. You're giving up that control, right? And so what we're seeing is the cloud providers, as they get more and more customers in their dominions, they begin to exert more and more pressure in somewhat nefarious ways. And so we've written about this in the past, but the market hasn't reacted the way that I was hoping they would. I was hoping people would say, oh my gosh, now this cloud provider's got all this power over us. What do we do?

Are you seeing that manifest in the sense of the services that require more, I guess, emotional investment or commitment to use effectively, having different pricing structures that feel predatory? Do you view it as effectively once customers are at a significant point in size, contractual terms start shifting? How do you see that playing out? Yeah, I think once customers end up getting a certain amount of lock-in to a cloud provider, that cloud provider ends up doing different things based upon each cloud provider. So for instance, if the cloud provider's primary business is selling database licenses, they're going to begin exerting pressure on that dimension. If their primary business is selling things like operating systems and productivity and so forth, they begin to exert pressure there. The case of AWS, AWS doesn't have really any of those except all in the cloud. We've seen them exert pressure on customers in their own unique ways.

So I think as customers get more and more strategically aligned to particular cloud providers, these cloud providers are not angels, and they exert pressure on customers in ultimately what comes down to rather strong-arm tactics. Corey Doctorow recently had a great post on the increasing inshittification of big tech companies, where first they wind up effectively giving the farm away and people fall in love with them and then invariably they wind up taking it out on some of their users and or their business partners. And it's almost like clockwork on some level where

you can trace through the evolution of a company how great or terrible it is based upon where it is on that particular cycle. And I couldn't help but think that that was ominous and disturbing given just how much infrastructure has moved to the big three cloud providers over the years. On some level, even though it's never happened before, you do have to wonder about these early cloud questions. What happens when AWS puts a zero on the end of every price? What do we do then? And, well, they've never done it before,

isn't really a sufficient answer to that. It really isn't. So what I found is that the level of nefarious behavior is inversely proportional to the provider's market share. So the lower the market share, the less control they have over customer, the less dominance they have over customer, and the less likely they are to pull out some magic zeros. But the higher up you go in the market share, the more likely they are to exert some pressure. I think people were expecting AWS to start being really customer hostile by now.

And I do admittedly see elements of it. I think that, for example, when I wind up typing anything arbitrary these days into the search bar at the top, getting this never-ending cascade of marketplace offerings where it feels like they're all in competition with each other and now we're starting to see what effectively feels like paid search inside of the AWS console. That is the drift that I'm starting to pick up on. I worry about what that portends down the road. I think that we're still relatively early days in cloud compared to basically how terrible Amazon.com, the retail store, has gotten. But I'm not particularly bullish on the future of the I found when I was at Gartner was that customers absolutely want to be able to use multiple cloud providers and do it together. So they want to be able to use Power BI and something like EMR, the Elastic Map Reduce service. They want to be able to use these together.

They want to use Azure for data visualization, but they want to use AWS for data crunching or GCP for data crunching. The cloud providers don't make this easy, especially AWS. If you ask them about the likelihood of working with one of their competitors, you know, they say that they're customer obsessed, but is that really the case? Being obsessed with someone isn't necessarily considered to be a positive thing when we're talking about interpersonal relationships. So I sort of wonder why people are so willing to misinterpret it as a corporate slogan. Yeah, I think that they should go work with their competitors. Like for Power BI,

that's what customers want. Customers want to be able to use these things together. And right now they have to jump through a bunch of hoops. And God forbid they make one simple mistake from an IAM perspective, and they find themselves in a world of hurt. Absolutely. And I know I keep talking about this in a variety of different ways, but it also does not seem like there's any real way around what can only be described as punitive data egress rates. If you wind up charging basically what distills down to cell phone provider data overage pricing to move things out of one cloud provider into another, then it doesn't matter how great the competitive offering is.

Just on economic grounds alone, it winds up being a complete non-starter. And I feel like that makes the entire industry poorer for it. I don't know if you've seen these in their private pricing, but I mean, I see these quite a bit. That has to be one of the most deeply discounted aspects of any individual service is their data egress for large commitment sizes, which tells me they have just tons and tons of gross margin, which Cloudflare did a really good job of highlighting. So the discounts were massive if you commit to a huge bar. So yeah, I agree with you. The data egress is a punitive roadblock to keep people from really doing things multi-cloud. Those significant discounts feel like they come into play once they've served their purpose of getting you to sign on a commitment that now takes over that purpose, which is getting you to commit body and soul to being on AWS.

That tends to be obnoxious. Let me call it my own bias here. In my day job of fixing bills, I focus purely on AWS, whether it be in terms of actual optimization, because cost and architecture are the same thing, or negotiating AWS contracts. It's still AWS-centric and AWS-focused. So I don't have a great depth of perspective on the other providers in quite the same way. Yeah, for the most part, it kind of looks like this. The other providers cannot discount egress the way that AWS does for lots of reasons. But ultimately, the discounting behavior looks pretty similar at the lower dollar levels.

So if you're talking about like a million dollar commit to these cloud providers, which in the grand scheme of things these days is relatively modest, the pricing mechanisms from a discounting perspective look pretty similar. I think that's one of the challenges I've been running into when I talk to customers who do also have Azure presences.

It's generally database driven. It feels like it is primarily because the economics of running Microsoft SQL Server on anything that isn't Azure are punishingly bad. In fact, even Azure had a ad campaign for a while talking about how it is five times cheaper to run Microsoft SQL on Azure than on any other cloud provider, as if they discovered some miracle of cloud economics that no one else figured out. No, you're just being dickish when it comes to the licensing terms. Don't break your arm, patting yourself on the back for that. It's a shakedown. I mean, this is one of the more nefarious ways I was talking about, right? So they have this legacy of operating system and database revenue that they can then use as leverage in rather unsavory ways. And that's what's happened.

So I am curious, given that you have a background in software engineering and then spent the better part of a decade more or less racing the clouds against each other in a giant variety of different directions. What are you doing next? And do you have a particular vendor that you're primarily going to go with? Or are you straddling the multi-cloud horses for a while? Or are you doing it and saying, how with this I've done, I'm doing it all on servers that live in my basement because that's the end of it. So actually I considered some of the, you know, build it in my basement. For some cases, particularly like GPU costs and so forth, it might make sense to think about either multiple cloud providers or perhaps having my own space. But to the question of what am I doing now?

So I'm a software developer and I'm an entrepreneur at heart. And being a Gartner analyst is a difficult place to really satisfy those needs, you know, this need to write code and bring it to the world. So I left Gartner at the end of last year to re-envision what Shopify might look like if created in 2023 from a developer perspective. So what's the developer experience look like in the e-commerce world, in the age of AI, in the age of things like React and Next.js and so forth? So that's essentially what I'm building, AI and headless commerce. And then to answer your question as to where, you know, which cloud provider. So the architecture of the platform that I want to bring to market necessitates that the cloud provider have things like CDNs and cloud functions and SQL databases and NoSQL databases. And there's really only one cloud provider that has all of that. And that is AWS. Google doesn't have edge functions. Azure doesn't have their own CDN or edge functions. Cloudflare doesn't have SQL databases or really great databases in general. They've got SQLite,

but that's not going to fit the bill. And their edge functions require JavaScript. So there's really only one game in town. So I imagine based upon the nature of what you're doing, that extreme low latency local to where the customer is is paramount for you. It is. It is. I mean, in e-commerce in particular, Amazon themselves, I don't know if you've seen this quote from them, but they say that for every 100 milliseconds in latency,

they lose 1% in revenue, which is astounding, right? So the service that I'm building is essentially entirely latency-focused from an architectural perspective, at least. So, yeah. One thing that came out back when AWS released CloudFront functions, which are JavaScript-required nonsense monstrosities, to be direct. To be honest, it kind of felt like they were taking another bite at the Lambda at Edge Apple after ignoring it for a while. But one of the things that they let leak, effectively,

based upon how they described them and started talking about them, is that Lambda at Edge functions run in the closest region to the customer, not the closest CloudFront pop, which is often significantly closer. Does that act in any way as a bar for you? Or have you found that these days it's hard to go somewhere on the internet that is too far from an AWS region? So far, it hasn't been a problem, but I think it could be. And it's particularly around, there are two dimensions that are pretty limiting right now with edge functions in general, not just AWS. One is the package size, and the other is the runtime duration.

So Lambda at Edge functions for viewer requests have to complete within five seconds. whatsoever getting to like DynamoDB or getting to Systems Manager Parameter Store to get secrets, you could be in trouble. So if that region where the pop, where it happens to be running is too far away, it might be problematic. But this is the same case with Cloudflare. So Cloudflare's got packet size limitations, they've got runtime duration limitations. So basically bundling Stripe plus Sentry plus Bodo 3 could bust you out of that packet size limitation really quickly. So you start having to modify third-party packages. Like, okay, which code path am I not going to use so I can strip it out? And that's awful.

Exactly. I mean, that might be the case. But I think so far, knock on wood, I've been under the one megabyte. It's one megabyte for Lambda at Edge for viewer requests, if you can believe it. My god, that's one of those areas where even one of the old five and a quarter inch floppies would take more than that.

Thank god Stripe has a relatively slim Python SDK. One thing that I did back when, you know, Twitter was not melting down all the time is I built the last tweet in AWS.com Twitter client for authoring threads.

And that still exists, though it's probably time for me to look at moving that over to Mastodon as well, because there's a certain lack of good thread authoring tools over there. But I wanted to deploy it so it was close to everyone. So I wound up deploying it to 20 AWS regions simultaneously. And the sheer amount of infrastructure I had to basically reimagine to do that in less than an hour was nothing short of

embarrassing on some level. It really feels like I am wrangling 20 distinct cloud providers on some level, where forget parameter store across the board, I'm now storing the secrets it needs to start the thing up in an S3 bucket that they all talk to. I had to build my own CI, CD, matrix job pipeline system so it could do the builds and deploys to each region simultaneously through GitHub Actions and running Docker container build environments

on Lambda functions of all things. And it works, but I'm looking at it and it feels like I'm the first person that ever talked to AWS and said, yeah, I have this lightweight thing I want to deploy to every region. What can you do for me? I did look into Lambda at Edge

and there were a few limitations around it that made it a non-starter that were more than a little frustrating. I wish there was more innovation on that side of things. So in your case, what was the form factor for the application? It's a container? Yes, it's a Docker container that contains itself, an Express application that winds up running.

It's basically fairly stripped down. I took the baseline thing that was more or less pure HTML and then had the good sense to wind up tagging in someone who's good at programming front-end style stuff. And suddenly it looked a lot prettier. I think the direction this stuff goes eventually is serverless containers with a Lambda personality on top of it. I think that is the way this should go, if not the way that it will go. So for instance, instead of these two things being separate services where you can build a container for Lambda and you build a container for Fargate or you build a container for AppRunner, you actually have a single container that can react to events like it's a Lambda function.

That seems to be the most common sense way where this stuff should go. It would make the lives of developers a whole lot easier, I can tell you that. There was a time that I would have argued with you on that point, and a number of purists were very dead set against that entire idea. But in practice, we've seen that the boundary between the idea of functions and containers

has been steadily thinning throughout. And I think what you describe now looks a lot less like a fantasy for people to rail against, and a lot more like an inevitability that it's time to prepare for. Azure's already doing that. Yeah, don't let my Azure hate. Fool you if you're listening to this. There's a lot that Azure gets very right. I just find a lot of their security missteps to be infuriating, and that sort of obscures everything else. But they

get a lot right once you dig down sufficiently into it and go out of your way to track it down if you're in the startup ecosystem, because they don't really talk to that audience particularly well. But there's a lot of neat stuff they have going on over there that really gets it in a way that presents what they're doing in a very different paradigm. There's certainly a lot of neat stuff they have going on over there that really gets it in a way that presents what they're doing in a very different paradigm there's certainly a lot of nuance i think one of the things that always drives me a little bananas is when i think of some of the naming conventions that they choose to use oh god so particularly around storage so they're the only cloud provider that calls object storage and they call it a block blob, which is block storage is

something else. You wouldn't use that to refer to an object storage, but that's what it is in the Azure context. A block blob is an object store in the S3 context. Same thing with, they've got a disk blob and a page blob and a pen blob. I think if I were in charge, I would say, you know what? We're going to use industry standard naming rather than this convoluted stuff. So there's definitely a lot of nuance in the Azure context. But yeah, I mean, they were the first to say, hey, we're going to do this thing where we have a functions personality on a container. For me, the worst example of cloud naming I think I've ever seen, ignoring the jokes and all the rest, was Azure DevOps, just because I was talking to a hiring manager at one point who saw it on a candidate's resume and was using it as an example of,

this candidate is completely out of touch. I mean, look at this. They're calling Azure DevOps like a skill set they have. And it's, whoa, whoa, whoa, hold on a second. There may be problems with the CAD that don't get me wrong, but that's an actual product name, and I think it's a little unfair to ding someone for putting it on their resume. And the hiring manager had no clue, because who tracks this stuff? I think that that is sort of the high watermark right now of a service name that is so bad that it impacts people's career chances if they put it on their resume. Like so far, it's hard. I haven't seen anything from AWS yet that rises to quite that level, but I'm sure they have their namers hard at work as we speak. But just think about where Azure is. I'm speaking of Azure DevOps and thinking

of where it exists in the overall tool chain. And I mean, I use Visual Studio Code every single day for 14 hours a day. And there are millions of other people that do the same. And GitHub as well. GitHub, right? Copilot for everything that it is. Not AWS Copilot, which I do actually love, but GitHub Copilot for all the crazy stuff

that's happening right now in that space and the controversy, it's pretty amazing. And it could be so much better than it is if they integrated a little bit more. If they do it at the right time and in the right way, a one-click deploy to Azure button becomes awesome. Or more cynically, wow, you're really bad at JavaScript. Here are three LinkedIn profiles for freelancers who might be a better fit for solving this problem than you clearly are. You know, I'll probably workshop the phrasing a little bit, but there is opportunity for stuff like that in ways that could be super helpful. I still believe the future of cloud is Microsoft to lose if they don't screw it up. But that's already in Visual Studio Code, right?

Like a deploy to Azure Functions thing is already there. Is that something you're, is that what you're referring to? Sort of. I'm talking about the idea of being able to take almost any application in a number of standardized formats. Think what Heroku pioneered and then everyone wanted to rebuild except the company that bought Heroku. And taking that to the next level of, oh, you've built this with a doc compose file that talks about how to do this. Here's a button that we're just going to put up here if you want it to, that click button, deploy to Azure.

And if they do this right, they become the de facto choice for basically everyone who's learning something new and puttering around on GitHub to experiment with stuff. Yeah, it's a lot of power in the hands of lots of developers that it doesn't look like they're quite taking full advantage of yet. But it's probably something that they, it doesn't look like they're quite taking full advantage of

yet, but it's probably something that they should be. I think they have such a good developer story in their own massive developer ecosystem where they could do an awful lot if they just unified it a little bit. Whereas with AWS, I've given up hope where the thing that makes the company rock is also the thing that makes it suck. Having a bunch of small teams that are silos onto themselves means that anytime you need to do something that requires significant integration between a variety of teams,

they're really fighting uphill. It's why the console is so challenging. It's why the bill is a nightmare. It's why anything like tagging or security become massive focus areas. Tagging hasn't succeeded so well. Security, I'm surprised it's gone as well as it has on AWS given those constraints.

And you see this throughout the entire Amazonian ecosystem. Have you used the Azure console? A couple of times in anger, and then I had to go to the bar for a few hours afterwards. I mean, I would just say, if you're comparing the two consoles, the AWS console and the Azure console, I think the Azure console is a whole lot more frustrating.

I would agree with your sentiment. I mean, for all the things that AWS might get wrong from a Windows administrative background, the MCSE types, and for whom these things make intuitive sense. And I'm just not that particular persona. I try mightily not to sound off too much in public when something is built for a user who is not me, because that feels a little unfair. But then I talk to people who are deep in the Windows weeds, and they have nothing better to say than I do about the Azure console sometimes. So part of me wonders if there's just a swing and a miss there. A large number of Azure customers, from what I can tell from speaking to thousands of customers while I was at Gartner, They would do things like provision Windows instances manually

and then just leave them running. That is like a big part of Azure usage is Windows servers that don't change, that are manually provisioned. So you're absolutely right. I find that in most cases in AWS, there's a decent part of that. Just swap Windows for Linux and you're pretty much there.

Like I keep saying, the highest form of infrastructure as code is ClickOps, where you use the console and then lie about using the console. And that isn't helped by the AWS ethos of, oh, stop going and doing things in the console, idiot. Oh, you built something in the console. How do you turn this into infrastructure as code? You throw the whole thing away and start over from scratch like you should have the first time. It's more little dispiriting. Although, have you seen CloudFormer? Have you seen the product called CloudFormer? I have. Are you talking about the one that came out of AWS itself or the third-party thing? No, the one that came out of AWS itself. It'll basically create the CloudFormation template based upon provisioned infrastructure, which is kind of

nice. So you don't have to throw things away necessarily. You can manually kind of ClickOps your way into where you want to be and then use CloudFormer to generate the CloudFormation template based upon your ClickOps. I haven't seen that at all in recent years. It came out in 2013. I made a bit of a splash around that, and it seems to have been largely forgotten. Ian McKay out of Australia, one of my favorite code terrorists, wound up building a console recorder too, I believe is what it was called, where there's now an extension that just watches what you do in the console, and then recreates the API calls and attendant IAM policies to wind up building, oh, this is how you would do

what you just did in Terraform or the CDK or CloudFormation or, God forbid, the CLI with a whole bunch of different, basically turn to a bash script. And that is just, I wish more things thought about it like that. Like, let me use what you have built,

which is fundamentally an IDE, the structure infrastructure, and then spit out the template that would generate that again in another account. That still feels like it's a far future concept. I used CloudFormer, I think, in the 2016-2017 time frame, and I was pretty amazed at what it did. I haven't touched it in a while, but surprisingly, a lot of AWS executives didn't know about it, actually. As of 2021, CloudFormer has been officially deprecated and removed. Yeah, that would explain it. They do deprecate things.

Who knew? Former2.com is apparently the spiritual replacement, but it is not immediately obvious to me who owns or runs that. Wait, what is the replacement? Former2.com. In fact, that is Ian McKay, who I just mentioned. That is his personal project. So, great. Awesome.

Once again, it gets put onto the shoulders of the community rather than the engineering teams that they hire to do these things. Wow. Yeah, Former2 is apparently the evolution of Console Recorder. So, there we are. That's the unification story. And it has last been updated

roughly a month before this recording. So it's still active. 800 and some odd commits so far. Cool. Yeah. So there are at least ways to get there, but it always feels, to be direct,

hacky. Like I'm not really doing this in the way that they envision me doing this, which is apparently JSON meets YAML meets, you know, the whale from my nightmares. Yeah, you know, I mean, when the rubber meets the road, the world is a much messier place

than how they want you to use it, right? I mean, things don't happen nearly as seamlessly as they envision. So yeah, I mean, I totally agree. I really want to thank you for being so generous with your time and lived experience, although some of us just call that trauma, I suppose, when it comes to cloud. If people want to learn more, where's the best place to find you? They can find me at my current endeavor, which is Perspect. So I would say Perspect.com, that's P-E-R-S-P-E-C-T.com, or I am at Raj on Twitter, however long that may be before the rug gets

pulled out from underneath all of us. And we will, of course, put links to that in the show notes. Thank you so much for being so generous with your time. I appreciate it. Thanks, Corey. Raj Bala, founder at Perspect. I'm cloud economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice. Whereas if you've hated this podcast, please leave a five-star review

on your podcast platform of choice, along with a very nice grid layout showing a quadrant of all the podcasts that are better than this one in the upper right. If your AWS bill keeps rising and your blood pressure is doing the same, then you need the Duck Bill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duck Bill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.