New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Bunny.net - Magic Containers!?? Super cool
Just received this from Bunny https://bunny.net/blog/introducing-magic-containers-what-edge-computing-was-meant-to-be/.
Looks very cool. Will be getting my hands on this tonight.
Thoughts?
Thanked by 1cainyxues

Comments
I tried it. They don't have persistent volumes, yet.
So hosting anything that needs to save data isnt possible right now. It is on the roadmap tho.
How would one, say, with a basic PHP driven site (No DB, no hipster web stack. Just nginx/php) use something like this if they wanted to replicate their website on this platform?
Looks like you have to create an app, and then connect it to DockerHub(?) or GitHub?
Help teach an old dog new tricks. I've always just used geodns to distribute our site to different continents but it still requires maintaining a server in each POP, for example. Something simple and lightweight like our main site wouldn't cost much based on their calculator ( Less than $7/mo ) and would perform much better than what I am currently doing.
Sounds like you'd need to create a dockerfile to do the heavy lifting, but that's super easy... Honestly could be a game changer all of this
So:
NVMe storage is not persistent? Tafak is that
. So, eliminate it and store data in memory, which is also paid in this case.
Product on paper looks good, but marketing fuss (written with AI) is clouding the real deal. Claim like this:
Begs lawsuit from "traditional cloud" providers. Essentially they sell edge containers, that is mutated and severely limited (docker) VPS.
I better stay with my edge worker https://workers.cloudflare.com/.
Pretty much, yes.
You would need to write a Dockerfile that bundles a web server and your site's files into a Docker image. Afterwards, you need to publish this image to an image repository. You can do all of this on GitHub, using workflows and a private repo. Afterwards, it's just linking it to Bunny and letting it do the deployment given your provided configuration.
As long as you don't need to store/edit any files dynamically, Magic Containers works well for this. You can either use Bunny's CDN on front or serve a web server yourself directly using an Anycast IP (but I'd rather use the CDN function).
This is basically "containers-as-a-service". Sucks that there's no persistent storage yet, but it's on the roadmap given what I've seen on the Discord.
Bunny also offers Edge Scripting.
too many cool words for docker containers
Well, if the site isn't dynamic, just make it HTML and serve it on Cloudflare Pages or something.
If the site is dynamic, and not dependent on any database, sure, I guess this is a good use case.
If the site is dynamic, and dependent on a database, it likely won't make a very big difference anyway since DB queries now can't be performed locally anymore. Could likely even make it worse. Just guessing here.
So I'd say in its current form the use-case is kind of limited, no?
Yeah, I'm a pretty big bunny fanboy, but the current implementation of magic container seems pretty limited. And even with the persistent storage, the advantage of global deployment would be held back by the DB query if you don't implement globally distributed database as well (as long as I'm not missing something - do let me know since this is one of the bigger reasons why I'm not currently able to move my stuffs to fly.io)
Honestly keeping everything aside, I'm not sure what kind of advantage bunny has over something like fly.io. Having another strong competitor is a plus side though
Network traffic pricing here is rather insanely expensive, but otherwise it looks fine.
I don't know what is the use case, Normally, for such low latency deployments, companies uses microservices with region wise deployments with each services on it's own DB and event driven architecture with kafka or nats. I don't think this make sense at all for such deployments.
I appear again 😆
The vision for Magic Containers is really two parts and one overlapping vision.
First part was to solve Edge Computing for bigger, busier, and more complex applications. We have quite a bit of experience running things like Bunny Optimizer that is very heavy on compute, but also globally distributed. This makes it quite time consuming to monitor, scale and handle spikes efficiently. With Magic Containers it kind of becomes set and forget.
The idea was really to optimize the compute for latency while minimizing cost, rather than popping up everywhere since that for us would be extremely expensive for example. The core of this is the provisioning model that constantly monitors the traffic and adjusts the deployments to run where they need to run to maintain low cost. We have a bunch of other services distributed globally as well as upcoming products that benefit for this, and we wanted to help other companies solve the same problems.
With the initial launch, we also wanted to bring low level networking and anycast support to the edge. Since bunny.net really started from nothing, we know the pain of trying to set up and maintain a global anycast from scratch. The goal was to make this a click of a button… and it costs only $2 per month, not 10k for a /24 subnet. Deploying global DNS, VPN, stateless APIs, streaming, game servers, data processing for example are some use-cases we wanted to help with at this stage, and mainly, without limiting users to a proprietary runtime. We wanted to give the ability to take any application global without having to basically rewrite it.
The use-cases are of course slightly more limited right now without persistent storage, but we wanted to get this out to help solve a set of very difficult problems for those that do have them and start collecting feedback and improving the product.
There’s a bigger vision ahead however, which starts with stage 2. We are planning to launch an edge database product in the next few months to expand what’s possible to build and run, and moreover, the #1 priority is to bring persistence.
That brings me to the full vision for Magic Containers, which really is to be able to deploy anything everywhere or anywhere, single region, regional, or global, with a few clicks, for the lowest entry cost possible and with an amazing user experience. The cloud is becoming extremely complex, and we want to help change that. It’s quite ambitious, but we want to help developers focus on building apps and provide an exceptional platform to run them on without worrying about infrastructure. The focus is on making the UX so great that it feels like magic, hence the name
We’re quite early into the full vision, and super excited about what’s coming next.
Of course, we’re not neglecting CDN, and there are big announcements coming there as well very soon. We just feel like we have a great global platform that gives us the opportunity to help with so much more.
Overall, we are super hyped up for the year ahead
Regarding the performance comparison: We updated the blog post to make it a bit clearer what we’re benchmarking and how. The point was really to show that dollar for dollar, MC hardware is extremely fast. Obviously traditional cloud can give you any level of performance up to 128+ dedicated cores, the idea was not to say we’re faster than that. Since we charge for CPU time, not CPU cores, it’s extremely important to us that the CPU time is extremely efficient, not old tech. We could of course put 15 year old CPUs with as many low speed cores as possible and say we charge pennies per CPU hour, but it would just be bullshit. We want MC to be top of the line.
I’ll check if we can further make this clearer on the graphic as well.
Distilled:
Magic Containers Vision Summary
Current Capabilities
Limitations
Upcoming Features (Stage 2)
Long-term Vision
Performance Claims
P.S. When one must run fckin claude sonet to extract value from text - there is something wrong!!!!
Basically that. Poured my soul into my sob story though 😝
Can you give Bryan two middle fingers for me? Pretty please.
Exactly, if a page load contains multiple non async queries, this would slow down and not speed up is my assumption.
And if you already have a globally distributed database, you’ve already done the vast majority of the work anyway.
I’m still sure there’s some use cases though.
With the edge database, this will be interesting.
The main goodness here is that essentially we will receive product as it was (or maybe still is) with https://buyvm.net/anycast-vps/ . No one in current market offer anycast VPS. At the end bunny will essentially offer anycast VPS.
I just hope that they dump that crappy lock on docker images. I just wanna slam Debian minimal and goooo. Though, price wise, such server still would be VERY expensive as realistic use of server with 100 MB RAM and 1 GB storage not gonna happen.
Why they will convert their "magic blabla" to anycast VPS? Because it is way more universal and attract more audience.
cool. I'm playing with northflank.com, it gives $20 per month for developing sandbox. It can install npm from github and deploy docker.
Tested scripting out the other day for a messaging API, and didn’t have too many issues getting it up and running.
Only pain point would the logging system (it sometimes flips between descending and ascending sort; and the “clear” button doesn’t persist after a refresh).
Edit #2: More feedback! The flow for using a custom domain isn’t super intuitive, considering you have to find the generated pull zone for
your-generated-app-name.bunny.run, and add it there.Beyond that, seems to be working well. 🙂
Sounds very interesting! I'm hoping for PG (or YugabyteDB / similar), Garnet and Nats support
Isn't the whole point of a CDN, that your files are stored in multiple servers in multiple regions and gets pulled based on each user's proximity to the closest server.
Their explainer video makes it seem like their existing CDN service isn't doing this, or more likely, it's all above my head.
CDN is caching static files. This is hosting Docker containers. So no, the existing CDN doesn't do this by design.