51–60 of 357 posts
Details aside, I think having a PAAS is awesome and something we’re really missing on AWS.
AWS has a PaaS: Elastic Beanstalk. Though I would forgive you for forgetting about EB since it sometimes feels like AWS's neglected step child.
Details aside, I think having a PAAS is awesome and something we’re really missing on AWS.
AWS has a PaaS: Elastic Beanstalk. Though I would forgive you for forgetting about EB since it sometimes feels like AWS's neglected step child.
Earlier quoted context omitted.
Wasn't the Appsail nanobox? IIRC, it was planed to be DO's PaaS, so it's cancelled and then DO's PaaS is based on k8s instead?
Appsail was nanobox from what I saw, they redid it between appsail and "apps".
Like all DigitalOcean products, the App Platform provides predictable, easy-to-understand pricing that allows you to control costs to prevent surprise bills. I can't see any features listed that enable me to control costs to prevent surprise bills. If a site got submitted to HN and hugged to not-to-death-because-it-autoscales then I'd wake up to a bunch of alerts and massive outbound bandwidth bill. I don't want that…
Thanks for the feedback! Autoscaling is not yet supported on the platform (but is coming soon). Before autoscaling lands as a feature, insights based alerting will also land. You'll be able to setup alerts for scaling events, bandwidth, cpu, memory, and more that can be sent via email or slack.
Earlier quoted context omitted.
My point is that alerts aren't really enough. If I'm asleep or on a plane or something then it could be many hours before I even see an alert, by which time it's probably too late. I'd prefer to be able to set up rules beforehand that prevent an unforeseen bill. If the App Platform doesn't have that feature, and it isn't planned, that's OK but I'd argue that isn't really preventing a surprise bill as the marketing si…
Sorry, I think I misunderstood what you were saying there. Could you clarify a bit more about what kind of functionality you'd prefer we support in the scenario you described? A large influx of traffic hits your application while you are unavailable to handle it. If you do not have autoscaling enabled, your application performance could suffer, if you do have it enabled your bill could grow out of bounds. We do plan…
Happy to see easy docker support. But I guess my ideal PaaS would be to just tap in a docker image from a private registry rather than running a Dockerfile from a repo.
There's just too much of a premium for this over a standard DigitalOcean droplet though. At the low end you're paying double for the same resources, and at the high end you're paying 4x.
I deployed a toy Node.js app that was a bit too resource hungry for 1 virtual CPU. The cheapest plan with 2 virtual CPUs is $150 per month (vs. $15 for a droplet with 2 virtual CPUs).
Seems like there are some pricing issues to work out.
Azure Static Web App is free and no limits compared to this offer, I can also scale Web Apps in Azure, not sure why I would choose the digital ocean option. Competition is good for us at least :).
Earlier quoted context omitted.
We do plan to let you set min and max bounds for autoscaling once it is implemented. This is exactly the sort of thing I'm talking about, but for money rather than computing resources or bandwidth. I'd like a feature that where the requirement is effectively "Fall back to a serving sorry-I'm-poor.html instead of the app if the total monthly bill has exceeded $xxx". For a side project I'm more interested in not paying…
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…
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 line .
And I can appreciate the enormous difficulty of competing with the big 3.