Welcome to the Fasthosts ProActive Podcast: Spill the IT. Each episode, we'll sit down with some of the amazing ProActive team and chat through their experiences of the ups and downs of IT infrastructure management in small businesses. There's always plenty to chat about.
Our team drill down into the invisible costs your TCO should but often doesn’t include and what the impact of those really is. Vendor lock-in exposed!
Listen on your favourite platform!
Want to listen on your go-to platform? We're on those too...
Welcome to the Fasthosts ProActive podcast, Spill the IT. Each episode we'll sit down with some of the amazing ProActive team and chat through their experiences of the ups and downs of IT infrastructure management in small businesses. There's always plenty to chat about.
Hi, everyone. And here we are again for episode four of the Fasthosts ProActive podcast. My name's Graham and I'm going to be your host for today. And with me I have Dan, who is the Senior Service Owner at Fasthosts ProActive. And I've also got Gary along as well, who's the Solutions Consultant.
But they're going to do a far better job at introducing themselves than I will. So Dan, over to you. Why don't you tell people a little bit about who you are?
Good morning, I'm Dan. I'm the Senior Service Owner here at Fasthosts ProActive. I've been in the IT industry for probably over about 20 years now. And here I'm responsible for making sure that the services that we offer to our clients meet their needs.
Hi, I'm Gary. I've also been in IT for far longer than I would admit. I'm the Solutions Consultant, so I'm the person that designs our infrastructure solutions and managed services to solve our client's business problems.
Fantastic. That's great. Thanks for the intro. Well, I hate to break it to you guys, but we have a fan. So after our last podcast, we're now starting to get some people sending in questions, things that they just would like to get a little bit more enhancement on.
And this is from Susie in Leicester. And Susie says, "Love, love, loved the first podcast." That's a lot loves in there, isn't it? "From the team at Fasthosts, and found by chance on your..." And she found it on your website. "Hope you don't mind, but I want to ask a question," she says. "Currently we have our own server room that we keep all our applications and transactions on. It works well."
And supported by her internal team. "But when listening to the podcasts from last time, it seems a no-brainer to consider dumping all my servers and putting everything in the cloud. Is this really as easy as you said?" Dan, should she be worried about costs that are out of her control?
I think the first thing I'd jump in with is don't worry. This is a process that has been done many times and certainly, here at Fasthosts ProActive, we're very experienced in doing this. So the whole point of having that managed service provider is to take the worry away. So first step is don't worry.
Is it really as simple?
Well, no two infrastructures and no two solutions are the same. Once you strip back the layers of the servers and the interconnectivity and everything that needs to be monitored and run, the really important part of that whole process is the migration and onboarding. So I would say with the processes, with the experience that we've got in terms of moving solutions to the cloud, we can easily handle, I'm sure, a whole bunch of different scenarios.
Fantastic. So Susie shouldn't really be worrying too much.
No, totally. I think for me, whenever I'm designing a solution, it's always around distilling what it is that needs to be achieved. We like to complicate things in IT, and in a lot of cases, without any good real reason. So for me, it's around what are the key functions that a client needs to achieve? And once you've distilled a piece of infrastructure down to those functions, the actual migration can be a lot more simple than people might imagine at first glance.
So getting your heads together early on just understanding what's got to be done.
Mapping it out and that makes it a whole lot easier. Yeah?
Good understanding, good planning. Yeah, fantastic. Well, seeing that Susie is worried about costs, we thought seeing that we have a fan at least, why don't we focus the next podcast on total cost of ownership?
And so what they got to be worried about? So for SMBs, where are the invisible costs? So the costs that you don't necessarily see. And then where are the hard, visible costs when it comes to managing their IT infrastructure on site?
TCOs I think are a massively overloaded, overused term in the industry. But for me, it kind of breaks down into five cost groups, for lack of a better term. So upfront costs, very visible, very understood. Perhaps it's the servers, it's the infrastructure, it's the things you can kick.
Then the slightly hidden costs may start creeping in around maintenance. So you understand it's got to be done, you think you understand how much it's going to cost, but until you're actually perhaps running it day-to-day, that's when those creep out. Then I think that the more intangible ones are things like operational costs.
How much is it really costing you to have Barbara and Ben running your infrastructure? What's the cost associated with their pay, with their upskilling even through to their pension? Then it's end-of-life costs. These days, if you're a responsible infrastructure owner, you're going to be running a refresh cycle.
And associated with that, it's going to be disposal, going to be recycling things that you might not think about until much further down the line as well. So replacement costs, total lifespan costs I think are a way you start to get in the dark art of, "How much is this thing actually going to cost me?"
One of the big things for me sits around the item life cycle. So I've spent a number of years in regulated industries, both FinTech and legal IT. Anywhere where there is a need to comply with say, Cyber Essentials Plus, you cannot have a single piece of IT infrastructure or endpoint devices that is out of support.
Now, that was a relatively new introduction into the compliance aspect. And so what I found was an enormous number of companies who had focused, as Dan said, purely on that upfront cost, this is how much server X is going to cost me from point of purchase. I'm vaguely aware of what my IT people do and what the salaries that I'm paying them are.
But then all of a sudden, when you suddenly discover that the small boxes you've got sat in a data center doing networking, for example, suddenly have to all be replaced because they're no longer supported by the manufacturer. Those are things that are rarely taken into consideration when a company's capacity planning.
Because everybody thinks CPU, disk, the standard metrics. And so there's these hidden costs that can sneak in. Similarly, then when it comes to replacing these pieces of kit, they're largely silent until you have to rip them out.
And so then there's the additional cost of bringing in specialist IT resource, paying overtime to your existing resource and then the disruption to business on top of that, just the whole lifecycle management, which I think, and as Dan said, towards the latter part of that life cycle where these costs can suddenly rear their heads and bite people on the budget.
And something that becomes big with the conversation at the end of that life cycle thing, "Oh, my god. Now we've got to do something for all this before we get maybe all our new gear in." So when IT managers have their own server room, they know they've got the capacity for peak transactions. But could they be worried about the cost of peak in the cloud-based environment? Is that a valid concern?
I think it's a massive concern because I think anyone who says they understand peak, is a little bit disingenuous. They understand peak as it stands for the last time they measured peak. Businesses change, the world changes and peaks, by their very nature, can go up and down. The big trouble I think with on-premise IT equipment is that: (a) you're taking a measurement at a static point in time and those demands will evolve.
But also, once you've got that "peak" measurement, you have to resource for that all the time. It's no good having IT kit that almost hit peak. Because when you hit peak, you need it to operate. Now, that peak may only happen for two hours a week. So for the remaining hours in that week, you're paying for peak performance when you're not utilizing it.
And I think this is one of the major benefits of moving to the cloud, it's that scalability piece. And thinking about what Gary just said there in terms of the answer to the previous question, which was about lifecycle management as well, along with the scaling up for those peaks and wet finger in the air, what that peak may look like.
There's also the lag time in actually acquiring some of that as well. So when you're in the cloud, scaling up can be quite quick. When you're on-prem physical hardware, you know you can't just pop down to Comets and Currys that other providers are available, buy a server off the shelf and bring it home and away you go. There's a significant lead time there as well.
Well, we've seen that massively over the last couple of years, and I know the situation is improving. But I've seen IT projects that procured hardware, or at least made the purchase and then had to wait nine, 10 months to receive that hardware.
And I think over the last couple of years, for obvious reasons, things like networking equipment, firewalls have all been enormously difficult to get hold of unless, of course, you want to pay a lot more and divert away from your standard suppliers and go to some of the more niche suppliers.
And that right-sizing, as I would describe it in those larger IT projects, is something you do right at the beginning because you know you're going to have that infrastructure lag. So six, eight months down the line when your hardware actually turns up, is that still the peak that you were planning for?
And it's not only just hardware, is it guys? It's staff as well. It's staff resource. Because sometimes, actually, if you think, "Okay, we're going to have this peak. So when do you invest in staff?" And obviously, we're probably going to have a separate podcast on skill shortages, but it does creep in and out of the conversation. But that's a massive issue as well, I'm sure.
Yeah. And there's a huge lead time on that from both running the recruitment process and actually finding the individuals with the right skills and the right fit for your organization. But then, once you've signed contracts and you've got day one starters, there's that delay in actually them becoming autonomous, getting up to speed, which can take anywhere from six months to 12 months, depending on the organization and the role.
So there's that aspect. And without delving too much into the skill shortages, I think the other point that people don't often understand is that when you do onboard a new employee, they're actually a greater drain on resource than they are adding that resource whilst they're getting up to speed. It does take a considerable amount of effort from other people already in the business.
Good. So from a cost perspective, some people choose a mixture, don't they, of on-prem and hybrid cloud configurations? But surely in the end, this must be more expensive to manage and control. What do you see when people are configuring between the two?
I think there's always a reason why people go for a hybrid model, and I think understanding that reason allows you to answer that question in a slightly different way. So I think, for some organizations, for some solutions because of constraints they have around their business perhaps or compliance, whatever it might be, then the hybrid model is okay.
But I think you're going to have to understand that for the on-prem kit, you're going to have all those things that we've just talked about, especially the latter end of the life cycle, which won't necessarily be offset by the other part of the solution, which is in the cloud.
So as long as people are walking into that eyes wide open to say it's more expensive, and to highlight that as a bad thing, it's just perhaps an option that somebody's had to choose because of constraints.
I think those constraints, whilst in many cases are valid, I think sometimes that they can be perceived. So again, certainly from some of the industries I've worked in in the past, it was always perceived that you couldn't possibly move certain types of data off premise for compliance for security reasons.
When in actual fact, that's not always the case. And I think it just means you can't move it off premise into public cloud. But there are options like private cloud where you can maintain the location of your data and stay compliant to your clients and the regulating bodies.
So I'd like to get a sense check on the subject of migration and the topics around data sovereignty, integration and vendor lock-in. What are businesses getting worried about in today's environment, guys?
I think vendor lock-in is a huge one at the moment. A lot of the hyperscalers are pushing their platforms, they're coming to market with initially very competitive pricing. But because of all the additional things that they offer within their "ecosystem," that's where the vendor lock-in comes in.
So one of the things we're quite proud of here at Fasthosts ProActive is that our use of the open source stack. So we're not locking people in. Come to us and stay with us because of our great stability, our great performance, our great customer service. But we're not going to lock you into a product that you can't move to.
Yeah. It's not going to say you've got to stay with us forever.
Yeah. Stay with us for the right reasons. Not because we've locked you into a software ecosystem that you can't move out of. Because I think that just generates a lot of bad feeling within the industry.
Yeah, totally. It's the same with mobile devices. You're generally in the fruit-based camp or the robot-based camp. And once you have enough of your own content in one of those camps, realistically, you're not going to move. And I think it's the same, as Dan said, with the big hyperscalers. Don't get me wrong, but they offer some phenomenal features and there's some really groundbreaking technology being used.
But if you base a solution on a proprietary technology, that's where it has to remain. You're then at the mercy of capacity problems, price hikes. And I know that there's a certain amount of reassurance from going with one of the massive hyperscalers, but I think we have seen instances where even the mighty have been unable to provide at a critical time. And I think that feeling of security is sometimes misplaced.
And as Dan said, all of the solutions that we design are using open source standard technology. So we can pick up the solutions that we design, move them to other data centers, move them onto different stacks, evolve them as our own stack grows with very little disruption to the client.
So we were talking earlier with the listener question, weren't we, about getting that planning absolutely right. So I guess you spend a lot of time with the customers planning migration, reassuring them that everything's going to be okay. Is that something that happens on a regular basis?
Absolutely. We deal with all kinds of customers. So we do have a good number of people who are coming to us for a virgin platform where there is no data to migrate, and they are looking at starting a new enterprise on that infrastructure from scratch. In the vast majority of cases, however, there are existing items to port across, and it's about understanding the availability needs for those items.
When can we move the data? Is there an optimal time? Do we need to run in parallel? There are 1,001 questions that we need to get to the bottom of from the get-go to make the process nice and smooth. However, that said, all of the solutions that we design have an element of flexibility in them.
So once the migration's complete, if the client suddenly realizes, "Actually, I need a bit more of resource X," that can be slotted in with very, very little effort. Similarly, if we have over-specced things, we can tweak and tailor solutions and do so once we've got the client's data migrated across.
So taking that answer, let's talk about people that are already working with the big hyperscalers. And they're not necessarily feeling comfortable and they want to do that big migration away from there. What are the issues? What do you have to do? What should they be reassured with?
It's going to come down to what technologies they're utilizing. I've said we use open source technology almost exclusively here. It's possible to reproduce the function of pretty much the whole stack of the hyperscalers within their examples. We have S3-compatible storage, so if people are leveraging that particular product from Amazon, we have a straight alternative that we can migrate that data to with all of the same features and benefits.
Similarly, we have a managed database platform, so whether people are running databases on their own infrastructure items or whether they're consuming that as a service, we can accommodate that. When it comes down to some of the more complex solutions, we have a managed Kubernetes platform.
So if people are leveraging that technology from Google or any of the other providers, again, we can design systems with the equivalent functionality that they'd get from the main hyperscalers and move them across to our platform without losing any of the key things that they need.
So really, what you're saying is there's nothing really to worry about.
If they've got proprietary applications and software, it's not a worry.
And that's part of the initial conversations. So we don't want any of our clients to go into a project without having a good understanding of the amount of effort that's going to be needed from both our side and their side.
There's always some stuff that they might need to do. And so getting to the bottom of that at a very early stage helps us define solutions that not only work functionally, but from an operations and onboarding perspective, are feasible to implement.
And I think data sovereignty comes into that for me a little bit as well. So I think people think about the hyperscalers and think about one of the things they offer is availability zones and data centers in different countries. But we can offer that too. It's not an exclusive benefit of going with some of the large providers.
Well, we're going to have to bring our conversation to a close at that point. But we've had some really great points and insights into the subject today on total cost of ownership. We're going to continue recording for now.
So everybody that's listening, make sure you come back next week and listen to part two. Gary, Dan, you've been great, as usual. So thank you. And we're looking forward to hearing more about this topic next week. Bye for now everyone.
Thank you for listening. We hope you enjoyed this episode. You can subscribe on Spotify or Apple Podcast or visit proactive.fasthosts.co.uk for more info. See you next time.