Hacker News new | comments | show | ask | jobs | submit login

As a counter argument: very few teams at Google run on dedicated machines. Those that do are enormous, both in the scale of their infrastructure and in their team sizes. I'm not saying always go with a cloud provider, I'm reiterating that you'd better be certain you need to.



Interesting, presumably they're very well informed and they obviously feel that Google's cloud offerings are the best way to go.

If I may ask a few questions:

- Are they charged the same as external customers or do they get a 'wholesale' rate?

- As internal clients, do they run under the same conditions as external clients? Or is there a shared internal server pool that they use?

- Do they get any say in the hardware or low-level configuration of the systems they use? (ie. if someone needs ultra low latency or more storage, can they just ask Joe down the hall for a machine on a more lightly loaded network, or with bunch more RAM, for the week?)

- Do they have the same type of performance constraints as the ones encountered by gitlab?

I feel like most of the reason to use cloud services is when you have little idea what your actual requirements are, and need the ability to scale fast in both directions. Once you're established and have a fairly predictable workload, it makes more sense to move your hosting in-house.


The Google teams that he's referring to probably don't run on Google Cloud Platform, and rather run on Google's internal infrastructure that GCP is built upon. So most of your questions may not apply. However, his points about cloud infrastructure are still valid.


If you're right, then Google teams using internal Google server infrastructure is literally Google rolling their own.


He technically only said they don't run on dedicated machines, not that they run on GCP. My guess would be Google has some sort of internal system that probably uses a bunch of the same software but is technically not GCP.


This is mostly speculation base don having read this http://shop.oreilly.com/product/0636920041528.do

Hopefully someone who actually knows what theyre talking about will be along shortly!

> Are they charged the same as external customers or do they get a 'wholesale' rate?

Id be quite surprised if internal customers are charged a markup. Presumably the whole point in operating an internal service is that you lower the cost as much as possible for your internal customers.

> As internal clients, do they run under the same conditions as external clients? Or is there a shared internal server pool that they use?

From the above book, it seems that the hardware is largely abstracted away so most services aren't really aware of servers. I assume there's some separation between internal and external customers, but at a guess that'd largely be because of the external facing services being forks of existing internal tools that have been untangled from other internal services.

> Do they get any say in the hardware or low-level configuration of the systems they use? (ie. if someone needs ultra low latency or more storage, can they just ask Joe down the hall for a machine on a more lightly loaded network, or with bunch more RAM, for the week?)

As above, the hardware is largely abstracted away. From memory, teams usually say "we think we need ~x hrs of cpu/day, y Gbps of network,..." then there's some very clever scheduling that goes on to fit all the services on to the available hardware. There's a really good chapter on this in the above book.

> Do they have the same type of performance constraints as the ones encountered by gitlab?

Presumably it depends entirely on the software being written.


But some workloads get all the priority while others get zero/idle priority. Not true in public cloud.


Multitenancy is a large part of what makes public cloud providers profitable, but they all understand the need to isolate customer resources as much as possible.


Using a resource abstraction layer such as mesos can alleviate this downside by consolidating many of your workloads onto a pool of large dedicated machines.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: