3 ms·

You should've migrated many months ago, if a cloud provider forces you to build your own networking or registry, you shouldn't use that cloud provider.

politelemon 3y ago
That was the first thing that struck me, the 'workarounds' stagger belief, but they seem to be casually dropped in (?). If I were in a situation where my company was contemplating implementing building our own registry/network stack, then the benefits of using a cloud provider are gone, and I would have considered moving to another provider... not saying "I can fix him". This feels like a sunken cost perhaps that is the right term.
- mrj 3y ago
  I would bet that they were thinking about colocating and would need to have secured intra-service communication anyhow. In Google this is transparent but at a (probably yet identified facility) it'd be up to them to provide.
  - justjake 3y ago
    (Blogpost Author) Yup. We've been thinking about colocation for a while, so we've just been building these up. Basically all that's left is to make our volume storage bulletproof. We'll do that as we're moving stateless workloads to bare metal early next year, and ideally be off GCP EOY latest
supriyo-biswas 3y ago
Well for folks building out cloud infrastructure, building your own networking stack and registry is a good way to achieve platform independence, without which you'll be left at a disadvantage and vulnerable to the whims of cloud providers who may or may not extend volume discounts, thus indirectly harming your ability to compete.
- chrisandchris 3y ago
  Doesn't the requirement of "building your own networking stack" outcompete with "just colocate"? I would assume that the skills required for building your own network ist just as high as hosting your own hardware. But I don't have any data point, so just a wild guess.
- wmf 3y ago
  An over-overlay is almost never the right solution. If you want platform-independent networking you should use an API shim layer that configures the underlying VPCs the way you want.

politelemon 3y ago

That was the first thing that struck me, the 'workarounds' stagger belief, but they seem to be casually dropped in (?). If I were in a situation where my company was contemplating implementing building our own registry/network stack, then the benefits of using a cloud provider are gone, and I would have considered moving to another provider... not saying "I can fix him". This feels like a sunken cost perhaps that is the right term.

mrj 3y ago
I would bet that they were thinking about colocating and would need to have secured intra-service communication anyhow. In Google this is transparent but at a (probably yet identified facility) it'd be up to them to provide.
- justjake 3y ago
  (Blogpost Author) Yup. We've been thinking about colocation for a while, so we've just been building these up. Basically all that's left is to make our volume storage bulletproof. We'll do that as we're moving stateless workloads to bare metal early next year, and ideally be off GCP EOY latest

supriyo-biswas 3y ago

Well for folks building out cloud infrastructure, building your own networking stack and registry is a good way to achieve platform independence, without which you'll be left at a disadvantage and vulnerable to the whims of cloud providers who may or may not extend volume discounts, thus indirectly harming your ability to compete.

chrisandchris 3y ago
Doesn't the requirement of "building your own networking stack" outcompete with "just colocate"? I would assume that the skills required for building your own network ist just as high as hosting your own hardware. But I don't have any data point, so just a wild guess.
wmf 3y ago
An over-overlay is almost never the right solution. If you want platform-independent networking you should use an API shim layer that configures the underlying VPCs the way you want.