Hakuna Cloud – Stop cloud servers when they are not in use • Hacker News Board

Re: Hakuna Cloud – Stop cloud servers when they are not in use

#31

Post by grepthisab » Fri, Jul 26, 2019, 5:34 PM UTC

tarl0s wrote: post #18

ssttevee wrote: post #17

From the FAQ: > The HTTPS trigger is intercepting all my traffic? > No, your data are safe if your server support HTTPS protocol. All the data exchanged between your server and your clients is encrypted and not accessible by us. Unless there's an IP allocated to each user, I don't think this is accurate. With SSL, the HTTP headers are encrypted, so there would be no way to know where know where to route the request w…

In HTTPS, all the headers are encrypted except the hostname: https://en.wikipedia.org/wiki/Server_Name_Indication SSL termination is always done on our customers' servers.

SNI was added on top of TLS to allow one server to serve multiple certificates. SNI is different than the hostname header, and in fact no headers are available until the traffic is decrypted post-handshake, which Hakuna can't see if it's not terminating TLS. But SNI lets the hostnames be available outside the encrypted TLS stream on hello.

From a comment above, it seems like Hakuna requires a FQDN of each AWS server it's serving traffic to, so if you're not MITM'ing traffic, this FQDN I'm guessing sits in with SNI and is used for routing rather than serving certificates. I don't think I've personally dealt with this use case on SNI, but it makes sense.

Re: Hakuna Cloud – Stop cloud servers when they are not in use

#32

Post by tasssko » Fri, Jul 26, 2019, 5:42 PM UTC

We do this with custom autoscaling with aws cloudwatch, lambda, alarms though we usually have something online all the time for uptime monitoring.

Re: Hakuna Cloud – Stop cloud servers when they are not in use

#33

Post by rednerrus » Fri, Jul 26, 2019, 6:04 PM UTC

grepthisab wrote: post #28

tlarkworthy wrote: post #12

It's pretty cool that utility computing is large enough to spawn 3rd party companies that further increase effeciency of the pool. It's layers upon layers of technical progress in parallel.

Maybe. This is a bit of a cottage industry that shouldn't need to exist. It's so hard to get data and visibility into these things in AWS right now. Billing is hard, it's impossible to easily tell what is costing me what in every region, etc. AWS should do all this natively as part of their service, but everything is so poorly designed from a user standpoint that it's very time consuming to do, so third-party service…

https://www.cloudhealthtech.com/

Re: Hakuna Cloud – Stop cloud servers when they are not in use

#34

Post by gingerlime » Fri, Jul 26, 2019, 6:47 PM UTC

Interesting. Why proxying though rather than monitoring DNS queries on the CNAME? And updating to point to the right ip when the server is live (This could maybe help with the 10gb base limit + $0.08/gb?)

Not trying to be an armchair coach but rather understand the architecture decisions and trade-offs that I must have missed

Re: Hakuna Cloud – Stop cloud servers when they are not in use

#35

Post by lone_haxx0r » Fri, Jul 26, 2019, 7:01 PM UTC

[Bikeshedding]

> Why Hakunacloud?

Having #000 headings on blue background while using #fff text without shadows or borders on that same background looks really amateur.

And the "read more!" is blue text on a blue background. Barely readable.

Re: Hakuna Cloud – Stop cloud servers when they are not in use

#36

Post by simonebrunozzi » Fri, Jul 26, 2019, 7:07 PM UTC

The image in the front page reminds me of Drupal's logo [0]. Not necessarily an infringement, just saying.

[0]: https://www.drupal.org/about/media-kit/logos

Re: Hakuna Cloud – Stop cloud servers when they are not in use

#37

Post by bifrost » Fri, Jul 26, 2019, 7:13 PM UTC

nine_k wrote: post #6

Now that we have CGI scripts in the cloud (lambdas), there ought to appear an implementation of inetd, too! Jokes aside, I wonder when cloud providers will add something like this as a native feature.

^^ Winning joke of the year!

Re: Hakuna Cloud – Stop cloud servers when they are not in use

#38

Post by avip » Fri, Jul 26, 2019, 7:29 PM UTC

najarvg wrote: post #11

dharmab wrote: post #3

Efficiency is an area where there can be a lot of cost hiding. We recently saved a lot of money by: - Using the Kubernetes Vertical Pod Autoscaler ( https://github.com/kubernetes/autoscaler/tree/master/vertica... ) for CPU and memory scaling, and switching to metrics like requests per second and connection count for horizontal scaling - Collecting metrics on container CPU and memory allocation vs utilization - Writin…

Would love to see a more detailed write-up, if one exists, on your experience. We're nowhere near your scale but will probably ramp up in the next year or so.

Pre-scale just overprovision and pay $ to Bezos instead of $$ your precious engineers. 96% you won't "ramp up" anyhow.

Re: Hakuna Cloud – Stop cloud servers when they are not in use

#39

Post by SpicyLemonZest » Fri, Jul 26, 2019, 7:30 PM UTC

grepthisab wrote: post #28

tlarkworthy wrote: post #12

It's pretty cool that utility computing is large enough to spawn 3rd party companies that further increase effeciency of the pool. It's layers upon layers of technical progress in parallel.

Maybe. This is a bit of a cottage industry that shouldn't need to exist. It's so hard to get data and visibility into these things in AWS right now. Billing is hard, it's impossible to easily tell what is costing me what in every region, etc. AWS should do all this natively as part of their service, but everything is so poorly designed from a user standpoint that it's very time consuming to do, so third-party service…

I think you’re underestimating how hard of a problem it is to provide continuous billing information. I’ve seen SAAS companies with an engineering team dedicated just to the monthly reports, handling things like pipeline delays and data cleanliness and conversion to both a clean UI and fiddly excel spreadsheets.

Re: Hakuna Cloud – Stop cloud servers when they are not in use

#40

Post by dvtrn » Fri, Jul 26, 2019, 7:36 PM UTC

robmccoll wrote: post #24

The header of the website occupies >50% of the screen on Chrome on Android and stays there on scroll. It is very frustrating.

"Hero images". Done well it's an informative "here's what we do in a nutshell". Done wrong, it's an annoying UI.