Unikraft Launches KraftCloud: Never Pay for Idle Again
82 points| nderjung | 1 year ago
We have built kraft.cloud, a millisecond cloud platform, where apps and services cold start, scale to zero and autoscale in milliseconds, ensuring you never pay for idle, can efficiently cope with traffic peaks, and don’t have to deal with complex cold start issues.
The platform (and we) come from research in the area of lightweight virtualization — trying to ask the question of how efficient cloud platforms could (or should) be while still retaining strong, hardware-level isolation. KraftCloud is the result of this research followed by years of building the Unikraft open source project (www.unikraft.org).
KraftCloud is based on unikernels, extremely specialized virtual machines, built on top of the Linux-API compatible Unikraft project. If you’ve heard of unikernels in the past, you’ve likely come across properties like millisecond cold start, small memory consumption, and small TCB, to name a few. You may have also heard of downsides like difficulty using them, debugging them, monitoring them or deploying them in the cloud — we’ve been hard at work tackling these issues.
KraftCloud leverages Unikraft unikernels, but also comes with a custom-built controller that can be reactive in millisecond scales and can scale to thousands of instances on a single server. We also have integrations with Dockerfiles, Terraform and Kubernetes, and the ability to deploy within hyperscaler infra. The end result is a platform where
- Cold starts take milliseconds (e.g., NGINX boots in 15ms)
- Scale to Zero (and scale back up) also takes milliseconds
- Autoscale takes milliseconds so you can transparently cope with fast peaks
- We can put 1000s of instances on a single server, reducing cost and carbon footprint
We’re in closed beta at the moment and are actively handing (free) access tokens via the sign up form here: http://kraft.cloud/signup
We would really appreciate as much feedback as humanly possible: what you like, what you don’t like, what isn’t clear, what we’re missing, what’s broken, etc (you can find more information in our FAQs: https://unikraft.io/faq, or this blog post: https://unikraft.io/blog/kraftcloud/
Thanks so much for reading all the way to the end and looking forward to your comments!
[+] [-] krab|1 year ago|reply
Or if I want to "bring my own DB", what are the latencies to other providers? Can I somehow host a DB in the same datacenter as you are?
What do you recommend for serious usage when I want low latencies app <-> DB and I don't want to lose any data? :-)
Another question - is there something like cron?
[+] [-] nderjung|1 year ago|reply
Because KraftCloud leverages Unikraft, a unikernel library OS project, we are single-process. Postgres is multi-process since it uses the fork() syscall. If you require Postgres, we can set it up for you as a managed service. That said also, we are currently working on supporting fork() and this should become available in the next few weeks/end of April.
Re: bring your own DB: yes. We are setting up metros in many popular hyperscalers and IaaS vendors and DC zones. This means there should be no egress fees and you'll have data locality.
For serious deployments, be close to your data. If you get in contact ([email protected]), we can discuss further how we are approaching this.
And yes, we are working on cron, this will translate to setting up an instance to start at a regular interval and not auto-restart it (so it scales-to-zero). :-)
[+] [-] zardozMN|1 year ago|reply
[+] [-] quadrature|1 year ago|reply
I could be mistakened.
[+] [-] fhuici|1 year ago|reply
[+] [-] gigatexal|1 year ago|reply
[+] [-] winrid|1 year ago|reply
[+] [-] nderjung|1 year ago|reply
There's an initial free tier that, but once limits are reached, we will switch to pay-as-you-go plan. Our next offering ("developer") is still work-in-progress, and we're setting it initially for our early customers with much larger workloads who need autoscale more than they need scale-to-zero.
[+] [-] dualscyther|1 year ago|reply
1. Scale-to-Zero: don’t ever pay for idle again;
So I believe this is true? Where are you seeing a pricing page anyway?
[+] [-] fhuici|1 year ago|reply
[+] [-] garronej|1 year ago|reply
[+] [-] jviotti|1 year ago|reply
[+] [-] shaqbert|1 year ago|reply
1- Is there an option to run your own "kraftcloud" in your own cloud account?
2- How does this compare to companies leveraging eBPF to squeeze more performance from the Kernel?
[+] [-] nderjung|1 year ago|reply
1. Yes. We're essentially a baremetal solution. Either we run it on your behalf (this is kraft.cloud), or we deliver an ISO or AMI and this can be installed on-prem/cloud-prem. This latter solution is our enterprise offering.
2. eBPF used in this way, I feel, has become a symptom of the problem that we're trying to solve at Unikraft: the bloated Linux- (and cloud native-) stack. In the end, you're adding more tools or doing more tricks to try and do computationally less since performance and running faster is about performing less operations in the critical-path. Unikraft approaches the problem space differently: bottom up (app first, then dependencies, then select OS libraries/primitives based on required syscalls) as opposed to top-down (taking away from Linux, its distros, removing functionality, making short-cuts, etc.).
[+] [-] RiyaBisht|1 year ago|reply
[+] [-] jokethrowaway|1 year ago|reply
I pay roughly 50$/m for 4 small machines. I need to handle scaling myself but I constantly have requests coming in.
If I can cold start my Rust & Python services and scale as much as needed without my intervention, that'd be great but I doubt it will be competitive on price vs cheap VPS.
I wish you all the best and hope you become the new standard!
[+] [-] kevin_nisbet|1 year ago|reply
I've been pondering this type of issue for awhile, not from an application standpoint, but from a dev environment where I want more resources than my laptop has, but it'll be very bursty workloads and I want them to just pause when I'm not using them. So I'll be excited to see how this tech develops... good luck!
[+] [-] gaocegege|1 year ago|reply
[+] [-] ananos|1 year ago|reply
Including acceleration libraries & device drivers could severely impact the size and complexity of the resulting binary image. API remoting though could be something.
disclaimer: We're building a solution based on API remoting, and we have an example integration with Unikraft, the unikernel tech that kraftcloud is based on.
[+] [-] fbergen|1 year ago|reply
Would this work for hosting databases too? I found the biggest annoyance and expense on my "infrequently accessed" side projects are databases, which are almost always idle.
[+] [-] nderjung|1 year ago|reply
We have a whole section in our documentation's guides section on example usecases with database:
https://docs.kraft.cloud/guides/#databases
They work exactly as you suggest, they scale-to-zero when no requests are made and data can be safely stored/transactioned in persistent volumes on the platform too.