Is this based on knative? It seems very similar :)
DigitalOcean App Platform
31–40 of 357 posts
Re: DigitalOcean App Platform
#32Earlier quoted context omitted.
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.
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 to let you set min and max bounds for autoscaling once it is implemented. Thanks for your help!
Re: DigitalOcean App Platform
#33Tried this out in early access and wanted to love and use it however a few things that made it not workable: * wildcard subdomains aren't supported. * Only CNAMEs to digital ocean's CDN are supported (can't have an A record). * There was no way to run a console command. * Bandwidth is 12x higher than usual droplets and unlike standard droplets there isn't an included bandwidth pool.
> * There was no way to run a console command.
There is a console now, was added a few weeks ago.
Re: DigitalOcean App Platform
#34Earlier 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?
We will be revealing a lot more about the architecture at our upcoming virtual conference called Deploy that is happening Nov 10-11th. There are a few sessions that touch on how the platform was implemented and I encourage you to tune in for those! (schedule to be announced soon).
https://www.digitalocean.com/deploy/
Re: DigitalOcean App Platform
#35So if I understand correctly, DigitalOcean just built an inferior version of caprover? (for which a digital ocean one-click droplet exists BTW)
Caprover is essentially a really nice GUI for docker swarm, Let's encrypt and nginx.
Re: DigitalOcean App Platform
#36Tried this out in early access and wanted to love and use it however a few things that made it not workable: * wildcard subdomains aren't supported. * Only CNAMEs to digital ocean's CDN are supported (can't have an A record). * There was no way to run a console command. * Bandwidth is 12x higher than usual droplets and unlike standard droplets there isn't an included bandwidth pool.
The bandwidth piece is interesting. I guess if you really have a need for bandwidth just use their K8s offering which is free and you just pay for droplets (with much more bandwidth)/networking. It will require more setup, but you will end up with higher bandwidth.
"Just use k8s" isn't a solution as k8s is a complex beast.
Re: DigitalOcean App Platform
#37Earlier 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…
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 an unexpected bill than getting traffic.
Re: DigitalOcean App Platform
#38So if I understand correctly, DigitalOcean just built an inferior version of caprover? (for which a digital ocean one-click droplet exists BTW) Caprover is essentially a really nice GUI for docker swarm, Let's encrypt and nginx. https://caprover.com/
[deleted]
Re: DigitalOcean App Platform
#39Earlier quoted context omitted.
The bandwidth piece is interesting. I guess if you really have a need for bandwidth just use their K8s offering which is free and you just pay for droplets (with much more bandwidth)/networking. It will require more setup, but you will end up with higher bandwidth.
"Just use k8s" isn't a solution as k8s is a complex beast.
Agreed, but they provide the management of the infrastructure. You will need to setup the services/pods, but it does then give you droplets with higher bandwidth if that is your need.
Re: DigitalOcean App Platform
#40Earlier 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…
I think he is simply requesting threshold limits. So for example you could set a threshold of 2 - 5 nodes/droplets. This way you will always have at least 2 nodes running, even with zero traffic, because that is the minimum you requested. Likewise the upper bound limit of 5 nodes/droplets would limit the maximum nodes that the service would generate.
So it autoscales up until it hits the maximum threshold and stops. Yes, if the app needed more resources than this, due to a spike in traffic, than performance would obviously suffer. But depending on the budget and needs of the project this might be the preferred outcome over incurring unexpectedly high server costs that you are not prepared to handle.