15 ms·

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

108 points by kchhina 6y ago

intellix 6y ago
Name is a little similar to https://www.apollographql.com/ https://www.apollographql.com/
- verisimilidude 6y ago
  Also: https://github.com/ApolloAuto/apollo https://github.com/ApolloAuto/apollo It’s a contested open source project name, for sure.
  - agloeregrets 6y ago
    And let’s not forget the well-liked iOS Reddit client as well. Or the Greek god Or the moon missions. Or Counter Culture’s Light Roast beans. Basically the name is a bit tired and few actually have a reason to call it that. (Apollo the Reddit client to browse the world of Reddit which has an alien as it’s avatar almost makes sense.)
    - andrewxdiamond 6y ago
      Amazon engineers will also recognize Apollo as something else https://www.allthingsdistributed.com/2014/11/apollo-amazon-deployment-engine.html https://www.allthingsdistributed.com/2014/11/apollo-amazon-d...
      - christophilus 6y ago
        As will old NASA astronauts.
    - zoom6628 6y ago
      or the premium workstation of the 80s.
      - iav 6y ago
        Or the publicly traded private equity / credit investor? Or the parent company of University of Phoenix Online? PS the private equity firm actually owns the education company since 2016... think about that confusion
        gabereiser 6y ago
        Or Adama from BSG? Or the short track olympic skater from US? Or Apollo.io for structured sales data? Or are we talking about Adaptive Patient-Oriented Longitudinal Learning and Optimization?
- khy 6y ago
  Not sure which is more overloaded: "apollo" or "spark".
- derfabianpeter 6y ago
  Yeah sorry for naming. Did 0 research upfront. My dog is named "Apollo, I'm a not-so-creative guy, things just evolved and now here we are!
whalesalad 6y ago
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.
- derfabianpeter 6y ago
  Thanks for the kind words. Hopefully you'll find the time to verify if it would fit your needs!
alpb 6y ago
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.
- zyang 6y ago
  I remember first time seeing Elastic Search around 2012. Shay Banon was the sole commiter for over two years at the time. Never underestimate determined founders.
- slayerjain 6y ago
  What are other docker/k8s based PaaS you've tried?
- giovannibonetti 6y ago
  What about Google App Engine Flex, Google Cloud Run and Amazon Fargate? In my company we have been using App Engine Flex in production successfully for a few years already.
  - alpb 6y ago
    Disclaimer: I work on Cloud Run. In my comment I was referring to open source PaaS projects building on Kubernetes/Docker. Those are managed services where you aren’t exposed to the underlying infra (to varying degrees). So they aren’t apples to apples with this project.
- gavinray 6y ago
  The fact that it works with an existing docker-compose.yaml and will provision itself on a cloud for you is pretty compelling I think. I have tried the Docker AWS ECS plugin for deploying your compose stack, and it's buggy. The AWS ECS CLI would deploy docker-compose files in V1. V2 (now called Copilot) has shifted away from this, and it uses a custom manifest YAML file. Copilot isn't bad. Most of the platforms I work on have a docker-compose stack with Postgres, a backend API, a frontend, and potentially ancillary services. Anything that integrates well with this is a godsend tbh, because otherwise you need to maintain two sets of configuration and keep them in sync.
randtrain34 6y ago
This seems very similar in concept to https://caprover.com/ https://caprover.com/
- axbytg 6y ago
  Looks like the main difference is docker compose compatibility but admittedly I have more reading to do. Still tho that is a good difference! I have multiple caprover nodes in prod for hobby stuff so absolutely not knocking it.
  - filmgirlcw 6y ago
    Yeah that seems like the main difference. Like you, I use CapRover for hobby stuff and love it. But Docker compose could make this really compelling too.
  - yowlingcat 6y ago
    Docker Compose compatibility is major. I just want a seamless Heroku like experience but with Docker Compose. Is that too much to ask?
  - zapt02 6y ago
    CapRover does support docker-compose. Maybe not as streamlined as some other platforms but you can use it. https://caprover.com/docs/docker-compose.html https://caprover.com/docs/docker-compose.html
    - gavinray 6y ago
      I know the docs make it look like it does, but it doesn't really. What it actually supports is copy + pasting sections of Docker Compose for prebuilt images. So let's say you have a docker-compose.yaml where one of your services uses "build"/"context" and points to a local Dockerfile. You cannot deploy this to CapRover (in this way, through docker-compose.yaml). The docker-compose support is more geared towards the "one-click" apps they have when you want to deploy something like pgAdmin or MySQL which uses a prebuilt image. Because of this, it means you can't really deploy your existing setup. From the instructions: 1. Navigate to Apps 2. Click on "One Click Apps/Databases" 3. Navigate to the very bottom of the list, and click on the last item, called >> TEMPLATE << ^^ Because this is happening on your serverside instance, in a web app, it has no context for local files. The "Alternative Approach" is to connect to your instance and upload the source + manually run "docker-compose up" with it wired to the overlay network. This is not a good or scalable solution IMO.
gavinray 6y ago
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 https://github.com/dokku/dokku [1] https://github.com/caprover/caprover https://github.com/caprover/caprover [2] https://github.com/flynn/flynn https://github.com/flynn/flynn
- filmgirlcw 6y ago
  Agreed with all of this. The other option I would mention, although it has a wonky pricing structure is Cloudron [1]. I use CapRover on a spare droplet and it’s a really good solution. This looks like a compelling option too. [1]: https://www.cloudron.io/ https://www.cloudron.io/
  - derfabianpeter 6y ago
    Author of apollo here. Using multiple Cloudron instances for production stuff and am still heavily inspired by the operational stability and ease of app-onboarding the Cloudron team has managed to maintain. apollo strives to deliver a Cloudron-like experience (in terms of stability) over time.
ngcc_hk 6y ago
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.
mabbo 6y ago
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.
- yowlingcat 6y ago
  It's painful. Many a day I thought of purchasing a box of oranges to pelt at the moon. In futility? Yes. Just like Apollo. Our team awaited the promised tangerines with hope. And yet they never arrived.
lomkju 6y ago
This looks a bit like portainer https://github.com/portainer/portainer https://github.com/portainer/portainer
throwaway77384 6y ago
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.
- dig1 6y ago
  I've been using Dokku for years, and I have only positive words for it. Here is my experience regarding your questions: - Scaling: Dokku can scale your application (via "dokku ps:scale" command) on the same machine. If you are concerned with spikes, put Cloudflare (free tier) in front, it will solve most of the problems. - Hacking: Dokku will expose Nginx and proxy requests to your application from the public. Assuming the rest of the system is behind firewall (eg. iptables with exposed only ssh/https/http ports) and the system is regularly updated, maybe the only critical part is how your application is secure (eg. XSS or SQL injection attacks). If you are using a sound framework and don't abuse it too much, things should be sufficient. Again, if you are behind Cloudflare, it can help a bit here. - Recovery: All your code is on git and you can easily replicate it on the new Dokku instance. If you happen to use a database as storage, frequent database dumps are advised (eg. daily cron job that will send dumps to Hetzner backup storage). - Load balancing: Because Dokku is using Nginx in front of your application, starting two (or more) application instances ("ps:scale") will be good enough. Notice however that this will be done on one machine only. If you want to spread it over 2 machines for example, install Dokku on both, git deploy on both (make or shell script will help) and put Cloudflare load balancer in front of it ($5/mo for two origins). Or you can use DNS instead; look for DNS load balancing.
pidster 6y ago
Looks a tiny bit like: https://github.com/capgemini/apollo https://github.com/capgemini/apollo
- derfabianpeter 6y ago
  Never heard of that software but yeah, seems apollo is a good name for all things infrastructure and platform :D
m3adow 6y ago
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.
- sradman 6y ago
  I assumed that Knative [1] is the canonical self-hosted PaaS for Kubernetes. It is branded as Cloud Run [2] by Google. I'm not sure how it compares feature-by-feature with Dokku nor a 12-Factor App PaaS like Heroku. [1] https://cloud.google.com/knative https://cloud.google.com/knative [2] https://cloud.google.com/run https://cloud.google.com/run
  - m3adow 6y ago
    Isn't Knative for functions & serverless only? That's not my main scenario at home.
    - sradman 6y ago
      If Knative is more self-hosted FaaS than PaaS, that explains the core use case for Apollo; a traditional 12-Factor App PaaS for Kubernetes/Docker-Swarm. Knative supports a Serving Spec for routing (like AWS API Gateway) but doesn't seem to have buildpacks for 12-Factor App frameworks, as far as I can see. Apex Up [1] deploys web apps on top of AWS Lambda using Amazon's API Gateway as the RESTful routing proxy. Maybe something like Apex Up is required to transform Knative into a PaaS for historical 12-Factor App frameworks. ZEIT Now 2.0 did the same thing for Serverless (Cloudflare Workers only?) but the company has been renamed Vercel and has pivoted around Next.js. [1] https://github.com/apex/up https://github.com/apex/up
      - slayerjain 6y ago
        AWS now also provides native support for deploying 'regular' web apps using lambda + API gateway. I've been using this for my hobby projects - https://github.com/awslabs/aws-lambda-go-api-proxy https://github.com/awslabs/aws-lambda-go-api-proxy
slayerjain 6y ago
Is this solving the same problem as CloudFoundary for K8s? https://github.com/cloudfoundry/cf-for-k8s https://github.com/cloudfoundry/cf-for-k8s
slayerjain 6y ago
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.

108 points by kchhina 6y ago

intellix 6y ago

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

verisimilidude 6y ago
Also: https://github.com/ApolloAuto/apollo https://github.com/ApolloAuto/apollo It’s a contested open source project name, for sure.
- agloeregrets 6y ago
  And let’s not forget the well-liked iOS Reddit client as well. Or the Greek god Or the moon missions. Or Counter Culture’s Light Roast beans. Basically the name is a bit tired and few actually have a reason to call it that. (Apollo the Reddit client to browse the world of Reddit which has an alien as it’s avatar almost makes sense.)
  - andrewxdiamond 6y ago
    Amazon engineers will also recognize Apollo as something else https://www.allthingsdistributed.com/2014/11/apollo-amazon-deployment-engine.html https://www.allthingsdistributed.com/2014/11/apollo-amazon-d...
    - christophilus 6y ago
      As will old NASA astronauts.
  - zoom6628 6y ago
    or the premium workstation of the 80s.
    - iav 6y ago
      Or the publicly traded private equity / credit investor? Or the parent company of University of Phoenix Online? PS the private equity firm actually owns the education company since 2016... think about that confusion
      - gabereiser 6y ago
        Or Adama from BSG? Or the short track olympic skater from US? Or Apollo.io for structured sales data? Or are we talking about Adaptive Patient-Oriented Longitudinal Learning and Optimization?
khy 6y ago
Not sure which is more overloaded: "apollo" or "spark".
derfabianpeter 6y ago
Yeah sorry for naming. Did 0 research upfront. My dog is named "Apollo, I'm a not-so-creative guy, things just evolved and now here we are!

whalesalad 6y ago

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.

derfabianpeter 6y ago
Thanks for the kind words. Hopefully you'll find the time to verify if it would fit your needs!

alpb 6y ago

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.

zyang 6y ago
I remember first time seeing Elastic Search around 2012. Shay Banon was the sole commiter for over two years at the time. Never underestimate determined founders.
slayerjain 6y ago
What are other docker/k8s based PaaS you've tried?
giovannibonetti 6y ago
What about Google App Engine Flex, Google Cloud Run and Amazon Fargate? In my company we have been using App Engine Flex in production successfully for a few years already.
- alpb 6y ago
  Disclaimer: I work on Cloud Run. In my comment I was referring to open source PaaS projects building on Kubernetes/Docker. Those are managed services where you aren’t exposed to the underlying infra (to varying degrees). So they aren’t apples to apples with this project.
gavinray 6y ago
The fact that it works with an existing docker-compose.yaml and will provision itself on a cloud for you is pretty compelling I think. I have tried the Docker AWS ECS plugin for deploying your compose stack, and it's buggy. The AWS ECS CLI would deploy docker-compose files in V1. V2 (now called Copilot) has shifted away from this, and it uses a custom manifest YAML file. Copilot isn't bad. Most of the platforms I work on have a docker-compose stack with Postgres, a backend API, a frontend, and potentially ancillary services. Anything that integrates well with this is a godsend tbh, because otherwise you need to maintain two sets of configuration and keep them in sync.

randtrain34 6y ago

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

axbytg 6y ago
Looks like the main difference is docker compose compatibility but admittedly I have more reading to do. Still tho that is a good difference! I have multiple caprover nodes in prod for hobby stuff so absolutely not knocking it.
- filmgirlcw 6y ago
  Yeah that seems like the main difference. Like you, I use CapRover for hobby stuff and love it. But Docker compose could make this really compelling too.
- yowlingcat 6y ago
  Docker Compose compatibility is major. I just want a seamless Heroku like experience but with Docker Compose. Is that too much to ask?
- zapt02 6y ago
  CapRover does support docker-compose. Maybe not as streamlined as some other platforms but you can use it. https://caprover.com/docs/docker-compose.html https://caprover.com/docs/docker-compose.html
  - gavinray 6y ago
    I know the docs make it look like it does, but it doesn't really. What it actually supports is copy + pasting sections of Docker Compose for prebuilt images. So let's say you have a docker-compose.yaml where one of your services uses "build"/"context" and points to a local Dockerfile. You cannot deploy this to CapRover (in this way, through docker-compose.yaml). The docker-compose support is more geared towards the "one-click" apps they have when you want to deploy something like pgAdmin or MySQL which uses a prebuilt image. Because of this, it means you can't really deploy your existing setup. From the instructions: 1. Navigate to Apps 2. Click on "One Click Apps/Databases" 3. Navigate to the very bottom of the list, and click on the last item, called >> TEMPLATE << ^^ Because this is happening on your serverside instance, in a web app, it has no context for local files. The "Alternative Approach" is to connect to your instance and upload the source + manually run "docker-compose up" with it wired to the overlay network. This is not a good or scalable solution IMO.

gavinray 6y ago

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 https://github.com/dokku/dokku [1] https://github.com/caprover/caprover https://github.com/caprover/caprover [2] https://github.com/flynn/flynn https://github.com/flynn/flynn

filmgirlcw 6y ago
Agreed with all of this. The other option I would mention, although it has a wonky pricing structure is Cloudron [1]. I use CapRover on a spare droplet and it’s a really good solution. This looks like a compelling option too. [1]: https://www.cloudron.io/ https://www.cloudron.io/
- derfabianpeter 6y ago
  Author of apollo here. Using multiple Cloudron instances for production stuff and am still heavily inspired by the operational stability and ease of app-onboarding the Cloudron team has managed to maintain. apollo strives to deliver a Cloudron-like experience (in terms of stability) over time.

ngcc_hk 6y ago

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.

mabbo 6y ago

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.

yowlingcat 6y ago
It's painful. Many a day I thought of purchasing a box of oranges to pelt at the moon. In futility? Yes. Just like Apollo. Our team awaited the promised tangerines with hope. And yet they never arrived.

lomkju 6y ago

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

throwaway77384 6y ago

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.

dig1 6y ago
I've been using Dokku for years, and I have only positive words for it. Here is my experience regarding your questions: - Scaling: Dokku can scale your application (via "dokku ps:scale" command) on the same machine. If you are concerned with spikes, put Cloudflare (free tier) in front, it will solve most of the problems. - Hacking: Dokku will expose Nginx and proxy requests to your application from the public. Assuming the rest of the system is behind firewall (eg. iptables with exposed only ssh/https/http ports) and the system is regularly updated, maybe the only critical part is how your application is secure (eg. XSS or SQL injection attacks). If you are using a sound framework and don't abuse it too much, things should be sufficient. Again, if you are behind Cloudflare, it can help a bit here. - Recovery: All your code is on git and you can easily replicate it on the new Dokku instance. If you happen to use a database as storage, frequent database dumps are advised (eg. daily cron job that will send dumps to Hetzner backup storage). - Load balancing: Because Dokku is using Nginx in front of your application, starting two (or more) application instances ("ps:scale") will be good enough. Notice however that this will be done on one machine only. If you want to spread it over 2 machines for example, install Dokku on both, git deploy on both (make or shell script will help) and put Cloudflare load balancer in front of it ($5/mo for two origins). Or you can use DNS instead; look for DNS load balancing.

pidster 6y ago

Looks a tiny bit like: https://github.com/capgemini/apollo https://github.com/capgemini/apollo

derfabianpeter 6y ago
Never heard of that software but yeah, seems apollo is a good name for all things infrastructure and platform :D

m3adow 6y ago

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.

sradman 6y ago
I assumed that Knative [1] is the canonical self-hosted PaaS for Kubernetes. It is branded as Cloud Run [2] by Google. I'm not sure how it compares feature-by-feature with Dokku nor a 12-Factor App PaaS like Heroku. [1] https://cloud.google.com/knative https://cloud.google.com/knative [2] https://cloud.google.com/run https://cloud.google.com/run
- m3adow 6y ago
  Isn't Knative for functions & serverless only? That's not my main scenario at home.
  - sradman 6y ago
    If Knative is more self-hosted FaaS than PaaS, that explains the core use case for Apollo; a traditional 12-Factor App PaaS for Kubernetes/Docker-Swarm. Knative supports a Serving Spec for routing (like AWS API Gateway) but doesn't seem to have buildpacks for 12-Factor App frameworks, as far as I can see. Apex Up [1] deploys web apps on top of AWS Lambda using Amazon's API Gateway as the RESTful routing proxy. Maybe something like Apex Up is required to transform Knative into a PaaS for historical 12-Factor App frameworks. ZEIT Now 2.0 did the same thing for Serverless (Cloudflare Workers only?) but the company has been renamed Vercel and has pivoted around Next.js. [1] https://github.com/apex/up https://github.com/apex/up
    - slayerjain 6y ago
      AWS now also provides native support for deploying 'regular' web apps using lambda + API gateway. I've been using this for my hobby projects - https://github.com/awslabs/aws-lambda-go-api-proxy https://github.com/awslabs/aws-lambda-go-api-proxy

slayerjain 6y ago

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

slayerjain 6y ago

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.