WEBVTT
00:00:05.040 --> 00:00:08.000
Hello everyone and welcome back to the SourceForge podcast.
00:00:08.080 --> 00:00:09.519
I'm your host, Bo Hamilton.
00:00:09.599 --> 00:00:18.320
Now, today's episode, we're getting into something that I think a lot of engineering and IT leaders are quietly wrestling with right now, and that's where should your infrastructure actually live?
00:00:18.480 --> 00:00:25.039
Uh for a decade, the default answer was the public cloud, obviously, but that default is getting challenged.
00:00:25.280 --> 00:00:35.119
Barclay's CIO survey found that 86% of CIOs planned to move at least some workloads off of the public cloud, which is the highest that number has ever been.
00:00:35.280 --> 00:00:40.479
So something's obviously shifting in how companies think about performance, cost, and of course control.
00:00:41.119 --> 00:00:44.880
My guest today is uh he he has a front row seat to that shift.
00:00:45.039 --> 00:00:57.359
Isaac Douglas is the general manager of servers.com by Nexus, a global infrastructure platform that's built its reputation on bare metal and recently joined forces with the Nexus and Liquid Web family.
00:00:57.520 --> 00:00:59.280
So I'm really excited to have Isaac here.
00:00:59.439 --> 00:01:08.480
Isaac has spent well over a decade in the hosting industry, several of those years in video game hosting, which is basically the ultimate stress test for infrastructure.
00:01:08.719 --> 00:01:16.959
You think about the hundreds of thousands of players, you know, hammering your servers at the exact same second, you know, all of them sort of allergic to lag.
00:01:17.359 --> 00:01:20.719
That's that's definitely a one way to test the limits of one's infrastructure.
00:01:20.959 --> 00:01:22.640
So um we're gonna get into that.
00:01:22.719 --> 00:01:31.120
We're gonna dig into where the public cloud model breaks down, what the alternative actually looks like, and how companies are making the move without lighting things on fire.
00:01:31.280 --> 00:01:34.480
So with that said, um, Isaac, welcome to the podcast.
00:01:34.640 --> 00:01:35.840
Glad you could join us.
00:01:36.239 --> 00:01:38.079
Yeah, thanks for having me.
00:01:38.560 --> 00:01:41.120
So um I want to sort of set the stage here.
00:01:41.200 --> 00:01:47.760
Um, there are a lot of names in the hosting world, and servers.com by Nexus is actually a sort of a newer combination.
00:01:47.920 --> 00:01:53.760
Servers.com has been around since 2014 and it recently became part of the Nexus family alongside Liquid Web.
00:01:53.840 --> 00:02:00.239
Uh, for listeners, hearing about servers.com by Nexus for the first time, how would you describe what the company does?
00:02:00.719 --> 00:02:04.400
Yeah, I think what we're best known for is being bare metal.
00:02:04.560 --> 00:02:07.760
So uh a true infrastructure as a service platform.
00:02:08.000 --> 00:02:13.599
But I think we were probably one of the ones that led the charges, a bare metal cloud, right?
00:02:13.919 --> 00:02:24.639
So this idea that back in the day bare metal was slow and long contracts and slow to provision and very manual.
00:02:25.039 --> 00:02:29.520
And we kind of came along and went, well, bare metal doesn't need to be that way.
00:02:29.759 --> 00:02:35.520
Hyperscale cloud and virtualization doesn't need to be the only answer to automation and scalability.
00:02:35.759 --> 00:02:47.520
Like, let's create a bare metal cloud platform where you can get all the benefits of bare metal, so cost, control, security, but let's make it scalable.
00:02:47.680 --> 00:02:55.199
So give our customers that ability to kind of scale up and down as they need, but get all those benefits of bare metal as well.
00:02:55.520 --> 00:02:56.000
Gotcha.
00:02:56.080 --> 00:02:58.719
Okay, so the scalability is a really big component there.
00:02:58.960 --> 00:03:06.000
Now, as I alluded to sort of in the introduction, I know a lot of companies, you know, they didn't just sit down and carefully sort of choose their infrastructure.
00:03:06.080 --> 00:03:10.560
They just sort of defaulted maybe to the public cloud because that was kind of the standard practice.
00:03:10.639 --> 00:03:12.560
It's maybe the path of least resistance.
00:03:12.719 --> 00:03:16.000
Maybe you could talk about where that model start to break down.
00:03:16.479 --> 00:03:20.879
Yeah, I think, you know, in the old days you would say no one got fired for buying IBM, right?
00:03:21.039 --> 00:03:23.919
Uh, I think everyone in tech has heard that saying.
00:03:24.080 --> 00:03:29.039
And I think for the last 10 years, you could probably say no one got fired for buying AWS.
00:03:29.120 --> 00:03:30.639
It's become the safe bet.
00:03:30.879 --> 00:03:42.960
And I think where it's really broken down is the promise of hyperscale was simplicity and cost savings and lower total cost of ownership.
00:03:43.120 --> 00:03:48.639
And as those platforms have grown and grown, the complexity's massively gone through the roof.
00:03:48.719 --> 00:03:55.840
You've got over 200 different services that you need to navigate how to buy, generally by yourself.
00:03:56.479 --> 00:04:08.560
Support is probably not as good as it could be in terms of they're just doing it at such a scale that it's hard to give everyone a white glove experience.
00:04:08.960 --> 00:04:12.159
And the costs, you know, have crept up over the years.
00:04:12.400 --> 00:04:19.600
And I think what our customer bases that are coming to us and saying is this isn't as simple as we were sold.
00:04:19.759 --> 00:04:30.560
This is way more complex, it's way more costly, but it you know, it does scale, and we will we want to still be able to have that scalability, but we want to also gain back that control.
00:04:30.879 --> 00:04:35.040
So that's where it's really breaking down for a lot of our customers that are coming to us.
00:04:35.439 --> 00:04:46.000
Yeah, you mentioned AWS, and it's like I, you know, you're not saying like burn down your AWS account, you know, um, but thinking about like stop treating one tool as sort of the answer to every workload.
00:04:46.240 --> 00:04:49.920
I think there's a lot of things to consider, of course, but yeah, it's it's neat to hear your thoughts.
00:04:50.000 --> 00:04:57.120
And I actually just want to plug your, you have a blog post uh you posted a while back uh titled Why the Hyperscale Cloud Bubble is Bursting.
00:04:57.279 --> 00:05:06.079
So for listeners, viewers um who want to learn more and hear more of your thoughts and um in-depth opinions on this topic, that's a good place to go.
00:05:06.319 --> 00:05:20.399
But maybe you could walk us through some of the problems that arise for teams running, like let's say, high traffic apps, gaming platforms, media servers, you think uh fintech systems, and of course AI, uh AI workloads, what infrastructure problems tend to show up first?
00:05:21.360 --> 00:05:34.800
For those kind of applications where they're you know high performance cloud applications, we tend to find that customers are hitting the edges of what's capable within their given platform, right?
00:05:35.040 --> 00:05:43.360
And so very much what you just said, which was one company, one platform shouldn't really be the answer for anyone.
00:05:43.600 --> 00:05:50.879
And I talk about that quite a lot in that actually when people come to us, I don't think they should be all on service.com.
00:05:51.040 --> 00:05:59.920
I think they should probably have service.com and another bare metal provider and probably multiple hyperscalers within their infrastructure mix.
00:06:00.160 --> 00:06:23.199
So it's when you get to a hard edge of any individual platform, or you find a part of your application stack that doesn't quite fit that particular platform or the way you want to solve a problem, you need to have that supplier mix to be able to go, okay, I'm gonna go solve this particular problem different, but it all needs to work together.
00:06:23.360 --> 00:06:50.399
And I think that's one of the things that kind of a hyperscale bubble is the same that blog post is it's like people have gone all in on one particular thing, and I think people are becoming wise now of actually what we need to do is we need to have a multi multi-vendor approach, we need to have different solutions to different kinds of problems, and one way of doing things isn't always the best answer.
00:06:50.639 --> 00:06:56.800
Now, when it comes to AI, that's what everyone wants to talk about right now, right?
00:06:57.040 --> 00:06:59.279
And it's a very different problem.
00:06:59.839 --> 00:07:03.759
Everyone is scrambling for capacity right now.
00:07:04.079 --> 00:07:10.480
Backlogs in these hyperscalers as well as the neo clouds are becoming really, really high.
00:07:10.720 --> 00:07:19.759
And really, it's about finding a vendor that can hit not just your technical requirements, but also hit your timelines.
00:07:20.399 --> 00:07:29.120
And the hyperscalers and the very large neo clouds, they're gonna go and chase those huge deals because you know that's what makes headlines.
00:07:29.360 --> 00:07:39.199
And I think there's other providers out there, including ourselves, where we still have quite a lot of scale available to us, but maybe we're not quite chasing those bigger deals.
00:07:39.439 --> 00:07:52.399
So if you are not an open AI or an anthropic and you're going and doing multi-gigawatt deals with data centers, you know, looking at further afield into different suppliers is probably going to be really beneficial.
00:07:52.800 --> 00:07:59.120
As we talked about the problems, I want to talk about some of the answers to them because I know servers.com isn't just a pile of their metal.
00:07:59.199 --> 00:08:00.560
There's there's like a whole stack around it.
00:08:00.639 --> 00:08:05.680
It offers cloud servers, storage, firewalls, load balancing, private networking.
00:08:05.759 --> 00:08:06.720
There's a bunch of features.
00:08:06.959 --> 00:08:10.079
How did those all those pieces actually come together for customers?
00:08:10.160 --> 00:08:13.839
Like what does a typical architecture stack look like?
00:08:14.399 --> 00:08:18.720
Yeah, so we we definitely did start out as just bare metal.
00:08:19.040 --> 00:08:27.839
And as we've we've grown as a business and as we've matured as a company, what we've really tried to focus on is two things.
00:08:28.160 --> 00:08:34.879
One is to listen to our customers, take feedback from them and build what they want.
00:08:35.279 --> 00:08:48.720
And then the other one is to try and close the gap with the hyperscalers to make it as easy for people to get the benefits of scalability and the hyperscalers with all the benefits of bare metal cloud.
00:08:49.039 --> 00:08:55.120
So it really comes down to your unique use case with us.
00:08:55.440 --> 00:09:04.720
We're not trying to build solutions where we're like, you come to us with a problem, and we're like, hey, this is the solution that we're going to sell you because we sell it to everyone.
00:09:04.879 --> 00:09:07.759
We're trying to tailor that for each customer.
00:09:08.000 --> 00:09:10.639
But typically a customer can come to us.
00:09:10.799 --> 00:09:13.039
It all starts with a server, right?
00:09:13.200 --> 00:09:25.440
It all starts with a server and how we make that enterprise grade, how we keep that server online in enterprise grade data centers and build an enterprise grade networking stack.
00:09:25.679 --> 00:09:38.399
And then it's about working with our team of experts on designing a solution around networking elements, say load balances, firewalls, storage.
00:09:38.799 --> 00:09:41.120
Do you need some cloud servers with that?
00:09:41.279 --> 00:09:45.360
Do you need some scalable bare metal along with your fixed bare metal?
00:09:45.600 --> 00:09:53.120
And they'll bring in those expertise of our product and help tailor a solution to each client's need.
00:09:53.279 --> 00:09:56.799
So there isn't really a typical stack for us.
00:09:56.960 --> 00:09:59.840
You know, there's always servers at the end of the day.
00:10:00.080 --> 00:10:16.639
There's always a data center at the end of the day, but really our where we've found value for our clients is being real consultants and listening to their problems and then coming up with a solution rather than having a solution and trying to, you know, only sell that cookie colour approach.
00:10:17.039 --> 00:10:27.440
There is one area that I do want to zoom in on because it sort of sits at that intersection of everything we sort of talked about, the flexibility people love around cloud and the performance of dedicated hardware.
00:10:27.519 --> 00:10:33.440
And that's Kubernetes, specifically manage Kubernetes on bare metal, which is offered by servers.com by Nexus.
00:10:33.600 --> 00:10:43.120
And for listeners who might not be super familiar with Kubernetes, basically it's like it's like the platform that automates the deployment, scaling and management of containerized applications.
00:10:43.519 --> 00:10:45.919
Maybe you can expand upon that uh for listeners.
00:10:46.080 --> 00:10:56.000
But I'm curious, like, how does manage Kubernetes on bare metal help teams get the benefits of the platform without taking on all of the operational overhead?
00:10:56.480 --> 00:10:59.759
Yeah, actually, I think you did a really good job of explaining it.
00:10:59.919 --> 00:11:04.559
And, you know, I was I was working with some of our new team members last week.
00:11:04.879 --> 00:11:14.960
And yeah, I think as an industry, we've gone from bare metal to virtualization was the savior of utilization across bare metal.
00:11:15.200 --> 00:11:27.120
And I think Kubernetes, whilst different to obviously different to virtualization, really takes that management of infrastructure and obfuscates it to an application level.
00:11:27.440 --> 00:11:41.120
And we really wanted to bring a product to market that allowed our customers to think of infrastructure as more like how do we scale their applications rather than how do we scale this infrastructure.
00:11:41.440 --> 00:11:51.279
And so we brought to we brought to market a product, you know, we call it managed Kubernetes, where we're taking over that overhead of managing the control plane.
00:11:51.600 --> 00:12:00.559
And the customer is just buying and using compute within Kubernetes cluster or multiple clusters with us.
00:12:00.879 --> 00:12:23.200
And what we're working towards in the future is with our scalable bare metal product, which will allow customers to scale up new bare metal instances in under 10 minutes and pay by the hour, is we're gonna have Kubernetes running across that and we'll be able to enable auto-scaling just like you would on a hyperscaler with their Kubernetes products.
00:12:23.440 --> 00:12:27.279
We charge no overhead for the Kubernetes managed Kubernetes service.
00:12:27.360 --> 00:12:29.200
It's just the cost of the compute.
00:12:29.440 --> 00:12:38.799
And I think that what that's really gonna do for our customers is allow them to seamlessly migrate workloads across hyperscalers and bare metal as if it's exactly the same thing.
00:12:39.120 --> 00:12:42.399
And that's why we really wanted to be one of the first to bring that to market.
00:12:42.960 --> 00:12:43.759
Wow, very cool.
00:12:43.919 --> 00:12:54.559
Yeah, so it sounds like Kubernetes was supposed to sort of abstract away from infrastructure, but instead it's sort of a lot of teams sort of ended up managing more infrastructure than before because of it.
00:12:54.960 --> 00:13:07.039
Yeah, I think uh, you know, there's like with any new technology, you've got people in your team that are specialists in one thing and a new technology comes out, and it doesn't mean they're instantly gonna be specialists in the next thing.
00:13:07.279 --> 00:13:21.120
And I think a lot of teams around the world had experience in system administrator or they were experts in VMware or other virtualization technologies, and that doesn't instantly mean anyone's gonna be an expert in Kubernetes.
00:13:21.279 --> 00:13:30.080
So we wanted to build that tooling and expertise in-house, and we'll take care of that complexity of running Kubernetes on bare metal.
00:13:30.159 --> 00:13:36.639
And for our customers, they just get a buy computer and they get to worry about their applications and how that's gonna scale.
00:13:36.799 --> 00:13:41.840
And again, our consultants will work with them and uh work on finding the right solutions.
00:13:42.080 --> 00:13:51.279
But um, we wanted to take a lot of that headache of working some of this stuff out away from the customers and uh do that in a way that made sense uh commercially for them.
00:13:51.759 --> 00:13:58.480
So let's say uh, you know, someone listening right now is is is nodding along, they're looking at their latency, and that's not a pretty picture.
00:13:58.639 --> 00:14:01.279
But all this sounds great in theory, everything you've mentioned up to this point.
00:14:01.519 --> 00:14:05.039
There's a reason people stay put with, let's say, like the public cloud.
00:14:05.120 --> 00:14:07.759
The moving infrastructure is a daunting process.
00:14:07.840 --> 00:14:10.960
It's it's sort of like the open heart surgery of a business.
00:14:11.279 --> 00:14:17.440
What are companies usually worried about when they're moving infrastructure providers or redesigning their hosting environment?
00:14:17.919 --> 00:14:26.159
Particularly for our customer base, and we're dealing with businesses that are the vast majority of their businesses online.
00:14:26.320 --> 00:14:29.039
They were maybe born online as a as a business, right?
00:14:29.120 --> 00:14:36.639
They never had bricks and mortar presence, you know, they were born online companies, and it's the lifeblood of their business.
00:14:36.720 --> 00:14:46.879
And if they make the wrong decision in their infrastructure, you know, it can cost a lot of money to people's lives and businesses and profits and staying alive as a business.
00:14:47.200 --> 00:14:55.200
So it does take a lot of trust to move your infrastructure, and generally you need to be in some kind of pain.
00:14:55.360 --> 00:15:08.480
And whether that's you're having outages or the support's terrible or your prices are scaling at such a rate that you can't actually take on more customers because it's becoming unprofitable to do that.
00:15:08.559 --> 00:15:10.639
And we've had several instances of that.
00:15:10.879 --> 00:15:13.440
I think you've got to be prepared to go through a process.
00:15:13.600 --> 00:15:16.960
I've written a blog on this as well, that it's going to be painful.
00:15:17.200 --> 00:15:23.679
And anybody thinking about going through it needs to go in with their eyes wide open, that there is going to be some pain.
00:15:23.919 --> 00:15:46.720
We actually have a calculator which we built internally for internal use of helping people understand what their cost of migration is going to be, and then calculating what their ROI is going to be of that migration over five years, looking at their costs with the hyperscaler, um, what their actual cost of migration is going to be, because there is a real dollar figure that you can apply to that.
00:15:46.879 --> 00:15:59.519
And then working out like, is this even going to save me money on my infrastructure or is it or is it going to free up enough resources to allow me to go make more money to make this migration valuable to the business in the long term?
00:15:59.840 --> 00:16:08.799
But yeah, I always come back to there are is going to be short-term pain, but generally it makes sense in the long term.
00:16:09.039 --> 00:16:17.679
And anytime where we take a customer through that and we go, let's fill in this calculator together and work out if this is valuable.
00:16:17.919 --> 00:16:22.559
Anytime it comes back into negative, we go, cool, then you probably shouldn't do this, by the way.
00:16:22.639 --> 00:16:24.720
And thanks for coming and talking to us.
00:16:24.879 --> 00:16:28.240
But you know, this isn't the right time for your business and this doesn't make sense.
00:16:28.399 --> 00:16:33.120
But you know, let's keep talking, and maybe maybe it does in a in a year or two years down the line.
00:16:33.600 --> 00:16:38.159
Yeah, that that's great to be to have that honesty there and be like, this is just isn't the right time.
00:16:38.240 --> 00:16:41.039
Maybe save this for a couple years from now, um, like you're saying.
00:16:41.120 --> 00:16:42.720
Yeah, because there's so many moving pieces.
00:16:42.799 --> 00:16:47.759
It can be expensive, um, it just uh a lot of headache-inducing moments.
00:16:48.000 --> 00:16:52.399
I imagine you've you've obviously helped a number of clients make the pivot.
00:16:52.559 --> 00:16:54.799
Maybe you could share some real world experiences.
00:16:54.879 --> 00:17:06.640
I mean, I don't I don't want to put you too much on the spot here, but do you have maybe an example of how the right infrastructure setup helped a customer solve maybe a performance problem, a reliability problem, or a scaling challenge?
00:17:07.039 --> 00:17:08.799
We're doing this all the time.
00:17:08.960 --> 00:17:17.839
And uh a few years ago, I worked on a on a very large project for an ad tech platform, and they were bleeding in a few ways.
00:17:18.079 --> 00:17:34.640
They were across a couple of the different hyperscaler platforms, and it really just the cost and the level of support that they were getting and the complexity in their infrastructure, it really stopped them from being able to continue to grow in the way that they in the speed that they wanted to be able to grow.
00:17:34.880 --> 00:17:36.559
So they had to make a change.
00:17:36.880 --> 00:17:45.759
We came in and we said to them, look, there are parts of your infrastructure stack that don't make sense to be on a hyperscaler.
00:17:45.920 --> 00:18:06.960
But by the way, there are certainly parts of your infrastructure stack that make complete and utter sense to remain where they are and let's work on a solution where we can move you over to service.com for some aspects, and that was a Kubernetes-based solution where we did a multi-site solution for them so they have an amount of disaster recovery built in.
00:18:07.200 --> 00:18:28.480
But then let's also uh make sure we have some private connections to your GCP account where some of your storage and databases can stay because that's a technology platform that you've got some vendor lock-in, and it doesn't make sense for you to move it right now because it's just not the part of your stack that's crippling you.
00:18:28.640 --> 00:18:43.200
And we, over the course of about six months, we managed that migration with them, and they've been you know back to growth and got their costs under control, and you know, performances the same, if not better, from what they were doing previously.
00:18:43.440 --> 00:18:49.680
And I think what was really refreshing for them is I think everybody else that they were speaking to at the time was going, bring everything.
00:18:49.759 --> 00:18:52.079
We want everything, we want the whole pie, right?
00:18:52.240 --> 00:18:57.519
And we went to them and we went, hey, like we we only want the bit of the pie that makes sense for your business.
00:18:57.759 --> 00:19:11.200
And I I do say something all the time to customers, which is look, I I tell you to do that quite selfishly, because if you make the right business decisions for you, you're probably gonna grow as a business and you're gonna need more stuff from me.
00:19:11.359 --> 00:19:18.960
So I I want to help you be successful quite selfishly, and I think that's quite an honest reflection that catches most people off guard a little bit.
00:19:19.279 --> 00:19:20.799
Everyone can appreciate the honesty.
00:19:20.960 --> 00:19:28.400
I was gonna ask, yeah, is there enough, has there been enough kind of time and data collected to follow up and see how they're doing post-pivot, post-shift?
00:19:28.640 --> 00:19:31.359
It sounds like the long-term decision is paying off.
00:19:31.680 --> 00:19:34.480
Yeah, I mean, they just renewed and added capacity with us.
00:19:34.559 --> 00:19:38.079
So you're very happy and very close with their CEO now.
00:19:38.160 --> 00:19:39.839
So uh we're we're good friends.
00:19:40.160 --> 00:19:44.799
So I think a lot of the tension as I see it is companies sort of want a few things at once.
00:19:44.880 --> 00:19:48.240
They want more performance, they want more control, they want the flexibility.
00:19:48.400 --> 00:19:53.599
And the standard public cloud model keeps asking them sort of to trade one for the other, right?
00:19:53.759 --> 00:19:59.519
And then when you factor in AI, AI is like throwing gasoline on all of it with all the massive compute demands.
00:19:59.680 --> 00:20:11.359
So I'm curious, like looking ahead, how do you see infrastructure evolving as companies need more of these things, more of the performance, the control, the flexibility than some of the standard cloud models and what they provide?
00:20:11.759 --> 00:20:22.880
We're already seeing this migration from 15 years ago, everyone was doing co-location or had on-prem capacity, very capex heavy.
00:20:23.039 --> 00:20:33.279
And over the last 15 years, we've seen this massive shift to the other end of the spectrum of opex everything, put it up at everything in the cloud, lose that level of control.
00:20:33.519 --> 00:20:37.839
But you know, we were supposed to gain all this simplicity and all this scalability.
00:20:38.079 --> 00:20:48.799
And I think people have realized that there you probably need a kind of uh a mixture of these different ways of doing things.
00:20:48.960 --> 00:20:53.279
And there is a middle ground, so you don't have to go all the way from colo to hyperscale.
00:20:53.440 --> 00:21:05.039
There are these middle options where you get more of that control, but you're still in an opex model, you get more of that performance, but you're still in an opex model with bare metal clouds like service.com.
00:21:05.200 --> 00:21:08.160
The hyperscale isn't going away, and neither's co-location, right?
00:21:08.319 --> 00:21:17.119
Co-location is seeing one of the biggest spikes in demand that it has, you know, since AWS launched, you know, almost 20 years ago now.
00:21:17.279 --> 00:21:19.680
And that's all down to AI.
00:21:20.400 --> 00:21:43.920
So AI is really changing the game for those particular workloads, and we've seen a bit of a return to the olden days where people are just going back and doing infrastructure again and servers, and people want to buy by the whole server, they don't want to buy by a VM because the virtualization of GPUs is not something that's effective.
00:21:44.079 --> 00:21:53.920
People want that raw access to the raw GPU power, and they don't want to be spending on anything that diminishes that access to that power because it's quite expensive.
00:21:54.160 --> 00:22:01.039
So we're going through a real flux in time at the moment, and I think there's going to be a real mixture.
00:22:01.119 --> 00:22:06.240
I think in traditional workloads, and when I say traditional workloads, I mean non-GPU workloads.
00:22:06.480 --> 00:22:13.599
I think we're still going through this awakening that, okay, we can't just be on AWS, GCP, Microsoft Azure.
00:22:14.160 --> 00:22:16.079
Like we need to have a mixture.
00:22:16.240 --> 00:22:35.759
And then I think in AI right now, it's who can get the capacity on fastest wins, and there's going to be some winners and losers in that space, and there's probably going to be some new companies springing up that maybe don't have that maturity of knowing how to do this long term.
00:22:36.000 --> 00:22:56.960
So I see this, particularly the AI business, is we're going to have a lot of new startups, these neo clouds coming out, and then there's probably going to be a reconsolidation of that market over the next five years as the true winners and the players that have the true maturity on how to do this and do it profitably and do it for the long term are probably going to win out.
00:22:57.440 --> 00:22:57.680
Yeah.
00:22:57.759 --> 00:22:58.000
Yeah.
00:22:58.079 --> 00:23:01.039
Once the dust settles, there's going to be some there has to be consolidation.
00:23:01.119 --> 00:23:05.119
I mean, it's just too wide open right now, I feel like, with what's been going on.
00:23:05.359 --> 00:23:06.880
But a lot to think about.
00:23:06.960 --> 00:23:08.880
Um, I appreciate everything you shared with us.
00:23:08.960 --> 00:23:14.240
Um, the through line of this conversation I'm thinking of is just the question isn't like no longer the cloud or not cloud.
00:23:14.319 --> 00:23:16.000
It's which workload belongs where.
00:23:16.079 --> 00:23:23.920
You want the flexibility, and then you want a partner ultimately who's actually going to help you sort of answer that question and work with you and give you the honest kind of answers and feedback.
00:23:24.079 --> 00:23:27.599
And so I think that's a great way to wrap the conversation up.
00:23:27.680 --> 00:23:32.079
And for those listening who want to learn more about the company, where should they go?
00:23:32.559 --> 00:23:34.880
Service.com, it's it's in the name.
00:23:34.960 --> 00:23:36.000
It's nice and simple.
00:23:36.160 --> 00:23:37.440
You can always contact me.
00:23:37.519 --> 00:23:38.960
I'm I'm on LinkedIn as well.
00:23:39.200 --> 00:23:50.960
But at servers.com, all the information, you can contact one of our consultants on there, and we'd love to jump on a call and get to know your problems and your challenges and work on a solution together.
00:23:51.279 --> 00:23:51.759
Perfect.
00:23:52.000 --> 00:23:54.240
Servers.com, that's easy to remember.
00:23:54.480 --> 00:23:57.200
Isaac Douglas, go follow him over on LinkedIn.
00:23:57.440 --> 00:24:01.200
Isaac, thank you really uh so much for everything you share with us.
00:24:01.440 --> 00:24:02.160
Thank you.
00:24:02.480 --> 00:24:05.039
Thank you for listening to the SourceForge podcast.
00:24:05.119 --> 00:24:06.720
I am your host, Bo Hamilton.
00:24:06.799 --> 00:24:11.359
Make sure to subscribe to stay up to date with all of our upcoming B2B software related podcasts.
00:24:11.519 --> 00:24:13.440
I will talk to you in the next one.
00:00:05.040 --> 00:00:08.000
Hello everyone and welcome back to the SourceForge podcast.
00:00:08.080 --> 00:00:09.519
I'm your host, Bo Hamilton.
00:00:09.599 --> 00:00:18.320
Now, today's episode, we're getting into something that I think a lot of engineering and IT leaders are quietly wrestling with right now, and that's where should your infrastructure actually live?
00:00:18.480 --> 00:00:25.039
Uh for a decade, the default answer was the public cloud, obviously, but that default is getting challenged.
00:00:25.280 --> 00:00:35.119
Barclay's CIO survey found that 86% of CIOs planned to move at least some workloads off of the public cloud, which is the highest that number has ever been.
00:00:35.280 --> 00:00:40.479
So something's obviously shifting in how companies think about performance, cost, and of course control.
00:00:41.119 --> 00:00:44.880
My guest today is uh he he has a front row seat to that shift.
00:00:45.039 --> 00:00:57.359
Isaac Douglas is the general manager of servers.com by Nexus, a global infrastructure platform that's built its reputation on bare metal and recently joined forces with the Nexus and Liquid Web family.
00:00:57.520 --> 00:00:59.280
So I'm really excited to have Isaac here.
00:00:59.439 --> 00:01:08.480
Isaac has spent well over a decade in the hosting industry, several of those years in video game hosting, which is basically the ultimate stress test for infrastructure.
00:01:08.719 --> 00:01:16.959
You think about the hundreds of thousands of players, you know, hammering your servers at the exact same second, you know, all of them sort of allergic to lag.
00:01:17.359 --> 00:01:20.719
That's that's definitely a one way to test the limits of one's infrastructure.
00:01:20.959 --> 00:01:22.640
So um we're gonna get into that.
00:01:22.719 --> 00:01:31.120
We're gonna dig into where the public cloud model breaks down, what the alternative actually looks like, and how companies are making the move without lighting things on fire.
00:01:31.280 --> 00:01:34.480
So with that said, um, Isaac, welcome to the podcast.
00:01:34.640 --> 00:01:35.840
Glad you could join us.
00:01:36.239 --> 00:01:38.079
Yeah, thanks for having me.
00:01:38.560 --> 00:01:41.120
So um I want to sort of set the stage here.
00:01:41.200 --> 00:01:47.760
Um, there are a lot of names in the hosting world, and servers.com by Nexus is actually a sort of a newer combination.
00:01:47.920 --> 00:01:53.760
Servers.com has been around since 2014 and it recently became part of the Nexus family alongside Liquid Web.
00:01:53.840 --> 00:02:00.239
Uh, for listeners, hearing about servers.com by Nexus for the first time, how would you describe what the company does?
00:02:00.719 --> 00:02:04.400
Yeah, I think what we're best known for is being bare metal.
00:02:04.560 --> 00:02:07.760
So uh a true infrastructure as a service platform.
00:02:08.000 --> 00:02:13.599
But I think we were probably one of the ones that led the charges, a bare metal cloud, right?
00:02:13.919 --> 00:02:24.639
So this idea that back in the day bare metal was slow and long contracts and slow to provision and very manual.
00:02:25.039 --> 00:02:29.520
And we kind of came along and went, well, bare metal doesn't need to be that way.
00:02:29.759 --> 00:02:35.520
Hyperscale cloud and virtualization doesn't need to be the only answer to automation and scalability.
00:02:35.759 --> 00:02:47.520
Like, let's create a bare metal cloud platform where you can get all the benefits of bare metal, so cost, control, security, but let's make it scalable.
00:02:47.680 --> 00:02:55.199
So give our customers that ability to kind of scale up and down as they need, but get all those benefits of bare metal as well.
00:02:55.520 --> 00:02:56.000
Gotcha.
00:02:56.080 --> 00:02:58.719
Okay, so the scalability is a really big component there.
00:02:58.960 --> 00:03:06.000
Now, as I alluded to sort of in the introduction, I know a lot of companies, you know, they didn't just sit down and carefully sort of choose their infrastructure.
00:03:06.080 --> 00:03:10.560
They just sort of defaulted maybe to the public cloud because that was kind of the standard practice.
00:03:10.639 --> 00:03:12.560
It's maybe the path of least resistance.
00:03:12.719 --> 00:03:16.000
Maybe you could talk about where that model start to break down.
00:03:16.479 --> 00:03:20.879
Yeah, I think, you know, in the old days you would say no one got fired for buying IBM, right?
00:03:21.039 --> 00:03:23.919
Uh, I think everyone in tech has heard that saying.
00:03:24.080 --> 00:03:29.039
And I think for the last 10 years, you could probably say no one got fired for buying AWS.
00:03:29.120 --> 00:03:30.639
It's become the safe bet.
00:03:30.879 --> 00:03:42.960
And I think where it's really broken down is the promise of hyperscale was simplicity and cost savings and lower total cost of ownership.
00:03:43.120 --> 00:03:48.639
And as those platforms have grown and grown, the complexity's massively gone through the roof.
00:03:48.719 --> 00:03:55.840
You've got over 200 different services that you need to navigate how to buy, generally by yourself.
00:03:56.479 --> 00:04:08.560
Support is probably not as good as it could be in terms of they're just doing it at such a scale that it's hard to give everyone a white glove experience.
00:04:08.960 --> 00:04:12.159
And the costs, you know, have crept up over the years.
00:04:12.400 --> 00:04:19.600
And I think what our customer bases that are coming to us and saying is this isn't as simple as we were sold.
00:04:19.759 --> 00:04:30.560
This is way more complex, it's way more costly, but it you know, it does scale, and we will we want to still be able to have that scalability, but we want to also gain back that control.
00:04:30.879 --> 00:04:35.040
So that's where it's really breaking down for a lot of our customers that are coming to us.
00:04:35.439 --> 00:04:46.000
Yeah, you mentioned AWS, and it's like I, you know, you're not saying like burn down your AWS account, you know, um, but thinking about like stop treating one tool as sort of the answer to every workload.
00:04:46.240 --> 00:04:49.920
I think there's a lot of things to consider, of course, but yeah, it's it's neat to hear your thoughts.
00:04:50.000 --> 00:04:57.120
And I actually just want to plug your, you have a blog post uh you posted a while back uh titled Why the Hyperscale Cloud Bubble is Bursting.
00:04:57.279 --> 00:05:06.079
So for listeners, viewers um who want to learn more and hear more of your thoughts and um in-depth opinions on this topic, that's a good place to go.
00:05:06.319 --> 00:05:20.399
But maybe you could walk us through some of the problems that arise for teams running, like let's say, high traffic apps, gaming platforms, media servers, you think uh fintech systems, and of course AI, uh AI workloads, what infrastructure problems tend to show up first?
00:05:21.360 --> 00:05:34.800
For those kind of applications where they're you know high performance cloud applications, we tend to find that customers are hitting the edges of what's capable within their given platform, right?
00:05:35.040 --> 00:05:43.360
And so very much what you just said, which was one company, one platform shouldn't really be the answer for anyone.
00:05:43.600 --> 00:05:50.879
And I talk about that quite a lot in that actually when people come to us, I don't think they should be all on service.com.
00:05:51.040 --> 00:05:59.920
I think they should probably have service.com and another bare metal provider and probably multiple hyperscalers within their infrastructure mix.
00:06:00.160 --> 00:06:23.199
So it's when you get to a hard edge of any individual platform, or you find a part of your application stack that doesn't quite fit that particular platform or the way you want to solve a problem, you need to have that supplier mix to be able to go, okay, I'm gonna go solve this particular problem different, but it all needs to work together.
00:06:23.360 --> 00:06:50.399
And I think that's one of the things that kind of a hyperscale bubble is the same that blog post is it's like people have gone all in on one particular thing, and I think people are becoming wise now of actually what we need to do is we need to have a multi multi-vendor approach, we need to have different solutions to different kinds of problems, and one way of doing things isn't always the best answer.
00:06:50.639 --> 00:06:56.800
Now, when it comes to AI, that's what everyone wants to talk about right now, right?
00:06:57.040 --> 00:06:59.279
And it's a very different problem.
00:06:59.839 --> 00:07:03.759
Everyone is scrambling for capacity right now.
00:07:04.079 --> 00:07:10.480
Backlogs in these hyperscalers as well as the neo clouds are becoming really, really high.
00:07:10.720 --> 00:07:19.759
And really, it's about finding a vendor that can hit not just your technical requirements, but also hit your timelines.
00:07:20.399 --> 00:07:29.120
And the hyperscalers and the very large neo clouds, they're gonna go and chase those huge deals because you know that's what makes headlines.
00:07:29.360 --> 00:07:39.199
And I think there's other providers out there, including ourselves, where we still have quite a lot of scale available to us, but maybe we're not quite chasing those bigger deals.
00:07:39.439 --> 00:07:52.399
So if you are not an open AI or an anthropic and you're going and doing multi-gigawatt deals with data centers, you know, looking at further afield into different suppliers is probably going to be really beneficial.
00:07:52.800 --> 00:07:59.120
As we talked about the problems, I want to talk about some of the answers to them because I know servers.com isn't just a pile of their metal.
00:07:59.199 --> 00:08:00.560
There's there's like a whole stack around it.
00:08:00.639 --> 00:08:05.680
It offers cloud servers, storage, firewalls, load balancing, private networking.
00:08:05.759 --> 00:08:06.720
There's a bunch of features.
00:08:06.959 --> 00:08:10.079
How did those all those pieces actually come together for customers?
00:08:10.160 --> 00:08:13.839
Like what does a typical architecture stack look like?
00:08:14.399 --> 00:08:18.720
Yeah, so we we definitely did start out as just bare metal.
00:08:19.040 --> 00:08:27.839
And as we've we've grown as a business and as we've matured as a company, what we've really tried to focus on is two things.
00:08:28.160 --> 00:08:34.879
One is to listen to our customers, take feedback from them and build what they want.
00:08:35.279 --> 00:08:48.720
And then the other one is to try and close the gap with the hyperscalers to make it as easy for people to get the benefits of scalability and the hyperscalers with all the benefits of bare metal cloud.
00:08:49.039 --> 00:08:55.120
So it really comes down to your unique use case with us.
00:08:55.440 --> 00:09:04.720
We're not trying to build solutions where we're like, you come to us with a problem, and we're like, hey, this is the solution that we're going to sell you because we sell it to everyone.
00:09:04.879 --> 00:09:07.759
We're trying to tailor that for each customer.
00:09:08.000 --> 00:09:10.639
But typically a customer can come to us.
00:09:10.799 --> 00:09:13.039
It all starts with a server, right?
00:09:13.200 --> 00:09:25.440
It all starts with a server and how we make that enterprise grade, how we keep that server online in enterprise grade data centers and build an enterprise grade networking stack.
00:09:25.679 --> 00:09:38.399
And then it's about working with our team of experts on designing a solution around networking elements, say load balances, firewalls, storage.
00:09:38.799 --> 00:09:41.120
Do you need some cloud servers with that?
00:09:41.279 --> 00:09:45.360
Do you need some scalable bare metal along with your fixed bare metal?
00:09:45.600 --> 00:09:53.120
And they'll bring in those expertise of our product and help tailor a solution to each client's need.
00:09:53.279 --> 00:09:56.799
So there isn't really a typical stack for us.
00:09:56.960 --> 00:09:59.840
You know, there's always servers at the end of the day.
00:10:00.080 --> 00:10:16.639
There's always a data center at the end of the day, but really our where we've found value for our clients is being real consultants and listening to their problems and then coming up with a solution rather than having a solution and trying to, you know, only sell that cookie colour approach.
00:10:17.039 --> 00:10:27.440
There is one area that I do want to zoom in on because it sort of sits at that intersection of everything we sort of talked about, the flexibility people love around cloud and the performance of dedicated hardware.
00:10:27.519 --> 00:10:33.440
And that's Kubernetes, specifically manage Kubernetes on bare metal, which is offered by servers.com by Nexus.
00:10:33.600 --> 00:10:43.120
And for listeners who might not be super familiar with Kubernetes, basically it's like it's like the platform that automates the deployment, scaling and management of containerized applications.
00:10:43.519 --> 00:10:45.919
Maybe you can expand upon that uh for listeners.
00:10:46.080 --> 00:10:56.000
But I'm curious, like, how does manage Kubernetes on bare metal help teams get the benefits of the platform without taking on all of the operational overhead?
00:10:56.480 --> 00:10:59.759
Yeah, actually, I think you did a really good job of explaining it.
00:10:59.919 --> 00:11:04.559
And, you know, I was I was working with some of our new team members last week.
00:11:04.879 --> 00:11:14.960
And yeah, I think as an industry, we've gone from bare metal to virtualization was the savior of utilization across bare metal.
00:11:15.200 --> 00:11:27.120
And I think Kubernetes, whilst different to obviously different to virtualization, really takes that management of infrastructure and obfuscates it to an application level.
00:11:27.440 --> 00:11:41.120
And we really wanted to bring a product to market that allowed our customers to think of infrastructure as more like how do we scale their applications rather than how do we scale this infrastructure.
00:11:41.440 --> 00:11:51.279
And so we brought to we brought to market a product, you know, we call it managed Kubernetes, where we're taking over that overhead of managing the control plane.
00:11:51.600 --> 00:12:00.559
And the customer is just buying and using compute within Kubernetes cluster or multiple clusters with us.
00:12:00.879 --> 00:12:23.200
And what we're working towards in the future is with our scalable bare metal product, which will allow customers to scale up new bare metal instances in under 10 minutes and pay by the hour, is we're gonna have Kubernetes running across that and we'll be able to enable auto-scaling just like you would on a hyperscaler with their Kubernetes products.
00:12:23.440 --> 00:12:27.279
We charge no overhead for the Kubernetes managed Kubernetes service.
00:12:27.360 --> 00:12:29.200
It's just the cost of the compute.
00:12:29.440 --> 00:12:38.799
And I think that what that's really gonna do for our customers is allow them to seamlessly migrate workloads across hyperscalers and bare metal as if it's exactly the same thing.
00:12:39.120 --> 00:12:42.399
And that's why we really wanted to be one of the first to bring that to market.
00:12:42.960 --> 00:12:43.759
Wow, very cool.
00:12:43.919 --> 00:12:54.559
Yeah, so it sounds like Kubernetes was supposed to sort of abstract away from infrastructure, but instead it's sort of a lot of teams sort of ended up managing more infrastructure than before because of it.
00:12:54.960 --> 00:13:07.039
Yeah, I think uh, you know, there's like with any new technology, you've got people in your team that are specialists in one thing and a new technology comes out, and it doesn't mean they're instantly gonna be specialists in the next thing.
00:13:07.279 --> 00:13:21.120
And I think a lot of teams around the world had experience in system administrator or they were experts in VMware or other virtualization technologies, and that doesn't instantly mean anyone's gonna be an expert in Kubernetes.
00:13:21.279 --> 00:13:30.080
So we wanted to build that tooling and expertise in-house, and we'll take care of that complexity of running Kubernetes on bare metal.
00:13:30.159 --> 00:13:36.639
And for our customers, they just get a buy computer and they get to worry about their applications and how that's gonna scale.
00:13:36.799 --> 00:13:41.840
And again, our consultants will work with them and uh work on finding the right solutions.
00:13:42.080 --> 00:13:51.279
But um, we wanted to take a lot of that headache of working some of this stuff out away from the customers and uh do that in a way that made sense uh commercially for them.
00:13:51.759 --> 00:13:58.480
So let's say uh, you know, someone listening right now is is is nodding along, they're looking at their latency, and that's not a pretty picture.
00:13:58.639 --> 00:14:01.279
But all this sounds great in theory, everything you've mentioned up to this point.
00:14:01.519 --> 00:14:05.039
There's a reason people stay put with, let's say, like the public cloud.
00:14:05.120 --> 00:14:07.759
The moving infrastructure is a daunting process.
00:14:07.840 --> 00:14:10.960
It's it's sort of like the open heart surgery of a business.
00:14:11.279 --> 00:14:17.440
What are companies usually worried about when they're moving infrastructure providers or redesigning their hosting environment?
00:14:17.919 --> 00:14:26.159
Particularly for our customer base, and we're dealing with businesses that are the vast majority of their businesses online.
00:14:26.320 --> 00:14:29.039
They were maybe born online as a as a business, right?
00:14:29.120 --> 00:14:36.639
They never had bricks and mortar presence, you know, they were born online companies, and it's the lifeblood of their business.
00:14:36.720 --> 00:14:46.879
And if they make the wrong decision in their infrastructure, you know, it can cost a lot of money to people's lives and businesses and profits and staying alive as a business.
00:14:47.200 --> 00:14:55.200
So it does take a lot of trust to move your infrastructure, and generally you need to be in some kind of pain.
00:14:55.360 --> 00:15:08.480
And whether that's you're having outages or the support's terrible or your prices are scaling at such a rate that you can't actually take on more customers because it's becoming unprofitable to do that.
00:15:08.559 --> 00:15:10.639
And we've had several instances of that.
00:15:10.879 --> 00:15:13.440
I think you've got to be prepared to go through a process.
00:15:13.600 --> 00:15:16.960
I've written a blog on this as well, that it's going to be painful.
00:15:17.200 --> 00:15:23.679
And anybody thinking about going through it needs to go in with their eyes wide open, that there is going to be some pain.
00:15:23.919 --> 00:15:46.720
We actually have a calculator which we built internally for internal use of helping people understand what their cost of migration is going to be, and then calculating what their ROI is going to be of that migration over five years, looking at their costs with the hyperscaler, um, what their actual cost of migration is going to be, because there is a real dollar figure that you can apply to that.
00:15:46.879 --> 00:15:59.519
And then working out like, is this even going to save me money on my infrastructure or is it or is it going to free up enough resources to allow me to go make more money to make this migration valuable to the business in the long term?
00:15:59.840 --> 00:16:08.799
But yeah, I always come back to there are is going to be short-term pain, but generally it makes sense in the long term.
00:16:09.039 --> 00:16:17.679
And anytime where we take a customer through that and we go, let's fill in this calculator together and work out if this is valuable.
00:16:17.919 --> 00:16:22.559
Anytime it comes back into negative, we go, cool, then you probably shouldn't do this, by the way.
00:16:22.639 --> 00:16:24.720
And thanks for coming and talking to us.
00:16:24.879 --> 00:16:28.240
But you know, this isn't the right time for your business and this doesn't make sense.
00:16:28.399 --> 00:16:33.120
But you know, let's keep talking, and maybe maybe it does in a in a year or two years down the line.
00:16:33.600 --> 00:16:38.159
Yeah, that that's great to be to have that honesty there and be like, this is just isn't the right time.
00:16:38.240 --> 00:16:41.039
Maybe save this for a couple years from now, um, like you're saying.
00:16:41.120 --> 00:16:42.720
Yeah, because there's so many moving pieces.
00:16:42.799 --> 00:16:47.759
It can be expensive, um, it just uh a lot of headache-inducing moments.
00:16:48.000 --> 00:16:52.399
I imagine you've you've obviously helped a number of clients make the pivot.
00:16:52.559 --> 00:16:54.799
Maybe you could share some real world experiences.
00:16:54.879 --> 00:17:06.640
I mean, I don't I don't want to put you too much on the spot here, but do you have maybe an example of how the right infrastructure setup helped a customer solve maybe a performance problem, a reliability problem, or a scaling challenge?
00:17:07.039 --> 00:17:08.799
We're doing this all the time.
00:17:08.960 --> 00:17:17.839
And uh a few years ago, I worked on a on a very large project for an ad tech platform, and they were bleeding in a few ways.
00:17:18.079 --> 00:17:34.640
They were across a couple of the different hyperscaler platforms, and it really just the cost and the level of support that they were getting and the complexity in their infrastructure, it really stopped them from being able to continue to grow in the way that they in the speed that they wanted to be able to grow.
00:17:34.880 --> 00:17:36.559
So they had to make a change.
00:17:36.880 --> 00:17:45.759
We came in and we said to them, look, there are parts of your infrastructure stack that don't make sense to be on a hyperscaler.
00:17:45.920 --> 00:18:06.960
But by the way, there are certainly parts of your infrastructure stack that make complete and utter sense to remain where they are and let's work on a solution where we can move you over to service.com for some aspects, and that was a Kubernetes-based solution where we did a multi-site solution for them so they have an amount of disaster recovery built in.
00:18:07.200 --> 00:18:28.480
But then let's also uh make sure we have some private connections to your GCP account where some of your storage and databases can stay because that's a technology platform that you've got some vendor lock-in, and it doesn't make sense for you to move it right now because it's just not the part of your stack that's crippling you.
00:18:28.640 --> 00:18:43.200
And we, over the course of about six months, we managed that migration with them, and they've been you know back to growth and got their costs under control, and you know, performances the same, if not better, from what they were doing previously.
00:18:43.440 --> 00:18:49.680
And I think what was really refreshing for them is I think everybody else that they were speaking to at the time was going, bring everything.
00:18:49.759 --> 00:18:52.079
We want everything, we want the whole pie, right?
00:18:52.240 --> 00:18:57.519
And we went to them and we went, hey, like we we only want the bit of the pie that makes sense for your business.
00:18:57.759 --> 00:19:11.200
And I I do say something all the time to customers, which is look, I I tell you to do that quite selfishly, because if you make the right business decisions for you, you're probably gonna grow as a business and you're gonna need more stuff from me.
00:19:11.359 --> 00:19:18.960
So I I want to help you be successful quite selfishly, and I think that's quite an honest reflection that catches most people off guard a little bit.
00:19:19.279 --> 00:19:20.799
Everyone can appreciate the honesty.
00:19:20.960 --> 00:19:28.400
I was gonna ask, yeah, is there enough, has there been enough kind of time and data collected to follow up and see how they're doing post-pivot, post-shift?
00:19:28.640 --> 00:19:31.359
It sounds like the long-term decision is paying off.
00:19:31.680 --> 00:19:34.480
Yeah, I mean, they just renewed and added capacity with us.
00:19:34.559 --> 00:19:38.079
So you're very happy and very close with their CEO now.
00:19:38.160 --> 00:19:39.839
So uh we're we're good friends.
00:19:40.160 --> 00:19:44.799
So I think a lot of the tension as I see it is companies sort of want a few things at once.
00:19:44.880 --> 00:19:48.240
They want more performance, they want more control, they want the flexibility.
00:19:48.400 --> 00:19:53.599
And the standard public cloud model keeps asking them sort of to trade one for the other, right?
00:19:53.759 --> 00:19:59.519
And then when you factor in AI, AI is like throwing gasoline on all of it with all the massive compute demands.
00:19:59.680 --> 00:20:11.359
So I'm curious, like looking ahead, how do you see infrastructure evolving as companies need more of these things, more of the performance, the control, the flexibility than some of the standard cloud models and what they provide?
00:20:11.759 --> 00:20:22.880
We're already seeing this migration from 15 years ago, everyone was doing co-location or had on-prem capacity, very capex heavy.
00:20:23.039 --> 00:20:33.279
And over the last 15 years, we've seen this massive shift to the other end of the spectrum of opex everything, put it up at everything in the cloud, lose that level of control.
00:20:33.519 --> 00:20:37.839
But you know, we were supposed to gain all this simplicity and all this scalability.
00:20:38.079 --> 00:20:48.799
And I think people have realized that there you probably need a kind of uh a mixture of these different ways of doing things.
00:20:48.960 --> 00:20:53.279
And there is a middle ground, so you don't have to go all the way from colo to hyperscale.
00:20:53.440 --> 00:21:05.039
There are these middle options where you get more of that control, but you're still in an opex model, you get more of that performance, but you're still in an opex model with bare metal clouds like service.com.
00:21:05.200 --> 00:21:08.160
The hyperscale isn't going away, and neither's co-location, right?
00:21:08.319 --> 00:21:17.119
Co-location is seeing one of the biggest spikes in demand that it has, you know, since AWS launched, you know, almost 20 years ago now.
00:21:17.279 --> 00:21:19.680
And that's all down to AI.
00:21:20.400 --> 00:21:43.920
So AI is really changing the game for those particular workloads, and we've seen a bit of a return to the olden days where people are just going back and doing infrastructure again and servers, and people want to buy by the whole server, they don't want to buy by a VM because the virtualization of GPUs is not something that's effective.
00:21:44.079 --> 00:21:53.920
People want that raw access to the raw GPU power, and they don't want to be spending on anything that diminishes that access to that power because it's quite expensive.
00:21:54.160 --> 00:22:01.039
So we're going through a real flux in time at the moment, and I think there's going to be a real mixture.
00:22:01.119 --> 00:22:06.240
I think in traditional workloads, and when I say traditional workloads, I mean non-GPU workloads.
00:22:06.480 --> 00:22:13.599
I think we're still going through this awakening that, okay, we can't just be on AWS, GCP, Microsoft Azure.
00:22:14.160 --> 00:22:16.079
Like we need to have a mixture.
00:22:16.240 --> 00:22:35.759
And then I think in AI right now, it's who can get the capacity on fastest wins, and there's going to be some winners and losers in that space, and there's probably going to be some new companies springing up that maybe don't have that maturity of knowing how to do this long term.
00:22:36.000 --> 00:22:56.960
So I see this, particularly the AI business, is we're going to have a lot of new startups, these neo clouds coming out, and then there's probably going to be a reconsolidation of that market over the next five years as the true winners and the players that have the true maturity on how to do this and do it profitably and do it for the long term are probably going to win out.
00:22:57.440 --> 00:22:57.680
Yeah.
00:22:57.759 --> 00:22:58.000
Yeah.
00:22:58.079 --> 00:23:01.039
Once the dust settles, there's going to be some there has to be consolidation.
00:23:01.119 --> 00:23:05.119
I mean, it's just too wide open right now, I feel like, with what's been going on.
00:23:05.359 --> 00:23:06.880
But a lot to think about.
00:23:06.960 --> 00:23:08.880
Um, I appreciate everything you shared with us.
00:23:08.960 --> 00:23:14.240
Um, the through line of this conversation I'm thinking of is just the question isn't like no longer the cloud or not cloud.
00:23:14.319 --> 00:23:16.000
It's which workload belongs where.
00:23:16.079 --> 00:23:23.920
You want the flexibility, and then you want a partner ultimately who's actually going to help you sort of answer that question and work with you and give you the honest kind of answers and feedback.
00:23:24.079 --> 00:23:27.599
And so I think that's a great way to wrap the conversation up.
00:23:27.680 --> 00:23:32.079
And for those listening who want to learn more about the company, where should they go?
00:23:32.559 --> 00:23:34.880
Service.com, it's it's in the name.
00:23:34.960 --> 00:23:36.000
It's nice and simple.
00:23:36.160 --> 00:23:37.440
You can always contact me.
00:23:37.519 --> 00:23:38.960
I'm I'm on LinkedIn as well.
00:23:39.200 --> 00:23:50.960
But at servers.com, all the information, you can contact one of our consultants on there, and we'd love to jump on a call and get to know your problems and your challenges and work on a solution together.
00:23:51.279 --> 00:23:51.759
Perfect.
00:23:52.000 --> 00:23:54.240
Servers.com, that's easy to remember.
00:23:54.480 --> 00:23:57.200
Isaac Douglas, go follow him over on LinkedIn.
00:23:57.440 --> 00:24:01.200
Isaac, thank you really uh so much for everything you share with us.
00:24:01.440 --> 00:24:02.160
Thank you.
00:24:02.480 --> 00:24:05.039
Thank you for listening to the SourceForge podcast.
00:24:05.119 --> 00:24:06.720
I am your host, Bo Hamilton.
00:24:06.799 --> 00:24:11.359
Make sure to subscribe to stay up to date with all of our upcoming B2B software related podcasts.
00:24:11.519 --> 00:24:13.440
I will talk to you in the next one.
