Render: a Zero DevOps Cloud Platform

I also find it sad how good Heroku still is when compared to Render or other similar services. Sad because Heroku has built such an incredible experience that others still haven’t caught up to after all these years.

Render is close, but they’re still missing a lot of important details that makes deploying Rails apps as easy as Heroku. Instead they kind of throw the manual at you and expect you to read a tutorial.

For exactly these reasons I was expecting for Pulumi to make a bigger splash, but apparently people just like pain.

Hi, I'm actually really sorry I don't post too much and I think when I do I am making the comments a bit short and its causing confusion. I hope this clears things up and is a bit helpful.

To explain the context, I find there seems to be a lack of clarity around K8s. Lets just say, for this post's purposes, I am a _user_ of k8s. That is, I don't actually run the cluster at all, I don't manage its storage, I am operating as a User without full admin access.

I also work in VMware who has the whole Tanzu thing going on so what happened was internal IT set up a K8s cluster for production hosting (maybe it was dogfooding or something I'm not really involved with that team, user only as I said).

I got frustrated when figuring out how to use it however. A bunch of online material is about setting up the K8s infrastructure/cluster, rather than using it as a Dev.

I hope this makes a bit more sense when I said redis was practically zero config.

To explain the setup. I code a python app, and I use docker compose and a single docker-compose.YAML. This YAML gives the build instructions for my app, and minimally (by this I mean with absolute minimal config options) also sets up a postgresDB, RabbitMQ and Redis.

Here's what I mean by minimal:

        redis:
                image: XXXXXXX.YYYYYY.com/dockerhub-proxy-cache/library/redis
                restart: always
                container_name: redis
                command: redis-server --requirepass XXXXXXX 
                ports:
                        - 6379:6379
                environment:
                        - REDIS_REPLICATION_MODE=master
                labels:
                  kompose.volume.storage-class-name: 1XXXXUUIDProvidedByPlatformXXXX1
                  kompose.volume.size: 1Gi
                volumes:
                        - ~/.docker-conf/redis/data/:/data/
                deploy:
                  resources:
                    limits:
                      cpus: '0.5'
                      memory: 2G
                    reservations:
                      cpus: '.1'
                      memory: 20M

I consider this minimal as most of it is boiler plate and I'm just configuring its resources.

So for dev when I want a local spin up I docker-compose build, docker-compose up.

As you can see above,

        volumes:
                - ~/.docker-conf/redis/data/:/data/ 

Gives it persistent storage across builds and deploys.

So to my mind this was pretty easy so far. Then I looked at what was needed to deploy on K8S and I nearly puked. Sorry there is no way I was touching that mess of yaml.

So I just use kompose-convert which uses the single docker-compose.yaml to auto generate all the little yaml babies needed for deploying to staging and prod (the K8S cluster).

Script is essentially:

        docker-compose build
        docker push corpImageLibrary/App:mar-felly2022(version)
        cd ./kubernetes-deploy-files && kompose convert -f ../docker-compose.yml

That's it. Regarding persistent storage which I use, I define that with the docker Kompose label in the main docker-compose.yaml. The goal just being a single file to config everything.

When I kill the deployment I just don't kill the persistent disks, and then deploy all the auto generated yamls at once (including the persistent disks, which wont overwrite them if they exist)

Deploy script:

        #!/bin/bash
        cd ./kubernetes-deploy-files
        kubectl --kubeconfig ../Kubeconfig apply -f \
        db-claim0-persistentvolumeclaim.yaml,\
        db-deployment.yaml,\
        db-service.yaml,\
        fluentd-config.yml,\
        rabbitmq-deployment.yaml,\
        rabbitmq-service.yaml,\
        redis-claim0-persistentvolumeclaim.yaml,\
        redis-deployment.yaml,\
        redis-service.yaml,\
        MYAPP-deployment.yaml,\
        MYAPP-service.yaml

Kill script:

        #!/bin/bash
        cd ./kubernetes-deploy-files
        kubectl --kubeconfig ../Kubeconfig delete -f \
        db-deployment.yaml,\
        db-service.yaml,\
        rabbitmq-deployment.yaml,\
        rabbitmq-service.yaml,\
        redis-deployment.yaml,\
        redis-service.yaml,\
        MYAPP-deployment.yaml,\
        MYAPP-service.yaml

(note I haven't made any edits on any of these yamls they are all auto-generated)

To me this is minimal config compared to trying to integrate with a third party outside of my app network (needing corporate firewall exceptions etc etc). But yea there is internal hosted redis offerings I think but even then I made a pass as the above is just very easy and neat.

Also the persistent disks are all backed up in the background.

I guess it's minimal config when you already have a nice K8S setup ready to use would be a fairer statement :)

Hope this is useful to someone just trying to get a dam app running!

Thanks for the details.

Looking at prices is definitely something I’m going to be doing in the short-to-medium term here. We’ve grown our Heroku bill for years, but I’m not entirely sure what all they take care of that RDS or Aurora wouldn’t also handle.

We currently don’t have anyone who is a dedicated sysadmin, so that’s one thing to keep in mind. We’ve been able to rely on shared sysadmin responsibilities here and there, and have Heroku take care of monitoring if our database has somehow “degraded.” But I do wonder if when Heroku identifies that a database needs to be updated, if they’re really just rebranding something AWS does automatically with RDS. I’m just not sure.