from Hacker News

Apollo – An Extensible Docker-Based Platform as a Service (PaaS)

by norcalkc on 9/29/20, 8:30 PM with 60 comments

  • by alpb on 9/29/20, 9:23 PM

    Despite the nice packaging, it appears to be a single-person maintained project. There are quite a few reasons why no opinionated PaaS built on Docker Swarm or Kubernetes (maybe surprisingly) came even close to being a popular choice in the market. Usually, anyone serious who's going to bet on a PaaS that runs their stack will also need a serious corporate entity (i.e. software vendor) supporting the tools in case things go wrong. Similarly, often many serious companies are better own building their own PaaS on top of these platforms as they realize sooner or later, they want a lot of customization and control over the platform. So far I'm adding this to the pile of people who’ve tried to build a PaaS on top of docker/k8s. I'm not seeing a lot of features to make it stand out, what I'm seeing in the features section is more of an opinionated stack.

  • by gavinray on 9/29/20, 10:32 PM

    This looks incredible! Has some serious offerings against the current Self-Hosted PaaS scene, hope I can check it out over the weekend.

    I have used Dokku[0] in production, and played with CapRover[1] on hobby projects. Flynn was like a better Dokku, before development died.[2]

    CapRover is a great experience, and it's not a toy IMO. It nails the role of "I want to press a button and have a self-hosted Heroku, with a nice dashboard, auto-provisioned HTTPS domains, and be able to deploy a bunch of Docker images or Buildpack apps." A single-node $10 box can run a good number of services.

    This looks well-positioned and closer to something like Nomad, but going through the readme I had a few questions:

      "Apollo requires a manager- or control-node. We call this manager-0. This node runs the entire controlplane and monitoring stack for a cluster and should be sized appropriately (8GB Memory, 2-4 vCPUs)."
    Is there a way to run this single-node and disable some of the peripherals for cheap/play $5-10 instances (disregarding best-practices)? An 8GB mem + 4vCPU DO droplet is $40/mo. Not an arm and a leg, but if you have to add at least a secondary server, seems like minimum would be ~$50/mo?

      "Your space has been created. Now let's cd to its directory: cd $HOME/.apollo/.spaces/demo-1.space"
    Are the Apollo Spaces not meant to be checked in to version control and used for infra + shared between people on your team?

    And final question (sorry if this is dumb):

      Automated infrastructure (currently only DigitalOcean and HETZNER Cloud supported)
    Does this mean I can still deploy to AWS/GCP, I just need to do it manually, or are these infrastructure templates required?

    [0] https://github.com/dokku/dokku

    [1] https://github.com/caprover/caprover

    [2] https://github.com/flynn/flynn

  • by intellix on 9/29/20, 9:02 PM

    Name is a little similar to https://www.apollographql.com/

  • by throwaway77384 on 9/30/20, 9:23 AM

    How does this compare to Dokku?

    Been using Dokku for a year now, and it is quite a joy.

    Admittedly, I'm not in the 1000s of requests per second space that many other people operate in (I'm in the internet equivalent of the Mom & Pop website hoster space). I've found Dokku does everything Heroku does, but I get to control it all, which is really nice.

    Never tried Caprover or the other container solutions, because I'm not big enough to even exceed single-instance sizes at Hetzner.

    My main worries nowadays are:

    - What if popularity shot up? How far does my solution scale?

    - Hackerzzz. Who is out there just trying to damage something. Not sure it's as bad as the media will have you believe it is, but I still want some relatively strong opsec.

    - Disaster recovery. I want to control as much of my stack as possible, so I can fix things when they go wrong, but I just can't seem to shake that eternal worry of 'what have I missed?' in the production DB

    I find it quite hard to strike a balance between over engineering things (boy do I wish I had a load balancer that automatically detected an issue with a node somewhere and then did some sort of seamless failover without losing whatever transaction was in progress at the time lol) and just trusting that the thing will work when it has to.

    The promise of platforms like Heroku is undeniably less hassle, or a worry-free life, but I don't know whether black-box models can ever truly provide that.

  • by randtrain34 on 9/29/20, 10:22 PM

    This seems very similar in concept to https://caprover.com/

  • by mabbo on 9/30/20, 12:03 AM

    Making this all the more confusing, the deployment tool most used inside Amazon is an internal tool called "Apollo". (We mostly hate it.)

    I checked - the primary author of this tool has never worked there.

  • by whalesalad on 9/29/20, 9:06 PM

    I've been wanting to build something like this for a long time, very neat. I haven't had a chance to use it yet but looking through the readme this is a very comprehensive project.

  • by slayerjain on 10/1/20, 8:40 AM

    For Hobby projects I'm loving Lambda proxy from AWS Labs. I'm able to use native Golang frameworks like gin/echo without changing anything much and deploying to Lambda + API gateway. This runs for basically free, and is easy to port out.

  • by slayerjain on 9/30/20, 11:12 AM

    Is this solving the same problem as CloudFoundary for K8s? https://github.com/cloudfoundry/cf-for-k8s

  • by m3adow on 9/30/20, 11:07 AM

    Is this the first self-hosted PaaS solution also running on Kubernetes? As far as I know neither Dokku nor CapRover do, which always deterred me from these applicationsas I'm running K3s at home.

  • by lomkju on 9/30/20, 5:39 AM

    This looks a bit like portainer https://github.com/portainer/portainer

  • by pidster on 9/30/20, 10:45 AM

  • by ngcc_hk on 9/29/20, 10:37 PM

    can similar run in digital ocean? Or is Docker image be published in a DO droplet and update or overwrite remotely to minimise hacking risk.