Screaming in the Cloud - Episode 45: Everybody Needs Backup and Recovery

Episode Date: January 23, 2019

Do you have to deal with data protection? Do you usually mess it up? Some people think data protection architecture is broken and requires too many dependencies. By the time a business needs to backup a lot of data, it’s a complex problem to go back in time to retrofit a backup solution for an existing infrastructure. Fortunately, Rubrik found a way to streamline data protection components. Today, we’re talking to Chris Wahl and Ken Hui of Rubrik. Some of the highlights of the show include: Transform backup and recovery to send data to a public Cloud and convert it to native format   Add value and expand what can be done with data - rather than let it sit idle Easy way for customers to start putting data into the Cloud is to replace their tape environment; people hate tape infrastructure more than their backups Necessity to backup virtual machines (VMs) probably won’t go away because of challenges; Clouds and computers break Customers leaving the data center and exploring the Cloud to improve operations, utilize automation Business requirements for data to have a level of durability and availability People vs. Technology: Which is the bottleneck when it comes to backups? Words of Wisdom: Establish an end goal and workflow/pathway to get there Links: Rubrik Chris Wahl on Twitter Chris Wahl on LinkedIn Ken Hui on Twitter Ken Hui on Medium Amazon S3 IBM AS/400 Amazon EC2 Instances Azure Virtual Machine Instances re:Invent DigitalOcean .

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 Cloud. This week's episode of Screaming in the Cloud is generously sponsored by DigitalOcean. I would argue that every cloud platform out there biases for different things.

Some bias for having every feature you could possibly want offered as a managed service at varying degrees of maturity. Others bias for, hey, we heard there's some money to be made in the cloud space. Can you give us some of it? DigitalOcean biases for neither. To me, they optimize for simplicity. I polled some friends of mine who are avid DigitalOcean supporters about why they're

using it for various things, and they all said more or less the same thing. Other offerings have a bunch of shenanigans with root access and IP addresses. DigitalOcean makes it all simple. In 60 seconds, you have root access to a Linux box with an IP. That's a direct quote, albeit with profanity about other providers taken out. DigitalOcean also offers fixed price offerings. You always know what you're going to wind up paying this month, so you don't wind up having a minor heart issue when the bill comes in. Their services are also understandable without spending three months going to cloud school. You don't have to worry about going very deep to understand what you're doing.

It's click button or make an API call and you receive a cloud resource. They also include very understandable monitoring and alerting. And lastly, they're not exactly what I would call small time. Over 150,000 businesses are using them today. So go ahead and give them a try. Visit do.co slash screaming, and they'll give you a free $100 credit to try it out. That's do.co slash screaming. Thanks again to DigitalOcean for their support of Screaming in the Cloud. Welcome to Screaming in the Cloud. I'm Corey Quinn.

This week, we're doing something a little bit different. Historically, a lot of guests that I've had on this show come from companies that were, quote unquote, born in the cloud. And that's great. But there's an entire world out there of companies that didn't start in the last 10 years, that have built out infrastructure over decades. And in many cases, we're sort of shortchanging them.

To start remedying that slightly, what I'm doing today is I have two guests from a company called Rubrik. We have Ken Hoy, who's a cloud solutions architect, and Chris Wall, who's the director of technical marketing. Welcome to the show, folks. Hey, hey. Hey. Good to be here. Good to be here too, Corey. So you historically have been working at a company that provides data protection.

What does that look like? Let's start at the beginning here and sort of unfold what it is that Rubrik does. Take it away. It's your pitch. Yeah. So we had our first product come out in 2015, which is also when I, hi, I'm Chris, joined the company. And one of the major reasons I joined, I guess, was data protection was something I had to deal with a lot as an architect and a consultant. And it's not fun. I didn't really enjoy it that much. And I often

kind of messed it up. And it's, in my opinion, because the architecture is kind of broken, and there's a lot of dependencies there. And if you look at what it takes to back something up, there's like something like 11 different components sourced from different vendors that you kind of have to cobble together to do that. So there's certainly a lot of opportunity to streamline that. And Rubrik came to me and said, hey, we've kind of figured out a much better way to do this, where we're using these crazy things that the infrastructure and operations teams don't normally use, like an API and declarative policies and things of that nature, to make it so that it's really just a matter of defining kind of at a business level, you know, what your RPO, your recovery point objective and things like that are into a policy. And then

you just apply it to objects and objects or things like virtual machines, which were our first use case all the way through databases and file sets and things like that. And then the system has the intelligence to go out and figure out the best way to provide that protection, you know, take those backups and store them in its system and replicate them somewhere and archive them somewhere and things of that nature. Are you interested? And I said, absolutely. These are, you know, the folks that founded the company had done some really interesting things at Google and Facebook and the normal things that you see in a Silicon Valley startup. And so that's why I joined and the original focus of the product, the version 1.0 is specifically what you said, Corey, a lot of,

you know, long tail companies that have built out a pretty impressive presence on-prem with all sorts of gizmos and virtualization and storage and whatnot, to where you could literally deploy this very small-looking, friendly, white appliance into the data center using a lot of the techniques from the big boys out there, the fangs of the world, to build out a distributed file set and a series of nodes instead of dual controllers and things like that so that you could provide data protection, but with all kind of the updates that have happened over the last 20 years

that I think a lot of backup companies just haven't had a chance to take advantage of. And so our first use case was literally backing up VMware virtual machines into the appliance, deduping it and doing all that kind of jazz, and then shooting it up to Amazon S3 for long-term retention. Obviously, we've built out our repertoire from there. We now protect most of what you'd find in the data center, and we support most of the public cloud infrastructure for long-term retention and archive and even protecting those areas. But that's kind of the where, what, and why of Rubrik from a 101 level. Which makes an awful lot of sense. One of the challenges that I would imagine you'd experience in that market is that by the time a company needs to back up an awful

lot of data, by that point, it's a hard and complex problem. It's very difficult to sell a product that's built around, oh, just go back in time and talk to me four years ago when you were setting out all of this stuff. Retrofitting a backup solution to an existing infrastructure is always painful, always difficult, unless you know something I don't, which you might. It's true that it is. It's a challenge no matter what you select, right? And we're obviously not targeting greenfield opportunities because that would be crazy. People have a lot of... Data has only accumulated over time, especially if you believe in data gravity, which I do. And that's why for a lot of folks, because we started with VMware virtualization, it wasn't a huge lift to say, you know what,

deploy it for that use case. Because right now what you're dealing with doesn't meet your service level agreements if you have them. It doesn't really meet the complexity needs that you have. And in a lot of cases, you're spending a minimum of 20%, if not more, of your time just babysitting the system. And so the opportunity cost is fairly good from an ROI perspective to introduce a technology that can alleviate a lot of the operational headache and potentially be cheaper from a CapEx perspective while unlocking a lot of new use cases. And I think that's the ultimate point

where people get really interested, because we're transforming backup, you know, I'm just gonna, I'm just gonna call a spade a spade, you know, like backup and recovery, it's this thing that everyone needs. But we're transforming it from this insurance policy, where it's literally just take this data and hold it and good luck, it's, it's just there just in case. And hopefully, it actually works when you pull a tape to recover it. To unlocking use cases, like making sure that you're able to send that data to a public cloud and convert it to the native format of that cloud

and use it to be able to live mount, which is our technology that lets you kind of zero provision a workload based on a snapshot from a previous backup and start putting that into your pipeline for introducing a new version or software regression testing or something like that. Really just teasing apart all these things we would like to do with data versus just

having it sit there kind of idle and just the Maytag man sitting on top of the washing machine just hoping that it breaks doesn't add a lot of value. So I think that's been something that's been very, I don't know, tangible for customers. People like use cases and they like to expand what they can do with their data. can't recall ever having done a hybrid style project for that. What changes as these companies start moving certain workloads out of the data center and into the cloud? What are you seeing as that starts to manifest? This is Ken. So I'll take a shot at that. I think what we find is a lot of customers are still trying to tip their toes and they're trying to figure out an easy way to start putting some of the data into the cloud. So an easy way to do that is to replace your tape environment because no one likes tape. If there's something people hate more than their backups, it's probably the tape infrastructure. I'm right there with you. I started my career many moons

ago selling tape drives for the AS400. For those who've never dealt with IBM mainframes, I envy you. But it was a difficult thing to do because first, everyone hates tape. Secondly, we were competing against IBM on price when it comes to backups. So why is our data unrecoverable? Well, we saved two grand on a tape drive. It turns out that's not really a defensible position and that company isn't in business anymore. I'm right there with you. Please continue. Yeah. So we find a lot of customers say, well, there's a real use case for let's try to get rid of our tape.

Let's use something like S3 or Azure Blob Storage as a replacement for tape. And it's actually a good learning ground for them to start finding out what they need to do to set up connectivity to the cloud or to find out whether the cloud storage is as durable as they think. I mean, I still talk to a lot of customers who are worried that when they put their data in S3, it's actually going to be less protected than if they just kept it on tape on site. So there's a lot of education that has to be done. And that's a proving ground for them to be able to say, I can actually trust the cloud for storing my data and know that I can recover it when I need it. So that's kind of the first initial use case. And then once people start being comfortable kind of moving some of the data to the cloud, then they start thinking about, well, how can I actually get my data, my workload to the cloud so I can take, let's say, a Linux server that I'm running on my data center

and stand that up in AWS or in Azure. And again, that's where one of the things we try to help customers do is we can say, now that you've got your data up there, let's help you figure out how to convert that into a C2 instance or an Azure VM. So it's pretty easy for you to kind of automatically spin up these instances and create a replica of your environment in the cloud. And you can start playing around with that and start, again, educating yourself on how to actually use a lot of these cloud services. One of the challenges that I've seen in this is that people talk a great game about building out things that are emphasizing infrastructure as code.

They build cattle instead of pets. And whenever you talk about things like backing up VMs, people cluck at you and say, oh, you shouldn't be doing that. You should have everything built programmatically, and you just need the data itself. And that's great in theory, but the real world's messy. The beautiful architecture diagrams we see in white papers don't exist here in the real world's messy. The beautiful architecture diagrams we see in white papers don't exist here in the real world. And embracing that messy reality in theory is something that should never have to happen. In practice, there are billions of dollars going into individual companies to solve these specific problems every year. And I don't see that going away anytime soon. To some extent,

looking at a company like Rubrik, it's easy to almost discount you folks as irrelevant. No one really cares about backups in this sense. They shouldn't need to worry about that. And yeah, by that same logic, you shouldn't need to hire any operations people whatsoever because code should be perfect the first time and you just run it and it's there until the hardware gets replaced. It's a fiction. I don't see that you're ever going to get away from having to worry about these things. That's what clouds do. They break. So do computers, for that matter, just in more understandable ways. I don't disagree. And as you're saying that, I'm thinking about the other challenges that people have, because it's not all about just, you know, certainly do love open source

and infrastructures code and making declarative pipelines and things like that. It's certainly, I mean, I think we have over 50 different open source projects just at Rubrik alone on GitHub. But there's also the other parts of the challenge, such as we have a product that interrogates every snapshot taken from your infrastructure. And it could be a SQL database or an Oracle database or Birch Machine or whatever. And what we're looking for is things like ransomware and encryption worms and just other security threats that are entering the workspace, not through a technical means, but often through a people means, and then kind of hiding out somewhere. And we're actually able to look at the deltas between, you know, kind of a known good state versus that bad state that gets introduced. And because we do have things like our software as

a service offering, that's looking at all these different instances of the Rubrik software running in your enterprise, we can start to do those deltas and actually dive in and crack open a snapshot from a metadata perspective and say, okay, I think there's something nasty going on here. Either malicious actor, ransomware, some type of operational, oops, I guess, you know, someone's still trying to move fast and break things and accidentally deleted a whole bunch of stuff. And we're able to alert a security team or an ops team or someone like that and say, this doesn't look right.

We feel there's something wrong here. And in fact, when we look deeper, we found there's some variant of WannaCry or whatever the topic du jour is for a ransomware security threat is. And then we're able to coordinate with all those running instances of the Rubik software to roll back to that known good state versus paying the ransom or hiring some forensics team to come in here and try to fix this stuff for an exorbitant amount of money. So just kind of pointing out there's certainly more to it than just, you know, VMs are bad and containers are good and serverless is better and things like that. There's also the security threats and things like GDPR to consider that just make human elements start to be introduced to the pipelines that you're trying to build

more from a technological perspective. As you take a look across your customer base and see people starting the process of doing a migration, what lessons do you see people learning the hard way over and over again? What advice would you give someone who's considering time to leave the data center and start at least exploring cloud to make their data challenges a lot more, I guess, manageable? From my perspective, I think probably the number one thing I see is that people a lot of people still think of the cloud as someone else's data center.

We hear that all the time, right? And so they don't really put the work into thinking, there's some changes I have to make operationally. When there's APIs that you can consume and things you can automate, that's very different than getting onto a vSphere console and provisioning machines by hand and updating them by hand. And a lot of times what customers don't do is they don't think about that kind of operational day two stuff.

They just want to get excited about moving things to the cloud. And then when they get up there, they wonder how come things don't work quite the same way that they expect, or they don't get all the value, like the agility that people are always talking about. So when I talk with customers, I always tell them, you need to think through how you're going to operationally change the way you manage instances, or how you want to manage databases in AWS or in Azure or Google as opposed to what you're doing on-premises. Yeah, I would add to that too. Sometimes it's just level 101 stuff, if you will. I've had folks come to me and say, how do I replicate S3 or backup S3 just in case there's a problem there? You kind of tease into that what kind of problem you're looking for.

What if one of Amazon's availability zones goes down? I'm like, well, you can control that more at the storage layer and you can set up the durability and the reliability at the bucket level and things like that. So it's really just, it is.

When you take folks like myself who worked on-prem forever and you take the constructs of an on-prem world and you try to cram those, kind of like a cookie cutter through the dough into the public cloud, it's pretty messy. And so I think a lot of it is just basic knowledge of how these different technologies work, what causes them to break, what causes them to lose performance or have some type of data degradation type issue. And that's

just, I think, standard to if you're going to be an engineer in any environment, you just have to learn what makes things blow up. And that's still kind of a, standard to if you're going to be an engineer in any environment, you just have to learn what makes things blow up. And that's still kind of a new thing for a lot of folks. Yeah, I think a clear example of that, Corey, is probably, I'm sure you've talked, when you talk to your customers, you advise them to use different availability zones, just as a standard best practice. But when I talk with customers, I'm amazed how many customers are only using one availability zone for most of the applications.

And typically, those are the customers who, they run their database on-premises, they move it to the cloud, and then they don't even think about, well, how do I make it highly available by spreading things across availability zones? They just keep that one machine running in one availability zone and they wonder how come when there's a problem

they don't get that high availability that everyone talks about in the cloud. I recently appeared on Real World DevOps and talked a little bit about this. We talked about the S3 apocalypse a year or two ago, where S3 went down for something on the order of eight hours in US East. And there was a knee-jerk reaction afterwards, where a lot of operations people suddenly started doing cross-region replication and getting copies of all their data scattered throughout the world. And that does double or triple your costs plus the overhead to manage all of that. Is there a business requirement for your data to have that level of durability and availability? And if not, why invite that level of overhead just to avoid a black swan style of event

not all businesses are created equal and not all companies have the same specific constraints around uptime requirements if s3 goes down across a region or even to some extent a single az drops out for a while that's the day where the internet is going to not be working well for almost everyone. And to some extent, you can sort of fly below the radar. Now, there are exceptions to this. If you have something that, such as an ad network, where people aren't going to come back and view those ads again later, you may want to wind up architecting for that. But mapping backup and DR considerations back to a point of being able to tie those to business requirements just seems like a no-brainer to me. Yeah, I remember that too. If I remember correctly,

some of the icons that even Amazon was using, I think, were hosted in S3 for the S3 status page. So it ended up being layers of lulls there, which are always fun. But that also goes back to some of the things that we've designed for and offer the correct layers of configuration, I think, for customers. So going back very early in the show, I talked about using policy-based administration for the system. Ultimately, you just kind of feed in what your business requirements are, and the system will tackle that. And certainly applications that you want to make sure, you know, an eight-hour unavailability window for data for some reason just wouldn't be acceptable. But probably for most of them, it's not the end of the world. So a typical policy that you can configure would state,

you know, keep anywhere from 15 to 30 days of the data that I backed up on-prem in, you know, the appliance that's taking the backups, and then send everything beyond that for the next seven years into an S3 bucket, as an example. If it's even more critical than that, you can say, you know what, mirror the data. I want it local and I want it to have, I want it to also be stored in the public cloud. So there's certainly ways that you can assign these policies and kind of tier them and prioritize them

to make sure that it makes sense. But ultimately the nice thing is you don't really have to do a lot beyond the policy creation. I think that's what people get kind of excited about. Because as Ken was alluding to, cloud tends to be hard. I mean, we've all read your S3 bucket of negligence award, because even security can be tough. And so we handle most of that and abstract away most of the nuance so that those mistakes aren't really repeated when you're setting up the product, which I think is kind of nice. But then all the controls to make sure that the data is where it needs to be and that it's available are all kind of being monitored

and handled by Rubrik to make sure that when you need it, it's available. Because as you said, it's not backup's easy, it's the restore part that's hard. Yeah, I'll also challenge you on that slightly, where I've noticed a lot of these discussions are not technical debates. They're people problems. Early in my career, I was building out an email system. It's where I started out my entire nonsense once I became pure technical. And I was talking to the business and asked them, okay, how much downtime a year is acceptable? And their answer was no downtime. The system must be always up. And my response to that, because I didn't really understand diplomacy back then,

not that I do now, was, great, that'll be $20 billion to start. I'll come back when that runs out, and we're still not going to get there, but we'll get close. At which point it led to a series of back and forth discussions. And it turned out that no downtime acceptable meant 40 hours a week when people are in the office, mostly for the email system. And it became a much easier target to hit as a result. But having that conversation was never something that technology at the time, at least, was going to be able to drive or facilitate or solve for. Because if you give people a question of what are the data durability and availability requirements, the answer you'll get is 100% across the board until you start tying that to cost.

Yeah. And to me, that's one of the interesting points because I totally agree with you. Having done a lot of these systems where the first answer is always zero, I never want anything to go down, always available, infinite retention, all these unobtainable goals that people that aren't technical don't realize what the cost and the impact of that's going to be. And also, traditionally, when you deal with a backup system, there's no question of what your availability is and your RPO is. It's all about configuring backup jobs and stating, I want these 10 servers protected first and then these next ones and send them here. And it's all about the tactics, but not a lot of strategy when you're working with these products. And I think that's one of the ways that it's kind of a forcing function when you're dealing with Rubrik. It's not about when do you want to take

it every third Thursday or every night at two in the morning. It's more around the specific business objectives. You know, when you edit a policy in the product, it's literally asking you for things like RPO and RTO. And do you want it to replicate? And what's the availability requirements? And so I think because we're kind of going down that path, it forces you to think in an alignment with the folks that are business users. And also kind of reveals what that's going to look like when you set it all up and when you

apply the policy. And you can change the policies later if you want to be more or less aggressive. But I feel like that departure from imperative, you know, kind of pull the lever, get the banana type job architecture, where it's really tough to answer a question like, what's my overarching RPO for these workloads? Oh, well, let me go check all these jobs. I'll run a report. I'll get back to you. With Rubrik, it's really, what's the availability for these workloads and this data? You can just go, it's four hours. Well, when is it going to back up? I don't know. Whenever it's necessary to meet a four-hour RPO. That's all you really actually care about. And so it just really kind of wipes the slate clean from all that technical debt, if you will, that I think we've been paying down and never actually reaching a zero level debt with when it comes to data protection.

So that's one of the things I really like about it. I remember some of the olden days, which we're talking three years ago, where I would have a backup job that ran and it took a while to run and it started to run into problems because the next backup job to meet our RPO had to start before the old one completed. And it led to a variety of terrifying hacks to make that work. And looking back, it would have been so much easier just to renegotiate the requirements around what it is we were trying to achieve or change some architecture, but that's asking for a magic wand. Yeah. Yeah. And that's, I had to deal with that for the better part of a decade. And I hated waking up in the morning.

I really hated looking at my phone because it was like, what broke this morning? Or I'm waking up because my phone's ringing because something's broken. And it ended up giving me like horrible panic attacks at night where I'm like, I don't want to go to bed because I know something's going to break. Or I know one of these systems I set up are going to not work because people are involved and they're going to change things and they're going to cause an impact to the environment. And my rules are static. You know, I'm not defining, it's not a dynamic system that's dealing with this.

It's a static, imperatively defined system. And so it doesn't adjust while I'm busy sleeping or going on vacation or something versus an intelligent system that is declaratively managed and is actually looking at the RPOs and the business needs and doing what's necessary to achieve those. We're just telling you, you're crazy. This is not going to work. Please adjust. Because Rubrik Software is looking at how it's configured as well as how the target

environment is configured and then determining how best to provide that data protection. And most of our customers, like I remember talking to Seattle Genetics, they're one of our public reference customers that is dealing with a lot of patient data and really needs restores to be lightning quick, you know, especially when you're in biotech, you know, it just can't, you can't deal with, I backed it up, but I can't restore it, because that could be some massive, important IP that you're dealing with. They were saying something like restores are 90% faster and all that critical patient data that they need. It's always protected. They don't have to worry about it.

They can focus on actually the science behind what they're trying to do instead of backing things up, which is actually their technical differentiation we're kind of following the trends that I think we're seeing across the industry, which is like even the legacy, a lot of older companies starting to realize things are getting so much more complex that we want to try to remove human decisions out of things as much as possible and kind of let code and let the automation take over. And I think we're trying to do that with Rubrik where it's less about bottlenecking because a user has to make a decision about when to back up something and when to send it to the cloud and saying, you tell us what you actually want things to look like at the end and we'll figure out how to do all that for you. And we've got other customers

like University of California, San Diego, who presented with me actually at reInvent this year and talking about how they went from all these tools and all this time they had to spend just managing backups to using Rubrik and using AWS. And now they're spending like minutes a day instead of hours just to make sure that the backups are going the way they want it to. I think that there's a definite challenge for a lot of companies as

they start to move in this direction to, I guess, embrace a new way of thinking about it. And one of the more discouraging parts about a lot of it, to my mind, is when you look up modern best practices, it assumes that either you're starting Greenfield or you've been working on this for a decade already. And that can be incredibly discouraging. I guess, what words of wisdom do you folks have for people who are in that position? Two things I would say is, at least have a general idea of what the end goal is. You need to have a goal that you're shooting for. Otherwise, you won't know when you've arrived, right? And sometimes I think customers with new technologies like cloud, like containers, they just do it because they were told

by their management that they should, but they don't actually know what the end goal, end state should look like. So I tell customers, have an idea of what the end state looks like and then figure out what the pathway to get there is and recognize you're not going to get there in a month, right? No one, if you've never used the cloud before, you're not going to become a cloud expert

and have everything running in the cloud in six months to a year. It's probably going to take a longer span of time. So figure out the end goal and then figure out what the interim states are. And that could mean like, I'll start off by just doing some lift and shift of my workload into the cloud. But then maybe over time, I'm going to start using some of the cloud services. And then further down the road, you may even start thinking about kind of re-architecting your applications to be cloud native. But don't try to bite that off all at once.

Just try to figure out how you can do that in incremental steps. Yeah, I don't disagree at all. I remember Sugar Creek was a customer we were working with, a smallish team, three people, and just spending way too much time on the day-to-day keeping lights on stuff. And I'll relate to some of their story that I think is good advice in that that they're basically saying, we want to automate the heck out of everything. It's necessary for cloud. It's something we have to do on-prem, but it's not even a question if we're going to do that when we start dealing with these public cloud environments. And so they were really looking to automate these workflows. And so the kind of advice that I have there is capture what that workflow is going to look like, even if it's manual today. What's the process to go from A to B to C

to ultimately reach the goals that Ken was talking about? And then figure out where you can insert this into a pipeline of some sort, automate the pieces that you need to automate, hopefully as much as humanly possible. So definitely make sure, you know, Rubrik, we obviously are very big fans of our API and things like that. But I would say, I wouldn't really introduce anything into my data center today that doesn't have a solid track record when it comes to publishing their API, making sure it's available and documented, and there's no license fee or anything goofy like that. Because how the heck are you going to build out something in public cloud if you're not even kind of practicing those models of,-driven, declaratively-driven,

policy-driven type architectures on-prem? Because the two go really well together. If you start with one in an area where, oops, I made a mistake, the automation isn't quite the way I wanted it on-prem, it's not like you're going to pay a bajillion pennies in transaction fees or egress, ingress fees or something like that it's kind of a good test bed to figure that out then you can hopefully apply a lot of that learning to a public cloud environment as you build out i don't know if we call it hybrid cloud or whatever but public plus on-prem together can actually be quite fortuitous for a customer absolutely ken anything you'd like to add i think in addition to what chris said which is choosing the right tools. Sometimes I hear customers and they want to evaluate 10 different tools that do the exact same thing.

And then they get stuck in that cycle just picking the right tools. Same thing with the cloud. Sometimes customers want to evaluate every single cloud service until they can find the perfect cloud for what they want. What I tell customers is, at the end of the day, narrow down your choices and just pick one to get started because all you do is spend your time evaluating all these things. You'll never actually get going. So it doesn't matter if it's AWS or it's Azure,

pick one and go with it. If you want to use CloudFormation or you want to use Ansible or Terraform, just pick one and get really good at that. And then once you've kind of built up some good practices and good knowledge, then you can start thinking maybe about trying something else. But to get started, don't clutter yourself with 20 different tools. Try to hone in on a few and get really good at those and learn those well.

Great advice. Analysis paralysis absolutely becomes a real thing. So if listeners want to hear more sage words of wisdom from you folks, where can they find you? Doesn't exist. I have no other sage words of wisdom. I'm just kidding. The best price probably to find me is on Twitter. I'm at Chris Wall on the Twitterverse or LinkedIn if you want to network or whatnot. But those are pretty much the two places I tend to hide. I'm on Twitter at KenHuiNY, K-E-N-H-U-I-N-Y. And I tend to tweet about technology and lots of snark about AWS. And I also blog at Medium, also at KenHuiNY. And about 90% of my blog posts are about cloud and about AWS. Thank you both so much for taking the time to speak with me today. I really do appreciate it. No problem. Thanks for inviting us. Yeah, thank you, Corey. Appreciate it. I'm Corey Quinn. This is Screaming in the Cloud.

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.