Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hyper.sh: Container-native Cloud

docs.google.com

Post reply on HN
Print view View original

21–30 of 30 posts

Re: Hyper.sh: Container-native Cloud

#21

Post by tyingq »

tannhaeuser wrote: post #13
tyingq wrote: post #5

Earlier quoted context omitted.

5 second boot time though. Better than a normal VM, but maybe not great for user facing serverless.

How is it better than a normal VM (or have I misunderstood)? You can get a full VPS with dedicated IP on OVH, Hetzner & co. for EUR 3.50/month.

Just pointing out that the 5 second boot time is better than a regular VPS. Which (combined with per second billing) makes this good for batch/cron oriented serverless functionality. But is too slow for "function as a service" type serverless where the end user is waiting for it to fire in a browser.

Re: Hyper.sh: Container-native Cloud

#23

Post by meddlepal »

curun1r wrote: post #10
mjmein wrote: post #6

I'm interested - what type of app can you run on 64mb of ram? What languages are suitable for building these types of microservices?

I'd just like to say how dispiriting I find this question considering I how envious of my friends $4k+ computer I was because it had 64mb of RAM and could play C&C Red Alert with absolutely no slowdown. Let that sink in...in the mid 90s, we comfortably fit a Windows GUI and a somewhat sophisticated game into 64mb of RAM and 20 years of "progress" later, we're asking what kind of special accommodations are necessary t…

Thousands of HTTP requests per second. Not just "a handful".

Re: Hyper.sh: Container-native Cloud

#26

Post by ceronman »

curun1r wrote: post #10
mjmein wrote: post #6

I'm interested - what type of app can you run on 64mb of ram? What languages are suitable for building these types of microservices?

I'd just like to say how dispiriting I find this question considering I how envious of my friends $4k+ computer I was because it had 64mb of RAM and could play C&C Red Alert with absolutely no slowdown. Let that sink in...in the mid 90s, we comfortably fit a Windows GUI and a somewhat sophisticated game into 64mb of RAM and 20 years of "progress" later, we're asking what kind of special accommodations are necessary t…

The original PlayStation had only 2MB of RAM and 1MB of video memory. Still you could play games such as Metal Gear Solid on it :D

Re: Hyper.sh: Container-native Cloud

#29

Post by lobster_johnson »

Gaelan wrote: post #7
mjmein wrote: post #6

I'm interested - what type of app can you run on 64mb of ram? What languages are suitable for building these types of microservices?

I’m pretty sure most languages, even interpreted, can run at least small programs in 64MB. If you want to minimize memory usage at all costs, I think you’d want a non-GC compiled language (C(++), Swift and Rust come to mind).

You can forget about Node.js, Python or Ruby for any meaningful app, like a web API. Erlang/Elixir is also iffy, I'm pretty sure. Java, last I check, had a default heap size of 64MB, and does badly on less.

I've written small Go programs that can consume around 15-20MB on low traffic. But they also have huge spikes in memory usage when you have concurrent requests hitting them.

Re: Hyper.sh: Container-native Cloud

#30

Post by NathanKP »

mjmein wrote: post #6

I'm interested - what type of app can you run on 64mb of ram? What languages are suitable for building these types of microservices?

A Node.js REST API can handle a significant volume of incoming requests with only 50mb-75mb of RAM. For reference here is a load test of handling around 75k-80k reqs/min using node.js containers deployed using Amazon ECS. Each node.js process is basically just doing CRUD operations, accepting incoming JSON, storing it in a database, fetching values back out of a database, and sending JSON back to clients. There is a bit of extra overhead from microservice HTTP fanout to other backend microservices, but the whole stack is very lightweight and 99% of requests are served in under 30ms.

As you can see this workload is only using about 6% of the available memory. For event loop driven systems like Node.js or Nginx, or Go the workload is almost always CPU bound not memory bound:

http://i.imgur.com/VCN5e21.png

Post reply on HN