Live data from Hacker News

DigitalOcean App Platform

pages.news.digitalocean.com

291–300 of 357 posts

Re: DigitalOcean App Platform

#291
post #273

I am so glad to see this. I was looking to deploy an app and the choice is either Heroku or manage your own server which I don't want to do. Heroku gives instant deployment for the most common types of apps (python/java/ruby). It's PaaS done right, it's fantastic. You should really have a look if you're not aware of it, it's only $7 for a starter app. Problem is, scaling up is about $50 per gigabyte of memory which m…

Why not take the initial complexity cost and learn k8s and containerization? That's what I've been doing as a step-up from Heroku and have been very happy with it. My project currently runs on Digitalocean managed k8s and setting it up really wasn't hard. I had everything already in containers for dev/prod anyway, and having those run on k8s just meant I had to write the deployment manifests that pull the containers…

> Why not take the initial complexity cost and learn k8s and containerization?

Security, OS patches, maintaince and more than anything DDOS attacks. I don't want to handle all that, I just want to concentrate on development not maintaince.

Re: DigitalOcean App Platform

#292
post #290

I was really excited about this when I got the email a few weeks ago with a beta invite but after two minutes I realised I’d be unable to use it, and still can’t now it’s launched... Why oh why is GitHub now considered the single place where code lives? Even as alternative providers gain in popularity. It’s really sad to see DigitalOcean requiring this for some reason. Please either allow use of arbitrary Git reposit…

From article: > You can deploy the source code directly from your GitHub repositories (support for GitLab and Bitbucket is coming soon). Naming specific git hosts suggests it may not be available on "arbitrary Git repositiories" in the near future, but looks like they are at least planning to broaden the options for where to have your code live

Such a weird approach that seems repeated by many. Instead of building something general that works for most cases and is easier to implement, they focus on specialized cases of specific SCM platforms.

If they started with support Git Remotes and then supporting specific platforms, they would have covered all use cases from the get-go, albeit with slightly poorer UX.

But instead they chose to only support specific platforms, missing plenty of people who actually want to use this, but can't.

Re: DigitalOcean App Platform

#293
post #291
post #273

Earlier quoted context omitted.

Why not take the initial complexity cost and learn k8s and containerization? That's what I've been doing as a step-up from Heroku and have been very happy with it. My project currently runs on Digitalocean managed k8s and setting it up really wasn't hard. I had everything already in containers for dev/prod anyway, and having those run on k8s just meant I had to write the deployment manifests that pull the containers…

> Why not take the initial complexity cost and learn k8s and containerization? Security, OS patches, maintaince and more than anything DDOS attacks. I don't want to handle all that, I just want to concentrate on development not maintaince.

Managed k8s offerings usually take care of everything below the k8s API. Our GKEs auto-upgrade their control plane and the worker nodes, both OS and k8s versions. I could force my way onto the workers via SSH if I really wanted to, but by default I can't even get on those machines. All you ever do yourself is kubectl this, kubectl that. I believe DO's k8s offering is like that as well.

Re: DigitalOcean App Platform

#294
post #290

Earlier quoted context omitted.

From article: > You can deploy the source code directly from your GitHub repositories (support for GitLab and Bitbucket is coming soon). Naming specific git hosts suggests it may not be available on "arbitrary Git repositiories" in the near future, but looks like they are at least planning to broaden the options for where to have your code live

Such a weird approach that seems repeated by many. Instead of building something general that works for most cases and is easier to implement, they focus on specialized cases of specific SCM platforms. If they started with support Git Remotes and then supporting specific platforms, they would have covered all use cases from the get-go, albeit with slightly poorer UX. But instead they chose to only support specific pl…

Git remotes is certainly not "easier to implement". You need to have ssh infrastructure setup to receive the repository, deal with key management, provide the user some way to input ssh keys, etc. Contrast that with GitHub web hooks + API and I can see why they didn't bother.

I bet GitHub covers the vast majority of their target users.

Re: DigitalOcean App Platform

#295
post #291

Earlier quoted context omitted.

> Why not take the initial complexity cost and learn k8s and containerization? Security, OS patches, maintaince and more than anything DDOS attacks. I don't want to handle all that, I just want to concentrate on development not maintaince.

Managed k8s offerings usually take care of everything below the k8s API. Our GKEs auto-upgrade their control plane and the worker nodes, both OS and k8s versions. I could force my way onto the workers via SSH if I really wanted to, but by default I can't even get on those machines. All you ever do yourself is kubectl this, kubectl that. I believe DO's k8s offering is like that as well.

You're still self-hosting, just on top of k8s rather than on top of VMs. All the ingress is your problem, logging, monitoring...

It's only managed in the same way that AWS Elastic Beanstalk is managed.

Re: DigitalOcean App Platform

#296

Earlier quoted context omitted.

No. I don't think so. The concern for me is a lack of hard limit on spending on GCP, Azure, and AWS. If I screw up and allocate a bunch of resources unintentionally, I'm left holding the bill. That's a terrible setup for PaaS because all programming involves mistakes eventually, especially for new users learning the system. Granted, there are likely limits on accounts, but those are to protect the services from fraud…

Hard spend limits are not an easy problem with cloud. There are too many things that incur costs. Everytime this comes up, I ask the same question: what do you expect to happen when the quota is hit? Shutdown your servers? Wipe your SSDs and storage buckets? Remove your DNS records? Should it be permanent? If not then they're just subsidizing the costs. If it's soft-limit then its just a warning, and if you just want…

> Shutdown your servers? Wipe your SSDs and storage buckets? Remove your DNS records? Should it be permanent?

I'd be absolutely fine with that in a sub-account or resource group as long as I had to enable it.

A while back I wanted to try out an Azure Resource Manager template as part of learning something. Since I was _learning_ it, I wasn't 100% positive what it was going to do, but I knew that it should cost about $1 to deploy it.

With a hard limit on spending I would have set it to $10, run the thing and been ok with the account being wiped if I hit $10. Even $100 I could tolerate. Unlimited $$ was too risky for me, so I chickened out.

The worst part is I can't even delete my CC because it's tied to an expired trial that I can't update billing for.

> Also for most customers, the data and service is far more important than the cost.

So don't enable the hard limit.

Re: DigitalOcean App Platform

#297

Earlier quoted context omitted.

This is spot on, except for one thing: Google Cloud Run. It's the closest offering I've found to Heroku and am planning to migrate all our services to it due to significantly better pricing. Make sure you look into it.

Google Cloud Run doesn't provide nearly the same features as Heroku. For example, there is no easy way to manage secrets with Cloud Run. There is no way to run a worker process. Integration with other Google Cloud things like Cloud SQL is clunky. Cloud Run is okay to get started but almost all apps will need more.

> there is no easy way to manage secrets with Cloud Run

See https://cloud.google.com/secret-manager/

I recommend this community-maintained FAQ on Cloud Run:

https://github.com/ahmetb/cloud-run-faq

Re: DigitalOcean App Platform

#298
post #172

Earlier quoted context omitted.

There are more options than Heroku: - Google App Engine (PaaS) - Google Cloud Run (serverless containers) - Fly.io (serverless containers with a minimum of 1 container running per configured region)

Fly.io is more exciting for me because it's edge app servers and it terminates web sockets. I've been envisioning a live-view like framework, or heck even a regular old rest api, where the client connects to the fly.io server with a single request then the app server makes a request to N number of back end processing servers using an efficient protocol like grpc.

It is cool, but it does not scale to zero, so if you have N services you will end up paying for at least N instances.

Re: DigitalOcean App Platform

#299

I was really excited about this when I got the email a few weeks ago with a beta invite but after two minutes I realised I’d be unable to use it, and still can’t now it’s launched... Why oh why is GitHub now considered the single place where code lives? Even as alternative providers gain in popularity. It’s really sad to see DigitalOcean requiring this for some reason. Please either allow use of arbitrary Git reposit…

You can use the [doctl](https://www.digitalocean.com/docs/app-platform/references/co...) CLI along with an app specification yaml to deploy from your self-hosted GitLab.

The App Specification supports a normal Git repository. However, I can see how this might be a problem if your repository is private as there are no configuration options for auth.

Re: DigitalOcean App Platform

#300
post #273

I am so glad to see this. I was looking to deploy an app and the choice is either Heroku or manage your own server which I don't want to do. Heroku gives instant deployment for the most common types of apps (python/java/ruby). It's PaaS done right, it's fantastic. You should really have a look if you're not aware of it, it's only $7 for a starter app. Problem is, scaling up is about $50 per gigabyte of memory which m…

Why not take the initial complexity cost and learn k8s and containerization? That's what I've been doing as a step-up from Heroku and have been very happy with it. My project currently runs on Digitalocean managed k8s and setting it up really wasn't hard. I had everything already in containers for dev/prod anyway, and having those run on k8s just meant I had to write the deployment manifests that pull the containers…

This is always great until there is a bug somewhere in the infr layer. Then having k8s is no longer such a good idea.
Post reply on HN