Most active commenters

    ←back to thread

    DigitalOcean App Platform

    (pages.news.digitalocean.com)
    646 points digianarchist | 13 comments | | HN request time: 1.101s | source | bottom
    Show context
    user5994461 ◴[] No.24700185[source]
    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 makes it a dead end for anything non trivial. You're forced to go to digital ocean / Linode / OVH instead to have something affordable.

    That leaves Digital Ocean as the only alternative (don't trust Linode) and it sucks because it only gives me a server to manage. I don't want to manage a server I want to run a (python) application. It's 2020 this sort of things should auto deploy from GitHub without bothering me to manage an operating system.

    replies(19): >>24700693 #>>24700794 #>>24701039 #>>24702228 #>>24702633 #>>24702880 #>>24703398 #>>24703543 #>>24703620 #>>24704410 #>>24704873 #>>24705031 #>>24705668 #>>24706188 #>>24706382 #>>24707003 #>>24709134 #>>24716137 #>>24727185 #
    1. dvcrn ◴[] No.24705668[source]
    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 and setup the pods.

    What I love about managed k8s (and also shared a couple times in comments on HN) is that it's separated from the servers below. I can have 20 containers (that can be separate things all-together) running on the cheapest Droplet and would only pay whatever that droplet costs, so under $20. Then when I need more power, I just scale the Droplets used for the k8s cluster and my pods/containers get shoveled around the available resources automatically.

    I liked this approach so much that I now have a private 'personal projects cluster' that runs on digitalocean with the cheapest/weakest droplet avvailable, and whenver I have a small hobby project that needs to be hosted somewhere, I just add that container to the k8s cluster and be done with it.

    replies(4): >>24705748 #>>24705749 #>>24706558 #>>24706813 #
    2. nojvek ◴[] No.24705748[source]
    I’m waiting for digital ocean to have something like google cloud run.

    Google cloud run is essentially here is a docker image that listens on the $PORT env variable. Spin it up when you get requests. It will handle X queries per second (you can set limit). If more than X, scale it up to this many replicas.

    I pay about 10 cents for my site. Zero maintenance. I push code to GitHub, GitHub builds an image, pushes to GCR and tells cloud run to use new image.

    This is how things ought to work for simple web server like functionality. “Here’s a dockerfile and source tree, build it, run it and auto scale it with this https domain” Boom!

    replies(1): >>24707316 #
    3. papaf ◴[] No.24705749[source]
    Why not take the initial complexity cost and learn k8s and containerization?

    I would argue that the complexity cost is ongoing not just front loaded. There is an overhead for every new application. For instance putting it in a Docker image, deploying it using gitops flavour of the month and then any extra policy management and routing.

    4. prakis ◴[] No.24706558[source]
    > 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.

    replies(1): >>24706591 #
    5. dividedbyzero ◴[] No.24706591[source]
    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.
    replies(1): >>24706689 #
    6. ForHackernews ◴[] No.24706689{3}[source]
    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.

    7. lnenad ◴[] No.24706813[source]
    This is always great until there is a bug somewhere in the infr layer. Then having k8s is no longer such a good idea.
    replies(1): >>24716207 #
    8. mcintyre1994 ◴[] No.24707316[source]
    What sort of cold start time do you get with that out of interest?
    replies(2): >>24708148 #>>24715311 #
    9. chishaku ◴[] No.24708148{3}[source]
    Not sure about exact numbers on the cold start but we avoid it altogether with a keep-warm request every minute.
    replies(1): >>24708250 #
    10. mcintyre1994 ◴[] No.24708250{4}[source]
    Makes sense, and the 10 cents in your above comment is literal with a keep-warm every minute? That's pretty solid!
    11. nojvek ◴[] No.24715311{3}[source]
    Even with no cron, it was <500ms cold start. With a cron that hit every 5 mins, I saw less <100ms to hit US central and back (from Seattle).

    I pay 10 cents a month to google. They have no shame charging me 3 cents on my credit card.

    12. aliswe ◴[] No.24716207[source]
    A non tech person could say the same about having an "app" at all.
    replies(1): >>24732552 #
    13. etherealG ◴[] No.24732552{3}[source]
    True, but at while later of “tech” is useful to you? I often solve problems with only google sheets. Why bother with an app if you don’t need it. Same for other layers of “infra”.