Hakuna Cloud – Stop cloud servers when they are not in use | Hacker News Reader

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

hakuna.cloud

124 pointstarl0s61 comments

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

- Writing scripts to auto-submit PRs to SREs with better recommended sizing based on actual usage

- Tuning our VM instance sizes and autoscaler configs

A few engineers were able to save the company several times their salary with a few months of work, and plan to 10x the savings over the next year

Actually, HakunaCloud works on cloud servers, not containers. With Kubernetes you pay for the worker nodes, not for running containers.

HakuaCloud starto&stop cloud servers, so you actually pay only for the time the servers are needed

The number of running nodes is a direct function of the number and size of your containers. The cluster autoscaler stops and and start servers based on how many containers are desired, which is in turn based on the Horizontal Pod Autoscaler inputs (e.g. incoming requests).

Very nice! I suspect the economy of Cloud will soon change in such a way that Cloud providers will be focusing more on Enterprise, which have very little capability of doing similar things. And then, a lot of companies like Hakuna Cloud (reported here) will emerge, just like what happened in the last iteration of IT infrastructure.

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.

During a ramp up the limiting factor is usually engineer hours, new features, and ability to have the load at all and not cost.

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

I'm going to try to convince the lead on this project to present at an upcoming Kubecon :)

> Tuning our VM instance sizes and autoscaler configs

Do you run kubernetes in VMs on baremetal?

Yes, we own some datacenters as well as use multiple cloud providers. You are still responsible for running your own worker VMs with a managed Kubernetes anyway.

If you ever open-source your rightsizing scripts, I think a lot of people (including myself) would find that useful. While the vertical pod autoscaler attempts to solve this problem, it's incompatible with horizontal pod autoscalers based on CPU and memory, and thus unusable in a lot of cases. Going with a semi-automated solution might be ideal.

You can just run vpa-recommender without vpa-updater to get VPA recommendations without the autoscaling. That should work for most people.

I am confused by your use of the word cost hiding. Do you mean cost saving?

as in hidden costs- costs that the organization is unaware of because it's wrapped up in r&d/goods delivered on the accounting sheets. Its='s not until you pull in the utilization metrics that it reveals itself as waste.

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 services like Hakuna pop up to take advantage of the inefficiency by saving some money. I'm halfway convinced AWS does this on purpose so you have to pay them for support or training for people new to cloud service providers, or AWS specifically, increasing their revenue.

https://www.cloudhealthtech.com/

If anyone here has used this, what has your experience been?

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.

Of course they do this on purpose, it does not require a lot to give you metrics on usage and tell you if you are over provisioned, when mint.com can suggest a lower interest credit card or a higher yielding account based on my financial history, AWS cab easily do the same. But, why would they. They rather laugh all the way to the bank!

Tag every resource you provision (probably on 3-5) dimensions and you’ll never wonder where your money is going. It’s a great system, but most people (including me for the first 3 years) skip the tags screen by default.

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.

I just had a conversation about this product idea a couple days ago. How long before Amazon acquires it and cripples the functionality? Could be a good exit strategy, at least.

I don't think they'd cripple it. Amazon takes a pretty long term view of things. They might well introduce something like this into their load balancer or api gateway though. It'd be nice to have in front of fargate because of the faster cold start times.

2 minute cold start is pretty slow for a lot of use cases... Amazon already built Lambda which is more widely applicable.

True, I think lambda would be a better choice for new projects. However, for old monolith projects, this sounds like a great way to cut costs on dev/staging servers.

Related: if you're looking for a service that starts/stops instances on a schedule (we find this really good for QA and development instances), check out https://www.parkmycloud.com/ . You can also set an instance to "always parked" and unpark it for a certain number of hours or until a certain date/time.

(No affiliation, just a satisfied customer.)

Interesting model, although I suggest looking at the GCP Cloud Run approach using Knative to start and server containers on demand.

That's the next generation of Lambda that all clouds and vendors are moving towards, and increases developer agility with much faster cold-start times. If we could have Cloud Run today across multiple clouds and locations with geo-loadbalancing stitched together automatically, that would be valuable.

> Hakuna Cloud is a software-as-a-service HTTPS proxy. You don't need to change existing software or infrastructure, and you don't need to install additional tools on your servers.

> Each cloud server must have an FQDN/DNS name configured as a CNAME to our load balancers.

> When your server stops receiving requests, it will be stopped. As soon as a new request arrives, Hakuna will start it.

Interesting idea. It's like a proxy that kind of makes an instance/vm-based service act like a serverless service, without moving to containers or rewriting.

Seems kind of niche but I can see the use: there's a lot of services that have a time-based usage pattern (during working hours, or used interactively for a few minutes/hours sparsely through the day).

What are the cold start times like with this (at least for a typical, simple app - say on asp.net on Windows or something hosted via nginx on Linux)? What happens if an instance is being stopped and a new request comes in - does the request have to wait for shutdown plus startup?

At Hakuna we use our own service to start and stop our Jira and NPM servers; the instances are automatically stopped at night or whenever nobody needs to do `npm install`.

In our use case, the EC2 instance starts in about 50 seconds, with another minute needed to start the Jira service.

We have a demo, deployable directly from our CLI, that starts a Nginx server on an Oracle Cloud instance in less than 40 seconds.

If the instance is being stopped and a new request arrives, it will have to wait shutdown + startup, yes.

Thanks.

Is there UI feedback to the user during the wait, or does the browser just show "waiting for response" for the whole time? If a user refreshes the browser a bunch of times during the wait, will the Hakuna proxy give up on those requests or still pass all of them through to the target server?

We cannot provide UI feedback during the wait: being a HTTPS proxy, we would need the SSL certificate to reply to the request, otherwise it would be some kind of MitM.

If the client closes the socket before the start of the server, the proxy gives up on its requests.

You should probably check your website on mobile. For me on Firefox Android, the unmoving header takes up 60-70% of the screen and the actual scrolling content is crammed into the bottom fraction.

For time-based server start/stop, we use https://www.parkmycloud.com/ .

I'm looking forward to checking out Hakuna Cloud - looks like the two services are pretty complimentary.

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!

google Kubernetes engine, alerts you when a cluster is under used and shows the amount you could save if you reduce the number of machines.

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

What happens where there are no servers live? Should the request fail?

I think they can point to some kind of a "Loading..." page that they can host? (SSL can be managed with Let's encrypt, since the CNAME is effectively controlled by them)

It seems like it does exactly (or a subset) of what Google Cloud Run already does. Just shove an application into a container and scale up/down depending on use. Other cloud providers probably have this too. So is the value add that this is less expensive or what?

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 without first decrypting the data, and thus having access to the data.

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.

The whole header is encrypted, including the Host header and request line. Certificate selection and routing relies on SNI[1]. The server name in the TLS client hello message is almost always, but not necessarily, a copy of the value of the Host header field.

[1]: https://en.m.wikipedia.org/wiki/Server_Name_Indication

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.

I had long wondered if it would be possible to have a custom autoscaler that just stopped/started instances rather than terminating and re-creating, in order to respond to load increases more quickly than amazon's autoscaling groups. You still pay for the EBS even when it's stopped and deploys involve briefly starting all of the stopped instances, but EBS is a fraction of the overall spend and maybe in some cases the complexity is worth it?

hakuna = there is no (Kiswahili)

what a great name!

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

Interesting idea. Almost bring the idea of lambda to VMs, doesn't it?

Also, how does hakuna work with DO? I thought DO still charges when VMs are powered off?

Hi, I'm a developer at Hakuna. Thank you for the feedback.

With DO, we destroy the instance so that nothing is charged for it, and save a snapshot to be used to restart the instance; you pay only for the snapshot storage - $0.05/GB per month.

What is the cold start time of a DO instance image to working VM? Isn't it like 2 minutes?

If a DO droplet for my marketing site cost me $5 per month to run.. I could use your service and save a buck or two, at the risk of a $5000 client timing out on my page as it tries to spin up?

Scaling based on demand is important, but it seems you are better using k8s with some metric based scaling, over trying to hack it on DO?

I think this is not something you'd use for customer facing services. It's fine for internal stuff of the first employee of the day has to wait two minutes, and it gets shut down at night after it hasn't been used for an hour.

With GitLab Auto DevOps we are using Knative to scale things to zero when not in use.

So is this the bring your own server version of “inactive app hibernation” that you see in the free tiers of PaaS providers like Heroku? If so, that’s neat!

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

[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.

I like the colors and find it readable.

> You don't need to change existing software or infrastructure, and you don't need to install additional tools on your servers.

then

> Install Hakuna CLI

and

> Update the DNS

That certainly sounds like installing things and making changes to your infrastructure...

It sounds like a cool idea for sure and can be really helpful for a lot of companies but this seems like an outright lie.

Installing the CLI is optional.

"npm install @hakuna.cloud/cli -g and you are ready to go. Or use the web dashboard!"

Hi, I work at Hakuna Cloud as a developer. Thanks for your feedback.

If you don't like the idea of updating your DNS records, Hakuna provides a hostname creation feature for trying the product (*.demo.hakuna.cloud CNAME records that point to our load balancers).

You can install the Hakuna CLI on your laptop, no need to have it on the cloud instances. Also, most of the features you can find on the CLI are also available on the web dashboard.

Reply on news.ycombinator.com