Ryan: 0:00

The well-elected framework is really a good tool for looking at one workload at a time. Right. A workload is a set of components that make up an application. If a company has 15 workloads, they're doing 15 well-elected reviews. Well, that's great at the workload level, but what is it at the organization level that gives the whole organizational kind of governance and best practices across all 15 of those workloads?

William: 0:34

Hello world. I am your host, william, and I'm here to bring that main character, energy, no cap. And with me is my co-host, yvonne Sharp, one of the greatest minds in deductive reasoning and literally slaying that cheesecake game daily. She's so based, it's actually unhinged. How are you doing today, yvonne?

Eyvonne: 1:00

I have no idea what you just said. You're trying to be the cool kid on the block and you need a new crowd because it's over my head, man.

William: 1:12

So for the audience, my you know again, my son plays a travel sport. So I'm in this locker room with all these eight, nine and 10 year olds and they talk in a different language and I'm trying very hard to learn some of that language, but it's honestly like learning a complete new language. It's pretty wild.

Eyvonne: 1:29

When we were children, all you had to say was something was bad, which actually back then meant it was good, and our elders gave us the eye roll, and I feel like that challenge has increased, or that dynamic is just growing exponentially. Like they're not even words now.

William: 1:52

So Agreed, yeah, joining us today is Ryan Cummingdeer, ceo at Platformer. So, first of all, thanks for joining us today, ryan, and how are things going? Did you? Do you have all the Christmas shopping done?

Ryan: 2:07

I do have all the Christmas shopping done. This year we jumped ahead a little bit before Thanksgiving to take care of a lot of those this year.

William: 2:16

Talk about prepared. I love it. That's awesome.

Ryan: 2:20

We actually opened Christmas gifts a little bit already. So my kids, can you know, while they're out of school, spend the whole Christmas break playing with their toys.

Eyvonne: 2:31

Awesome.

William: 2:32

I wish my parents would have done that with me growing up. Thank you again for joining us. I think we both had the opportunity to be at reInvent this last year and just kind of looking through. A lot of your experience has been in cloud, or at least your more recent experience. But let's go back maybe a little bit further first. You know, do you want to give us just kind of a quick overview of your background, Like, was it always grounded in software or how did you get to where you are today?

Ryan: 3:02

Sure, long story short, I took my first programming class in seventh grade, loved it ever since.

Ryan: 3:09

So I was in app development and programming from the mid to late 90s, all the way until today, did a lot of consulting, a lot of application building, mobile apps, web apps, enterprise like B2B apps as well. But, yeah, I got introduced to the cloud and I think 2008. At that time I had a data center where I hosted all of my websites that I built and that data center went down while I was on vacation and I had to drive all the way back into town. I was like a six hour drive in the middle of the night to work on my servers and I think shortly after that I said where can I put these that are not in my closet anymore? So I think 2008 is when I started looking at AWS at that time. So I've moving all my servers up to EC2s. And then after that it was kind of a history from AWS's perspective. I joined AWS on every one of the services they started working on for the last 15 years and have never looked back.

Eyvonne: 4:07

It's got to be a better way. Moment. When we were hosting infrastructure right Years ago, I worked for an engineering firm and the cooling apparatus that was in our data center would frequently go out and there were no windows. There was no, and you know, I remember, in the middle of the dice storm, the power went out. Driving to the office and trying to like skate up the frozen driveway to get in the building, to open the door, to set up, you know, to try and cool it, with no power in the building other than the generator power that was running the systems but not the coolant. And uh yeah, we've, we've all been like there's got to be a better way yeah, not having to worry about that infrastructure is is pretty a pretty big deal yeah, that's exactly what I was gonna say is, for those of us that love the software side of things, uh, dealing with the hardware and the infrastructure.

Ryan: 5:03

Was that necessary evil that we were happy to get rid of? So?

William: 5:07

absolutely yeah. Even with if you think about just uh, things, things in the past that were so hard like if you had, like, multiple data centers, you have to make sure your, your application is highly available. You know, the bigger the company means you probably have some dr to look after as well, and having to build out your high availability in DR across multiple data centers for a highly distributed application, versus doing it in cloud, it is much different and much easier.

Ryan: 5:40

I think, as we say, the undifferentiated heavy lifting that every company has used to do by doing disaster recovery environments, by doing infrastructure management, is now mostly removed at some level and as far as the full-time jobs that require that specialty knowledge, now you've transitioned to more of that cloud specialty knowledge and hopefully have that opportunity to scale more.

William: 6:03

Yeah, so let's talk. I mean, one of the things you have experience with is the AWS Well-Architected Framework, or at least what I could see from some of the work that you've done. If you had to, I guess, if you had to explain what this framework is to you know maybe someone in a coffee shop that doesn't know tech as well as you do how would you explain it?

Ryan: 6:27

Um, I would probably start with why I even looked at the well-actuated framework um and why I started there. Um, so, as I had built up my companies over the last 15 years, um, I I was helping a lot, I was a consultant and I was helping a lot of customers over and over and over again, most of them in that startup to small to medium size and they were asking for a software development company to come in and help them out. But what they really needed was a CTO to kind of tell them how to manage their technology, how to look at everything from security of the software to reliability of the software, to the cost Make sure that the cost of the goods sold is matching what the revenue model looks like for their customers. So more and more of those customers started leaning on us to give them more than just technology what they said technology, software development guidance, but really kind of business guidance. And so I kind of built my own little internal framework back in like 2012, just for like a checklist of things that I think I talked to the customers about. But then when Amazon came out with that well-elected framework that replaced mine and it was by far the most holistic kind of business checklist of how you should look at technology, how to manage as far as like, best practices things, questions. You should ask yourself whether you are outsourcing your IT team, whether you have an in-house IT team, whether your technology is in the cloud or whether your technology is on-prem. It asks you all the right questions to at least think through what matters to the business.

Ryan: 7:51

And so I started working, I think, as a beta partner for the Well-Contributed team in like 2016. And then when it launched, I think me personally did more well-experienced reviews than any other solutions architect over like a four-year period, so I really enjoyed it. As I told other, my job title at the time was a CTO and as I told other CTOs, like, if you want to be a good CTO, you've got to memorize a well-experienced framework. It gives you this framework, this lane to stay in to say this is what good looks like, but it helps you kind of communicate that to the other cost departments, security departments, operations, that product owners for usability and performance. So it helps you translate from just writing the code and getting the job done to actually what matters to business. So it was kind of my CTO Bible, I guess you can say, for a long time.

Ryan: 8:47

I sold my company in 2020. And then, after I sold my company, I went and joined that Lockdown team. So I became a pillar lead for that Lockdown team. Just because I loved it so much and I wanted to kind of keep seeing it mature and grow and get to more of the customers, get to more of the lessons learned. I was like okay, well, what didn't the walkthrough framework cover? What pain points was a surprise to the customer? Because they went through this and we had a gap. And so I wanted to kind of start filling in some more of those gaps on the walkthrough framework and I really enjoyed working on those best practices and understanding how it impacts customers.

William: 9:24

That's awesome. I love how they have. For those of you that don't know, there's six pillars. Which pillar did you work with specifically?

Ryan: 9:35

I was in charge of the performance pillar, which by far is the most technical pillar, and it was probably because of my application development background.

William: 9:44

I know that, like there's so like I had the opportunity to go through and do some things with this framework as well, like in a, you know, within a real company.

William: 9:53

And one of the things that I thought was interesting just because you have these, this well-architected framework, it doesn't mean that it makes the work any easier. It doesn't mean that it makes the work any easier or that you know, if you don't under understand your applications, that you're there's some like easy button, you still there's a lot of work to do and a lot of times what tends to happen is you end up bringing in some professional services or something like that to assist in this journey, because there's going to be a lot of times there's things that a company, a big company, is ready for, but then there's a lot of things that that company may not be ready for. So I guess where am I going with this? So do you have any like uh, is there any misconceptions that you've seen over the years that are maybe common with companies as far as, like, adopting this framework? Like, oh, we think we understand this, but then you start, you know the wheels start turning and you start doing things and it's like, oh wait, we.

Ryan: 10:54

We didn't understand this as well as we thought um yeah, so, um, as you said, it has six pillars, um, and to repeat what those pillars are, you have operations, which is always a good place to start because it really is an underlying pillar across all those other five pillars. You've got security, you've got costs, you have performance, you have sustainability and you have reliability. And what I have seen as far as misunderstanding or even misusing that well-actuated framework is the well-actuated framework team at AWS, at Azure, at GCP. They try to make it an objective best practices and recommendations, and what I have found after doing hundreds of these well-educated reviews is that the two biggest outcomes of going through that is one, education of what best practices look like, but number two is prioritizing your risks that are contextual to your business, and that is, I think, the biggest struggle that companies have, or that AWS has trying to use a blockchain framework for customers is trying to make an objective across all companies with the same level of risk based on the same best practices, and I found that that's not the case.

Ryan: 12:10

A startup has a different level of acceptance of a risk, such as disaster recovery, than an enterprise company does, and so, even though the long-shaded framework might say, because you don't have a good DR plan in place, that might be a high risk for you.

Ryan: 12:25

Well, that's not necessarily true at a startup company when they are trying to do time to market, when they're trying to prove out a market pain point, whereas opposed to the enterprise company where every minute downtime is an extra $10,000 an hour right or whatever that ends up being with the cost level.

Ryan: 12:41

So that was probably the biggest friction that the Wellic framework has is that it is not subjective to based on your company profile. Framework has is that it is not subjective to base it based on your company profile. One of the initiatives that I tried to start at the Wellick when I was on the Wellick team was creating a business profile that would show or hide different best practices based on where we thought you were coming from. So a startup company that is going digital native from day one is a completely different list of best practices and risks than an enterprise company that had a lift and shift migration two years ago and is running a $1 million annual indie dress spend. So that was probably the biggest friction that I've seen customers experience with that well-intended framework and I think and I hope that the well-intended team is, and if they're listening today. I hope they are taking some of that and trying to figure out how to adapt it to companies.

Eyvonne: 13:38

So so, as you, as you look at those frameworks and I think you know I've worked with customers, I was a customer, I've worked with customers for a long time you know they often want a prescriptive answer. And how do you, how do you guide customers when, yeah, you've got a framework, but but the framework isn't a turn by turn map for how to get where you want to go. It's, it's a framework. It's like well, you, you, you know if you're, if you're in Kentucky and you're driving to Oregon, you know people need to go, you know north and west, but it's not a turn by turn guide. How do you help fill in those blanks for customers who you know really what they really want is a turn by turn.

Ryan: 14:26

So that's a great question and a topic and I believe all the cloud providers are going to head those directions. So, out of the well-optinated framework about 60% of the best practices you can be fairly prescriptive on the recommendation. And because you can be prescriptive on the recommendation, that leads to the question of then why can't that be an automated recommendation? And why can't we have that built into our cloud consoles to say now go fix it. If you can automatically identify this as a problem and you're recommending it to me, why can't you just automatically fix it for me? And there are a lot of third party companies out there trying to do that.

Ryan: 15:03

There's also AWS. Specifically, I think the trusted advisor team was starting to work with the well-elected framework team saying if you're recommending that all of our servers have an encrypted EBS volume, then when we find one, we'll make an easy button for the customer to say this is your prescriptive remediation. For that, you know, is the is the reality that every company has a snowflake solution out there. Uh, with different tech stocks, different business priorities, um, different recovery time objectives, different security compliances, and it's really hard to create a one-size-fit-all um that is inexpensive and um appropriate for every company out there. So there's always going to be some need for either professional services companies or for education for the developers to come in and do it from the ground up.

William: 15:59

Yeah, so earlier you were talking about being on the performance pillar, which is great. Many or a lot of conversations, I think these days, at least that I'm in, tend to resolve or revolve around cost optimization, you know, but sometimes it feels like it's competing with performance and there's just a lot of confusion there. Is there some like balance or sweet spot to be found, you know, between cost and performance?

Ryan: 16:30

Absolutely, and I think that depends on your business goals, right. So if you have a website that is loading after doing a page load after 10 seconds, you have to look at that opportunity loss that you are experiencing with those customers, right, that they just can't sit around and wait and look at what that could be if you sped that website up to less than a second type of page load, would that increase usability? Would that increase your expansion of your product? Would that include more customers coming on board? You always have to look at those third-party numbers on what makes sense for your company and for your technology product there.

Ryan: 17:08

But yeah, a lot of times on the performance, you can get bigger servers, faster servers, faster IOPS and that does result in an instantly higher cost. But if you can now offset that with more on-demand, not reserved kind of compute for all the times that you might need to be running that server, so it's more scaling as your customers scale, there's always kind of those offsets you can run there. But that was a constant conversation while I was having is me and the cost pillar his name was Ben at the time sitting down side by side and saying how can we get both faster and cheaper at the same time, and a lot of times. Then you always have the underlying requirement of, and we have to meet the security requirement, no matter how fast and how cheap we go, and that was. It's always that natural friction, which is why it's not one size fits all as a remediation.

Eyvonne: 18:07

Well, and there's the. We need the fastest performance we can get side of the coin. The enterprise we need comes from the enterprise world, which is really where, where william and I cut our teeth, there's this we're going to deploy the biggest, fastest thing there, just in case, right. And so there isn't, there isn't muscle memory and there aren't skills built around determining what exactly do I need. You know, like, what does this application require? And how do I determine that so that I'm not over deploying right, because I see so many customers who end up upside down in a cost scenario because they didn't really interrogate what kind of performance their application needed and they just over deployed because they felt like they could and because they have that old muscle memory around. Just give me the fastest, because I've already bought it all anyway. Right, they're not used to, you know, paying by the slice. As an example, they're like just give me a whole pizza. So how do you handle that side of it?

Ryan: 19:16

Well, the cloud providers, so AWS specifically. They are introducing more and more services and tools that will help you identify that quickly. In the past 10 years there's been a lot of companies that have been filling that hole of showing you your unused CPU or disk space or IOPS and network usage. But AWS now has a cost optimization dashboard that really highlights for you, say, here's your unused resources and your opportunity to shrink those down. So those are the easy, low-hanging identification and recommendations that you could automate that prescriptive solution for the customers on.

Ryan: 19:57

There's always those exceptions, especially in the enterprise world. Virtual memory manager is always the gotcha when you're trying to reserve those big EC2s, those big servers where you need memory more than you need CPU. And so right off the bat those enterprises were like, well, I'm not going to look at the memory optimized instance classes, I'm going to just look at the general ones, and because that one has got 32 gigs of memory, that's what I'm going to use. And then they end up having 90% of unused CPU. So you end up getting more specialized later down the road into more of that memory optimized because of the Java memory manager. But yeah, aws is trying to help those customers. That's one thing I actually really love about AWS is they are so customer obsessed. They are willing to figure out how to save the customer money, even though it's going to get them less revenue in the door, because they believe that customer is going to stick around and use that budget elsewhere on innovation and growth.

William: 20:56

Great answer there, which I guess I wanted to sort of split this up. So I did want to talk about the well-architected framework and we've talked about a lot of good things, but what I really wanted to talk to you about, honestly, was you know you in 2023, you co-founded Platformer with Bill Stock. So, first of all, was there any particular inspiration behind going off and starting this company?

Ryan: 21:24

Yeah, absolutely, and you've actually helped me kind of talk a little bit about already. So the well-elected framework is really a good tool for looking at one workload at a time, right. A workload is a set of components that make up an application, and so if a company has 15 workloads, they're doing 15 well-elected reviews. Well, that's great at the workload level, but what is it at the organization level that gives a whole organizational kind of governance and best practices across all 15 of those workloads? And that's really why we started Platformer. We saw that companies now had some guidance from the blockchain framework team on how to make one software run really well and meets best practices. They introduced the cloud center of excellence idea and team for a governing group of people at a enterprise company or a midsize company to define what cloud best practices look like. But there's no tools. There's no.

Ryan: 22:22

The industry is just now maturing to the point where now we can start looking at the bigger company management company governance across all of their cloud usage, and that's why we actually started Platformer is some of these services that AWS has released over the last four years have just now started making it possible to start automating more of the organizational governance where it hasn't been existing in the past. And so we saw that companies coming on board AWS were still. The only option they had were professional services, were consultants that gave companies kind of snowflake solutions and their own unique spin based on their experiences on how to set up company governance, to then look at all 15 of your workloads, making sure they have the same governance for operations, for security, for cost, for liability, to meet those business requirements. So that is the fundamental reason why we built Platformer was to elevate it from a workload level up to the company level and say let's look at this holistically.

William: 23:23

And I'm guessing by the name Platformer. It is a platform so kind of like an as-a-service platform that you would plug your as a certain kind of like an as a service platform that you would plug your stuff into and begin working on. Is that a correct assumption?

Ryan: 23:35

It is a good. This is a good, a good assumption. Um, it is a platform for cloud ops. We're for cloud governance. Um, what we, uh our philosophy here is um, you know Bill Stock, my co-founder. He's been. He was a AWS pro serve for about six years. I ran a consulting company for about 15 years.

Ryan: 23:53

We are taking all of our prescriptive guidance on how to build cloud governance as well as how to manage workloads within AWS and making that into a product and a platform. The number one thing that customers want is just a prescriptive answer, as you said earlier. It's like okay, I have a WordPress website. Well, how do I host a WordPress website on AWS? If you go look at AWS documentation, they'll say here's 30 different ways to do it, but we know as a consultant there's really only one or two ways to do it right that meet most of those business requirements out there. Sorry, I picked up WordPress. It's probably one of the least boring or the most boring topics of hosting technology on a website, but that's an example of saying let us be a very prescriptive push button. Go configure AWS for you based on your workload type and based on your business requirements.

William: 24:44

That's great and you're absolutely right, building on AWS is like is like building a house, like you can go to Home Depot and say, hey, I need to build a house. I'm going to say like, there's the nails, there's the concrete, there's all your stuff. Have fun, yeah, it'd be a blast, but there's got to be some middle ground to where you do have, you know, sort of these platforms that bring a lot of things together for you and they still allow you to have the flexibility of what you want your outcome to be and, you know, sort of tie back into your organizational structure, your organizational policies, compliance and all these things. So you still get the flexibility to choose how something is done, but a lot of the tedious, the you know, all this work under that layer is kind of abstracted to you, which is great?

Ryan: 25:33

Yeah, absolutely. I mean, amazon uses the analogy of Lego blocks, right? So Amazon's got more than 220 different services, so 220 different types of Lego blocks that they give the customers and they kind of just say here, have fun, and you can create a mess out of those Lego blocks if you really wanted to. Where we are trying to say no, we know how to build this Lego dinosaur. Really well, let's build it for you. We're going to ask you a few questions like what color do you want? Some basic things that any company would be able to dictate to a consulting company, and then, 90% of the times, we're just going to build everything else out behind the scenes and take care of that for the customer. Yeah, and that's where we're really excited to head out. We're taking that.

Ryan: 26:16

So I see this cloud governance space as kind of three different areas.

Ryan: 26:21

You have your organizational governance, which is like your security compliance across the board, your operations across the board, so your standard operating procedures for each workload type, where usually each department needs to follow.

Ryan: 26:33

And then your cost, your budgets, budgets, your cfo, that's saying here's all my budgets across all my workload types. So you have your organizational governance. And then you have your development team or your I, your it team's governance and, um, the the term platform engineering has come out in the last few years. Um, that's kind of been built off of the devops, uh, role, um, and we're taking a lot of that too and say now we have the company governance, we're moving into platform engineering so we can help out your development teams and your product ownership teams. And then the final thing we want to do is now help your support team and understand the health of both your company and your workload types, because, in the end, that support team, your internal security team, your IT team, your SREs they need to understand how to define health between not only the company but also each workload type that you're managing.

Eyvonne: 27:22

One of the I love the Lego analogy. By the way, one of the things I've said and I believe a lot of this is a maturity curve with public cloud Like it's, you know it's just. We are just now getting enough infrastructure in the public cloud getting it's, you know it's just. We are just now getting enough infrastructure in the public cloud, getting large enough organizations in there where we realize, you know, wait, we need governance. It used to be for me that things like governance, program management, all of that were dirty words, but at the end of the day you've got to have some structure for how things get done. But the analogy that I've used often is that customers want a Millennium Falcon right, they want the Lego Millennium Falcon and they want that to sit on their shelf and look at, and often what they get handed is a bag of gray Lego blocks without instructions and frameworks. Governance best practices are the difference between that bag of gray Lego blocks and a constructed thing that actually delivers what you want it to.

Ryan: 28:29

Yeah, I think. I think you're absolutely right. So, in my own words, william, I think platformer is the evolution of where well-actuated framework will go. I think well-actuated framework is at a workload type, and I think AWS has released what's called their cloud foundations, best practices, which is really that governance at the top level, and that's where we are trying to start with and get ahead of the customers to say there's easy answers to this Go find your Lego masters, your master builders Is that what it's called? Your master builders? And let us build out those Lego solutions for you at a time, and you just press the go button. So, yeah, we're excited about that.

William: 29:09

I have an interesting thought Well, not interesting, I think it's kind of a dismal thought really but a lot of times, many, many companies, before they will go out and they will buy a platform to do a thing, they have to try it on their own. They have to go and build and learn a few things the hard way. Because a lot of times, depending on what, like, say, you work on on the infrastructure side of things, for instance, you, you think you can build the best infrastructure. You don't. You don't want to, you don't want help, you don't want to buy another platform, but a lot of the times you don't realize it, but you you really need it. And so what that means is you, you basically have some technical debt that you have to tidy up and that technical debt can ride for years. Am I is that? Has that been kind of your experience? And how can? Is there an easy way to change? I guess that's perspective in a sense. But is there an easy way to change perspective there?

Ryan: 30:09

Well, there's always a conversation to build versus buy right and to the decisions that come into play when you're discussing that is time to market is the amount of technical debt you're willing to get on board, the expertise that you have in house that's available for this? Those are always the type of questions that you're going to bring up when you do build versus buy. At least my philosophy, at least my philosophy with platformers specifically, is that we are not giving you technical debt. From an outside vendor's perspective, our only outcome is 100% configured AWS services and let AWS manage the technical debt for you with their feature upgrades, with their service improvements, and then a lot of that then requires education on making sure your team is up to speed on how to use those services, going right out on the gate and buying that.

Ryan: 31:01

I've always told customers that you know a technology solution has about a three to five year life cycle now between something dramatically changing coming out that's going to make it irrelevant. So it only invests as much as you can when you can get that return on investment over a five-year period of time. Otherwise, you're going to have to move to another platform, another solution, another tool, whatever that ends up being. You need to be able to reevaluate it. Those customers that have been on the same platform, the same tool, for 10, 15 years. They're not doing themselves any benefits there because end up, uh, not taking advantage of the latest, you know, innovation technology, so forth. Especially looking right now like gen ai is everywhere, and if there's a tool that doesn't have gen ai on it, you start re-evaluating pretty quick so this is true.

William: 31:46

Yeah, ai is in every coming you know freshly minted william from reinvent um ai, ai, ai. Everywhere, actually, every event that I think I've been to, uh, every event that I've probably been to this year, there's been some sort of theme or rebrand towards ai.

Ryan: 32:05

Yeah, when, when we were looking at raising uh funds for a platformer, every single one of our investor um pitches. Their questions was how do you use the AI? Where is it in your title? Where is it your documentation? It was obviously the, the answer they were all looking for.

William: 32:25

Oh, I was on mute there. Sorry about that. I'll have to rephrase. I have to like look for that line and then come back to it. So one, one question I have as well. So a lot of the you know just kind of looking at what Platformer is doing, you know you have a focus with AWS and there's an outcropping of tools and platforms and some are geared towards single cloud, some are geared towards, you know, taking on other clouds as well. So do you have a multi-cloud future or do you want to stay like zoned in, specifically with providing value to the AWS ecosystem?

Ryan: 33:01

So have you been talking to my investors? Is that why you bring up that question?

William: 33:06

So to kind of like back that up, I actually work for a company, a network platform, that builds infrastructure, and we do so for kind of like what you all would do with your area of expertise. We do for networking, and we do it across multiple clouds now, so I usually lead with that question.

Ryan: 33:26

So right now my team's expertise is in AWS. My support system is in AWS, whether it's partners and customers, whether it's the AWS leadership. So we have more momentum within the AWS world right now. I think obviously their their TAM SAM SOM if I just looked at AWS is quite large on the number of customers that I can onboard into a platformer. I also will get more funding opportunities from AWS if I say I'm AWS only. So there's a lot of reasons why today I am saying I'm a single cloud solution.

Ryan: 34:07

Now what I'm hoping for is, as expansion comes, as I get a critical mass of customers in AWS and I end up being the go-to answer for Greenfield customers going to AWS on its migrations or Visual Native, or for those modernization clients that are looking to fix their cloud governance, then it will start looking into Azure and maybe even GCP. But that'll be down the road. That'll be when I don't need AWS funding to help me scale, because once I say I'm multi-cloud, I lose a lot of the individual funding per cloud. So, yes, it's coming in the future, but only time will tell when. That is yeah and I'll have to hire some leadership that are more familiar with the other clouds. I was an Azure partner back in the day, but then I quickly switched to AWS, I think in 2012, and then never looked back after that.

William: 35:03

Yeah, well, it's funny.

William: 35:04

I think I remember I was naive at one point when I was working for a company that was one cloud and and I learned that cloud fairly well it was AWS, and then we went multi-cloud and the multi-cloud decision wasn't my decision, of course, but I was overconfident, I think, at the time, in our ability to actually set up the governance, the whole scaffolding of that second cloud.

William: 35:37

You just don't know, until you go and you try to do it, you think things, kubernetes, platforms between clouds, and they're very different, even like the network buckets that you place them in, how they span and how they scale across regions and availability zones and all these things. There's so many differences and they're tiny differences, but all those tiny little differences they add up to just change, you know, entirely change the architecture really. So, yeah, it's definitely and you threw I've met a few folks out there that are very deep in more than one cloud like very deep, like great expertise, but it's a lot, especially if you're looking beyond one tight. You know multiple services, infrastructure and you bring in more things. It's definitely a huge challenge.

Ryan: 36:38

So that's usually a hill I will die on is when I give advice to customers. When they always ask me, should I be multi-cloud? And they have a choice from day one, I usually will say no, go single cloud only. The benefits of going single cloud far outweigh the benefits of being multi cloud, unless there's a really good reason, whether it's a compliance reason or because you're getting half a million dollars in funds from Azure and they want you to put something on Azure or AWS. I've never regretted saying that to customers. If you have a choice, I'd go single cloud.

Ryan: 37:13

That piggybacks off my last statement, though, of saying but if you get so far into the weeds and you end up backing yourself into a corner, you always have to reevaluate that decision in the future, and so it's never a one-time decision to move on.

Ryan: 37:27

You always have to rethink that. But the investment you have in educating your staff, the partnership that you give with cloud whether it's AWS or Azure or GCP the support that they'll give you to be on that single cloud Coming from the performance pillar expertise the deeper you go into a technology, the more you know how something in cloud native works, the better performance is going to be, the less costly it's going to be, the more secure it's going to be. If you try to baseline, like, normalize your technology stack like Kubernetes is a great example. So you can put it theoretically from AWS to Azure to on-prem, you're going to increase all of your costs, you're going to decrease all of your performance and you're going to make it a little less secure because of that. So it dumbs down all of your benefits when you go multi-cloud.

William: 38:16

Yeah, I remember there was some big hype around Kubernetes and I think it was like DR. This was like years ago, Even at some of the companies I worked for. Like there was this thought that, you know, a containerized workload can just be placed anywhere. So we want the best diversity possible, so we're going to have an app that lives in one cloud in one region and then for that other region it's going to be a different cloud in a region. And you know, really the right way to do that is to do, you know, span across availability zones, of course, and then do regional DR with a single cloud provider. Like usually taking a single application and running that across multiple clouds doesn't make much sense. Well, I don't think it would ever make sense, unless maybe someone if you're out there and this makes sense and you've done something valuable with it, reach out, we would love to have you on. Yeah, that's yeah.

Ryan: 39:08

I've helped a few enterprise companies be multi-cloud for the sole purpose of disaster recovery and typically the complexity that that adds, because in the end, you still have the single point of failure, which is typically your DNS management, your routing, network routing, and a long time is during those game days where you test out your disaster recovery solution. You end up figuring, you end up finding, coming to the conclusion you're like huh, how do we take care of this? Because, for example, in AWS, if their US East 1 region goes down, which is their control plane, it's where they manage all of their services. If that goes down, there's no way for me to manage Route 53, even if I need to point it to Azure, Azure. And then if I end up moving to a third-party DNS round or low, underlying are those third-party DNS?

Ryan: 39:57

Is it on-prem, Is it hosted by AWS or Azure behind the scenes? It's so hard to be truly redundant across the board and so sticking with one cloud provider, being multi-region, having air gaps in place for multiple accounts, is your best bet. And because, as you said, if you're not building an application that uses that cloud native, there's so many disadvantages of making it objective, of making it standalone and not dependent on the cloud services. You're losing so much value out of that that you would only really see the value of that if your environment goes down. Again and again and again you end up using that disaster recovery environment.

Eyvonne: 40:39

Well, dependency mapping has always been a challenge, right, and especially dependency mapping over time, because you may have your dependency maps built out in the very beginning, but then services move around and you don't always completely redo your dependency map, right? I mean, we ran into this in the early days of virtualization, right, where you would have a, you would have a domain controller that was hardware based, but then at some point it was like well, everything's virtualized, now let's just virtualize these remaining domain controllers. Then, all of a sudden, you have a virtualization outage. Oh, by the way, now your domain controllers are down and you can't authenticate anything. Right, like this is a 15-year-old problem that has not gotten better. That's actually gotten worse with the cloud, those dependency mappings, and you're absolutely right If you lose identity, if you lose DNS, nothing else matters. I think so.

Eyvonne: 41:32

The thing I've seen customers do that I think works really well is you select a primary cloud. That's where the vast majority of your workloads go. Undifferentiated services are going to run in that cloud. It's your primary. And then if you have a differentiated service that you need to run in another cloud, sure, you can do that and that may make sense. But you're absolutely right on the contractual pieces, the discounting the cloud relationship, and and I've seen organizations who have tried to take a um unopinionated view of cloud um, and it just doesn't work. Well, it's, it's very expensive. You end up with services that run in a million different places, that are managed by a million different people, and and then how do you govern that? Right? And so, while I might argue for a different public cloud to be your primary cloud, I still very much agree that that you need a primary cloud to run your services in, and that's what's going to make organizational sense for you, and to not make that decision is really, frankly, a failure of leadership for your organization.

Ryan: 42:43

Yeah.

Ryan: 42:44

What I have found, though, is back to the original topic of cloud governance, is some of those questions, and guidance is still missing out there in the industry in general.

Ryan: 42:53

It's saying pick a primary cloud for most of your control plane, for your identity, for your DNS, for your services that are kind of singletons like that and then this is how to back into a multi-cloud strategy, or this is how to back into a disaster recovery in a single cloud environment. So there's still a lot of, I'd say, missing industry best practices that are from a central source or from an authority at some level, and so that's really where I think the future of cloud is going to go over the next few years. Looking at the Amazon services or the, even the Azure services that have been released in the last three years so many more of them are now at the governance letter level at this that it's just now. This industry is just now starting to bring up this more broader topic, just like this year. Up until now, it was trying to solve issues from the bottom up, and I think we're just now able to get from the top and start going down now.

William: 43:44

Yeah, that's a great way to put it. I think I'm fresh. I'm fresh out of questions. What about you, Yvonne? Do you got anything else you want to hit on?

Eyvonne: 43:51

No, I think it's been a great conversation.

William: 43:52

Yeah, I think it's been a great conversation. Yeah, I think we're hitting our time cap. Which good timing. But if the audience wants to find you, ryan, where can they find you at?

Ryan: 44:02

Well, you can find me on LinkedIn If you search for my name, ryan Kimgear, or you can find me on the platformercloud website, and that's no E before the last R, so platformercloud.

William: 44:16

I love that. By the way, that is just a really uh you know, it's so hard to find a name that is like different, that stands out, that's not overly complicated or just something random, and it is like true, to kind of like what you're doing. But yeah, that's a really cool name. So kudos on the brain architect behind the name and the brand.

Ryan: 44:38

So, to bring this back to the beginning, I think I'm going to try to make that a Gen Z slang word, so people just start naturally saying it in the in the everyday language.

William: 44:47

I dig it.