Screaming in the Cloud - Billion-Line Cloud Bills with Rodrigo Flores

Episode Date: August 25, 2020

About Rodrigo FloresRodrigo Flores is Managing Director of the Accenture Cloud Platform (ACP) in charge of Architecture, Product Management and Engineering innovation. Currently he leads a team of 400 people delivering the service to 3000 clients and $400M of cloud spend. The Accenture Cloud Platform is a hybrid cloud service that delivers a variety of providers such as Amazon, Azure, Google, VMware and Microsoft-based private clouds. Additionally, Cloud Management Services such as patching, security, backup, hardening, monitoring and security. This includes cloud brokering, security and cloud optimization services.Additionally, Rodrigo frequently works with Global 2000 enterprises to help them in their cloud transformation and migration projects. These engagements include DevOps, financial, security and program reviews as well as one-on-one coaching and consulting with C-suite executives.Prior to Accenture, Rodrigo worked at Cisco in the cloud software business group as CTO. He founded newScale (acquired by Cisco) the service catalog and cloud management platform pioneer from 2000--2011.Links Referenced: Accenture main site: http://accenture.com/Rodrigo’s blog “Working Class CTO”: https://workingclasscto.com/LinkedIn: https://www.linkedin.com/in/roflores/Twitter: @rfflores

Hello, and welcome to Screaming in the Cloud, with your host, cloud economist 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 tools. It'll move your business forward fast. Okay, let's talk about what this really is. It's Visual Basic for Interfaces. Say I needed a tool to, I don't know, assemble a whole bunch of links into a weekly sarcastic newsletter that I send to everyone. I can drag various components onto a canvas. Buttons, checkboxes, tables, etc. Then I can

wire all of those things up to queries with all kinds of different parameters. Post, get, tables, etc. Then I can wire all of those things up to queries with all kinds of different parameters. Post, get, put, delete, etc. It all connects to virtually every database natively, or you can do what I did and build a whole crap ton of Lambda functions, shove them behind some APIs gateway, and use that instead. It speaks MySQL, Postgres, Dynamo, not Route 53 in a notable oversight, but nothing's perfect. Any given component then lets me tell it which query to run when I invoke it. Then it lets me wire up all of those disparate APIs into sensible interfaces, and I don't know front-end. That's the most important part here. Retool is transformational for those of us who aren't front-end types. It unlocks a capability I didn't have until I found this product. I honestly haven't been this enthusiastic about a tool for a long time. Sure, they're sponsoring this, but I'm also a customer and a super happy one at that. retool.com slash lastweekinaws. That's retool.com slash lastweekinaws

and tell them Corey sent you because they are about to be hearing way more from me. Normally, I like to snark about the various sponsors that sponsor these episodes, but I'm faced with a bit of a challenge because this episode is sponsored in part by A Cloud Guru. They're the company that's sort of famous for teaching the world to cloud, and it's very, very hard to come up with anything meaningfully insulting about them. So I'm not really going to try.

They've recently improved their platform significantly, and it brings both the benefits of A Cloud Guru that we all know and love, as well as the recently acquired Linux Academy together. That means that there's now an effective, hands-on, and comprehensive skills development platform for AWS, Azure, Google Cloud, and beyond. Yes, and beyond is doing a lot of heavy lifting right there in that sentence. They have a bunch of new courses and labs that are available. For my purposes, they have a terrific learn-by-doing experience that you absolutely want to take a look at.

And they also have business offerings as well under ACG for Business. Check them out. Visit acloudguru.com to learn more. Tell them Corey sent you and wait for them to instinctively flinch. That's acloudguru.com. Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by Rodrigo Flores,

whose professional affiliation is a bit of a story. Originally, he was the founder of the NuScale platform, which was sold to Cisco. And after time at Cisco, he then went to become a managing director at a small consulting company called Accenture. Rodrigo, welcome to the show. Hi, happy to be here. So you're coming to this show from a slightly different perspective of the majority of our guests because you don't work for

a cloud provider itself, and you don't work for one of those cloud-native type of companies. You're coming from a service provider perspective, which is rare in its own right, and specifically one that's focused on the global 2,000 largest enterprises, which is a bit of a departure from the typical types of conversations that we tend to have here.

Given that you've listened to at least one or two episodes and put up with my slings, arrows, and other forms of various sarcastic misfortune on Twitter. What's different about the market that you work within? The global 2000 and government have a tremendous amount of legacy because of the success. In our industry, we tend to think of legacy as a bad thing. In fact, in other countries, legacy is a good thing. So that means that there are hundreds or thousands of applications that were built way before even the advent of Unix in some cases. So the notion of adopting public cloud, for many of them, is not and cannot be an all or nothing.

So there will be data centers, there will be mainframes, there will be still. And so the question of how to adopt cloud, it's both a transformation program, it requires new operating models, which means thinking about roles, new skills. Probably the biggest challenge to public cloud adoption today is the lack of skills in general that are available and experienced in public cloud. And so, on the other hand, most of them are adopting public cloud in some fashion or another. So whether it's the adoption of SaaS, Microsoft Office, 365, Salesforce, Workday, ServiceNow, and of course, the big three. Many of them advertise.

As the majority of advertising dollars flow through online, in fact, you'll see their marketing operations and sales operations be actually quite knowledgeable about cloud-native stuff. So at different stages of maturity, even within the same company, I've run into companies that have very old mainframes from brands that are not IBM. That's how old. And then they have bought other operations that are completely cloud-native, and they have to somehow make both operational models work together. So they need a lot of help refactoring applications, migrating applications, reconceiving the operating model, as I said, creating centers of excellence.

It's a lot of work. My approach towards multi-cloud has always been that it is not a best practice that anyone should strive for. I've given talks on this. I've written blog posts. I've been chased out of conference halls. But my point has always been that from a position of best practice and a per workload basis, that's where I stand. Examples where it does make sense are exactly what you just described,

where you have a multidivisional company that acquires something. No, migrating them to a new cloud provider is almost never going to be worth doing. And dealing with companies as they are, who have an established track record and have a serious revenue base for which they have to express concern, means that suddenly you don't get to throw something away just because it's not using the absolute latest JavaScript framework that Hacker News has fallen in love with this week. There becomes a serious business consideration and a serious concern around this. And watching those concerns make their way into a world of public cloud has, from someone who doesn't participate overly much in that sector recently, has been fascinating for me to watch.

Yeah, I think I can agree with you because of the caveat you put on a per workload basis. I do not see much value in trying to have the same thing across a couple of clouds because of the knowledge and the skills that you need to have, the security models, et cetera, et cetera. But it is a multi-cloud world because of M&A, because different divisions have different needs. And then you have the other issue, which is, you know, outside the U.S., Windows servers are the data center. And to be frank, because of licensing and other reasons, if you have a lot of Windows workloads, Azure's probably a pretty good choice for you. I would argue that Azure is not a terrible choice, even if you don't. There's a startup that provides the no-code slash low-code solution I use to put my

newsletter together called Retool. And I was seeing an outage from them one day and I checked and they were public about this. They run on top of Azure completely. And there was an Azure issue that, oh, that is fascinating to know. Now, the fact that it came to my attention through an outage is a little eh, but by the same token, if you choose Azure, I do not believe you are fundamentally making a mistake. Yeah, it's absolutely right. So as I mentioned another time, Accenture itself has been for now almost three years, 95% of our internal workloads are on public cloud and somewhat divided between AWS, Azure, and now emerging Google. And so we've had a lot of experience running and managing multi-cloud.

And we have to because we manage what our clients tell us to manage. We don't get to dictate the terms of where we host things. The client does that. Oh, I run a small services company myself. I absolutely appreciate and respect the need not to come into an engagement and tell the customer that everything they're doing is wrong and they should fix it immediately. That is the hallmark of a junior, crappy, and short-tenured consultant. That's not going to work. Well, not a second time.

Not a second time. Yes. So, the notion here is that it will be a multi-cloud world. It will be a multi-cloud world. It will be a bit messy. But yes, if you're starting one app, right, for example, in my environment, Accenture Cloud Platform, which is a combination of commercial off-the-shelf software, right? We don't write our own monitoring. We buy monitoring tools. We don't write our own backup.

We buy backup tools, right? But to do cloud discovery at scale and security at scale with thousands of accounts, we actually had to create our own tool back in the day, which was all built on serverless. So part of my architecture has been entirely serverless. I mean, like dictatorially serverless, meaning we didn't want a single VM because VMs in that case would engender patching and we need to work with another team in operations and we want to do it all DevOps. And so we for that part of the platform is entirely serverless.

And the challenge has been managing the economics, teaching the information security folks how you secure serverless. Right. Because almost all the protocols were for VMs, right? So, and that part is entirely on AWS, right? Yet for our billing operations, we used a tool that was acquired by Google. So eventually to do our analytics for cost, we basically are on Google, BigQuery, et cetera, et cetera, because our tooling ended up there, not by us it, but that's how I went, right? And I can't really replace the billing tool overnight. It takes about a year due to the complexities of cloud billing, which you write. Let's not kid ourselves. When we talk about cloud billing, we're really talking about the complexities of Microsoft Excel. Well, when you have a bill that is over a billion lines,

you can't even open it in Excel. Exactly. That's when you move to a big data problem, also known as Excel for workgroups. Yeah, big problem. And the complexity of different contracts, because in our case, we are a consumer of cloud, so like a regular user, and that generally happens under something called enterprise agreement. But we also resell.

So that happens under a different contract with different terms, different liability, different discounts. And so for every single account and for every single account on the bill, we have to figure out under which contract, what discounts, and what terms and conditions. A little different than just being a user of cloud. Just a bit. But one thing that's been fascinating to me is watching Accenture from the outside, obviously. I fit in large companies about as well as I fit into other people's shoes.

It's fascinating watching first. Of course, you have to wind up being conversant across every cloud provider. There's no real alternative for you folks. You have to go where your customers are, and spoiler, as someone who's dabbled with enterprises once or twice, they're everywhere. There is virtually no provider that a sufficiently sophisticated enterprise is not running at least some workload on. So watching what happens in that space is really neat. There's some kind of

joint venture called the Accenture AWS Business Group. I don't know whether that is staffed by people from Accenture or people from AWS, but by calling it the Accenture AWS Business Group, it definitely shows the trademark AWS creativity in naming. Yeah. Accenture has a very strong ecosystem alliances model where we work with the top providers in the world across the entire ecosystem, SAP, Oracle. Those are very big business groups. So a few years back, I think about four years ago, well, more than that, Accenture was a very early adopter of public cloud. That's something people don't necessarily think about that. Very early adopter. I joined in 2013 and public cloud was already in use at Accenture. And the notion became, it's like we had to go big, right?

And so we partnered with AWS in creating a joint business group, not a joint venture, but it's joint business group that has an executive from Accenture, an executive from AWS, and then personnel underneath to essentially create a workforce that could help Accenture clients move to cloud, whether it's migrate to cloud, build a cloud native. I believe the last numbers I saw, there were over 3,000 people in that business group. Now, there's also one for Azure, and there's one for Google. So each of them has been staffed by a separate executive with a separate workforce. So there are literally tens of thousands of people dedicated to public cloud at Accenture.

It's quite a big scale, actually. It's always interesting to me watching companies adopt these cloud providers at scale. Because, yeah, we're used to seeing, more or less, conferenceware, where people do a quick demo online or an open source project. Here's this thing I beat together in 20 minutes. at what it takes when every person at a small startup becomes an entire division at an enterprise and the political consequences thereof of just the interdepartmental communication. It's an organizational beehive, for lack of a better term. And finding ways for those processes to continue to function in a cohesive, responsible, and compliant way is a massive, massive challenge. So a lot of things that come out of enterprises that they show to the world about their architecture can look,

from a startup perspective, to be hilariously overwrought. Like there's somehow this, oh, someone went and decided to build as complex a pipeline as they possibly could in order to make enough work for everyone to have something to do, whereas in practice it's just the opposite. This is a significant streamlining of the thing that came before. And I'm not sure that's well understood. Yeah, well, you know, the big thing that drives big companies is liability, right? As I said earlier, I spent most of my career in small companies and startups. In the year 2009, I started NuScale, which pioneered the service catalog concept. I was the first company to ever

have this notion of service catalog. We had to explain what a service catalog was. We had to prove that services could be cataloged. And I started literally with four people, just some friends of mine. We had nothing. So you could get very, very risky and cut corners because who's going to come after you? You have nothing. Big companies, though, have a lot to lose. So you end up with a lot of processes that are driven, all of a sudden becomes, you know, there are 20 different people with 20 different roles that are all involved in the same darn thing.

And trying to stitch all that together when you do DevOps is the big, big challenge for big companies. It's what I call the issues with the operating model. For example, I was with a large company here in the Bay Area in the healthcare space. And the whole issue of procurement and budgeting for IT just completely gets blown up by cloud. You know, people are spinning up instances left and right. And somebody says, hold on a second, how do we control that? Do we need approvals? And I go, well, no, you can't have approvals because you won't be able to do CICD. And they said, yeah, but then how do we ensure

that the budget stays in place? That auto-scaling group scaled up without a change approval request. Right. And the VMs may scale up, but the wallet doesn't. Sure. And well, at least in enterprise scale, the numbers are always a little bit different. But in some cases, those conversations can be hilarious, particularly for people who don't seem to understand a lot of these things that go on. When a CTO is asking, why did that scale up without a change approval request? The easy answer is, who are you and why do you think that that's how this should work? The honest answer in some cases is, hi, I'm the person that will go to jail if we

don't have the proper compliance controls in effect. That's not really how startup land tends to think most days. Move fast and break laws. Hey, look, I was talking about a serverless app, right? So I actually have a tool that we built so I can keep watch on the spend, right? So every month we get the bill and I call up the chief architect for that app and I say, hey, dude, how come this thing went up 20%? And, well, you know, we're managing some stuff.

So basically as we manage more and more instances and cloud resources, of course the cost will go up naturally, organically, and that's fine. But then we saw a spike. A spike is something that we've identified as this went up, you know, vertical like we see in the bill, right? 90%. And basically, it said, whenever things go spike, we got to watch them. So we actually created a tool for ourselves we call SpikeWatch, just to see, is that a legitimate spike?

For example, one of our accounts does a lot of end-of-month processing on Redshift. So you see the Redshift go for the first week of the month, just go up and up, right? And then after about five, six days of the batch processing done, it goes down to zero, which is exactly what you want. But initially, we didn't know, right? So the question then is, how do you get visibility on that and management on that and say, no, no, that's a fine spike. That is exactly working as intended versus what happened here in spike watch. And in the first time we ever saw that, what it was, it was one of the providers had moved us to the wrong rate card.

And if you have a bill that's over a billion lines, there's no human being that can watch that. You need tools and systems, but you also need processes because the people watching that need to be able to communicate with the operators and say, hey, guys, there was a massive spike in costs here. And the operator needs to say, hey, we haven't touched a thing. Okay, root cost analysis. A couple of weeks later, aha, we found the root cost. Wrong rate card. Not out of scaling, not anything. So when you think about going back to this large client here in the Bay Area in the healthcare space, they're really

challenged for how to think of procurement, financials, and operator, and how those things come together. In what you might be forgiven for mistaking for a blast from the past, today I want to talk about New Relic. They seem to be a relatively legacy monitoring company, and I would have agreed with that assessment up until relatively recently. But they did something a little out there. They reworked everything. They went open source, they made it so you can monitor your whole stack in one place, and, most notably from my perspective, they simplified their pricing into something that is much more affordable for almost everyone. There's even a free tier, with one user and

100 gigs per month, totally free. Check it out at newrelic.com. Oh yeah, in the world of AWS billing, I find that talking to people on Twitter, one of the biggest misconceptions people have between the folks I talk to about their personal accounts and their bill shocks versus the large customers, when people live in fear on their personal accounts of having a bill surprise that leads to some extortionate number, the enterprise story is very different. If I wind up compromising your account and spinning up a bunch of Bitcoin miners, for example, if you're spending $30 million a month on AWS, that isn't even going to register on the bill. So let's face it, the bill is in many cases the best security reporting tool people have set up in their accounts.

It's a very different mindset. And okay, the bill's now 10% higher this month. Why? Understanding why the bill has increased, or in some cases decreased, is a very non-trivial exercise past a certain point of scale and attendant complexity. One of the things I noticed in my serverless accounts one day was like, I said, look, this thing's going up quite a bit. And I don't think the number of items that we're managing and discovering has gone up. And the chief architect, I said, what happened? He says, oh, new InfoSec demands about encryption and security,

so we are having to lock this. And so next thing you know, it's like, oh, I see. 40% of the spend now is with security issues. So, hey, you got API gateway and you have KMS, and all of a sudden KMS is being invoked every single time, and now you have a hefty KMS bill. In fact, the first learning experience for a lot of them is when they get this enormous bill from Amazon Web Services, they see Amazon and wonder how the hell many books you've bought this month because they didn't notice you reading that much when they walked past your team in the elevator. It becomes a learning process. And, okay, KFS is now super expensive. Is that normal or is it not?

Okay, it sounds ridiculous to people who are up to speed on what the various services do, but that's every bit as legitimate from their perspective as, huh, the EC2 bill is awfully high. Should that be a major component of the bill? And understanding the nuances of this, I keep describing what I do as less about engineering these days and more about marriage counseling for engineering and finance. Getting two very different groups who, believe it or not, are aligned, communicating in a common language

is a fascinating problem. Now you take it to a bigger company and now you have three groups, right? Or four groups. You need to be talking to finance, which includes both budgeting and procurement. And you need to talk to engineering, of course, the developers,

but then operations is usually a separate group. And so you got to talk to them. And in the the developers, but then operations is usually a separate group. And so you've got to talk to them. And in the middle of all of this, there's also security. And so bringing now those four different areas, four or five different areas together, it's what I mean by the operating model. How are we going to tackle this new reality? We want the benefits of public cloud,

but we also are now going to have the problems of public cloud. And we have to have some way of bringing all this together. And that requires new roles, new skills, new operating model. And next thing you know, as you said, is you're doing marriage counseling rather than architecture. It's easy to sit here and think from a perspective of, oh, well, I would just solve it by X, but that misses the entire point. There is so much else that has to happen and how this stuff winds up working that even looking at this from a perspective of, oh, I know what the right answer is, is a lie. And if you haven't done it before, if you haven't been living cloud native, the question I have is, how would you know? And this is the challenge for a lot of clients, which is, where do they

get started, right? I was with the VP of Ops of a large and well-known financial services company here in the States. And they run almost everything off of Mainframe and Unix. And so they wanted to know how we could help them with cloud transformation, what they needed to do, what the business case is, right? And at the end of the meeting, he said something that stuck with me. He says, look, we're running this big operations. We're all working long days. We've had two outages in the last 60 days that have completely drained all our time.

Where do I get the time? Where do I find the skills and the know-how for us to start moving to public cloud? Because I think it's the right thing to do, but our situation is we don't have the money, we don't have the people, and we're all working long hours already. So there's a real human story there, right, Corey? I mean, it's a real issue.

Oh, absolutely. And again, all the hilarious things companies do or generally can boil down to a lack of understanding or context. A question for you that I like to ask sometimes is what do you think is the most misunderstood aspect in the general market about Accenture? But before you answer, I'll give my answer for this

because I turned this into a conference talk. I saw a billboard at an airport once from Accenture. New isn't on the way. We're delivering it now. New applied now. So I made hideous fun of this, as I am wont to do. And then a friend of mine who works in marketing, who's way smarter at these things than I am, sat down with me and said, oh, by the way, you know what's going on with that really, right? And sure I do. Of course I do. But why don't you tell me? Because I like hearing the way you say it. That's how one lies convincingly. And the answer was, yeah, look at what they sell. These are large scale implementation projects in many cases. And there's some strategy work too. But they're at a point where no one is going to go to Accenture.com, punch into a shopping cart, one consulting please, and click the buy button. Instead, it comes down to brand awareness. So when they wind up pitching to the decision maker or the board, the question is not who the hell is Accenture? It's a brand awareness campaign, and that is its entire purpose. In fact, the fact that you talked about them on stage would

be considered by that marketing team to be an absolute win. Sure, it was funny, and it wound up taking it out of context, but that name is going to stick in people's minds and it gets them one step further removed from who the heck are you? That was one of my early introductions to marketing and I thought the idea was fascinating. But curious to hear your answer. Let me see. Having been here seven years, I think that one of the things that I appreciate about the Accenture culture is the intense focus on client success. And I know that sounds silly because, you know, what business could afford to not focus on client success, right? But in the sense that we value the relationship, we build long-term relationships with our clients.

The biggest insult that I heard one managing director one time in Australia say about another, she said, he's way too transactional. He's not relationship focused. That's why people work with Accenture. They trust the relationship. They trust they're not going to get burned. I'm not saying things don't go bump in the night and everything's perfect all the time, but I'm saying the culture here absolutely is client-centric at all costs. And I say that because most of my career was working in software companies, whether small ones like my own or big ones like Cisco. And there, it's always focused on the sales numbers, right? Take the

money off the table. That's not the way people think here. One thing that has always stuck to my mind is that I come from a very small business background. To me, a big company has 200 people. And it's common for me in that case to say, oh, that company sucks. Okay, why? Because Ted works there, and Ted's an asshole. And that's accepted when we're talking about a 10-person company. Accenture has half a million employees, at least. And what is astonishing is that, yeah, at that point, it goes well beyond any one-person team or project, or even client, for that matter. Accenture has been around for, what, 31 years? And it's still one of those areas where, yes, they get things wrong and sometimes it makes headlines.

Every company who has been around long enough will have stories like that, or they haven't really affected any change at all. And it's easy to wind up coming at this from a dismissive thing of, ah, see, here's a bunch of bad headlines going back 20 years. Yeah, but no one writes an article on how that engagement went super well, and it makes the New York Times. And also, a lot of the things we do, part of the service is confidentiality. There are many things that people use and work with that they're very happy. In fact, Accenture's behind it. The best description of what Accenture does actually was done by Jimmy Kimmel. I don't know if you ever saw that Jimmy Kimmel skit.

That depends. Jimmy Kimmel has done a couple of those. On Accenture. Oh, I did not see that one specifically. No, he's done a lot of work. But for some reason, I've missed his management consultancy send-ups. Yeah. Well, if you recall when healthcare.gov was having a lot of trouble, right? I don't know if you recall that. And it was all over the headlines. Oh, yes.

And the government was using a particular set of service providers, and they decided that they needed more help. And they called Accenture. And basically, we stepped in. And, you know, nobody knew that. Nobody knew. I think this came out later, right? And we put literally thousands of people to work on that. And so Jimmy Kimmel kind of said, who's Accenture, right?

So the little thing is, in the modern complex world, you know, sometimes it gets fucked up. And that's what we call Accenture. So anyway, if you find it, it's pretty hilarious. But that's the notion. There's a lot of services that we provide and that we do that are essentially not seen by anybody. And confidentiality is part of the package, which is why I can't talk about them. Yep, and that's the worst part in some cases about doing really awesome things for customers

who have fascinating billing issues. It's one of those, hey, can we tell this story publicly? A lot of people would benefit from it. And the response is absolutely not. Anything involving what we spend on any given cloud provider, or in some cases, the fact that we're that cloud provider's customer at all, is a complete non-starter. If you say that, we will sue you to death. Cool. So that's a no then? Or it's very much a no. I mean, at some point, even getting logo rights is like pulling teeth. We certainly don't get them all the time. But it's a challenge in that some of your best stories you can't talk about, which from a branding and marketing perspective makes it sound completely, you can't put it publicly, but if anyone's on the fence, have them call me and I'll tell them a story over drinks, which is ideally sometimes the best you can get to. But it's an ongoing balancing act. Yes, it is absolutely a big challenge to get client references always because of the delicate nature of some of the stuff that

we do. Or how it can influence stock prices in many cases, right? Oh, my stars. Yes, the publicly traded company and the markets. And Matt Levine of Bloomberg is saying constantly that everything is securities fraud. Anytime a company does anything, they get sued for securities fraud for not disclosing it or disclosing it too soon or in the wrong way. It becomes a challenge. And that, for better or worse, is not something I generally have to deal with in most cases. Right.

So that's the story. It is. So at the time of this recording, you are winding down your time at Accenture. The plan then is for you to go and take some time off, something that will have transpired by the time people are listening to this. So as of this moment, looking forward into the, yay, I get to sit down and not do anything for a while, what are you looking forward to? Well, I'm looking forward to having a bit of a rest. When I started New Scale in 2000, and that was a small startup, raised money, run it. We get acquired by Cisco. You have to hit the ground running and learn a brand new company. When I left Cisco, my last day was on a Friday. And on a Sunday,

I was on an airplane to my first day at Accenture in New York. So I haven't really had a rest, a true long vacation since before the year 2000, so well over 20 years ago. So I plan to spend the next few months recharging the battery, but I'll still keep in cloud. And I advise startups, so I'll probably continue to do that and do a little more. My sister has her own company, so she needs help. But I'll be deciding whether I go back

and join a big company or whether I go and join a small company or start another company. But it's time and I'm blessed to have had the success and the opportunity to work at Accenture and Cisco that I can afford to do it. And so this is a good time, you know, in the midst of a pandemic to step back and say,

okay, I'm of a certain age. I got probably one more big thing in me. What do I want that to be, right? No regards, right? No regards. Exactly. It might be a digital transformation or a cloud migration or, heaven forbid, a new startup. One never knows.

Yeah. There are some interesting problems in cloud that I think could use some new approaches. I agree. And some of them are attached to people with job titles. Rodrigo, thank you so much for taking the time to speak with me today. If people want to hear more about what you have to say, where can they find you? I have a blog and I have Twitter.

So, you know, my Twitter is RF Flores. In case you wonder, that starts for Rodrigo Fernando Flores. And I have a blog called Working Class CTO. So you can find my writings there. So I'm easy to find. Excellent. And we will, of course, put links to that in the show notes. Rodrigo, thank you so much for taking the time to speak with me.

I appreciate it. You're welcome. It's been delightful. It really has, hasn't it? Rodrigo Flores, Managing Director at Accenture Cloud Platform in the closing days of that role. 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 Apple Podcasts. Whereas if you've hated this podcast, please leave a five-star review on Apple Podcasts. And in the comments, include your RFP acceptance criteria. This has been this week's episode of Screaming in the Cloud. You can also find more Corey at ScreamingInTheCloud.com or wherever Fine Snark is sold. This has been a HumblePod production. Stay humble.