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

DigitalOcean App Platform

pages.news.digitalocean.com

Post reply on HN
Print view View original

141–150 of 357 posts

Re: DigitalOcean App Platform

#141

Post by mrkurt »

cloverich wrote: post #95
ufmace wrote: post #83

Earlier quoted context omitted.

Very interesting that this feature is often demanded in tones of righteous outrage on posts about autoscaling cloud services, yet when actually implemented, nobody has actually set it up.

> So we never made it self service. I may not underestand parent, but it sounds like its not equivalent to a button next to the auto-scale but more like an email and pre-requisite knowledge that it exists?

Yes we advertised it as a feature to all new signups, with a link to request limits. It's not equivalent to a button, the dirty secret is that when people requested it, I planned to put a notification in my calendar to go look at their usage the last day of the month and adjust their bill accordingly. :)

We were concerned about spending time on marginal features that didn't actually matter much to people, so we "launched" it without building it to see if anyone cared.

Re: DigitalOcean App Platform

#142

Post by alexellisuk »

colinclerk wrote: post #71

We've been happy https://render.com customers for over a year now and on the surface this looks very similar. I'm glad to see another company take a stab at iterating on Heroku while keeping ops burden low. I'm interested to know - what's the sales pitch for DO over Render? I'm noticing some pricing differences but at first glance it seems they tip Render's direction. I'm also noticing Render is a bit further along (…

Congrats to DO on this launch. There's also completely free & OSS platforms that provide a similar experience, perhaps a little more Cloud Native (auto-scaling, scale to zero, team features) like OpenFaaS Cloud - https://github.com/openfaas/openfaas-cloud

Re: DigitalOcean App Platform

#143

Post by mrkurt »

the_duke wrote: post #60
mrkurt wrote: post #41

Earlier quoted context omitted.

For what it's worth, we (Fly.io) have this feature, and announced it as part of our launch post on HN. But literally no one has asked us to enable it on their apps. So we never made it self service. I think for most companies, it's better to set the expectation that the service costs money, bursts will cost more money, and then forgive outlier charges once or twice. It's tremendously difficult to compete against the…

I'd argue that many users that end up with surprise bills are either inexperienced or are deploying something small without giving it much thought. In those cases, the users will either not know or not think about such expense limits. The solution is to set relatively strict limits by default and even occasionally warn users about unused/underutilized resources. But as you said: such features are bad for the bottom l…

I think such features create really negative surprises too. People expect their app or service to keep working at almost any scale. Disabling an app that hits a threshold sounds terrible, because most peoples' apps _benefit_ from more (legit) activity and they are delighted to pay the extra fees if things just continue to work.

For people who are inexperienced or don't give it much thought, just waiving their overage fees creates a really nice experience. We've had multiple instances of people asking why their bill is so high and being relieved/excited when we explained it and made it go away. People love when we're responsive to problems.

Re: DigitalOcean App Platform

#144

Post by alexellisuk »

sciurus wrote: post #25
phildougherty wrote: post #7

Earlier quoted context omitted.

We certainly took a lot of inspiration and leaned on the awesome experience of the nanobox team, but this is largely a completely different architecture.

Can you tell us anything about the architecture?

This is what I found out by printing the environment variables: https://twitter.com/alexellisuk/status/1306343018488791040

Re: DigitalOcean App Platform

#145

Post by alexellisuk »

aitchnyu wrote: post #112
bizzleDawg wrote: post #5

I'd be interested to know if this is integrated and rebranded nanobox [0]? Or something completely from scratch? [0]: https://nanobox.io/

I was guessing KNative, which powers Google Cloud Run. https://knative.dev/

Google's Cloud Run the SaaS doesn't use KNative + K8s under the hood. It just uses a compatible HTTP API.

Re: DigitalOcean App Platform

#149

Post by dang »

stocknoob wrote: post #118
tobr wrote: post #99

Earlier quoted context omitted.

Right, it’s almost as if there’s more than one person here, with more than one temperament.

A message board centered around startup accelerator might be expected to have a median temperament closer to a startup than a 100 year old accounting firm.

HN has many different subpopulations and the startup founder subgroup became a small minority many years ago. There are probably more users here now who actively identify against startups than the other way around. Cycle of life.

Re: DigitalOcean App Platform

#150

Post by erulabs »

Heh - this is extremely close to the company I am building! Shared Kubernetes is a great starting point, but unless the PaaS can be installed on _any_ Kube cluster I wonder how much of a step forward this really is.

That said, auto-configuration guessing based on the contents of a GitHub repo is probably the future - Automatically get a redis server when you've installed a redis driver, etc.

Post reply on HN