He doesn’t anymore. I’m pretty sure he justified it by saying that it makes you slower because you end up with a habit of waiting for it to tell you the wrong answer.
Yes I get what your saying, but in this analogy the screws are destroying the planet, and also hallucinate enough to be completely untrustworthy as fastenings.
I agree. The issue is people are not comparing this to a manual lookup. they are comparing it to another person who is just as likely to hallucinate/misremember things.
I hated Rails so much. It kept changing tech stack for every minor version patch. Last I used it, I remember Propshaft was supposed to be the new default.
Unix has been my favorite dev platform since I first used it 30 years ago. I’m typing this on a Mac, which also does just fine. But I’m happiest on my Linux box. Even WSL was OK, but the bloat of Windows overpowers the hardware. My Linux daily driver is a 9-year-old laptop that couldn’t handle Windows any longer.
There are use cases for the cloud. I put e-mail in the cloud- ain’t nobody got time to deal with providing reliable SMTP or Exchange while keeping spam out. If you have a web app that needs to scale quickly, cloud’s the way. If you’re a startup with limited capital and you don’t want to blow it on a bunch of servers when you’re not sure if you’ll survive more than a year or so, cloud’s the way.
But Cloud ISN’T the end-all answer for everything.
If you have a predictable workload, especially one that relies on more expensive cloud services, de-clouding can save you a bundle. Buying hardware can be cheaper than renting it, if only because (think about it) the cloud provider has to buy the same hardware and rent it to you AND make a profit. If you’re going to be around a while, and you expect to use a piece of hardware for its full service life, that makes a lot of sense.
As long as you realize that the “cloud” is someone else’s computer, it is a very viable way of hosting your service. However as your service grows all those micro services that your cloud provider charges you for will grow as well. Eventually you’ll get to the point where “data transfer” costs begins to make up >50% of your total cloud spend. At that point (or ideally before) you should have a plan to stop expanding your cloud footprint, because that cost grows geometrically with the size of your cloud data and the number of cloud functions you are using on your data.
Remember Data has Weight. If you don’t understand what that means, you aren’t ready to make a cost comparison between cloud-hosting and data center hosting.
Relevant passage: “While there are some additional other costs associated with the extra servers, it’s relative peanuts in the grand scheme (our ops team stayed the same, for example)” (emphasys mine)
Either the team had free time and weren’t being used to capacity, employees aren’t doing continuing education during work anymore, or they are being overworked. You don’t just magically take on scope and not have labor hours shift at a bare minimum.
I refuse to take anyone at face value when they say they are using physical hardware, setting up automation, and running support on all of that and the labor hours are described as peanuts.
I also wonder what they are doing for security and data privacy.
Exiting cloud being useful seems to be a very narrow use case.
For one, you have to be at a large enough scale where buying and hosting your own infra is feasible and cheaper.
Second, you have to give up the ability to almost instantly scale up or provision hardware in response to traffic or other events. (which is very common at scale)
Maybe his use case happens to be that very narrow case, but this isn’t something I would take as general advice.
Your last paragraph is why we’ve heavily used the cloud here in rural Canada for years.
Monitoring data is much easier to push into the cloud and read from there than it is hope for a reliable connection to a farm or rural plant.
Self-hosted services need to be cloud hosted for uptime and because it was getting ever harder to get a routed IPv4 address from any provider. IPv6 is nice to finally have, but Starlink is the only provider at all supporting it and it’s only been a few months at that. Their prefixes change constantly too, come on guys get your shit together.
Even basic remote access systems require a VPS or VPN cloud service as you always need both ends to punch out through layers of CGNAT. Now we can finally have one end available through IPv6 but the remote user is often trying to use a IPv4 CGNAT network to connect… So you still need something in the cloud to punch holes.
Can’t believe it’s been over 20 years for the IPv6 rollout
I’m still trying to figure out how to use Docker with an unstable prefix (hey Docker, this is as much your problem as the ISPs, honestly) as any of the v6NAT solutions I’ve found that enable the same full containerization available on IPv4 all require you feed the Docker daemon a fixed prefix on startup. Frustrating.
I’m also tired of reading posts about v6NAT being irrelevant because half of the point of containers is the interchangeability, Docker containers aren’t supposed to be routable unless you intentionally put them on the host network! Docker just needs to work the same on v4 and v6!
Tor as a hole puncher is an intriguing idea but I don’t think I would use it for something customer facing… Too many moving parts. We like to use Wireguard and a tiny cloud VPS instance when someone needs to punch into an unreliable network around here.
That’s the thing, ‘cloud’ is just another tool in your toolbox. It’s the right tool for some workloads and the wrong one for others. The fact they’ve shifted the work to their own servers and kept the ops team suggests it was the wrong sort of workload to be in the cloud in the first place.
For a while there was an obsession with moving everything to the cloud, and that was always going to be an expensive mistake in a number of different ways. Hopefully, as the hype dies down more nuanced decisions will be made. There’s a whole gamut of options between all in the cloud and all in the data centre, and when people jump straight from one end to the other I’m put in mind of Hamlet’s quote “There are more things in heaven and earth, Horatio, / Than are dreamt of in your philosophy.” Understand your workload, understand your business’ future plans and their needs, and then make a plan, considering all the tools at your disposal.
I hate the obsession to move to the cloud and the obsession towards serverless or functions.
Functions are stupid and crazy for anything that is actually used often.
For small utilities, they make a ton of sense, but next time I see an app with millions of requests per day using functions, I’m going to lose my mind.
Years ago I was the senior techie in designing and implementing distributed high performance server systems and what you reminded me of just made my blood start to boil… :/
If there’s anything that 3 decades in Tech have taught me is that fad-following commonly rules it, even with the supposedly logical (but not really) techies.
Cloud storage and cloud computing became a fad about a decade ago (I still remember the hype repeated by people who had never actually designed distruted systems) so there were tons of people jumping headfirst without a plan into it for the hype and the seemingly cheaper price (if you didn’t think your needs and future evolution through) even though it wasn’t the best choice for them.
No doubt well see the same kind of fad-following over making-sense-for-us thing with the latest hype-train: AI.
That’s the thing, ‘cloud’ is just another tool in your toolbox. It’s the right tool for some workloads and the wrong one for others. The fact they’ve shifted the work to their own servers and kept the ops team suggests it was the wrong sort of workload to be in the cloud in the first place.
For a while there was an obsession with moving everything to the cloud, and that was always going to be an expensive mistake in a number of different ways. Hopefully, as the hype dies down more nuanced decisions will be made. There’s a whole gamut of options between all in the cloud and all in the data centre, and when people jump straight from one end to the other I’m put in mind of Hamlet’s quote “There are more things in heaven and earth, Horatio, / Than are dreamt of in your philosophy.” Understand your workload, understand your business’ future plans and their needs, and then make a plan, considering all the tools at your disposal.
What always kept me off the “cloud” (other people’s computers) is not only giving up my data but giving up control on what I spend. Corporations lure you in with flashy promises and low prices, then usually over time the service gets worse the prices go higher and higher. I’m sure the cloud hosting corporations are good at pricing their services very high but not quite high enough to make most customers cancel.
Lock-in is quite an old strategy in Tech (back in the day Microsoft’s dominance was built on it) and apparently every new generation needs to learn their lesson…
Hopefully, they place their servers at 2x the historical peak floodpoint. Or set up standby zones in different geographies in case there’s a power or network outage.
So you say that if you don’t make an additional investment in backup infrastructure your data is at risk… Sounds pretty similar to self-hosting, doesn’t it?
Shocking, right? (/s) You don’t get what you do not pay for. OVH also offers private cloud hosting, basically managed servers in a cloud setup and normal hosting options. I have no idea, what the datacenter was primarily used for.
That was a data center, not a cloud. The sort of place they are moving to from the cloud.
With a cloud solution, you make sure to use services that are redundant. AWS and Azure build each region (geographical location) with **multiple **interconnected independent data centers (availability zones). High durability is one of the strong use cases for public clouds.
Having your compute in “the cloud” doesn’t remove the need for a good backup strategy, it just changes how it works. Yes, disaster recover for natural disasters should be easier (OHV’s fire showed that this may not always be true). But, that doesn’t cover cases like ransomware, insider threats, data mistakes or any other case where data is corrupted/modified by mistake. You still need a plan for these cases. And cloud based backups actually make a lot of sense.
But, just because you put your backups in the cloud, doesn’t mean that your compute should be there as well. There is an advantage that your Time to Recovery is likely lower with both backups and compute in the same cloud. But, is that worth the ongoing cost of running your compute in the cloud? That needs to be considered separately. You also need to consider the cost of running on-prem versus in the cloud. If you have fairly predictable, static loads, it may be cheaper to buy and run servers yourself. For hard to predict, elastic loads, cloud may make more financial sense.
As others have said before, there was a period where companies were just going to the cloud for the sole reason that it was the popular thing to do. For some it actually made financial sense. For some, it didn’t. The OP’s article seems to be the latter.
The cloud isn’t just for storage or compute. There are a number of managed services that let you build a full application by snapping together lego building blocks.
For example, pop together a REST API handler, an auth service, a few functions-as-a-service, a database, and a storage service. Then add a static website server. Throw a CDN in front. You got yourself a dynamic application service that can be accessed globally for a few pennies and can scale up and down without you doing anything. Add multi-zone support and auto-DNS failover and you’ve got a production quality scalable, resilient back-end, for both web and mobile. When it’s not being used, it costs very little and when it goes big, hopefully it means you’re doing well. Wrap it all in an infrastructures-as-code script and you can bring all this up in 30m.
To host all that in-house, you would have to buy a lot of equipment, stage it, manage it, add cooling, electricity, security patches, upgrades, security, etc. Now you have part of your business just doing all this instead of focusing on what you do best. I won’t bother going into the tax implications of capex vs opex.
This, is what the cloud sales people call ‘undifferentiated heavy lifting.’ There are reasons to have on-prem hardware. For a lot of applications though, it makes more sense to let someone else take care of all that infrastructure cruft.
There are also many organizations that wish they has some local backups after their cloud service providers lost all their data. Lesson to learn: Backup properly with offline storage. Tape in a safe, maybe even off-site, etc.
world.hey.com
Hot