5 ms·

> We take Docker-type containers from users and transmogrify them into Firecracker micro-VMs What is the relationship with micro kernels? Is the feature availa

by spockz 6y ago

> We take Docker-type containers from users and transmogrify them into Firecracker micro-VMs What is the relationship with micro kernels? Is the feature available separate from the deployment/hosting?

tptacek 6y ago
None. A Firecracker micro-vm is just a very small, very quick-to-start-up VM. It uses KVM, eliminates the BIOS, and implements only the minimal devices needed to boot and run server Linux. Amazon built the project for Lambda and Fargate. More about it here: https://fly.io/blog/sandboxing-and-workload-isolation/ https://fly.io/blog/sandboxing-and-workload-isolation/
- atonse 6y ago
  Is this sort of like what MS is doing with Windows Subsystem for Linux, where they're able to "boot" that Linux in mere seconds? By the way, as an elixir developer Fly.io looks extremely cool. But my (mostly public sector) customers want to hear something similar to the words "AWS" when asked about hosting – so is it running on top of AWS or Azure or GCP? (instances look like they may be GCP, which is fine too).
  - tptacek 6y ago
    It runs on our own hardware. There's no AWS or GCP beneath it.
    - atonse 6y ago
      Ok thanks – this has been one of the rare things that some of those clients seem to care about (whether they're right or wrong, or rather, more conservative). I had another question – this seems similar to what Hashicorp is doing with Boundary. Have you looked at Boundary and how this potentially compares with that, from an architecture standpoint? Of course there are parts of this that are bespoke to your infrastructure, but I'm just more curious from a nerdy-aspect of it because we're evaluating boundary as a replacement to our current setup (Wireguard bastion host), for all the other benefits like auth and logging.
      - tptacek 6y ago
        There is a lot of Hashi in our stack already; we orchestrate with Nomad (we have our own Firecracker task driver), we backend our certificate system --- which is awesome, certificates just work for Fly apps --- with Vault, and we use a lot of Consul. I think our take on end-user access management is lower-level than what Boundary is trying to do. Boundary, as I understand it, sees the world the way an IdP RP does, mostly in terms of bearer tokens. We see stuff as infrastructure; a static configuration on an EC2 instance or a CI container; "just Unix". If we weren't building a PAAS, we'd probably lean much more strongly towards Boundary's way of looking at things. As well, we care about minimizing and understanding as much of the code we expose as possible. For all the talking I've done about SSH here, the serverside of this feature is just a couple hundred lines of code; it is dwarfed by the clientside code. I couldn't say that about a Hashi product. (HashiCorp could though!)
        atonse 6y ago
        Thanks. I actually feel like if Boundary had an experience more like Tailscale does, but on top of their stack (wireguard network, secrets in vault, server/service discovery in consul, etc), that would be really powerful and a no-brainer for those of us who also use a lot of Hashicorp products. But I'm still trying to fully understand what they're doing with Boundary. The abstractions just feel a bit off to me unlike other Hashicorp products (it's odd to me that you have to tell boundary to treat a database connection differently rather than just giving me any TCP or UDP access). But their team does great work and has elegant designs so I trust it's more likely that the lightbulb just hasn't gone off in my head yet with Boundary.
        jefferai 6y ago
        TCP targets (the only kind currently in Boundary) actually work with _any_ TCP connection. The `boundary connect <subcommand>` bits are just some CLI syntactic sugar around the main `boundary connect` command -- which works all by itself! -- that fill in IP/port and other information for various clients. (This has been an unfortunate bit of confusion for many people trying Boundary out. We'll take another look at how we can make this more obvious in our getting started/learn docs.) It's all TCP though. Eventually we'll do more interesting things with specific protocol types.

by spockz 6y ago

tptacek 6y ago

None. A Firecracker micro-vm is just a very small, very quick-to-start-up VM. It uses KVM, eliminates the BIOS, and implements only the minimal devices needed to boot and run server Linux. Amazon built the project for Lambda and Fargate. More about it here: https://fly.io/blog/sandboxing-and-workload-isolation/ https://fly.io/blog/sandboxing-and-workload-isolation/

atonse 6y ago
Is this sort of like what MS is doing with Windows Subsystem for Linux, where they're able to "boot" that Linux in mere seconds? By the way, as an elixir developer Fly.io looks extremely cool. But my (mostly public sector) customers want to hear something similar to the words "AWS" when asked about hosting – so is it running on top of AWS or Azure or GCP? (instances look like they may be GCP, which is fine too).
- tptacek 6y ago
  It runs on our own hardware. There's no AWS or GCP beneath it.
  - atonse 6y ago
    Ok thanks – this has been one of the rare things that some of those clients seem to care about (whether they're right or wrong, or rather, more conservative). I had another question – this seems similar to what Hashicorp is doing with Boundary. Have you looked at Boundary and how this potentially compares with that, from an architecture standpoint? Of course there are parts of this that are bespoke to your infrastructure, but I'm just more curious from a nerdy-aspect of it because we're evaluating boundary as a replacement to our current setup (Wireguard bastion host), for all the other benefits like auth and logging.
    - tptacek 6y ago
      There is a lot of Hashi in our stack already; we orchestrate with Nomad (we have our own Firecracker task driver), we backend our certificate system --- which is awesome, certificates just work for Fly apps --- with Vault, and we use a lot of Consul. I think our take on end-user access management is lower-level than what Boundary is trying to do. Boundary, as I understand it, sees the world the way an IdP RP does, mostly in terms of bearer tokens. We see stuff as infrastructure; a static configuration on an EC2 instance or a CI container; "just Unix". If we weren't building a PAAS, we'd probably lean much more strongly towards Boundary's way of looking at things. As well, we care about minimizing and understanding as much of the code we expose as possible. For all the talking I've done about SSH here, the serverside of this feature is just a couple hundred lines of code; it is dwarfed by the clientside code. I couldn't say that about a Hashi product. (HashiCorp could though!)
      - atonse 6y ago
        Thanks. I actually feel like if Boundary had an experience more like Tailscale does, but on top of their stack (wireguard network, secrets in vault, server/service discovery in consul, etc), that would be really powerful and a no-brainer for those of us who also use a lot of Hashicorp products. But I'm still trying to fully understand what they're doing with Boundary. The abstractions just feel a bit off to me unlike other Hashicorp products (it's odd to me that you have to tell boundary to treat a database connection differently rather than just giving me any TCP or UDP access). But their team does great work and has elegant designs so I trust it's more likely that the lightbulb just hasn't gone off in my head yet with Boundary.
        jefferai 6y ago
        TCP targets (the only kind currently in Boundary) actually work with _any_ TCP connection. The `boundary connect <subcommand>` bits are just some CLI syntactic sugar around the main `boundary connect` command -- which works all by itself! -- that fill in IP/port and other information for various clients. (This has been an unfortunate bit of confusion for many people trying Boundary out. We'll take another look at how we can make this more obvious in our getting started/learn docs.) It's all TCP though. Eventually we'll do more interesting things with specific protocol types.