[dsr_]

The cloud isn't a money-saving tactic. It enables you to test demand for a service for a very low absolute cost. Spin up a tiny machine for $60/year? And you can pay for it by the month, or the hour? That's great. You can find out if anybody is going to buy your thing at all. You can probably get to ramen-profitable.

As soon as you can confidently predict sufficient demand, the economically rational decision is to hire a good ops team and run real hardware. But to do so, you need to either have money or get money - and the costs of cloud service are zooming up, potentially leaving you without the margin to invest.

The question is what that level of sufficient demand is.

[deegles]

> Hire a good ops team

I feel this is one of those "easier said than done" statements...

[tw04]

I'd argue that's only easier said than done if you insist on doing a roll-your-own open-source science project. If you default to established enterprise vendors, finding ops people isn't THAT difficult.

[tobltobs]

But then the cloud might be cheaper again.

[tw04]

It isn't, and it's not even close. Unless you're running at less than 40% efficiency the cloud is more expensive for infrastructure running 24/7. If you're a shop with 1 server and no IT guy? Sure, probably makes sense to use the cloud - although I'd argue you'd be better off with managed hosting so you actually have a number to call if something breaks.

An organization of even medium size? Not a chance.

[dragonwriter]

> Unless you're running at less than 40% efficiency the cloud is more expensive for infrastructure running 24/7.

Sure, paying extra for a dynamically scalable service is inefficient if your resource needs are flat 24/7/365, but is that realistically the case?

(OTOH, one must not forget that there is a cost to engineer systems to take advantage of dynamic scaling to minimize costs while meeting requirements.)

[hueving]

>Sure, paying extra for a dynamically scalable service is inefficient if your resource needs are flat 24/7/365, but is that realistically the case?

Yes, the vast majority of apps are not 12 factor architectures designed for scaling so nodes can't be brought online and killed at the flip of a switch.

[tw04]

In most enterprises yes. They've got a consistent flat workload 90% of the time. I'm willing to bet gitlab is the exact same way other than a tiny portion of the environment. And, as you mentioned, writing an app from scratch to take advantage of instant scaling is extremely difficult, and sometimes impossible depending on what statefulness is required.

[dragonwriter]

Established enterprise vendors are increasingly promoting cloud offerings, and their pricing reflects that.

[zip1234]

Also can be very expensive. If another IT devops type costs 100k per year. How much will that buy in cloud services and time saved?

[qaq]

150 TB/month of data transfer on AWS will cost you 15k/ month the same thing on dedicated provider will be 500/month. And so on.

[cstejerean]

That's about the fully loaded cost of one engineer, and you may easily need multiple additional people to run your own hardware instead of using AWS.

[qaq]

That's fairly modest traffic and does not include cost difference for the compute and persistence layers. In case of GitLab their dev and ops office is in Ukraine so that difference on traffic cost alone would pay for 3 good ops people.

[dragonwriter]

> The cloud isn't a money-saving tactic.

Most tactics in business are money-saving tactics, and cloud is clearly one: dynamic scaling means only spending now for what you need now rather than spending now based on anticipated future need, and someone-else's-server means economies of scale in ops.

[polishTar]

I'd also argue that "sufficient demand" is a threshold that's been rising very fast over the last couple of years and likely to continue doing so.

This also explains why older tech companies disproportionately use their own hardware, even those that aren't all that big. They all made that decision at a time when it made sense and the switching cost is sufficiently high to prevent them from turning back now.

I doubt there are many rational cases now for newer companies to use anything but the cloud. Even at the scale of Snapchat (>3B$ infrastructure spend over next 5 years) and Netflix, it appears the public cloud is still the rational choice.

[tbrowbdidnso]

You should remember that the early cloud unicorns are getting super low rates for their name clout as well. Their discounts are passed as extra costs to everyone else.

So while it may be worthwhile if you're huge enough to get a big discount, that doesn't mean it applies to small or medium size companies

[emodendroket]

> The cloud isn't a money-saving tactic.

If it requires no or a smaller ops team then it seems like it might be.

[gpapilion]

Generally you're hitting the cheap part of your ops team. The rack and stack, and dc technicians. You start seeing the real savings when you move up to using higher services like managed databases, and analytics engines.

[rayvd]

I think that's right. We tend to see fragmentation w/ our hybrid approach. Teams doing DevOps type stuff with VMware/vRA on internal hardware and also on AWS/Azure. "Customers" of each environment also tend to be different so priority conflicts arise.

Could be solved by more staffing, I suppose...

[emodendroket]

Anecdotally, I used to be on a two-man team and switching to Azure made life insanely better.

[stephenr]

> If it requires no or a smaller ops team then it seems like it might be.

If you needed a team to manage it before, you still need Ops with "the cloud"

[morgante]

> and the costs of cloud service are zooming up, potentially leaving you without the margin to invest.

What do you mean by this, because it sounds like a straight up lie?

Amazon and Google are in an ongoing price war and cut costs regularly.

[hueving]

>What do you mean by this, because it sounds like a straight up lie?

There is no economy of scale with the cloud. As you scale up your service, Amazon/Google happily scale your bill right up with it. When you roll your own datacenter, things get much cheaper per unit (bandwidth, storage, etc) as you get larger.

[tbrowbdidnso]

Possibly outgoing bandwidth. These costs are directly proportional to traffic and regularly 20-30x the unmetered rate for a colocated box

[morgante]

Yes, cloud bandwidth is expensive. I don't disagree with that. But it's not increasing in price.

Obviously if you're growing your costs will grow, but that's basically a tautology. Bare metal costs also rise as you grow.

[dsr_]

Will you stop calling me a liar if I correct that from "the costs" to "your costs"? I am assuming that you are growing, and I think there's a provable assumption that for high levels of service, hiring someone else to do it is more expensive than in-house.

[morgante]

That's an entirely different statement than your original one. Saying "the costs of cloud service are zooming up" disingenuously makes it sound like the price of cloud services are going up.

[dsr_]

Thanks for the charitable interpretation of my words.

[user5994461]

> hiring someone else to do it is more expensive than in-house.

Except you're gonna need between 10 and 100 people to recreate the service in-house, not just one.

Trying to re-do something from scratch in-house is always more expensive than just buying the product.

[majewsky]

I get the sentiment, but it really depends: For some services, it's very true. For other services, careful problem analysis will show that you only need one or two features from the full package, which then can be replaced by a very small shell script.