I love that they point out the massive added benefit of using your own products.
Dealing with software you kind of always see if the software is actually used by developers.
Too many times I'm pained with request that take for ever, asset management tools that just don't click or just mondboggling APIs that need 3 other APIs to function properly.
I think using your own products and iteration over internal feedback early and often is the way to a brilliant product and such cost efficiencies are a nice byproduct.
> Establishing AWS identity outside of AWS is a headache, and often comes with a chicken-and-egg problem of needing to possess a secret to show you are allowed to get a secret.
> For most stuff here, we can rely on the fact that every connection over Tailscale is encrypted and authenticated to an identity
Mm, okay, but you still have the chicken and egg problem of distributing the creds to join your tailnet.
Isn’t it not that different than distributing aws creds to access secrets manager?
You can use Instance credentials within AWS to avoid chicken and egg. Your instance short-lived creds are strongly tied to the instance identity itself.
yeah, I wonder if there's room for a different networking abstraction that could address most of complex orgs networking issues, I, for sure, don't think that we should still think about cidr range limitations when making networks, for ex.
that said, I'm not sure the tailscale approach scales well in typical modern corporate environments, where you've got a small army of junior devops often overlooking security or cost implications (don't forget about egress costs!).
the traditional, meticulous approach of segmenting networks into VPCs, subnets, etc., with careful planning of auth, firewall rules and routes, helps limit the blast radius of mistakes.
tailscale's networking & security model feels simple and flat, which is great for usability, but it lacks the comforting "defense in depth" that will be asked in most big corps.
I love that they point out the massive added benefit of using your own products.
Dealing with software you kind of always see if the software is actually used by developers.
Too many times I'm pained with request that take for ever, asset management tools that just don't click or just mondboggling APIs that need 3 other APIs to function properly.
I think using your own products and iteration over internal feedback early and often is the way to a brilliant product and such cost efficiencies are a nice byproduct.
> Establishing AWS identity outside of AWS is a headache, and often comes with a chicken-and-egg problem of needing to possess a secret to show you are allowed to get a secret.
> For most stuff here, we can rely on the fact that every connection over Tailscale is encrypted and authenticated to an identity
Mm, okay, but you still have the chicken and egg problem of distributing the creds to join your tailnet.
Isn’t it not that different than distributing aws creds to access secrets manager?
You can use Instance credentials within AWS to avoid chicken and egg. Your instance short-lived creds are strongly tied to the instance identity itself.
Yes, that’s what I do. The way I read the tailscale post it suggested a magical way to circumvent this credentials bootstrapping dance
yeah, I wonder if there's room for a different networking abstraction that could address most of complex orgs networking issues, I, for sure, don't think that we should still think about cidr range limitations when making networks, for ex.
that said, I'm not sure the tailscale approach scales well in typical modern corporate environments, where you've got a small army of junior devops often overlooking security or cost implications (don't forget about egress costs!).
the traditional, meticulous approach of segmenting networks into VPCs, subnets, etc., with careful planning of auth, firewall rules and routes, helps limit the blast radius of mistakes.
tailscale's networking & security model feels simple and flat, which is great for usability, but it lacks the comforting "defense in depth" that will be asked in most big corps.