¶ Bridging the Gap With Cloud Repatriation
I think there's a challenge here , and when you say you're leaving cloud and you're going to repatriate that , okay , what are you providing in your colo now ? What are you providing to your developers ? They're expecting to have a cloud-like experience , and so what you need to be providing for them is a private cloud .
That's really what I think you're operating by and large .
Welcome to the Cables to Clouds podcast . Cloud adoption is on the rise and many network infrastructure professionals are being asked to adopt a hybrid approach . As individuals who have already started this journey , we would like to empower those professionals with the tools and the knowledge to bridge the gap .
Hello , all you beautiful listeners out there and welcome to another episode of the Cables to Clouds podcast . My name is Chris Miles at BGP Main on Twitter , and I guess we're at this point where we should probably start plugging Tik TOK , so I guess I have the same moniker on Tik TOK .
Join us as always by my two lovely co-hosts Tim McConaughey at Juan Golbez on Twitter and Tik TOK . Are you on Tik TOK ?
Actually I'm on . I'm Carpe DMVPN on Tik TOK .
Just to make it complicated , he chose a different name . But let's Just to make it complicated , he chose a different name . But Tim is probably the most active out of all three of us on TikTok , so definitely check out some of his content . He's doing some really good tech terms with Tim .
If you like some alliteration , go out and check out his TikTok account and , as always , the TikTok-less Alex Perkins , who is at Bumps in the Wire on Twitter .
Only on X for me .
He calls it X . We're basically going to have to kick him off at this point .
Yeah , dude , you're getting banned . You're like two more times of that and you're getting banned , you're off , but yeah . So we have a very special show lined up for you today . So today we are going to be talking all about cloud repatriation . I don't know how many hot takes we'll get out of this episode , but there might be a few .
And we've brought on a very special guest , ethan Banks from the Packet Pushers Network , and you know I will throw it over to Ethan to give you a little , give a little introduction about yourself . I highly doubt there is anyone in this realm of networking-focused podcasts that knows who we are , who doesn't know who you are .
But you know what ?
I enjoy being wrong and , for the sake of my enjoyment , let's hear it . Who are you ? What do you do ?
I wish I was as popular as you guys seem to think I am . That's all I raise .
I am .
Ethan Banks . I am the co-host of the Heavy Networking podcast over at Packet Pushers packetpushersnet , Among other things . You can find me on our YouTube channel doing video bites and other such things , and I've been podcasting since 2010 . And people came to know me online because I had a blog way back in the day .
If you're an early Ethan Banks follower , you followed me in 2007 , 2008 when I was blogging through my CCIE route switch . That's where it all started as far as online stuff for me . And yeah , that goes back . Gosh , that's getting to be what's this ? 2024 , 2007 , math , that's a lot of years . However many years , this is , that's a lot of years .
So thanks for having me on guys . I'm glad to be here .
Yeah , we're glad to have you .
Of course , very glad to have you there . So yeah , without further ado , let's kind of jump into the topic today . So I think so , for those not familiar , there is a show that you guys have on the Packet Pushers Network called Day 2 Cloud .
I think I listened to a recent episode which kind of sparked the interest in potentially bringing you on to talk about cloud repatriation . So we'll plug that in the show notes as well , but let's just kind of jump into it . So , cloud repatriation , ethan , and I guess in simple terms can you define what that is for the listeners out there who may not
¶ Cloud Repatriation
be aware .
Yeah , cloud repatriation is all about . You have a workload that's in a public cloud somewhere AWS , azure , gcp , something called Oracle Cloud , I think I've heard of and you've got a workload up there and now you're bringing it back . It's too expensive probably to run it out there , for whatever your reasons are , and you're going to run it on-prem .
Now You're going to bring it back in or you're going to run it in a colo . You're not doing it in the cloud anymore . You're repatriating that workload , and so that means you're providing the OS now You're providing the networking , now all the other foundational infrastructure layers .
I mean again , maybe you're farming some of that out to a colo provider , but that that's the big idea behind cloud repatriation yeah , or like an msp or something , you're getting somebody to do some period of that for you .
But yeah , you're taking back ownership , right , that's the main thing . You're taking it back over .
You're gonna run it yourself yep , I I do actually wonder , um , I I don't think I've seen data on this , but I wonder how many people that repatriate are doing it on-prem versus in a colo . Because , because it seems to me like , from what I've seen , is colo is very popular now , way more popular than it has been in the past , I think .
I think you've got to be a specific kind of organization to be able to effectively run your own infrastructure . Now I mean , really You're going to do perf tiles and raised floors and cable raceways and plumb all that electricity and you really you want to be in that business . This doesn't make a lot of sense .
There's been so much more fiber run over the last decade and a half anyway , all over the place . You just need , you really want to be , in a well-connected colo . That's a good got , a good crossing point on the internet to be , have you close to where your customers are and so on .
Can you really I mean , unless you're in a metro area can you really do that in your own facility ? You know , even if you wanted to run that facility , yeah , yeah , I'd be in a colo if it was up to me .
It's actually a really good point . So , and let's think about the fact that you know feeding the repatriation . I hesitate to call it a movement , but whatever you want to call it , the process that is repatriation means we had to move something there in the first place .
So what about all of the CIOs , ctos , whatever that were chasing the pot at the end of the rainbow eight years ago , that were like we can close all our data centers , we move everything to the cloud , we don't need data centers anymore . So that's again what are we repatriating back to if we actually started closing all of our data centers ? Yeah , exactly .
Yeah , maybe they were smoking the pot at the end of the rainbow , I don't know .
Very possible . So , yeah , okay . So we kind of covered what repatriation is . Let's kind of get into why organizations do repatriate from cloud , and is it purely based on cost , do we feel , or is there some functionality that they're not getting within the cloud , which they think they can build on-prem , because that seems like obviously the heavy lift for me .
I don't see that being an opportune thing for a lot of organizations , but I don't know how do you guys feel ?
Cost is the big one . That's almost what everyone talks about . You read through oh , david , what's his name ?
DHH .
He's written about this , the 37 Signals guy . His logic has been very much about cost . I think we can get into some of his content a bit later because there's more to his particular story than cost . But cost is the big one people talk about . Public cloud . Bills are expensive . They're hard to understand . The formulas do change a bit .
You were talking about the Day 2 Cloud Show that we have on Packet Pushers . I'm no longer co-hosting that show , but when I was co-hosting that with Ned , we did another show just trying to break down basic costs of fundamental services like storage and networking and workload placement , compute and so on , ec2 , et cetera . It's ridiculous .
You can't fit it all in your head what all the different costs are , how certain ones are kicked off when you're now going to be paying for X , whatever it is , and then what the different tiers are when you're going to get hit with certain things and not other things . So there's that .
And then I think related to the cost component is going back to the comments somebody made earlier about all those CIOs and CTOs going let's get all those workloads in the cloud , we can shut down our data centers and save all this money . But they did a lift and shift .
They never really factored their apps to be cloud native so that they could really scale them . Well , they ended up doing the same thing in the cloud that they were doing on-premises and so they end up with these big , oversized EC2 instances that they don't need most of the time but maybe they need them . It's like oh , can't they do auto-scaling ?
No , the app was never redesigned to do auto-scaling , so they're sitting there just chewing through money just in case they have a spike , come in and make sure that they can meet that demand . So I think cost really caught a lot of people where it's like holy crap , this is expensive . I got to get this thing out of here .
I mean it's meant to be that way of here . I mean it's meant to be that way . The cost is meant to be obfuscated and hard to read and hard to understand and to scale up at certain arbitrary thresholds and all of that , like you said .
I mean and you know I know , in the cloud gambit was it Will was talking to Corey Quinn who , of course , you know he's got an entire business that does just this . Right , cloud finances . Yeah , it's meant to be that way , right . And I love what you said about the fact that you can't take an app .
You can't essentially take a 24-7 data center , vm hosts that are running your app all 24-7 , go put that in the cloud , change nothing and save money , because how could you right ? You're just paying someone else's cooling bill , someone else's power bill . Who want to make margin on you .
They're going to mark it up because that's how business works .
Yeah , but .
I mean . So we I mean we could park on cost for a while . Right there's . I think we know that that is the biggest driver , at least from everything I've been reading , that's definitely the biggest driver for repatriation , but there are some other ones that I've run into no-transcript .
Some other things I've heard too storage costs , because cloud storage is again expensive . So I don't know if this is a cost thing or not , but depending on what tier of storage you get , that can be very spendy and you can have better control over your storage and storage costs that way .
And then control over policies is another argument I've seen , although this one didn't feel was the strongest one , because if you look at what you can do with IAM policy , wow , it's very rich and nuanced , which is maybe the problem , because it's get your head around IAM and get those policies written and have them be effective as a thing .
But I've heard that argument made we have better control over policy if we bring it on prem and use our own systems rather than being beholden to the cloud . I thought that was a weaker one , but still an argument that some people make .
Yeah , and I agree with all those . I think , like you said , the data governance thing is a big one , and now , with all AI stuff , everybody's worried about data sovereignty and separation of their private data . So I think that is also driving a lot of this conversation right now , or , if it's not , it definitely will be right .
A lot , of , a lot of people are going to start worrying about what they're feeding into these models and where they're hosted . So , for sure , I agree with all those .
Yeah , I think I think AI is obviously . Obviously it kind of exacerbated the . I think everyone always wanted to own their data , but now there's like a much more compelling argument that you should own it and stop it from making it into things that could potentially , you know , make business decisions based on your data type things .
So not that that's necessary . You mean someone else making profiting from your data by using your data to train their AI .
You mean yeah , no one would ever do that though right , but yeah , that makes sense .
Plus , I mean , it's hard to navigate too far away from costs . I mean , to the points you guys have made , you know FinOps . I feel like FinOps is a thing just because of cloud right , Like that probably wouldn't have ever come into the equation had cloud not been involved .
And there's entire organizations and that's potentially separate products that you're using just to maintain opportune cost savings in each CSP that you're part of and things like that . So , yeah , I think those are all great points .
Well , real quick . So , like Tim , you brought up Will Collins , right . He wrote an article back when VPC Lattice came out and I'm looking at it . There are three types of charges . There's per hour , per gigabyte and requests .
And this is a common thing .
They're stacked on .
Yeah , they're stacked , but people don't think about this .
Yeah , exactly , people don't think about this , like all the different types of costs just within a single service and then how they all tie together like it's .
it's a mess on purpose or like a service insertion with something like transit gateway right , you pay when you pay all the different times . It goes in and out of the tgw attachments for the security , right , like there's it's , it's ugly man , and they do that . They keep it obfuscated on purpose and and it's really the ultimate micro transaction service .
Right , you know where you can feed in pennies and , oh crap , my pennies just turned into a thousand dollar bill , right ?
all right , um , so that's good . So let's , let's , let's kind of move on . Let's actually look at repatriation as a whole .
I guess the current status on repatriation do we do we feel like it's , you know , is this the manifestation of the loudest , or the first to go , like first to leave the cloud type thing , where you know it's the vocal minority that are talking about this , but in actuality , there's not a lot of meat on this bone here . How do you guys ?
So what are you seeing out there ? Is there a lot of people that are saying that they're doing this ?
¶ Cloud Repatriation and Growth Trends
If you refer back to the Day 2 Cloud show that we did , we had a guy on who'd done some research and reporting on growth of what's happening within different clouds .
Actually , I don't know if it was that show or a different show , but anyway there was a show we did whether it was the repatriation show or a different one where he studied what the growth curves were and what the budgetary planning were for the big three cloud providers and the point he was making was everybody's growing .
Google's not investing as much as everybody else , but everybody's growing . I know some other reports have come out that have basically said you know , maybe they're not growing as quickly as they were , but they are all growing the big three cloud providers , as they were , but they are all growing the big three cloud providers .
So if we look at that and we look at where they're standing up new data centers , where there's new regions and availability , where the submarine cable maps continue to grow these guys are building out all their own networks globally . It's not as if they're like , oh , everyone's leaving , we should slow down . No , they're getting bigger and bigger and bigger .
It's not slowing down from that standpoint . So are some people repatriating ? Yeah , is it enough that it seems to be materially impacting AWS , azure and GCP ? Not really .
I'm not seeing any data that suggests it's having a significant impact Like , wow , we need to have a marketing campaign to talk about the glories of public cloud and remind everybody the awesomeness that is . Because they're leaving . We're not getting any messaging like that . No one's worried , no one's that concerned . So there's some people that are doing it .
But another piece of this is I don't think it's an all or nothing . I don't think it's like we're going to repatriate and that means they're leaving cloud entirely Not likely .
It means they're picking and choosing certain applications that just don't really fit and probably never should have moved to public cloud to begin with , and bringing it back because they can do that more efficiently . So I think it's a complicated story the way it looks , and is it again materially impacting them ? I don't think so .
Have you guys seen anything that suggests that AWS or anybody else are getting particularly hurt by cloud repatriation ?
Definitely not repatriation itself . Obviously , I think in the last year a lot of them have kind of lost a little bit of the astronomical trajectory that they were growing in .
That happened eventually anyway . That's what I mean .
I don't think that's directly related to repatriation Because , like you said , I mean they're still . They're building out so many data centers , they're still laying so much fiber , they're still growing like crazy and looking for more opportunities to grow even more . So I don't think it has any impact currently on the bottom line at all .
Well , I mean also pay attention to the loudest talkers about all the repatriation that's happening . Like who are the people talking the loudest about all this repatriation and how inevitable the whole thing is ? It's a lot of . It's like Dell , it's like you know , it's like people that benefit from building data centers and from bringing that stuff in on-prem .
I'm not saying I mean , obviously everybody's got an ulterior motive somewhere , but I mean , yeah , I'm with you guys , I didn't . I don't . Outside of DHH , anytime anyone talks about repatriation , it's always that Basecamp article . I mean where's all the other people like , oh , we're getting the hell out ?
And it's always like , oh , mysteriously , they're just doing it , but they're not talking about it . I mean okay .
There's not that much content out there . You Google cloud repatriation you're going to get half a dozen or a dozen articles that come up that are unique , and there's not a lot .
There's DHH , who comes in with hard numbers and a lot of specific criteria about how it worked , why they worked , what they spent , what they're saving and why they're super unique as far as I'm concerned in what they're doing and why it works for them .
It's not like the most common story in the world where some CTO from a company is telling their story and they run a company that feels like most of the rest of the organizations that we support . That's just . There's not a lot of data out there like that at all .
Not to mention , I think , the , I think the Basecamp article kind of goes over what ?
what they were replacing and it was like , it was like a few racks of gear .
It was very small , very small . So yeah , it's like , yeah , if that's all you're getting rid of , then yeah , you're probably not gonna see these . You know um insane cost savings or insane um , you know the movements and agility and things like that . So , yeah , it's it's all .
It's all contextual it was a few racks they bought . They bought a bunch of big metal , um , and , but but only a few racks worth , yeah , but um , their savings pretty quickly were able to recoup . I think they spent 600 000 on000 on servers , something like that , and within a year they saved a million or a few million or something like that .
But we're not talking tens or hundreds of millions in their cloud spend so far from the biggest organization out there .
Yeah , I mean , there's an article that I'll link in the show notes from A16Z with Martin Casado and Sarah Wang , and this came out in 2021 , right , and it's called the Cost of Cloud A Trillion Dollar Paradox . And this was really .
It's a bunch of evidence to support not that people should repatriate , but the reasons why people might look into it and really the main takeaway .
If you don't read it , the main takeaway is there's a quote in here Basically , you you're crazy if you don't start in the cloud and then you're crazy if you stay in the cloud , and I think that applies for so many people like base camp yeah , you don't know your demand at first , so you start in the clouds , so you have that elasticity and you know
evolvability . But once you get to a certain point , it makes sense to start wondering about repatriation for certain applications , and I think that's true for every company .
It's the certain applications , right , like we all know that there are applications that will never fit an elastic model Like if you're , if you're , I don't know whatever . Pick an app where you just have to do chunking all day , every day , and that's what the app does .
That's never going to make sense to just sit there in the cloud and have it do it , especially if it's a static , what we call a static workload , where it's always doing the same thing . It's not going to grow , it's not going to shrink . So why are we running it on someone else's hardware ? We're just paying someone extra to run the same compute .
We could do it on-prem , so that makes sense to never have put in the cloud in the first place , much less through Patriot . So if you can't take advantage of elasticity , it probably shouldn't be in the cloud .
Yeah , there's definitely probably an internal cost of maintaining two operating models for things like that that are on-prem versus in the cloud , but that just feels like the cost of doing business to me .
¶ Challenges of Cloud Repatriation
But I mean to your point , yeah , about about people talking about this with something to gain from it , like , like you said , the like Dell Dell , for example , we have that .
I think there was a graph that was shared from Michael Dell just just like a few days ago I think , talking about that Barclays survey where it was like CIOs that are planning on repatriating and now it's like it started out with a very low number , kind of even keel , and now it's like the mass majority is planning repatriation of some sort .
But if that's the case , do we feel like that has to be a very small subset of things ? Or are people just keeping this close to the chest Like ooh , we're leaving the cloud but we're not telling anybody ? How does this happen ?
Yeah , it looks like . So I'm looking at the graph . It goes back to 2018 , basically , and there's like a light blue that is planning repatriation , and it's about 63 back in 2018 and now it's at 83 .
So it's I don't think it's quite as much as it seems like it is on the last picture , but it's the not planning repatriation that has gone down a lot as well but we need to .
I mean , you gotta , you gotta scope that right . So we say repatriation , we're not saying we're like you . Like you said earlier , ethan , it doesn't mean we're picking up , we're pulling up stakes and like we'll have no workloads left in the cloud , we're just everything's moving back right , nobody's .
I very seriously doubt that anybody maybe besides Basecamp is doing that .
Well , I think there's a challenge here . And when you say you're leaving cloud and you're going to repatriate that , okay , what do you ? What are you providing in your colo ? Now ? What are you providing to your developers ? They're expecting to have a cloud-like experience , and so what you need to be providing for them is is a private cloud .
That's really what I think you're operating by and large . You can't expect to disrupt , to have two different operating models . You can't go back to the way it was .
This is you're not going back to a decade or two decades ago where you're throwing tickets over the wall so that someone can stand up a VLAN and ports and get a VM running and put security in front of it , and that was a month , and now I can actually put work . No , it's got to be on-demand self-service . Come on , that's the way it's got to be .
And so I think that's another piece of this puzzle . If you're repatriating , you're repatriating it to your own cloud . Did you build one ? Do you have the operational expertise to build and operate your own cloud ?
I think that is a different thing , and I wonder how much of an impact that's having on certain organizations as they think through this and make their decisions . Now , if you follow with what VMware is doing right now the Broadcom , that's it , I got it .
If you look at their messaging and where they're headed now , they want their customer base to be moving to VMware Cloud Foundation , vcf . That is where they're expecting their customers to land . They want their customers to be operating a private cloud customers to land . They want their customers to be operating a private cloud .
So if that's the trend for the future , I don't know that . We're there yet for a lot of shops . I think there's a lot of shops that are still just running . If you look at the outrage in the changes to the pricing model and where VMware is trying to get their customers to go , and a lot of people don't want it .
They just want I have my perpetual license and I want to run VMware and my hypervisor and vSphere and that's it . No , that's not what VMware wants you to do . They want you to operate private cloud . That's where they are intending to take you as a customer . So we know there's a lot of people that aren't there yet .
I think that complicates the repatriation story . What are people repatriating to ? Are they really just going back to old school VMware or Nutanix or something like that ?
I think it's complicated because I've , you know , speaking from experience , just directly related to VMware's offering specifically in Azure , so AVS A lot of the kind of communications that I've seen coming from people on the VMware as well as the Azure side is like yes , you can deploy this on Azure um in its own dedicated instance , but you have to kind of treat
it as its own dedicated data center , treat it as its own , like physical location , separate from it . So it was like what are you ? What are you ?
really accomplishing .
Yeah , like , like , whether you could just do that on your own , um , or do it . You're not even really doing it in the cloud if you have to treat it in that capacity , right ? So like , what are you really gaining in that scenario ?
Yeah , the operating model is no longer agile , right , which is what you want . You want agile . That's the whole point . And that's a great point , ethan , and it's probably one of the most important ones is that CTOs and CIOs chase the . We'll save money by closing data centers . Go to the cloud . Now they're chasing the .
Oh crap , this is way too expensive , let's move it back . But what are they moving it back to ? And that is something that's not going to show up on a budget line item .
I think it's complicated . I started thinking through this . If you're going to repatriate now and bring it back , and you're trying to figure out what to bring it back to , how do you figure out the cost of that and do it well , do it accurately .
You've got a bunch of sunk one-time capital costs for the project to stand up racks or even if you're in a colo just to rent the RUs that you need and get in there , you got to fill it up with metal . And what hardware is it going to take to support your apps ? Your app , or your apps , presumably apps , a lot of apps .
Most organizations seem to have minimally many dozens of apps , if not hundreds , and I've talked to several organizations where it's thousands of apps that they're supporting . Okay , so are you going to do scale out or scale up ? How is that going to work ? You need to size your hardware appropriately for that . Is your app close enough to your user base ?
If you're up in the cloud , you can get your app close enough to your user base pretty easily just by picking and choosing where your apps are deployed .
If you're going to repatriate all of a sudden , you have to think about geography and where your clients are and make sure that your app is published and all the places it needs to be published , and you're kind of on your own for that to make that happen , whereas cloud makes that pretty easy . Do you have redundant architecture ? Can you survive outages ? Now ?
Remember those battle problems from disaster recovery planning days and quarterly exercises to make sure we can fail over and all that kind of stuff . Or making sure your app is architected so you can do active . Active Hardware's got a life cycle . It's going to age out . You got to amortize that cost . Is it three years ? Is it five years ? Is it seven years ?
How long is that metal going to last ? Do you have access to the hardware you want ? Can you even get at it ? Supply chains are better , right , I mean , most of the supply chain problems are over , but they're not gone . And GPUs , from what I'm hearing , are very hard to come by and they're not cheap .
So if you think I'm going to build my own AI learning cluster , yay , no , you're not . You can't get that hardware . It doesn't you know it's . Yeah , you're on a waiting list , and I could go on , but making the point that if you want to repatriate , you got to repatriate to something . What is the cost to build that and operate that ?
And that's just hardware , let alone the software layer . Now that actually does all the work to provide you with that private cloud . And then what about the people that are going to operate this ? Do you have the heck ? Well , we'll use the same people that we use to operate our public cloud infrastructure . Maybe , maybe not .
Dhh would say yes , that's , we just had the same people you know come over and they did the same things .
He had a very small . He had a very small footprint , though , right .
Is it all the same skills or not ? I'm not convinced . The skills are identical . There are very similar skills and I think you can pick up those skills .
But it's not a slam dunk that because you have a bunch of Azure AWS gurus on staff that they're just going to be able to pick up and operate a private cloud super easy , and it's going to be able to pick up and operate a private cloud super easy , and it's going to be awesome .
And when you begin thinking about that geography stuff , just be able to provide an effective disaster recovery or business continuity solution , whereas the cloud , it was basically clicking and it's done . How do you do that internally ? Now you actually have to think about things like bandwidth in between remote locations and having data replicated everywhere and so on .
All of that stuff Again like the bad old days , the reasons . We were like , oh , screw this , I'm going to cloud .
Yeah . So , as you can see , I think that this point is probably the most important point for this whole episode , and we should do an entire episode just around what it would look like to actually repatriate . And come back , ethan , you've named a bunch of things , and that's just the start of it . Like you said , it's just the start .
What about infrastructure as code ? Has anyone actually tried ?
Yeah , automation .
I've done a lot of trying to make Terraform and stuff work with on-prem traditional vendors . It's not pretty and it's not easy and there's , like you know , are people going to start using Backstage right to provide developer platforms , like there's so many things to consider and the bottom line is you're competing against the hyperscalers . You don't have the resources .
They do , no matter how much money you have or how big of a company you are . So it's just like there's just so much to talk about that people don't think about when it comes to this . That makes it very difficult to keep up .
Yeah , I think the automation thing is probably the biggest , the longest pole in the tent of repatriation .
Like , you can go buy hardware , you of repatriation , you can go buy hardware , you can go buy software , you can hire people to run your VMware environment , but you can't provide Nobody out there today provides that on-demand experience , that agile experience of automation , spin up , spin down , elasticity , all of that stuff you get from public cloud .
None of that is provided on prem . You can't go to the store and buy that software . It doesn't exist right . You've got OpenStack . You can good luck trying to figure that , you know somebody's probably figured it out but you can go build it with OpenStack but it doesn't exist right .
Like , if you want to run it on-prem , if you want that cloud experience , you've got to go build it yourself .
Yeah , I personally I don't think it's there yet and it's slowly kind of creeping towards that . But there's still a long ways to go and anyone who says that they have it is probably trying to sell you something , right .
Yeah , and I think you know it's . I wonder if you do take a lot of the same clientele or you know the same you know workforce that's currently doing things in the public cloud and trying to move it on prem .
I think you're going to create this dynamic of people that are just , you know , wondering about the good old days when things were all API driven and it was all built out for them , right . And now , because if you bring them on cloud , you're like , okay , you remember all those things that you liked about cloud , let's build it here and that's .
It's probably good in the sense that they know the things that they like and the things that they don't like , but it's immediately going to turn around on its head when they realize how hard it is to build the things that they like , because it's going to be just a daunting task to even step foot in that realm . Right , so it's ? Yeah , I mean , so that's .
I guess that's . That's
¶ Future of Hybrid Cloud Complexity
a good segue . What is ? What is the future of hybrid ? I'm glad we come around to this point because I think we've been saying this since the start of this podcast that hybrid is the future . We feel like that's always going to be the tent that fits most most people . So what is the future that look like ?
Are we looking at workloads that have been brought on-prem , but do we have this dynamic of disaster recovery where things fail over to the cloud ? Or , if capacity needs reach a certain level on-prem , do we extend to the cloud ? Is that a possibility ? Where do we feel things are going to have to go from here ?
It goes back to what we were saying earlier Not all workloads are cloud friendly . And even if I'm running them , if I'm repatriated , then I'm on-prem . Now I guess you're saying do I run them in cloud in an emergency Because it's going to cost me dearly , but it's better than being down .
Yeah , pretty much yeah .
Yeah , pretty much , or terabytes of it . That's not quite the problem . That petabytes is Still .
You're shoving this data across a wire somewhere to get it so that your cloud instance can actually use it , and being able to do that in a timely fashion can be a big challenge , and I always find these scenarios of oh , I'm just going to stand it up in the cloud real quick if we have a problem . Are you , though ? Because it's not .
How exactly do you do that ? Again , the compute's one thing , the storage is a whole different thing .
Where does the data live and how do you get it where it needs to be ? That's always the question .
I think another funny thing that I just thought of is , you know , we're talking about building a private cloud to compete with public cloud , and some of the examples that have been given about applications that move to the cloud just lift and shift .
Well , if they were never refactored for the cloud when you repatriate , they're still not ready for your on-prem cloud either , right ? So there's still a lot of work , no matter what to be done .
Yeah , it was just definitely going to affect things like scale out versus scale up . If you can't scale out with the app because that's just not the way it was built , it kind of doesn't matter where you put that stupid thing it just is what .
it is Just the cheapest around . It's going to cost you ?
Yeah . Another thing we haven't talked about at all is SaaS , but I think we didn't mention it at the top of the show . We're talking about repatriation , I think SaaS is . That's a different thing , that's a different discussion , but it does .
Saas does come in a lot when you talk about hybrid , because there are companies that when they think about hybrid , they're like well , we have this service and that service that we use . Yeah , that's not going to change . You're still going to use your SaaS offering , whatever it is , without that changing too much , and still consider yourself hybrid cloud .
It's just not what we're talking about at the moment . I don't think it's the big deal here . Another challenge with hybrid to me is just the complexity of it .
You're running in two different environments , two different operational protocols , two different ways of thinking about things , two different cost models , two different amounts of proximity and latency to your user community .
You have a complex network interconnection potentially something as simple as a VPN tunnel or as complicated as you care to make it with different multi-cloud networking providers that you might layer on in the middle to manage that and manage the security of it for you . There's different skill sets that are involved there .
Do you got to have those skill sets in-house to be able to support that . So you got to have the AWS people that also know how to run your private cloud too a point we brought up earlier and any time you put a technical solution together that has a lot of complexity , it tends to be fragile .
There are elements of that solution because it's complex and it's powerful , it can do a lot of things , but it'll break . It just has a tendency to break . There's there's dependencies , interdependencies between processes on networking , on dns and it working right , on security and it working right that when something in the chain breaks , the system goes down .
Complexity breeds fragility and a multi-cloud or hybrid scenario like this , where something's going to be on-prem and some of it's going to be up in the cloud and we're just going to mix and match and do what we want . Are you , though , again , are you ? I don't ? I wouldn't go for that as my primary .
Looking at cloud as backup , maybe , but I don't want to live in both worlds . I don't think Not for the same app .
anyway , did you guys ever talk to anyone on any of the Packet Pusher shows about the people from I think it's , target and Walmart , both kind of have like their own on-prem cloud and they can burst up to public cloud ? Yeah , they do cloud bursting , but I've seen . They're the only two companies I know of that .
I've seen talks they did I don't remember what year it was , it was a couple years ago but they talked at onag about that exact scenario . But they're the only two companies I know of that I've talked .
Think of the scale of their it ops . That's what I mean . That's giant companies , yeah , yeah , no , cloud bursting was all the . That was one of the reasons you were gonna , um , go to cloud , or was one of the the features the vendors are going to sell you our ability to cloud burst . This goes back , you know , 10 years ago .
It's like a thing and it's just . I'm the same as what you were saying , alex . I don't know if really anybody doing it unless it's boutique and it's a shop that you know has the ability to bake that feature in . It's not like we all know about the software that allows us to do cloud bursting with a click . That doesn't exist .
It's not a thing Right and you're . It's almost like whatever app you write has to be written in that way , Like I wrote the app so that I could cloud burst it Right .
So right , how many of us have been on the networking side of things ?
And because the app wasn't written for that , we're doing stupid network cartwheels with tunnels and NATs and crazy DNS things and BGP , anycast or whatever crazy things we're doing just to make this thing work right , and then staring intensely at the storage arrays going you stay in sync , you stay in sync .
Don't you dare , because then the whole house of cards falls down .
I mean that one's the tale of all this time man Pick an app , run it anywhere . That's always been the case . We wrote this shitty app and we can't change it , so you just got to make it work .
Yeah , I think you make a great point , ethan , in that a lot of people aren't going to want to live in two camps of doing it this way versus doing it that way , on-prem versus cloud , but it seems like , I don't know , there's a lot of heavy lifting that's going to need to go in and front load that to give those app teams the ability to make the proper
decision about putting it in one camp or the other . And how do you ?
I still don't think . It's even not , I don't know . Yeah , it's still not going to be even that simple . I still think there are going to be use cases to have certain services that live in cloud and certain ones on-prem for sure , right , and there is going to be a need for multi-cloud networking .
To me , the distinction I would draw the line as if I want to run the same app in those two places no , you don't , I don't , you don't want to run a particular service up in the cloud because reasons , and you want to have this core app live here because reasons . Okay , you can kind of make that make sense .
It's more like the two data center model , the multi data center model , where you can kind of get your head around that and make it make sense . It's still complicated and , depending on the service , it might be we're using this magical Azure service that does the thing and so we have to stay plumb to the cloud because the Azure service is doing the thing .
Okay , fair enough , you know , if that's , that's what that is . And then it goes back to the networking people again to make sure the whole house of cards doesn't fall down .
Well , I mean we , so like Chris and I , work at Aviatrix , right , and a lot of our customers are heavily invested like most cloud customers are these days and more every day , in the Azure identity stack right , because it's seamless and works perfectly on-prem . And like talking about hybrid , what about Azure AD versus on-prem AD and the syncing and all that ?
Right , but also that extending identity to other clouds right . So I mean , the use case has been established for why you would do it . I think the question we have to , well , every organization has to ask itself is is the complexity required to make this work ? Is the juice worth the squeeze ? Right ? At the end of the day ? Right ?
Is it worth it ? Yeah , and there's no one answer for that is there . Is it worth it ? You know it depends .
It's a question of budget , it's a question of skillset and the answer that might be right for one company might be wrong for another one because of nothing to do with technology and everything to do with budget or headcount , or you know things that are Culture , who knows ? Yeah , that are that way .
As a young engineer , I was always frustrated when decisions were made that had nothing to do with technology , it's like but this is the right technical decision to go this way . We should have bought this box or implemented the software whatever it was .
And as I got older and wiser , I learned oh , there's this thing called a budget , and sometimes you don't have the people to do it . And oh , just because I , in my young youthful exuberance , think that the ideal solution is X and we didn't do X , which means we compromised . No , it means we did the right thing in face of all the circumstances .
And that's this all over . You know for sure , and I'm telling you , complexity in IT , to me , is driving me nuts . I have looked over the last I was going to say 10 years , but even five years at the number of things we have added to the stack . You guys brought up automation a little bit ago . Okay , automation doesn't actually change the technology .
It just changes how we deploy the technology . That's just tooling and it's process and it's operations and it's how we get something done . It's not the thing we're doing . You look at networking and all the overlays that we've added to the stack .
Now you look at security and the myriad different layers that we're doing security now and what it takes to put an IT stack together that is robust and modern , that's DevOps friendly , that's infrastructure as code and the skill sets that you need to have in-house to be able to support that you actually have to .
Going back to the is the juice worth the squeeze question I think it's up and down the IT stack now where you have to think about that and really take a step back and go okay , we can do these things , they give us these advantages , but wow , the implicit technical debt that's created every time you flip a new switch and turn a new lever and add a new
tool and the complexity that adds to your stack makes it sticky , makes it hard to move , it makes it hard to repatriate if you want to repatriate it makes it hard to change . And we're getting deeper and deeper and deeper with these things as IT evolves and as new market segments come out .
And it's like , oh , you got to have the new thing , you got to do sassy Now that's the latest , it's , et cetera . I think it's a .
It's a growing I want to say it's a growing solution , but it's a growing problem to me , all this complexity . Do we have to have all of this stuff that makes our it stack what it is ?
As you say . It's funny we've gotten this far and we haven't even really talked about security , because that's also another thing of maintaining security across you know , obviously the demands yeah it's , that's , that's a , that's a burden on its own . So maybe that'll be . I don't think we'll have time to get into it today , but maybe that'll be on the next one .
Alex , did you have something ?
Yeah , I got a . I got a somewhat quick one . You know I love to talk about platform teams , so I think to me this is like a perfect example of why platform teams are going to be more and more important in the future .
And I mean it just showed right Like we just had an episode with Chris Wall talking about platform teams and that was really for more , I guess like kind of more traditional on-prem stuff , but it just shows like platform teams need to be able to go everywhere .
Multicloud , on-prem like every single thing that's what a platform team is meant to solve is these kinds of complexities .
So I don't know that businesses see it the same way , right , I think they just kind of see it as oh , these are people that can tie all our things together , but the people that are on these teams are going to be the ones that come out with these new products and new ways of how we can tie everything together .
You can replace what I was saying earlier in the show about you're building a private cloud with you're building a platform .
You're doing platform engineering . That's really what's going on , yeah
¶ Building Cloud Platforms for Repatriation
.
Yeah , and I've talked to Chris Chris and I keep up pretty regularly and I know a bit about some of the things he's built with some of his projects and yeah he's taken the way we used to build IT thrown it out and rebuilt it in the model of a platform .
If I had to build my own cloud , if I had to build something that's self-service for developers but still private , what does that look like ? How do I do that ? What's the thought process behind it ? He's got a lot of thinking behind it .
He showed me some internal only stuff of how to think about that and I'll tell you it is not the way those of us coming from traditional standing up servers and racking things and cutting ourselves on cage nuts and so on . That's not the way we grew up to think . It's a whole different thing that comes from the cloud paradigm .
Yeah , yeah , and I think he's got four blog posts out right now about building platforms and kind of his thoughts behind them , so definitely check them out . We'll link his website in the show notes as well .
Wallnetworkcom .
W-A-H-L networkcom .
Yeah , well worth a sub .
Well , and we need the platforms because of what you just said , ethan how , as the technology matures , we just get more technology right and it's more complicated and it's more interconnected , as it should be . Interconnected is something that we should have always had , probably . We can't silo anymore , because the tech doesn't allow us to silo it anymore .
Really , it's all interconnected , so it's form following function . And then I couldn't agree more .
On the plus side , the world is getting better connected , where the challenges of latency and so on are reducing . I live in a rural town in the mountains of New Hampshire . Somebody in my town is ruling fiber out . There are huge spools of fiber going out everywhere . I'm not sure who the provider is . 100% I think it's Fidium .
I think I saw on somebody's truck Not positive , but I mean the fiber is getting out there . There's enough investment happening finally in America that even in the hinterlands where I live the broadband and the fiber is getting rolled out such that maybe it does get a little easier to build some of these solutions without worrying about oh geez , how much latency .
55 milliseconds . Oh , that's going to suck , and maybe it's not as bad a problem as it was , oh yeah .
Yeah , we just got fiber within the last year in my neighborhood .
You just got it Fiber . I don't have it here , that's not happening in Australia anytime soon , so I do miss it . I was in Tulsa , oklahoma , prior to this and had fiber to the home and it was wonderful . But you know tradeoffs , right , this whole episode is about trade-offs . I made a trade-off to come here , right . But with that , yeah , let's wrap it up .
I think I think this has been a good conversation . I think it's funny that this is a topic that's kind of bubbled up and started getting some commotion on the socials and things like that , because it just made it it . I feel like every blog post and every um kind of uh take I've heard on it made it so trivial .
Uh , in that it was just , you know it's , it's so easy . You know why wouldn't you repatriate ? But we've spent you know 50 plus minutes here talking about how complicated it is and why you should really put thought into it prior prior to doing it . Um , so , yeah , with that .
I guess , ethan , do you have any closing thoughts you want to make on repatriation before we wrap up ?
Well , just to echo what you were saying , chris , it's not a straightforward solution Like ah , you bring it back , you save money . Yeah , that's the beginning of the conversation , the very , very beginning , and all the cost that's involved is not in terms of dollars and cents .
There's a lot more to it than that , and to really make an intelligent decision about whether or not you're going to repatriate , you have to do a robust return on investment analysis .
It's going to be a serious study , with either your team internally or you bring in a consultant that actually knows what's going on and knows how to quantify these costs and the non-dollar costs to help you figure that out .
This is a serious undertaking , very serious undertaking , and if you don't remember the old days of what it was to run your own racks and run your own servers and your own power and cooling , even if you're doing a colo , now time to remember , time to remember and that's like a business model , right .
Like someone could be like the opposite of the duck bill group and do it for on-prem right . Just figuring out all the financial implications .
Yeah , it starts with the costs of the CapEx and the OpEx and then it goes to do we even have the skills to do this ? What does it take to scale up ? Do we have the headcount ? What does it take to find those people , and so on .
How much agility ? How does this extend our software development timelines ? Because we don't have the on-demand anymore . Like you know , there's definitely a lot of stuff that doesn't end up in a budget sheet to think about .
Yep , 100% . All right with that . Let's close it out here . So thanks again , ethan , for coming on . This was great , and you know as much as you probably don't know how much people know about you . I know I've been listening to Packet Pushers for years , so it was great to have you on and , lastly , I'll give it to you Anywhere you want to plug .
You know where can we find you online ?
Yeah , 100% PacketPushersnet . If you go there , we have not just the original Heavy Networking podcast , which is how Packet Pushers started , but several other shows as well . We've mentioned along the way here Day 2 , cloud . We've also got specialty shows like if you're into wireless , we've got Heavy Wireless with Keith Parsons .
We have a security show now , packet Protector with JJ Minnell and Drew Conroy-Murray . Our weekly news show that I know a lot of people really like is Network Break .
We have a strategy show for those in the C-suite and we tend to any architects that like to think about strategy , heavy strategy , and I'm sure I'm forgetting something because I'm rattling these all off the top of my head . But anyway , go to PacketPushersnet . They're all there right on the front page .
Or just go to wherever you listen to podcasts Spotify , apple Podcasts , type in Packet Pushers and a whole list of shows will come up . And we got other stuff too , guys . We have a Slack , community newsletters and all the things . We have all the things .
So if you want to follow me personally , you can find me on the Packet Pushers Slack group or on LinkedIn . Linkedin is where I do most of my social posting these days . It seems to have you know . I was on X Twitter there forever and I'm still there occasionally . I'll tweet something very occasionally , but LinkedIn , linkedin's where you can find me .
Yeah , linkedin's talking the most these days .
That's fair . It's crazy how hard LinkedIn's come back into the fold . For me , I did not see it coming , but here it is .
The shitification of the of the competition .
Yeah , no , kidding , all right . Well , thanks a lot , guys . This has been cables to clouds . You can find us online at cablesables to Clouds on all the socials any of them . There's so many of them out there , we're probably on all of them .
Hit us up at Cables to Clouds at gmailcom if you have any inquiries or want to chat to us about anything at all , and we will see you next time . Hi everyone , it's Chris and this has been the Cables to Clouds podcast . Thanks for tuning in today .
If you enjoyed our show , please subscribe to us in your favorite podcatcher as well as subscribe and turn on notifications for our YouTube channel to be notified of all our new episodes . Follow us on socials at Cables to Clouds . You can also visit our website for all of the show notes at CablesToCloudscom . Thanks again for listening and see you next time .