The Growing Dominion of Cloud Providers with Raj Bala

• Perspect: https://perspect.com
• former2.com: https://former2.com
• Twitter: https://twitter.com/raj

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: This episode is brought to us in part by our friends at Min.io

With more than 1.1 billion docker pulls - Most of which were not due to an unfortunate loop mistake, like the kind I like to make - and more than 37 thousand github stars, (which are admittedly harder to get wrong), MinIO has become the industry standard alternative to S3. It runs everywhere - public clouds, private clouds, Kubernetes distributions, baremetal, raspberry’s pi, colocations - even in AWS Local Zones.

The reason people like it comes down to its simplicity, scalability, enterprise features and best in class throughput. Software-defined and capable of running on almost any hardware you can imagine and some you probably can’t, MinIO can handle everything you can throw at it - and AWS has imagined a lot of things - from datalakes to databases.

Don’t take their word for it though - check it out at www.min.io and see for yourself. That’s www.min.io

Corey: 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.

Raj: Thank you, sir. Glad to be here.

Corey: 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 CIPS Magic Quadrant no?.

Raj: Correct. Correct. That is it.

Corey: 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.

Raj: It’s so funny because it’s so true, right? I mean, that’s what happens is they plaster all over their sites, you see a bunch of press releases, we get to take a big sigh of relief that the thing is finally published, and then on to the next Magic Quadrant.

Corey: 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.

Raj: 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, you know, they said, “Oh, you know, 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, low and behold, it’s actually true.

Corey: 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.” Ever since then, every time I’ve tried to race Graviton against anything comparable, there’s really been no contest.

Raj: 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.

Corey: 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. “Okay, we’re going to have to get circle back with you.” And then they bring in an engineer or six to the conversation. And it almost feels like they’re surprised that someone has actually used the thing. And they’ve 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 that 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.

Raj: Yeah, it’s pretty rare.

Corey: 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 read them?

Raj: 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—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 began to exert more and more pressure in somewhat nefarious ways. And so, we’ve written about this in the past, but it hasn’t… the market hasn’t reacted the way that I was hoping they would. I was hoping people would say, “Oh, my gosh, now we’ve—this cloud provider has got all this power over us. What do we do?”

Corey: 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?

Raj: 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. In 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 and 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, and ultimately, what comes down to rather strong-arm tactics.

Corey: Cory Doctorow recently had a great post on the increasing in-shit-ification 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.

Raj: 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, less dominance they have over customer, and the less likely they are to pull out some magic zeros. But the higher up you go into market share, the more likely they are to exert some pressure.

Corey: 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 AWS user experience, as long as that trend continues.

Raj: So, what we found—I say we. Since I—as if I’m still at Gartner—but what 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 MapReduce 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?

Corey: Being obsessed with someone isn’t necessarily considered to be a positive thing when we’re talking about interpersonal relationships, so but I sort of wonder why people are so willing to misinterpret it as a corporate slogan.

Raj: Yeah. I think that they should go work with their competitors. Like for Power BI; I mean, 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.

Corey: 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.

Raj: 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, you know, 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.

Corey: Those significant discounts feel like they come into play once they’ve served their purpose of getting you to sign on a commitment that that now takes over that purpose, which is getting you to commit—body and soul—to being on AWS. That tends to be obnoxious. And let me call out my own bias here. In my day job of fixing bills, I focused purely on AWS, whether it be in terms of actual optimization—because cost and architecture 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.

Raj: 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.

Corey: 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 an Azure are punishingly bad. In fact, even Azure had an 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.

Raj: 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.

Corey: 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 saying, “Hell with this. I’m done. I’m doing it on servers that live in my basement because that’s the end of it.”

Raj: 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, I have 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 SQL lite, but that’s not going to fit the bill—and their edge functions require JavaScript. So, there’s really only one game in town, unfortunately.

Corey: So, I imagine, based upon the nature of what you’re doing, that extreme low latency local to where the customer is paramount for you?

Raj: It is. It is. I mean, in any 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 of latency, they lose 1% in revenue. Which is astounding, right? So, the service that I’m building is essentially entirely latency-focused, from an architecture perspective, at least. So yeah.

Corey: One thing that came out back when AWS released CloudFront functions—which are JavaScript-required nonsense monstrosities, to be direct, to be honest; I kind of felt like they were taking another bite at the Lambda@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@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?

Raj: 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@Edge functions for viewer requests have to complete within five seconds. So, if there’s any latency 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. This is the same case with Cloudflare. So, Cloudflare has got package size limitations, they’ve got runtime duration limitations. So, basically bundling Stripe plus [Sentry 00:19:08] plus Boto3 could bust you out of that package size limitation really quickly.

Corey: 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.

Raj: Exactly. I mean, that might be the case, but I think so far, you know, knock on wood, I’ve been under the one megabyte. It’s one megabyte for Lambda@Edge for viewer requests if you can believe it.

Corey: 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.

Raj: Thank God Stripe has a relatively slim Python SDK.

Corey: One thing that I did—back when, you know, Twitter was not melting down all the time—is I built the lasttweetinaws.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@Edge and there were a few limitations around it that made it a nonstarter that were more a little frustrating.

Raj: 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?

Corey: Yes. It’s a Docker container that contains itself, and 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.

Raj: 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 App Runner, you actually have a single container that can react to events like it’s a Lambda function. That seems to be the most commonsense way where this stuff should go. It would make the lives of developers a whole lot easier. I’ll tell you that.

Corey: 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.

Raj: Azure is already doing that.

Corey: Yeah. Don’t let my Azure hate for 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.

Raj: 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—

Corey: Oh God.

Raj: —so particularly around storage. So, they’re the only cloud provider that calls object storage, 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 an append 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.”

Corey: 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 candidate, 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 a high watermark right now of a service name that is so bad that it impacts people’s career chances if they put it on the 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.

Raj: But just think about where Azure is—and speaking of Azure DevOps and thinking of where it exists in the overall toolchain 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—

Corey: And GitHub as well.

Raj: 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.

Corey: 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, 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 a cloud is Microsoft’s to lose if they don’t screw it up.

Raj: But that’s already in Visual Studio Code, right? Yeah. Like a deploy to Azure Functions thing is already there. Is that something you’re… is that what you’re referring to?

Corey: 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 built this as a—with a Docker compose file that talks about how to do this. Here’s a button that we’re just going to put up here—if you wanted 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.

Raj: Yeah. It’s a lot of power in the hands of lots of developers that they [audio break 00:26:41] doesn’t [audio break 00:26:41] they’re quite taking full advantage of yet. But it’s probably something that they should be.

Corey: I think they have such a good developer story and 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.

Raj: Have you used the Azure Console?

Corey: A couple of times in anger, and then I had to go to the bar for a few hours afterwards.

Raj: 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 their own console experience, I think it’s at least somewhat sane.

Corey: My way of rationalizing the current state of the Azure console has been to assume that there’s an entire ecosystem of folks coming 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.

Raj: 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.

Corey: I find that in most cases on 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 than a little dispiriting.

Raj: Although have you seen CloudFormer? Have you seen the product called CloudFormer?

Corey: I have. Are you talking about the one that came out AWS itself or the third-party thing? I’ve seen a couple.

Raj: No, the one that came out of AWS itself. It’ll basically create the CloudFormation template based upon provision 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.

Corey: I haven’t seen that at all in recent years. It came out in 2013 and made a bit of a splash around that and then seems to have been largely forgotten. Ian Mckay out of Australia, one of my favorite code terrorists, wound up building a Console Recorder 2, 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 turned into a bash script. And that is just, I wish more things I thought about it like that. Like, let me use what you have built—which is fundamentally an IDE—to 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.

Raj: I use CloudFormer, I think, in the 2016, 2017 timeframe and I was pretty amazed at what it did. I haven’t touched it for a while. But surprisingly, a lot of AWS executives didn’t know about it, actually.

Corey: Oh, as of 2021, CloudFormer has been officially deprecated—

Raj: Oh—

Corey: And removed.

Raj: Oh—

Corey: [crosstalk 00:31:08]. 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.

Raj: What, what is the replacement?

Corey: 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, you know, the engineering teams that they hire to do these things.

Raj: Wow.

Corey: Yeah. Former2 is apparently the evolution of Console Recorder. So, there we are. That’s the unification story.

Raj: Oh.

Corey: And it has last been updated roughly a month before this recording. So, it’s still active. Eight-hundred-and-some-odd commits so far.

Raj: Cool.

Corey: 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 envisioned me doing this, which is apparently JSON meets YAML meets, you know, the whale from my nightmares.

Raj: 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.

Corey: 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?

Raj: 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 dot com. Or I am @raj on Twitter, however long that may be before the rug gets pulled out from underneath all of us.

Corey: And we will, of course, put links to that in the [show notes 00:32:51]. Thank you so much for being so generous with your time. I appreciate it.

Raj: Thanks, Corey.

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.

Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.