91–100 of 114 posts
There's a Github Pages FAQ describing why it was made and how it fits with other solutions: https://firecracker-microvm.github.io/ and a high-level design document about how it works https://github.com/firecracker-microvm/firecracker/blob/mast...
Clear containers (now called kata containers) did this more than three years ago, with similar performance numbers (sub 200 ms boot times). It is frustrating, but not surprising, to see the same regurgitated solution receive this much excitement. The firecracker documentation also does not mention the similarity with prior work, oh well. [Not affiliated with Intel in any way---just a long-time proponent of the clear…
The FAQs on the Firecracker website[1] specifically address the difference between Firecracker and Kata Containers. The main thrust being that they have decided not to use QEMU and have instead chosen a much more minimal "cloud-native" oriented approach that deliberately abandons certain features in order to gain greater security, efficiency and agility going forward. They also decided to implement it in Rust. Based…
Earlier quoted context omitted.
Doesn't a Kubernetes master on Fargate cost a significantly non-zero amount of money? Pretty sure it does.
Only dev instances should see zero traffic, any production site will have > 0 load at all times.
- If we're talking about a business that provides a service to local companies, there are quite a few hours during the week where everyone is either asleep or enjoying their weekend. Not every company has millions of users spread across every time zone; some companies provide a niche service to a small number of high paying users.
- Lots of developers have small hobby projects that are inactive for most of the day/week.
Scale to zero can be convenient, but it's not usually a make-or-break thing.
Earlier quoted context omitted.
The FAQs on the Firecracker website[1] specifically address the difference between Firecracker and Kata Containers. The main thrust being that they have decided not to use QEMU and have instead chosen a much more minimal "cloud-native" oriented approach that deliberately abandons certain features in order to gain greater security, efficiency and agility going forward. They also decided to implement it in Rust. Based…
OK I had missed the kata containers blurb in the FAQ, thanks for pointing it out. In fact the tweets make my point: we are all so blinded by new shiny releases that we forget their highly incremental nature.
I think what is impressive about Firecracker is that they have chosen to reuse a lot of the right things (Linux/KVM/Rust) while also taking a new approach and rethinking important assumptions (No BIOS, no pass-thru, no legacy support, minimal device support).
In my opinion the Firecracker FAQs give sufficient mention to parallel projects and tools they have built on like Kata Containers, QEMU and crosvm. The developers certainly seem open to collaboration with those communities.
AWS doesn't have much of a track record in terms of leading an Open Source projects so some skepticism is understandable, but I think what we have seen so far is a very good start.
I really hope this helps with the cold start times on Lambda. We were currently looking heavily into moving our API from Lambda to EKS, but if this impacts cold start times, I think we will look at how it ends up looking like in practice.
Earlier quoted context omitted.
OK I had missed the kata containers blurb in the FAQ, thanks for pointing it out. In fact the tweets make my point: we are all so blinded by new shiny releases that we forget their highly incremental nature.
Sure, there are going to be some people that are excited by the fact that something seems new or just because it is written in Rust, but jessfraz and bcantrill certainly don't fall into those categories. They have a lot of experience with Operating Systems, VMs and containerization and I don't get the impression that they are eaisily impressed by shiny things. Note that they all work for or worked for AWS competitors…
Earlier quoted context omitted.
Sure, there are going to be some people that are excited by the fact that something seems new or just because it is written in Rust, but jessfraz and bcantrill certainly don't fall into those categories. They have a lot of experience with Operating Systems, VMs and containerization and I don't get the impression that they are eaisily impressed by shiny things. Note that they all work for or worked for AWS competitors…
These days, I would expect bcantrill to be excited by something written in Rust :)
Earlier quoted context omitted.
These days, I would expect bcantrill to be excited by something written in Rust :)
Hey now -- I'm not quite that easily impressed! ;) This is a problem domain that I have suffered in[1] -- and we have recently moved from KVM to bhyve[2] for several of the same reasons that motivated Firecracker. Not that it hurt that it was in Rust, of course... ;) [1] https://www.youtube.com/watch?v=cwAfJywzk8o [2] http://bhyvecon.org/bhyvecon2018-Gwydir.pdf
I am excited that everyone seems very excited.
Earlier quoted context omitted.
Heh. Truthfully, what I'm most excited about right now is being able to start a worker in less time than it takes to make an internet request. When you can do that you get magical autoscaling and it becomes just as cheap to run it in hundreds of places as one. As long has you have to invest ~100ms of CPU to get one of these VMs running I'm not sure it will have quite the same economics.
Yeah, jokes aside I simply don’t think it makes sense to run full processes on the edge. Not yet, anyway. Script isolates makes a lot of sense with current hardware limitations, but full processes at the edge are coming sooner or later.
Qemu is exciting technology and has paved the way for all kinds of interesting layers. So, creating a slimmed down improvement that really makes it faster and provides a new lambda-ish execution context is great.
I'm sure Amazon cares about that. I'm sure people doing millions of lambda calls a day care about that.
But, if I'm an entrepreneur thinking about building something entirely new, is there something I'm missing about this that would make me want to consider it?
Lambda and Firebase Functions are exciting partially because they break services into easy to deploy chunks. And, perhaps more importantly, easy things to reason about.
But that's not the big deal: the integration with storage, events, and everything else in AWS (or Firebase) is what really makes it shine. It's all about the integration.
When I read this documentation, I'm left wondering whether I want to write something that uses the REST API to manage thousands of micro vms. That seems like extra work that Amazon should do, not me.
Am I missing something important here? Surely Amazon will integrate this solution somewhat soon and connect it to all the fun pieces of AWS, but the fact that they didn't consider or mention it makes me think it is something I should not consider now.