February 15, 2023 at 12:00 am
Comments posted to this topic are about the item The Cost of the Cloud
February 15, 2023 at 1:51 pm
The company I'm working for now is preparing to make a major jump to the cloud. I'm struggling with their reasons for the move, which seem very abstract and shallow. We're a team of about 25 and we have a couple people with no real experience talking it up. On the other hand, I've never had more than a small percentage of my SQL Servers in the cloud, so I lack experience to speak either way. I'm struggling with whether I should speak up on the matter. To date I haven't really been involved in many discussions, so I'll probably just keep quite and implement whatever is decided.
I wouldn't be surprised if 5 years down the road we find the cloud experiment to have been more expensive than we expected, and quite frankly a waste of all the time it took to make the transition.
February 15, 2023 at 2:31 pm
Thoughtful article, Steve. We're making lots of moves to the cloud. Not all at once, but in pieces. Currently moving test SQL databases to the cloud. I love going to the cloud because, hey let's admit it, the experience will look great on my resume.
But I question why we are going to the cloud in the way that we're doing it. All our migration to the cloud is lift-and-shift. From what I've read an IaaS approach to the cloud is more expensive than either a PaaS or SaaS approach. I've tried to pass that information upward, but either no one is listening, or I'm talking to the wrong people and don't know that I've spoken to the wrong people. I'm sure that for operations and development writing apps like they'll all on-prem (i.e.: like they always have) is just the path of least resistance. Like David.Gugg said, I wouldn't be surprised if 5 years from now we retreat from the cloud back to on-prem, because people didn't want to approach development and deployment in a new way.
Rod
February 15, 2023 at 3:52 pm
There's a thing that Google, AWS and Microsoft all have called the "Well Architected Framework" with 5 pillars (AWS invented a 6th pillar later that seems superfluous). Those pillars are
For each cloud provider these are similar. When you read it then it is all common sense stuff.
If you do a lift and shift to the cloud then there is little advantage in doing so. The Well Architected Framework does warn about this.
The big 3 cloud providers do give you a lot of useful tools and facilities that would be expensive and time-consuming to implement in your own data centre. AWS in particular is good at having services that connect together. Logging, alerting and monitoring being core to watching errant activity.
Of the many things to watch out for is the size of any infrastructure that isn't serverless. If you buy for a data centre you try and guess how big a box you will need to last for 3-5 years, maybe more.
In the cloud you lease for today and if you need less power than you thought you reduces it ASAP, scaling back up as you need, or even, if you need.
For many people the cloud IS more expensive. Some of it is the way they planned (or failed to plan) their systems.
February 15, 2023 at 3:59 pm
The company I'm working for now is preparing to make a major jump to the cloud. I'm struggling with their reasons for the move, which seem very abstract and shallow. We're a team of about 25 and we have a couple people with no real experience talking it up. On the other hand, I've never had more than a small percentage of my SQL Servers in the cloud, so I lack experience to speak either way. I'm struggling with whether I should speak up on the matter. To date I haven't really been involved in many discussions, so I'll probably just keep quite and implement whatever is decided.
I wouldn't be surprised if 5 years down the road we find the cloud experiment to have been more expensive than we expected, and quite frankly a waste of all the time it took to make the transition.
My view is that you need to look at your workload. Is it very predictable? Is it something that lends itself to some scale up/down, or is it steady state? Steady state, at similar performance levels, can be hard. However, it's not just the db servers. Is the cost of maintaining hardware, firewalls, replacing, patching these, etc. something that overwhelms a higher price at 2+ years? That's where you can raise issues, and help someone decide if this makes sense.
It may or may not. Like I wrote, I find lots of companies like it, but lots also jump in quickly and then move back 2-3 years later. We saw some of this with colocation facilities, but a lot of people were happy to pay to not manage a lot of the non-computer stuff.
February 15, 2023 at 4:03 pm
Thoughtful article, Steve. We're making lots of moves to the cloud. Not all at once, but in pieces. Currently moving test SQL databases to the cloud. I love going to the cloud because, hey let's admit it, the experience will look great on my resume.
But I question why we are going to the cloud in the way that we're doing it. All our migration to the cloud is lift-and-shift. From what I've read an IaaS approach to the cloud is more expensive than either a PaaS or SaaS approach. I've tried to pass that information upward, but either no one is listening, or I'm talking to the wrong people and don't know that I've spoken to the wrong people. I'm sure that for operations and development writing apps like they'll all on-prem (i.e.: like they always have) is just the path of least resistance. Like David.Gugg said, I wouldn't be surprised if 5 years from now we retreat from the cloud back to on-prem, because people didn't want to approach development and deployment in a new way.
The cost of the server is more, but this is an OpEx vs a CapEx, so it can be hard to determine if this makes sense. The cost of provisioning and getting things set up isn't something to take lightly. I've seen companies lift and shift and save money with IaaS, though often this is at the end of some other IaaS type contract or a data center close with less people involved in managing the systems.
It's not simple. PaaS can be a lot cheaper, but often requires a lot of labor and rewriting apps. IaaS can go either way.
February 15, 2023 at 4:04 pm
There's a thing that Google, AWS and Microsoft all have called the "Well Architected Framework" with 5 pillars (AWS invented a 6th pillar later that seems superfluous). Those pillars are...
For many people the cloud IS more expensive. Some of it is the way they planned (or failed to plan) their systems.
Well said
February 15, 2023 at 4:06 pm
Thanks for the response Steve.
I guess the one question I have when people talk about scale up/scale down, are they more like at seasonal changes or intraday changes? If 90% of our traffic is 9 - 5 CST, do we implement scale down for overnight?
I used to work at an online retailer where 80% of their business was Q4. That seems like a poster child for cloud scale up/scale down opportunities. Where I'm at now though, it fairly consistent throughout the year. Unless we're simply scaling down at night, then back up in the morning, I don't see much opportunity.
February 15, 2023 at 4:11 pm
Thanks for the response Steve.
I guess the one question I have when people talk about scale up/scale down, are they more like at seasonal changes or intraday changes? If 90% of our traffic is 9 - 5 CST, do we implement scale down for overnight?
I used to work at an online retailer where 80% of their business was Q4. That seems like a poster child for cloud scale up/scale down opportunities. Where I'm at now though, it fairly consistent throughout the year. Unless we're simply scaling down at night, then back up in the morning, I don't see much opportunity.
Scaling is hard and weird. A lot depends on what your architecture is. If you have VMs, then maybe, maybe not. A lot of times you have maintenance or backups or something at night. Can you save? Maybe. You can certainly script some changes, but a lot of VM size changes down require rebooting because of the OS. Linux is better than Windows, but not always.
With a PaaS db, some people scale down for low periods. Or even scale high for something like a data load. Serverless is interesting in many cases as well. More, the Q1/2/3 v Q4 thing is a place where some systems shine. One of the early MS cases was their internal HR for benefits. Scaled down most of the year. Late Q4/Q1, scale up for people making changes.
Harder to do that on premises. Can be done, especially with things like VMWare ESX, but most people are too lazy since it's a sunk cost. What's the point of moving more/less CPUs/RAM if you've paid for them?
February 15, 2023 at 6:02 pm
My company did a wholesale move to the cloud in 2015-2018. We closed down all five North American data centers and did a lift and shift of everything that was not located in a production facility. Once we got there the plan was to refactor applications to a more cloud native architecture on that application's normal refresh cycle. Results have been mixed. Some applications have seen great improvements, for my database servers there have been more frustrations than wins. Having to refight the battle over shutting servers down at night again and again got old fast.
As Steve mentions the transition from CapEx intensive projects to OpEx budgeting is as big a change for the organization as the technical change of using cloud resources. Not sure it has saved any actual money over the longer term, but what is being spent is far more transparent than in the past. No more of some manager buying a server on travel expense card and starting a shadow IT organization.
Overall it is definitely not the path I would have chosen, but I'm not in the best position to see the benefits either.
February 15, 2023 at 10:29 pm
You can certainly switch off your DEV environment overnight. I know of one large company that had an autodestruct at 19:00. You could request a 1 hour extension to your personal dev environment, but only until 20:00.
Most non-production environments don't need to run 24/7 or don't need all components up all the time. However,the ability to spin up an entire environment up on demand for a specific reason is extremely useful.
In production environments some components can be switched off. For example, if you have overnight batch processes you don't need that infrastructure during the day.
If you have 24/7 microbatch systems then you have infrastructure for that need which is separate from the overnight infrastructure.
Loads of things are possible but you do need to design carefully to get the best out of the cloud.
There are techniques and tools that I would regard as essential.
Infrastructure as code and under source control. CI/CD. Monitoring, alerting and logging. Rehearsed backup/restore. Tools like Terraform/Terragrunt.
Penny pinching on training, IDEs and developer tooling is a sure fire way to result in huge bills downstream
February 15, 2023 at 10:57 pm
Doctor Who 2 wrote:Thoughtful article, Steve. We're making lots of moves to the cloud. Not all at once, but in pieces. Currently moving test SQL databases to the cloud. I love going to the cloud because, hey let's admit it, the experience will look great on my resume.
But I question why we are going to the cloud in the way that we're doing it. All our migration to the cloud is lift-and-shift. From what I've read an IaaS approach to the cloud is more expensive than either a PaaS or SaaS approach. I've tried to pass that information upward, but either no one is listening, or I'm talking to the wrong people and don't know that I've spoken to the wrong people. I'm sure that for operations and development writing apps like they'll all on-prem (i.e.: like they always have) is just the path of least resistance. Like David.Gugg said, I wouldn't be surprised if 5 years from now we retreat from the cloud back to on-prem, because people didn't want to approach development and deployment in a new way.
The cost of the server is more, but this is an OpEx vs a CapEx, so it can be hard to determine if this makes sense. The cost of provisioning and getting things set up isn't something to take lightly. I've seen companies lift and shift and save money with IaaS, though often this is at the end of some other IaaS type contract or a data center close with less people involved in managing the systems.
It's not simple. PaaS can be a lot cheaper, but often requires a lot of labor and rewriting apps. IaaS can go either way.
Good points, Steve. So, even though we're taking an IaaS approach, we might experience a savings. Something I hadn't considered before. I do know that there will be a huge reluctance to re-writing anything with people using the, "If it ain't broke, don't fix it" mantra. What I would rather see us do is migrate some of the databases and apps into the cloud in a lift-and-shift approach, but others re-write them to make them more cloud-native. That way if some of them turn out to have a good ROI we can see which they are. At this rate only doing lift-and-shift means we're putting all our eggs into my cloud approach.
Rod
February 16, 2023 at 3:05 am
Heh... Some of the people I've had to work with in the past seem to make a pretty good living at "If it ain't broke, fix it until is" mantra. 😀
--Jeff Moden
Change is inevitable... Change for the better is not.
February 16, 2023 at 1:34 pm
I hear ya, Jeff, but where I work, they take the "If it ain't broke, don't fix it" mantra to the extreme. They will leave something alone until it is so broken that it cannot be fixed. That results in panic, a rush to find the "guilty", and a purchase order for something that could have been cheaper, if they weren't so desperate to get it replaced.
Rod
February 16, 2023 at 4:15 pm
So, the cloud is like a super buffet where every type of food imaginable is right there for the taking at a price point that's less than you would spend if you cooked it at home. However, the catch is that getting charged per pound, so you have to keep an eye on the kids to make sure they are not overloading their plate - so you don't get sticker shock at the cash register.
There are things you can do to save costs, like: reserving capacity in bulk, using Spot VMs for development environments, automatically pausing VMs, Azure SQL, and other resources on a schedule so it only gets billed for storage when not in use, auto-scaling DTU and other resources based on periods of known peak usage (like month end), etc.
One of the projects I work on is a data mart that ingests daily utilization and cost data for Azure resources, so operations and accounting can keep tabs on it.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
Viewing 15 posts - 1 through 15 (of 16 total)
You must be logged in to reply to this topic. Login to reply