11
26 Comments

Just use a CaaS

I have been a professional software engineer for 9 years and during that time have spun up probably a dozen side projects on various infrastructures (as well as managing various work-related infrastructures).

What is a CaaS?

A CaaS is a "Container as a Service". This means that it takes a Dockerfile as input and deploys a machine around it. The idea is that this machine can then scale horizontally with increasing load. Google's CaaS is called "Cloud Run". AWS has "Fargate". Azure has "Container Instances". Kubernetes is sometimes called a CaaS but Kubernetes does a lot more than a bare-bones CaaS.

Why is the CaaS model a good fit for most of this community?

The simplest websites are just static pages. These can be easily put on one of the hundreds of static hosting providers and cost basically nothing to serve. Many people in this community are building something that requires at least some backend code though. So you need a server. But chances are good that you do not need complex networking configuration, the ability to process millions of files, edge computing, or Kafka. You just need something that will serve HTML and process some database transactions, and maybe make use of a few compiled libraries like ImageMagick. Oh, and if your app jumps suddenly in popularity, you want to know that your backend will scale to meet the challenge. Better still, the primary input of a CaaS is a Dockerfile so it's relatively easy to recreate your production environment locally.

Why not use Heroku, App Engine, or Elastic Beanstalk?

These are all examples of platforms as a service (PaaS). All have the same problem: they come with rigid frameworks. Rigid frameworks are problematic for a few reasons. First, they can require a lot of configuration and a lot of framework-specific knowledge. This takes time and opens you up to mistakes. Second, the frameworks tend to lock you in. If you go with a more expensive option like Heroku, this might hurt you financially after it becomes very difficult to extract your app. Third, if you need more flexibility, like the ability to run a rust program or write to disk or install operating system packages, it will be difficult at best.

How am I using a CaaS?

I'm using Google Cloud Run for my business: https://fastmap.io. Fastmap is a way to parallelize arbitrary Python code in the cloud with very little setup. It is useful when your code is too slow but spinning Lambdas or Spark would be overkill. I would love feedback if you have it!
The project took about a month and a half to put together from the first commit and I credit the rapid development partially to choosing Cloud Run. Over the next few weeks, I'll be setting up a duplicate platform on AWS Fargate. I'm doing this because while Cloud Run is dead simple to set up, the Google Cloud terms of service leave me concerned (basically, they don't allow cryptocurrency mining on their platform. While I'm not targeting miners, I suspect it will eventually happen and I want to have a backup).

  1. 3

    Yes, I agree.

    However, I think you're overselling the complexity, at least WRT Heroku. With Heroku, I literally just drop in my Rails app and it's fine- no extra config required!

    1. 1

      I never said Heroku was complicated, I said it was expensive :). You're right though, it's very easy.

      My suggestion was that with a CaaS you get way more flexibility and much cheaper scaling for only a little additional complexity.

  2. 1

    Hey there, I'm a little late to the party but I love the idea and I'm unsure as to why there aren't more hosting platforms with this as a core concept.

    You've probably already thought about this...I've been using firebase to make the jump from static websites to dynamic websites and it seemed just fine at first but, I've been reading so many different things about how it is vendor locked-in, not open sourced, and scales terribly (not that I've even gotten to that point yet, but kind of concerned about incurring technical debt if I actually made something people used routinely). I was personally pissed about deploying in Heroku just to realize how painful it would be to configure Lets Encrypt or any free certificate on the free dyno plan. Of course, it becomes super easy once you put a credit card in and upgrade to their $7/month plan.

    Your product would probably appeal to anyone who's a little familiar with DevOps or have struggled in the past hosting. But couldn't you gain more traction by going from a simpler concept (i.e: how hosting a small dynamic landing page would look like, operating a small MVP with wildcards, would it be possible to launch a dynamic web app using CaaS for $0) using fastmap?

    Feel free to pull the rug under me since it is probably trivial and I've got way less experience developing, but I'd honestly try CaaS as a solution for any side project if I understood how those things work better right off the bat. It does occur to me that a noob developer like me might not be your target audience, so sorry if I went off in the wrong direction, kind of hoping to get corrected and learn here :).

    1. 2

      I appreciate the feedback!

      It's possible you misunderstood my post or that I am misunderstanding you. Either way, I like your advice.

      My intention with the post was to provide an introduction to the benefits of a CaaS while sneaking in a little plug for my service at the end. I didn't write this to try to sell the benefits of fastmap being utilized on top of a CaaS.

      That being said, my ultimate goal is to build a single-deploy cloud where you can use a single repo, locally testable as a single web-server process, to deploy a distributed architecture of arbitrary complexity and scalability.

      Until I get there, I think your advice is good - to write up a simple concept for deploying a basic CaaS webserver with fastmap included to show off how easy it is to put up a low-cost application with built-in dyno-worker-like capabilities.

      1. 1

        I didn't write this to try to sell the benefits of fastmap being utilized on top of a CaaS.

        Yup I got that much. Your service is something I've kind of been dreaming of but I didn't make the connection until I read this post.

        You've got yourself a follow, the product sounds amazing. I would honestly be happy to even provide open-source boiler plate of a use case if I do end up doing something like this for a couple of my side projects.

        1. 1

          You've got yourself a follow back!

          It looks like we live in the same city. I'm a big believer of the benefits of entrepreneurs supporting each other in a community. Let me know if you want to meet up / hack on something together sometime soon.

  3. 1

    My app uses memcached in front of the postegres database. I've been meaning to switch to cloud run but am unsure how I'd get memcached to work (or if I even need it). Any thoughts on that?

    1. 1

      Whether you need it or not depends on a lot of things. My assumption from what you say is that you have a layer in your application (Django?) that checks memcached before actually calling your database. In that case, you would just need to change your configuration to use either google's kv store https://cloud.google.com/memorystore or use a 3rd party memcached provider.

      It's also possible that you have a memcached layer that is tightly coupled to a postgres instance and runs directly in front of that database. That's not something I've heard of but it's possible it might just be something I've never encountered. If that's the case, I have no advice :)

  4. 1

    I have been pondering building a github app which builds and deploys to google cloud run. Might anyone have interest in this?

  5. 1

    I'm enjoying Cloud Run so far. The biggest change for me (from a Kubernetes background) was how having secrets set as env vars is not recommended; instead I followed the Django on Cloud Run tutorial making use of GCP Secret Manager.

    One thing on Faragate: It's not really comparable to Cloud Run. It's more of a simplification of Kubernetes. AWS Fargate doesn’t support auto scale and scale-to-zero out of the box. But, it can be configured with Horizontal Pod Autoscale (HPA) or Vertical Pod Autoscale (VPA).

    1. 1

      Fair enough. The out-of-the-box autoscale on Cloud Run is very nice. GCP has always been far simpler than AWS in my humble opinion.

  6. 1

    Any resources you can share? I currently use EC2's and do all the setup in box. I use Docker locally using docker compose but not found the deployment story 1-1.

    I use Django for my stack. But also use workers (Celery and Huey) - how do they play with Fargate? what about external services like redis and RDS?

    1. 1

      My primary experience is with Cloud Run so I can speak with confidence on that platform though I would be surprised if any of this is not true on Fargate.

      Deploying something on Cloud Run is basically the same as doing it on EC2 except for a few differences:

      • Everything is deployed with a Dockerfile so you don't need to do any manual copying or ssh-ing.
      • As another commenter mentioned, with Cloud Run, local and prod environments can be pretty darn close to 1:1 which is a huge advantage.
      • You get autoscaling for free
      • Your serving process (e.g. Django) is started on the last line of your Dockerfile
      • You get error recovery for free (e.g. your instance will just restart)
      • You must assume no state because your containers can shut down at any time. This is a good assumption on EC2 anyway but now you have no choice but to design your system knowing that container instances shut down regularly.

      Otherwise, everything is the same. You get a basic linux server with a filesystem, the ability to install packages, and the ability to access anything on the internet including Celery, Redis, etc.

      1. 1

        Okay sounds good - how does deployment work? For example, deploying all instances? Do they have something like S3 or cloudfront for serving static assets such as front-end assets.

        How does local dev work? Do you just use the docker desktop and run the containers as usual? (I use docker within WSL2 on windows).

        or does cloudrun have a managed layer on top?

        1. 1

          Deploying is two commands done from the directory where the Dockerfile lives:

          • gcloud builds submit
          • gcloud run deploy

          For S3-like functionality, there is "cloud storage" which is basically the same. That being said, I think serving static files from the app server and putting a CDN on top would be the simpler approach if you're just trying to serve a few static assets.

          To make local work like prod, you just run the the same Dockerfile locally - with a few config options (e.g. database url) changed.

  7. 1

    This is great. The best part of using CaaS in my opinion, is your local development is a true 1-1 with the environment that will run in prod. Continue the container revolution for IH!

    Just a few tips on Fargate, I’ve been using it for a few years.

    1. When you deploy a new task definition, the containers will continue to attempt to spin up over and over again if they are unable to check in as a healthy host. I’ve lost many hours to this. When I deployed new content(or at least I thought), I was unable to see that new functionality. Turned out the new task definition was just continually trying to deploy the new containers without reporting a failed deployment.

    2. Be sure to fully understand your scaling policy. I would suggest using Target Tracking Scaling.

    1. 1

      Good tips. In my experience, I tend to run into weird problems on AWS more often than on GCP. In any case, I think an important lesson is to read the docs and know the consequences of what you are doing rather than just trying to wing-it with cloud deployments.

      1. 1

        I agree, ensure you fully understand the products you’re using. Speaking of products, yours looks great!

  8. 1

    This comment was deleted a year ago.

    1. 2

      With Heroku, it shouldn't be too difficult to switch over to a cheaper CaaS-based design eventually. The architecture model of a CaaS is similar to having auto-scaling dynos. The most difficult thing you'll run into will likely be translating your Heroku configuration and workflow to something based on Dockerfiles. And honestly, a Dockerfile is just a list of commands for building a container. If you can handle the command line, a Dockerfile is only a small step forward.

      1. 1

        I'm on Heroku too but I've heard it gets expensive after you amass a lot of users (though I would happily accept that problem). I'm curious, do you know how switching the add ons would work if you transition from Heroku to CaaS? The only add on I have on Heroku right now is a Postgres Database, how do you do db management with a Caas?

        1. 2

          Yup, so there are two options there.

          1. Use a hosted Postgres service like https://www.elephantsql.com/. I've never used them but basically, you're just going to end up putting whatever URL they give you into your app when you connect to the DB.
          2. Use the AWS/GCP/Azure hosted db solution. This will be either AWS RDS, Google Cloud SQL, or Azure database for Postgres. This will probably be a little more configuration than using the outside Postgres service but there are advantages to staying within the same cloud provider.
          1. 1

            Thanks! I'm amazed, so far the work you've mentioned for switching from Heroku to CaaS seems like <1 day of work.

      2. 1

        This comment was deleted a year ago.

        1. 1

          Yup, there is a reason why Heroku exists and was sold for $212 million 😉. They do a very good job making it dead-simple to deploy apps. Putting together a Dockerfile is just a little bit more though. For example, if you have a one line procfile, you can probably do something this simple with a Dockerfile and get the same result:

          FROM python:3.8-slim
          WORKDIR /app
          ADD requirements.txt ./
          RUN pip3 install -r requirements.txt
          COPY . ./
          CMD exec gunicorn --bind :$PORT server:app
          

          So you have 6 lines instead of 1

          1. 1

            This comment was deleted a year ago.

            1. 1

              I commented this elsewhere in the thread, but if you have plugins for Heroku it can be a little more complicated than just setting up your container. You may also need to find a place to host your DB, serve static files, use additional plugins like SendGrid, Redis, etc (IF you're using such plugins). I'm personally holding off on learning all the extra DevOps stuff until Heroku starts burning a whole in my wallet, but I wouldn't advise following in my footsteps.

            2. 1

              Lol. Hey, Heroku is good for what it is. They do make things easier. You don't need to switch. I'm just here to shine the light on other options

    2. 1

      This comment was deleted 4 years ago.

Trending on Indie Hackers
How I grew a side project to 100k Unique Visitors in 7 days with 0 audience 49 comments Competing with Product Hunt: a month later 33 comments Why do you hate marketing? 29 comments My Top 20 Free Tools That I Use Everyday as an Indie Hacker 16 comments $15k revenues in <4 months as a solopreneur 14 comments Use Your Product 13 comments