전사 🔗
WEBVTT
1
00:00:00.100 --> 00:00:12.440
[upbeat music] Hi, everyone. I'm Jess. And I'm Tom.
2
00:00:13.040 --> 00:00:25.140
Welcome back to the Fast Track, a podcast by Fastlane where technology, innovation, and learning come together. Today, we're talking about something that a lot of organizations are dealing with. Definitely.
3
00:00:25.240 --> 00:00:33.560
Multi-cloud is something that is a reality, I would say, in the whole enterprise world nowadays. There are practically... I mean, not just nowadays, I would say.
4
00:00:33.620 --> 00:00:40.640
In the last, in the last decade, we've been in the cloud world. So now it's twenty twenty-six, that would be twenty sixteen, twenty seventeen.
5
00:00:41.260 --> 00:00:45.420
Most of the organizations started adopting cloud somewhere in the twenty fifteen, I would say.
6
00:00:46.020 --> 00:00:57.760
And as soon as they started exploring that space, it was kind of immediately visible that they're just not gonna stick with one vendor. They're going not-- they're not gonna put all their eggs in one basket.
7
00:00:57.800 --> 00:01:06.200
That's kind of something that, that, that we've been taught about the IT for the last couple of decades, that we have to mix it up a little bit, and that's what we've been observing.
8
00:01:06.320 --> 00:01:14.980
So there are organizations that are using two, there are even organizations that are using three cloud vendors for certain different kinds of workloads out there. Absolutely.
9
00:01:15.520 --> 00:01:26.440
And using AWS, Azure, Google Cloud can give organizations a lot of flexibility, but it can also create a lot of complexity, right? Absolutely.
10
00:01:26.500 --> 00:01:35.240
You know, every cloud is different to some extent, so we don't have such a thing as a standardized cloud offering. I mean, there are virtual machines everywhere, but they are called differently.
11
00:01:35.320 --> 00:01:45.780
The way they work is slightly different, and it's not just one-on-one mapping. So any ca- any time that you are introducing a new vendor into the mix, you are introducing complexity into your IT infrastructure.
12
00:01:45.860 --> 00:01:50.270
If we come to talk about cloud, there are certain, I would say, patterns that always emerge.
13
00:01:50.600 --> 00:02:02.140
There are certain things that everybody cares about and that everybody noticed that are the typical problems and, uh, some things that I would say we need to address. So let's start then with the big picture.
14
00:02:02.540 --> 00:02:11.470
When companies first move into multi-cloud, since, as you said, two thousand and fifteen, companies are moving to cloud and multi-cloud in one way, right?
15
00:02:11.500 --> 00:02:19.500
So there's usually a reason behind it, but where does this strategy usually start turning to a sprawl? I would say that
16
00:02:20.520 --> 00:02:29.710
if you look at the history of the whole IT infrastructure, even when you started to move into the cloud, you immediately started to move kind of in the multi-cloud scenario or multi-cloud scenario.
17
00:02:30.100 --> 00:02:38.160
Because you still had on-prem environment, which some people started calling their private clouds, even though that's terminology, just it's not a technology.
18
00:02:38.190 --> 00:02:47.800
It's basically just the term that's gonna say, "Okay, that's not a public cloud. That's why it's my private cloud." There were no consensus, there was no consensus what private cloud actually is.
19
00:02:48.160 --> 00:03:00.160
Is it just any kind of data center? Is it automated data center? Is it, you know, fully fledged automated infrastructure pro-provisioning system that just sits in your realm? There is really no definition.
20
00:03:00.180 --> 00:03:08.760
Private cloud would be anything that's not in the public cloud realm, so anything that's not owned by Microsoft, Google, AWS, or some of the other smaller vendors out there.
21
00:03:09.200 --> 00:03:17.980
So even when you started moving into the single cloud, as we would call it, you were immediately in the multi-cloud because there were things that are still managed by your internal team.
22
00:03:18.020 --> 00:03:26.060
There are still, I would say, infrastructure that you own, infrastructure that you paid for differently than the one in the cloud, so there were already differences.
23
00:03:26.420 --> 00:03:36.500
Now, when you introduce into the mix two different cloud vendors, that actually means that you are managing two different contracts, which would be, you know, a financial thing or operational thing in that manner.
24
00:03:36.900 --> 00:03:46.640
But on the other hand, you have the IT operational thing because none of the clouds are created equal. So there's a, there are differences between Azure, between AWS, between GCP.
25
00:03:47.080 --> 00:03:52.820
And even if you are going to use the particularly specialized cloud vendor, which are now becoming really popular...
26
00:03:52.840 --> 00:04:09.810
For example, there are cloud vendors which are offering massive amounts of GPUs, which are important for the AI, and those are a little different or totally different than what we are used to in the, in the world of the typical cloud computing, typical public cloud of those top three, as we are always calling them.
27
00:04:10.300 --> 00:04:28.560
So I would say that the strategy that immediately becomes, uh, I would say, a necessity, is the way how you are going to manage multiple contracts and which tools and which tool sets and which skill set your engineers are actually going to have in order to tackle different clouds with the different workloads.
28
00:04:29.200 --> 00:04:39.580
And that is one thing if you're going to choose one cloud for one type of the workload and a second cloud for the second type of the workload. Then maybe you actually are handling two different teams, are handling...
29
00:04:39.620 --> 00:04:47.580
You know, for example, you're keeping your
Load full transcript
virtual machines and all of those infrastructure workloads in AWS, and you chose Azure or Google Cloud for your AI workloads.
30
00:04:48.080 --> 00:04:51.180
That might work perfectly because they are completely different.
31
00:04:51.440 --> 00:05:14.280
However, if you tend to mix those workloads, and you will at some point in time, one way or the other, then you are actually going to-- That, that, that process is going to involve kind of transfer of the knowledge, transfer of the skills between those two different teams that are managing the cloud, and you need to create one single cloud team that are going to manage the whole infrastructure, no matter where it is at the end of the day.
32
00:05:15.820 --> 00:05:27.120
That's really interesting. And that leads me to another question that would be, um, is there a point where you can look to an environment and say, "Okay, this company doesn't really have a multi-cloud strategy anymore.
33
00:05:27.160 --> 00:05:36.580
It's just they just have, like, many clouds"? You mean what is the difference between many clouds and multi-cloud? [laughs] Well, if there is no- Yeah... strategy, you are in many clouds.
34
00:05:37.040 --> 00:05:41.320
That just means you're managing things that don't have anything to do with each other.
35
00:05:41.670 --> 00:05:49.200
And I would argue that many companies that are claiming to be in multi-cloud environment are actually, as you called it, in a many cloud environments.
36
00:05:49.460 --> 00:05:54.490
Because they just have multiple contracts, and there are different teams. For example, marketing is using, I don't know-
37
00:05:55.984 --> 00:06:07.824
Salesforce cloud, for example, and there's the finance that's relying on the internal tools that are in private cloud, and then you have developers or AI developers that are using something completely different, and there's no connection between it.
38
00:06:07.864 --> 00:06:14.904
That actually usually means there is no cloud strategy. If there's no cloud strategy, we cannot have a multi-cloud strategy because we don't have a strategy.
39
00:06:14.944 --> 00:06:27.514
That's the key piece that's usually, that's usually missing in that, in that particular mix. However, you know, you need to start from somewhere. So the question is, and I would say the first question,
40
00:06:28.484 --> 00:06:37.154
do you actually need a multi-cloud? Are you a customer that needs a multi-cloud strategy? Not just a strategy. Do you need a multi-cloud practice?
41
00:06:37.454 --> 00:06:49.724
Are you going to utilize different vendors, or are you okay with just one vendor? Because trust me, the fact that you have multiple vendors is not a good thing. [laughs] It's putting complexity into that mix.
42
00:06:50.004 --> 00:07:01.884
If you would be just managing one vendor and one type of the cloud, that's easier, technically speaking. Problem is that that might lock you in, and lock-in is way worse in the cloud than it was on-prem.
43
00:07:02.444 --> 00:07:11.784
Because in the on-prem world, you would be paying for the license, and that's your total lock-in. Here, you are paying for everything. So if the vendor decides to raise the prices, you cannot do much.
44
00:07:12.084 --> 00:07:23.904
That's why people are deciding to use multi-cloud scenarios so that they could actually kind of, I would say, have a feeling of control under what they can and cannot do.
45
00:07:23.964 --> 00:07:36.224
Depending on which type of service you're using, that control might be actual fact or might be illu-an illusion, but it feels better to actually have a sense of- Wow. That's interesting.
46
00:07:36.284 --> 00:07:49.944
And I keep thinking, who got to choose that? Who really needs to own the multi-cloud strategy, for example? IT, cloud teams, finance, leadership, or a combination of each one of them? I would say all of them.
47
00:07:49.984 --> 00:07:58.234
Technically speaking, the question of infrastructure, especially, I mean, there are certain things it's more related to the governments than to the companies.
48
00:07:58.334 --> 00:08:08.144
But I would argue that it can actually be applied to the big corporations and any kind of enterprise out there, and that it's called critical infrastructure. The infrastructure that's critical for your main operations.
49
00:08:08.704 --> 00:08:18.504
As I'm saying, that term is coming from the government, from the actual nation states who have critical infrastructure to p- support their citizens, their citizens' livelihoods and everything else.
50
00:08:18.924 --> 00:08:27.784
On the other hand, enterprises need to support their key businesses. Their key business workloads are critical infrastructure in an essence.
51
00:08:28.244 --> 00:08:37.944
When you have critical infrastructure, you cannot have just one person responsible for that. You might have one that's actually doing the work, but there are going to be a couple of them accountable.
52
00:08:38.314 --> 00:08:45.624
So when you are talking about multi-cloud or cloud strategy in general, you cannot just rely on, okay, this is an IT work-workload.
53
00:08:45.664 --> 00:08:53.244
So it's cloud, it's IT, so Chie-Chief, uh, Chief IT Officer or however we are calling that person now, is going to be responsible for the cloud.
54
00:08:53.604 --> 00:09:01.524
It cannot be just like that because cloud means cost, and it's an operational expense on the other hand. Yes. So it's going-- immediately it's gonna be visible on the bottom line.
55
00:09:01.564 --> 00:09:09.584
It's not something that's, you know, depreciated over time or something like that. It's an operational expense. So CFO has to be involved into that strategy.
56
00:09:09.644 --> 00:09:18.104
On the other hand, it's touch-basing with the core operations of the company. You cannot avoid that on the CXO level, so on the CEO level.
57
00:09:18.554 --> 00:09:26.024
And on the, on the, on another important point, we're talking
about critical infrastructure, which immediately opens up a security topic.
58
00:09:26.564 --> 00:09:33.124
And when you put security into the mix, it's again a job of the CEO because it's so, such an important topic.
59
00:09:33.684 --> 00:09:49.174
So I'm not expecting every single CEO in the end- in, in, in every single enterprise across the world to actually be knowledgeable about how cloud operates, how to deploy a virtual machine into the cloud or some AI agent or whatever we are deploying.
60
00:09:49.494 --> 00:10:01.344
But I would expect every single person who tends to own the business or be responsible for the full, for the full business from top to bottom to understand the impact cloud computing has on their businesses.
61
00:10:01.764 --> 00:10:05.924
And on the other hand, this is just a modern way of talking about electricity.
62
00:10:06.004 --> 00:10:14.294
You don't need to know to h- to calculate and to create, you know, circuits or whatever, but you need to understand that your bill for electricity is going to impact everything.
63
00:10:14.624 --> 00:10:25.144
So if your industry is based on the electrical energy, and everybody else's, everybody is nowadays, so that's an important part of your story. The fact that you are going to have...
64
00:10:25.484 --> 00:10:29.874
You know, while it's running, it's all good. When it stops running, you are in trouble.
65
00:10:30.164 --> 00:10:39.124
So you need to be aware that that's the same impact cloud is going to have and multi-cloud strategy is going to have on your business once it's not running. While it's running, it's the job of IT.
66
00:10:39.564 --> 00:10:50.484
When it's not running, it's the job of the CEO. That makes total sense. And even because cloud was originally a way to gain flexibility and potentially reduce infrastructure costs, right?
67
00:10:50.504 --> 00:10:57.424
But now we hear a lot about organizations that are struggling with unexpectedly high cloud bills and all of that because they don't have control.
68
00:10:57.444 --> 00:11:06.023
They keep choosing and, and that, that's the strategy that we do not want to follow. That's, again, missing the strategy, I would say- Mm-hmm... that that's producing that kind of results.
69
00:11:06.444 --> 00:11:09.064
I mean, technically speaking, a lot of people,
70
00:11:10.344 --> 00:11:20.404
especially nowadays when AI is in the mix, because AI costs are enormous, even higher than what we would expect to be, and even higher growth of the cost than it was with cloud computing.
71
00:11:20.484 --> 00:11:28.884
So currently, not that many people mention FinOps anymore. But there was a point in time, let's say five years ago, when FinOps was everything.
72
00:11:28.924 --> 00:11:36.264
It was like, we are going to hire FinOps specialists, just like you can hire that kind of a person. There is no FinOps specialist. There are best practices.
73
00:11:36.644 --> 00:11:47.444
And just like with everything else, when going into the cloud without rethinking it, without thinking it and thinking it through basic and creating a strategy, you are missing the point at the end of the day.
74
00:11:47.544 --> 00:12:01.172
Because everybody was like, "Oh, go to the cloud, it's gonna be cheaper." Well, says who? Yeah. Did anybody calculate it? Was there ever a promise that moving you to the cloud is gonna be cheaper? I don't think so.
75
00:12:01.412 --> 00:12:11.432
I, I haven't seen that kind of a campaign. It was always about they're gonna be flexible, and there was another story in the cloud you're going to pay only for what you use.
76
00:12:12.452 --> 00:12:16.451
That's technically true, and the problem is that people don't understand what they use.
77
00:12:16.592 --> 00:12:24.172
And then that- that's the point where the cloud bill comes in at the end of the month, and it's like, "Oh my God, these are unpredictable costs."
78
00:12:24.932 --> 00:12:30.852
I would argue there ne- there, there isn't a single cost in your cloud bill that's unpredictable.
79
00:12:31.552 --> 00:12:48.042
You might not be aware of it, but it's not unpredictable because you are charged only for what is running inside of your account, project, subscription, however the actual tenant is called inside of the cloud computing world, depending on AWS, Google, or Microsoft.
80
00:12:48.572 --> 00:12:55.892
But the problem is that people are not aware of what they are running and how the service that they are running is actually charged.
81
00:12:56.432 --> 00:13:05.032
And when you don't understand that, obviously your cloud bill is going to get enormous, and it's gonna surprise you every single month. So that's one problem.
82
00:13:05.612 --> 00:13:16.912
Second problem is when you start adopting cloud computing, usually there are people who can just create resources all over the place. "Oh, let's give something to Joe. Let's give something to Ryan.
83
00:13:17.252 --> 00:13:27.792
Let's give something to Tom." And then the three of us are responsible for creating resources. And I wake up one day, I want to test this virtual machine. I spin it up.
84
00:13:28.652 --> 00:13:35.552
Then I wake up the other day, now I'm going to test this database. The third day I'm going to test, test this AI capability.
85
00:13:36.312 --> 00:13:43.992
And then I'll just keep it up and running, and suddenly that VM that's doing practically nothing is spending money every single minute that it runs.
86
00:13:44.372 --> 00:13:55.971
At the end of the month, I'm going to get the bill for everything that I was using. And then somebody comes in and say, "Oh, but I wasn't using any of this." Well, you are missing the point of what using means.
87
00:13:56.032 --> 00:14:03.532
You created the service, and service was up and running. Yes. And that's what we are charging you for. If you stopped that virtual machine, you wouldn't be charged for it.
88
00:14:04.052 --> 00:14:20.341
So that's where the confusion
comes in, and that's the, the fact that enterprises deploy cloud, like, okay, different departments are going to have different subscriptions, and they're going to have their own, their own possibility or their own freedom to create any kind of resource that they would like to.
89
00:14:21.012 --> 00:14:34.162
At the end of the day, if you don't have guardrails in place, that will create something that to you might seem completely unpredictable cloud bill. And do you know who receives that cloud bill? The CFO. Yes.
90
00:14:34.162 --> 00:14:45.242
And then CFO who cannot understand what is actually happening is just like, "Oh, this is un- unpredictable cost. We need to cut it down 20%. We need to cut it down 30%." And what does that mean?
91
00:14:46.612 --> 00:15:01.372
Maybe you can cut it down 90%. Maybe you cannot even cut it down 10% because it really depends what is actually running in that cloud and what kind of workload, and is that workload at all a candidate for the cloud?
92
00:15:01.992 --> 00:15:11.172
I mean, now, obviously, technically speaking, everything can run in the cloud. But that doesn't actually mean that everything should run in the cloud.
93
00:15:11.242 --> 00:15:21.482
Maybe there are things that are gonna be cheaper if they are kept on-prem. For some of the security reasons maybe, sometimes maybe for the cost reasons, maybe for the flexibility reasons.
94
00:15:22.112 --> 00:15:31.822
Because you might argue that if we have a server that is local and everybody's los- using it locally, it has local presence, local latency.
95
00:15:32.752 --> 00:15:47.532
Why would we now move it hundreds of miles from the company and just create all sorts of tr- trouble for everyone? It's not bothering anyone. It's standing there. It has five more years of life. It's cool. Keep it up.
96
00:15:47.592 --> 00:15:50.992
You're not gonna... It's not gonna be cheaper just because you move it into the cloud.
97
00:15:52.092 --> 00:16:03.132
But there are workloads, and I would say there are predominantly different workloads that can live in the cloud, but not everything should. That's kind of how I look at this whole story.
98
00:16:04.552 --> 00:16:18.062
And so, so in the end of the day, what metrics should organization actually be watching, you know, not to fall in this mis-strategy? Huh. I wouldn't say me- I mean, metrics.
99
00:16:18.192 --> 00:16:27.152
Metric by definition is some number of something over time. Yeah. That would- Mm-hmm... define metric. So you can say cost over month, cost over day. I would say that there are practices.
100
00:16:27.552 --> 00:16:39.972
So first of all, there is absolutely no reason why you wouldn't have a cost alert of every single cloud. So every single day, either daily budget, weekly bud- monthly budget, doesn't matter.
101
00:16:40.032 --> 00:16:48.232
If you see the cost rising from day to day, and you can monitor it on that level, if you see it rising more than 20%, something is wrong.
102
00:16:48.752 --> 00:16:54.172
Or it's normal, but somebody didn't inform you that there is a new project coming up.
103
00:16:54.612 --> 00:17:04.492
So those, those things, those rising of the costs that are un- unpredictable by def- by your definition should actually be alerted, so you could immediately see.
104
00:17:04.802 --> 00:17:15.152
I can tell you, for example, I was preparing for a training, and I have alerts on, of all of my clouds. And it was immediately visible after two or three days that my cost has grown from the previous month for 30%.
105
00:17:15.212 --> 00:17:25.532
I'm on the 30% of my small budget of a hundred bucks, which is my budget for the training. And it was immediately visible that I spent 30 bucks. It was okay because I knew what I was doing.
106
00:17:25.652 --> 00:17:29.712
I knew that I was gonna spend that money. At the end of the day, one of my customers is going to pay for that.
107
00:17:30.232 --> 00:17:42.332
But the problem is if you don't s- have alert in place, if I didn't have alert in place, I could have spent hundreds of dollars without knowing what is happening. And it's an easy fix, you know. It's an easy fix.
108
00:17:42.892 --> 00:17:48.092
On the other hand, companies should control who has access to creation of the resources.
109
00:17:48.632 --> 00:18:02.012
Because if you have access to any kind of cloud portals, you can just easily in a couple of clicks, if there are no guardrails in place, you can create a virtual machine that's gonna have 256 cores and four terabytes of RAM
110
00:18:03.208 --> 00:18:17.167
That thing costs a couple of thousand dollars per day. So easily, just like that, you create 10K of cloud bill if you don't put those people under control. And it's not just the control, you know, who can do what.
111
00:18:17.528 --> 00:18:28.468
It's also the control what can actually be spun up on that particular cloud without additional approval. Sometimes you're gonna need that kind of virtual machine.
112
00:18:28.508 --> 00:18:38.778
If you're ru- running, for example, SAP workload in the Azure or Google or Amazon Cloud, you're gonna need that, that machine. But that doesn't mean... I mean, that kind of cost is usually planned.
113
00:18:39.168 --> 00:18:46.828
That kind of project shouldn't just happen, let, uh, Peter spin that up just like that. No, it's never gonna happen like that.
114
00:18:47.168 --> 00:18:53.128
It's always gonna be planned because it's a big cost, it's a big commitment, it's SAP in the cloud, it's a big project at the end of the day.
115
00:18:53.508 --> 00:19:04.288
So you can always kind of know when that cost is gonna occur at the end of the day. So alerts definitely controls what can be done, not just by whom.
116
00:19:04.508 --> 00:19:15.678
You can have 10 administrators, but there should be a limit on the amount of CPUs or cores or whatever is called that you can spin on a particular project without additional approval.
117
00:19:16.708 -->
00:19:30.228
So those are some caveats, some guardrails that companies can put in place easily without necessarily employing any kind of con- advanced consultancy, any, any kind of, you know, people or who are going to act as an advisors.
118
00:19:30.608 --> 00:19:38.478
Those are the things that you can learn easily from the basic course that you would take on cloud computing. From Amazon, Microsoft, Google, doesn't really matter.
119
00:19:38.808 --> 00:19:41.308
Cost management is the first thing that you, that you are taught.
120
00:19:41.878 --> 00:19:56.488
And even if you don't understand how each and every resource is charged, you can still put those guardrails together because it's easy to just ask for additional approval and check additional information before something is actually deployed.
121
00:19:57.148 --> 00:20:05.388
And do you think it's possible for the organizations to create a single view of what's happening so they don't get lost? You know, you mentioned the alerts.
122
00:20:05.708 --> 00:20:17.628
Is there anything that they can connect to make sure everyone is following it up so we don't, we don't lose the tracking? I mean, those are all elements of the... I mean, it's a combo.
123
00:20:17.788 --> 00:20:28.208
FinOps world, that, that's, that's why FinOps is called FinOps. It's somewhere between finance and operations at the end of the day. Operations. Mm-hmm. So they are kind of a shared responsibility.
124
00:20:28.248 --> 00:20:38.928
But from the IT point of view, the tools to monitor the costs are already there. Every single cloud has cost management solution. It's free of charge on the cloud that you're using it.
125
00:20:38.988 --> 00:20:48.168
That's a little bit problematic when you're talking about multi-cloud strategy, but in, at the end of the day, it's either one or two or three tools that you're gonna use. It's not dozens of tools.
126
00:20:48.648 --> 00:20:57.848
And all of those have some kinds of integrations. All of those support exports to any kind of, you know, business analysis system. So that's something that can be done on a regular basis.
127
00:20:58.228 --> 00:21:08.568
Alerts in place is the second thing. Third thing is general operational monitoring. What is happening with my system? And orgs usually have those things in place.
128
00:21:08.828 --> 00:21:19.028
So I would say if you have an observability team who is responsible for functioning of the system, FinOps should be just one extension of that observability team.
129
00:21:19.098 --> 00:21:30.548
So instead of just monitoring the uptime of your services, monitoring the s- how, how much memory is on the s- on that particular VM, how much CPU is there consuming, is there a need for additional one?
130
00:21:30.888 --> 00:21:38.288
All those things are already in place in, in the observability teams or in any kind of opera- IT ops teams that exist.
131
00:21:39.188 --> 00:21:48.228
We should just put additional metric, which is the cost of the resources, and tracking down the total cost of the resources into that particular mix.
132
00:21:48.738 --> 00:21:57.588
And then we should have, and we need to have basically people from finance and people from operations talking together on a regular basis.
133
00:21:57.628 --> 00:22:21.588
So people from IT ops with the fin- with somebody from fin- finance have to form a council that's going to actually meet on a regular basis, it's weekly, bi-weekly, whichever they decide, so they can discuss what are the new investments that are gonna happen, how much they are going to cost, and how much the new investment or the new technologies that are going to be brought up into the mix are actually going to increase the cost.
134
00:22:21.848 --> 00:22:35.448
Or if IT ops can do optimization, in which way and in which manner they can optimize the resources so they can actually cut down the operational cost. Okay. And now it brings me to the AI environment.
135
00:22:35.548 --> 00:22:39.648
So AI is changing a lot of things, and it's now changing the conversation again, right?
136
00:22:39.828 --> 00:22:51.228
Uh, we're seeing the emergence and rapid growth of GPU-focused cloud providers built specifically around the massive computing requirements of AI training and, and inference, right?
137
00:22:51.608 --> 00:23:03.408
Uh, how do these specialized GPU clouds change the traditional multi-cloud strategy? Huh. That's an really interesting one. Technically speaking, the current market size,
138
00:23:04.588 --> 00:23:16.588
you wouldn't believe, is already at between 20 and 25 billion. Just to compare it, Microsoft has somewhere around 100 billion, and the cloud computing AWS has around 150. So
139
00:23:17.748 --> 00:23:30.348
f- I would say up to qua- quarter of what Microsoft has is already consumed by neo cloud sec- neo cloud sector as they are calling it. It's a neo cloud, basically. It's GPU-based cloud computing.
140
00:23:30.728 --> 00:23:41.728
So those are completely specialized cloud computing vendors. They don't have many services. They offer you a bare metal, which has a ton of GPU power, and it's used for two things.
141
00:23:41.988 --> 00:23:52.138
It's either used to train the model or to inference the model, period. That's what you do with those cloud vendors. And do you know who their biggest customers are? Who?
142
00:23:52.288 --> 00:23:57.248
The traditional cloud vendors who cannot keep up to speed with the GPU power.
143
00:23:57.568 --> 00:24:08.328
So they are renting the equipment that's owned by the other clouds, smaller clouds, to actually offer to their customers the ability and capability to run the GPUs.
144
00:24:08.728 --> 00:24:17.708
I mean, they're listed as official vendors and everything else. It's not like that they are hiding something. But it's an amazing change in the dynamic how cloud actually expands.
145
00:24:18.404 --> 00:24:21.504
Problem is, how is that going to go further along?
146
00:24:21.624 --> 00:24:33.664
So are Microsoft, Google, and Amazon buying these services, which is an OpEx now for them, so they are not depreciating their equipment, but they are buying the OpEx, the most expensive thing when you are a cloud vendor.
147
00:24:34.244 --> 00:24:45.504
So how is that going to look like in a year or two? It's gonna be interesting to actually see. But yeah, I mean, from that point on, specialized cloud can be a reason to g- to do multi-cloud.
148
00:24:45.564 --> 00:25:01.284
For if you have a lot of requests, you have your own models, or you are training your own models, there is a reasonable thing to do to actually go down the road of spending money to somebody who is completely specialized for GPU power.
149
00:25:01.584 --> 00:25:11.224
First of all, it's gonna be cheaper. Second of all, it's probably gonna be a better service at the end of the day because they are specialists in what they do. So it's definitely an emergence that's gonna continue.
150
00:25:11.284 --> 00:25:24.964
I don't see that changing that quickly. The problem is, how long will it take for big vendors, which have the most money in the whole wide world, to acquire enough GPU power? Currently, they are struggling.
151
00:25:25.244 --> 00:25:35.304
They're also struggling with power, actual el-electricity. Electrical power is another story where there are certain things happening around the place, so Microsoft is investing in power plants.
152
00:25:35.864 --> 00:25:40.044
I could have never imagined that, like, ten years ago or five years ago to the, to that point.
153
00:25:40.124 --> 00:25:54.584
So those smaller vendors, which are not small and not that small anymore, are going to player, uh, play a significant role in the time to come until there's enough GPU power for everybody on the planet so that we no longer talk about it.
154
00:25:55.044 --> 00:25:57.364
We'll see how it goes. Might...
155
00:25:57.404 --> 00:26:11.904
First time since the cloud started and since the cloud war started, that's basically where the top three companies entered the war, I feel like there might be a space for some new player to emerge out of all of these GPU-based cloud vendors.
156
00:26:12.664 --> 00:26:21.484
And how... What do you think is the differentiator that this would have? I mean, the differ- it's they're going to be specialists, but we were always having some kind of specialist.
157
00:26:21.524 --> 00:26:30.044
You know, for example, everything is in the cloud, we still have GoDaddy. GoDaddy is a specialized web- Yeah. Mm-hmm... hosting service providing webs, web hosts.
158
00:26:30.404 --> 00:26:40.984
We still have Hostinger, which is another web hosting service in the US. There is Hetzner in Europe, another vendor that's providing mainly web hosting sites.
159
00:26:41.004 --> 00:26:49.254
Because somehow websites are, especially those marketing websites, not web applications, that's a whole different set of things.
160
00:26:49.644 --> 00:27:02.524
But websites are actually not that good citizens of the cloud computing because they are mainly based on the poorest written software on the planet Earth called WordPress, and WordPress requires special attention.
161
00:27:02.544 --> 00:27:11.404
And those hosting platforms actually give WordPress the special attention, and due to that fact, they are there. So that's why they, th-those companies still exist.
162
00:27:12.064 --> 00:27:18.764
I would argue that for these specialists, there's a role now and there will be a role in the future because guess what?
163
00:27:18.924 --> 00:27:31.244
Just like we are talking about different clouds and whether or not you want to keep all your eggs in the same basket, there's another story whether or not you're going to keep all your models done by same vendor.
164
00:27:31.824 --> 00:27:40.884
Are you going to just use Anthropic, for example, or are you just going to use Google, or are you just going to use Microsoft? Can you afford to have only one AI? What is...
165
00:27:41.164 --> 00:27:53.164
What kind of a lock-in is that if everybody's gonna start using AI? And it's no longer just IT. We are talking about end users. So it's gonna be interesting to see where that all, where, where that whole thing goes.
166
00:27:53.264 --> 00:27:59.164
I don't see any name, if you're asking me for the actual name of the- Mm... of the player. I don't know who's gonna be better. No.
167
00:27:59.184 --> 00:28:11.264
Currently, they're all somewhere around, and they're all, they're all always, you know, amazed or they're so happy when they sell large contract to s- to their main competi- competitor, and that's Google, Microsoft and Amazon.
168
00:28:11.624 --> 00:28:25.864
They are still really good because they are getting the money. Problem is that when you are signing such a contract, you commit to the certain capacity, and that capacity is not gonna be there for long periods of time.
169
00:28:26.224 --> 00:28:38.064
The depreciation of that hardware is also happening, and basically, that hardware is going to need to be replaced in a certain amount of time. And the more it's used, the sooner it's going to need to be replaced.
170
00:28:38.104 --> 00:28:44.204
The question is: Are you charging enough today so that you have the money to replace that hardware?
171
00:28:44.224 --> 00:28:54.944
Because currently you invested, you want to get back your, get your investment back, but the question is: Are you charging enough? If you are not charging enough, you're gonna be in trouble in a year.
172
00:28:55.664 --> 00:29:07.184
And, and this leads me to another question. That would be, when does bringing a workload back on-prem actually make sense? Well, if you asked me that question ten years ago, I would say never.
173
00:29:07.274 --> 00:29:13.203
[chuckles] Because the cloud hype was there, and we were expecting kind of the- Yeah... prices to drop.
174
00:29:13.244 --> 00:29:26.344
We were expecting
that there is gonna be innovation in the cloud that just not gonna match what is happening on-prem. I would say five years ago, during the COVID time, it was like, "Okay, this is happening.
175
00:29:26.484 --> 00:29:36.484
Everything is now going into the cloud because there's no way any single enterprise can manage that kind of a capacity that's required for the people who are starting to work from home." But guess what?
176
00:29:36.544 --> 00:29:48.544
We somehow overcame that story. We somehow were able to manage to create enough infrastructure to actually have every- everybody working from home at that point in time, and businesses were booming.
177
00:29:49.244 --> 00:29:59.524
So everything was growing, and somehow cloud vendors kept that pace in terms of investing infr- in, in the infrastructure, but the prices didn't come down.
178
00:29:59.764 --> 00:30:09.544
I haven't seen change of pricing in terms of the VMs or app services or databases that is going rapidly down in the last five years. Prices stay the same.
179
00:30:09.624 --> 00:30:16.744
Some of them increased, but majori- ma-majority of them stay the same. So you can actually count in the inflation and all of this.
180
00:30:16.764 --> 00:30:25.244
But we've seen that other than the pure infrastructure, the rest of the cost was actually coming up. The licenses are more expensive. So we've seen that.
181
00:30:26.236 --> 00:30:32.976
We've seen special services that current kind of like they change, they are saying they're changing the licensing model.
182
00:30:32.996 --> 00:30:40.336
What they're actually doing, they're increasing the price just by adding certain things that nobody needs. So we've seen that around the place for the last couple of years.
183
00:30:40.756 --> 00:30:52.176
We've seen hardware vendors or, or actual, you know, the product companies like Apple, for example, increasing their prices due to the fact that there's an inflation that influencing that.
184
00:30:52.416 --> 00:31:00.656
But the second thing is that the GPU prices have gone up. Due to that fact, you need to increase any kind of system that's depending on the GPU price, and we're gonna see that coming.
185
00:31:00.776 --> 00:31:12.016
I would say two years ago, for example, AI service was normally charged per user, per seat, or something like that. Nowadays, you see Copilot in Microsoft Word, for example.
186
00:31:12.096 --> 00:31:19.536
If you're gonna use pure Copilot, which can do certain things, you are charged X amount of dollars per user. But guess what?
187
00:31:19.616 --> 00:31:31.246
If you want to use advanced capabilities like Copilot Cowork or Work IQ, some of those services, you are no longer charged just per seat, you are charged for every single token that you spend. My God- Yes...
188
00:31:31.256 --> 00:31:42.436
but you were promising me I'm gonna have end user pricing, and I'm gonna have a license. No, no longer. Even you are now charged, even what we are using is now charged per the amount of tokens we spend.
189
00:31:43.116 --> 00:31:53.716
So then whether or not I'm going to use Cowork to generate a document, that will really be a decision to make because, for example, to generate one nice PowerPoint deck of like
190
00:31:54.736 --> 00:32:07.236
15 slides, which is a typical, you know, marketing pitch or something like that, you would spend around 20 to 30 bucks. Is it worth it? Maybe, but maybe not, depending on what you are doing.
191
00:32:07.936 --> 00:32:18.756
So these are the decisions that people are going to ask. So I wanted to touch base with that because that's one of the ways how you can think about what it makes sense to bring on-prem.
192
00:32:19.736 --> 00:32:22.636
If the workload is completely constant, if
193
00:32:23.636 --> 00:32:36.836
it's just something that's not mission critical, you don't need any kind of disaster recovery for it, it just needs to run, and it's running constantly the same pace, probably a good candidate to think about on-prem.
194
00:32:36.876 --> 00:32:41.736
I mean, if it's not bothering you in the cloud, if it doesn't cost much in the cloud, you're probably gonna leave it there.
195
00:32:41.976 --> 00:32:53.256
But if it's something that's creating a significant cost and the vendor is telling you, "You know, but when you are in the cloud, you have disaster recovery, you have automated backup, you have three copies of each and every bits and piece of data,"
196
00:32:54.436 --> 00:33:03.416
but you don't need any of that, that means that you are overpaying the service because your service is actually not adequate for the cloud. It never was. It maybe should have never been migrated.
197
00:33:04.756 --> 00:33:12.756
However, if you already laid off all of your IT staff, I don't think everybody has done that, but there were talks about it, then who's gonna manage that service?
198
00:33:12.936 --> 00:33:16.076
So those are now the questions that you're going to end up asking.
199
00:33:17.716 --> 00:33:32.506
Another prob-- another thing why that question is now viable is due to the fact that cloud and investment in the cloud made vendors to invest in the typical operational software, which was never needed before.
200
00:33:33.136 --> 00:33:45.236
But guess what? A lot of that software was actually open sourced. Now, something that you could have never afford to create yourself is available there for you to utilize and run inside of your environment.
201
00:33:45.245 --> 00:33:57.516
So those farms of servers and those large disks that were striped and everything else, that, th- those were the technologies that didn't exist on-premise. They were invented in the cloud and now are being pulled on-prem.
202
00:33:58.025 --> 00:34:07.536
So those are the reasons to think and rethink whether or not everything should truly be part of the cloud world or could it actually be run on-prem.
203
00:34:07.846 --> 00:34:22.636
And I think that there are many examples out
there that, that companies actually saved money, a lot of money, sometimes in millions, sometimes in billions, by bringing certain workloads back into the, into their own data centers while they still have it.
204
00:34:23.356 --> 00:34:33.596
Am I saying go now and invest in your new data center, go now invest in your hardware? No, I'm not saying that. It's, it would probably be foolish, and probably there's no financial math that could actually
205
00:34:34.516 --> 00:34:38.376
ap- approve that kind of approach or that could actually, that could actually make sense.
206
00:34:38.676 --> 00:34:52.746
However, if you still have hardware down in, in your on-prem world, if you still have the capability of running your own workloads, yeah, every single workload should be judged again and figure out, "Okay, does this make sense in the cloud, or am I going to keep it locally?"
207
00:34:53.296 --> 00:34:57.436
Because sometimes the answer is going to be, yeah, let's keep it locally. It's a good option.
208
00:34:58.176 --> 00:35:07.996
And when it comes to the people side of this whole thing, uh, what skills the team needs today to manage this multi-cloud environment successfully?
209
00:35:09.436 --> 00:35:19.496
I would say that I- I usually like to tell people, you know, if you know one cloud, you know, you know them all, and that's technically true. There are certain differences, especially in the terminology.
210
00:35:19.896 --> 00:35:27.836
You know, Amazon is going to call the service EC2. Google is going to call it Compute. Microsoft is going to call it Azure VMs. It's exactly the same thing.
211
00:35:28.336 --> 00:35:35.896
But at the end of the day, they are called differently, and there are s- many sub-services that also create a confusion between the people.
212
00:35:35.936 --> 00:35:47.676
Technically speaking, all of the clouds are kind of converging into offering similar things, but those similar things are configured a little bit differently, and as I said before, terminology is a little bit different.
213
00:35:48.116 --> 00:35:59.016
So I would argue that any IT professional nowadays should know at least two clouds and should be certified for at least two clouds. Which one to choose from, that can be up to you totally.
214
00:35:59.336 --> 00:36:07.676
Choose AWS and Azure or AWS and Google or Microsoft and Google. It's totally up to, up to you at the end of the day what you would like to choose from those.
215
00:36:07.736 --> 00:36:19.608
But definitely at least two you should know and should be certified in. It's even better if you can cover all three, and it might be possible to do that. The skill level is always in the cloud computing being the same.
216
00:36:19.788 --> 00:36:29.778
You need to start from the point of the capability to deploy certain type of service into the cloud, and then the rest is general IT world.
217
00:36:29.848 --> 00:36:40.808
You need networking capabilities, you need to understand the virtualization, you need to understand how storage actually operates in a, in a manner of speaking, and how the apps are configured on top of that.
218
00:36:40.828 --> 00:36:52.108
If you have that, you're going to be good in any realm, whether it's the cloud or it's later on-prem world. One important difference in the cloud than in the on-prem, that you're not gonna see the hardware.
219
00:36:52.408 --> 00:36:59.048
So you're not gonna be managing the storage in the hardware way, you're not gonna see where it's hosted, you're not gonna be connecting cables together.
220
00:36:59.348 --> 00:37:03.428
However, networking knowledge in the cloud is as relevant as it is in the on-prem world.
221
00:37:03.748 --> 00:37:19.968
So I would say anything that brings you to become an IT professional who can manage their way into the modern IT world, both on-prem and in the cloud, is the knowledge that's gonna support you when you start to design the new cloud services.
222
00:37:20.607 --> 00:37:22.008
But keep one thing in mind.
223
00:37:22.168 --> 00:37:35.188
Nowadays, entering the cloud world is gonna be, to somewhat extent, a lot easier because we have AI, and AI is built into the cloud, and the same vendors who are providing cloud services are providing AI technologies.
224
00:37:35.588 --> 00:37:48.068
That actually means that a ton of work that we used to be doing manually can now be completely automated. Does that mean that you're... that it's a bad decision to go learn cloud computing nowadays? No.
225
00:37:48.608 --> 00:38:01.748
It just needs a different way of learning. So it's not just about you knowing by heart how to write, I don't know, some kind of Terraform script and all those different bits and pieces of your infrastructure as code.
226
00:38:02.168 --> 00:38:15.908
Probably not the good investment of time, but you still need to understand what it is, you still need to understand what the components are, how the architecture is going to work together, and then you can use AI to generate all of those, and AI can then start doing the work for you.
227
00:38:16.688 --> 00:38:33.608
So those are some of the things that I would argue are going down the road of what we are doing in Fastlane in terms of how we are equipping our IT professionals who are, who trust their careers to us to actually get them up to speed as soon as possible and become AI-augmented professionals.
228
00:38:33.688 --> 00:38:35.908
That's amazing. That's exactly what we do here.
229
00:38:36.008 --> 00:38:45.128
Um, and just remembering that, uh, Fastlane is an authorized training partner, so if you're interested to talk to us and get to know a little bit more about our services, we're also here to help.
230
00:38:45.508 --> 00:38:54.828
So before we wrap up, uh, I want to do a quick fire round, short answers. So I'm gonna ask you some quick questions, and then you can answer what comes to your mind. Right?
231
00:38:55.308 --> 00:39:12.228
So our first question, one cloud or multi-cloud? Multi-cloud. Best way to reduce cloud waste? Monitor what you are deploying and put alerts. Most underrated cloud skill? I would say security.
232
00:39:13.068 --> 00:39:30.028
One multi-cloud mistake companies should stop making. Don't go multi-cloud if you don't have to. FinOps, finance responsibility or technology responsibility? Both. Cloud first or workload first? Workload first, always.
233
00:39:30.408 --> 00:39:43.348
And finally, what's one piece of advice you would give a company trying to get this multi-cloud environment under control today? I would say figure out what you have. Do any kind of assessment analysis that you can.
234
00:39:43.768 --> 00:39:54.968
Figure out where you are. Because designing a strategy and not knowing what you have, it's not gonna be a strategy at the end of the day. It's just gonna be a piece of paper that you put together that looks nice.
235
00:39:55.288 --> 00:40:01.788
It was probably generated with the help of AI. It's wonderful document, but it's not gonna tell you what you should do.
236
00:40:02.128 --> 00:40:14.108
You should first understand what you have, what processes you have in place, and then you can do the change management, which basically is going to be required for you to start managing that cloud environment that you put together.
237
00:40:14.888 --> 00:40:23.068
Yeah, and that leads to run from many clouds and stick with multi-cloud. [laughs] That's a really cool... That's a really cool advice. Tom, thank you so much.
238
00:40:23.228 --> 00:40:29.438
I think the biggest takeaway from today's conversation is that multi-cloud itself isn't really the strategy, right?
239
00:40:29.768 --> 00:40:37.008
Making intentional decisions about where workloads belong, how they are governed, and how much the value they are creating is.
240
00:40:37.128 --> 00:40:49.328
And for everyone listening, Fastlane helps organizations build the expertise across AWS, Microsoft Azure, Google Cloud, and multi-cloud environments, from technical training to architecture and professional services.
241
00:40:49.528 --> 00:41:00.988
Don't miss the next episode where we're gonna talk about cybersecurity. We're gonna talk about some of the important topics that are overwhelming everything in the IT world today.
242
00:41:01.068 --> 00:41:07.538
So cybersecurity is no longer just a job for the IT, it's a job for the whole organization.
243
00:41:07.568 --> 00:41:15.988
So I think that some of the trends that we are seeing, and that we're gonna uncover in the next episode, are gonna be interesting for absolutely everyone to listen to. Awesome.
244
00:41:16.448 --> 00:41:24.138
Find more information, www.fastlaneus.com, and I'll see you in the next episode. Thanks. Thank you.