Render: a Zero DevOps Cloud Platform

In case it helps, we announced $20M funding round in December: https://techcrunch.com/2021/11/22/render-secures-20m-series-...

It is sad to see how Heroku has been totally abandoned by Salesforce. I mention as it's probably Render's closest competitor.

I'm curious what the source of the burn is.

We recently got bit (not quite burned) with the load balancers in the Common Runtime being shared across all apps.

Some piece of malware was associated with one of the IPs of Heroku's load balancers. One of our customers ended up blocking one of our servers associated to that IP because of it. We did some research and we even think we know what app caused it (it's someone's app they host on Heroku), and we don't think it should be flagged as malware, but either way... some other app in Heroku could be truly doing bad things and we would then get our server blocked again.

Heroku's advice was to put up a CDN in front of their load balancers, which has worked for now. But that's extra cost and system complexity just to get around a limitation of Heroku.

We did confirm a Heroku Private Space would eliminate this, since we'd get our own set of IPs for the Private Space's load balancers. But that comes with extra cost, and perhaps even limiting which add-ons we can use in the Private Space.

So although we've generally been happy with Heroku, we are concerned with some technical limitations, like this important (to us) one.

Basic things like rolling deployments are still considered "labs" features.

You need double your number of typical connections to support rolling, combine that with the large price jumps and low connection counts on the plans and it becomes very expensive just to have something that should be standard in a modern PaaS platform. This is but one example.

Heroku wasn't even profitable when it sold

Overpriced yes, but garbage? Heroku is definitely stagnating, but they were integral to a whole new genre of PaaS. Heroku got a ton of people's first apps online. Even today their 12 factor app methodology is incredibly useful/powerful.

Now that said I totally relate to having strong negative opinions after being burned. I've got a few orgs like that too. What did they do for you?

Edit: nevermind I should have refreshed. You already answered in a sibling comment

Right now I'm on my third job in my career where we've migrated off from Heroku. There have got to be agencies out there that specialize in this, right? If not, it seems like a hell of an opportunity for someone.

I agree, but people also used offsite, hosted memcache... so... shrug

Coincidentally, we just had a scoping meeting for Render Postgres v2. PITR/HA are both top of mind.

Interestingly, Heroku improved and grew quite a bit after the acquisition (2010), but ultimately, getting acquired was a personal/financial decision for the founders: https://twitter.com/_adamwiggins_/status/1334595789201563649

I'm very happy to share my own acquisition calculus over email (in profile).

Mind pointing me to the podcast? Cloudflare is quite easy to set up in front of Render now.

I have ~10 websites / web apps with Render + Cloudflare and setting up cloudflare proxying for render is super easy.

You can even proxy * domains (i.e. requests for *.foo.com going to a single render server / ip address).

This is valid and helpful feedback; it also validates our priorities because we have ongoing projects to address each of these points.

Where’s the new one? Loving render.com so far but latency in Spain is not great.

Since a lot of their customers share passwords or only use git automation to deploy without logging in, as they charge by team members, they've started to count git committers as "team members" which blows my mind: even if you can justify some sort of "cost" associated with having a team member, I can't fathom why you would charge by the git committer, except for jacking up your revenue in preparation for a sales or the next VC round or some non-customer related matter.

We have a large team of devs who didn't have Netlify accounts. They couldn't log in to see build logs, change configs, or anything else. Aside from seeing the deploy preview URLs, they wouldn't even know that we used Netlify to deploy our static sites. We were paying ~$120/mo for three accounts for managers, bandwidth, and extra build minutes.

Then we get an email saying that because we have 20 devs who commit to our private repo of the site we deploy, we need to pay for 20 member accounts. Each member account is $99/mo. So, because they started reading our git commits to count authors, our monthly bill was going to go from $120 to over $2,000 (way more than what we pay for all of Google Cloud).

Neither do I. I just want to deploy my app and get on with developing my project, not engage in an infrastructure jungle.

AWS and GCP are a nightmare.

I mostly don't write CI pipelines, I generally use my existing templates. Those are little annoying quick tasks, not a big deal.

There's a nice poetry to seeing a system autorecover from outages or scale correctly when it gets a huge burst of traffic. From being able to help an engineer do something they think is impossible, and do it easily.

1000 euro/day, tiny workload, endless stream of work available?

Horrible indeed. ;)

It's the easiest part of my job. It's just YAML indicating steps. Each step is a "thing to do". There's really no magic to it or terror or discomfort.

It is a part of my job, however so far I have found that if your pipelines are getting too complicated, it is time to break them out into build docker images, bash scripts etc.

If you don't care about optimizing latency, we definitely didn't build Fly.io for you. That's not because you want the wrong thing, though. It's because we have a narrow and, we think, very valuable focus.

We're actually not in the same niche as Render! At least, I'm pretty sure we're building towards different things. But we are each (a) small (b) scrapping with large public cloud providers and (c) attempting to generate a self sustaining startup reaction.

Attracting people with new apps is a way both of us prove the value of what we're doing. Attracting people who want to run their apps close to their users is the way we make a lot of money.

I think GP means adding a redis container to an existing k8s cluster. Which I suppose, especially without persistence or HA, is not much more than specifying the image.

GP is saying adding a Redis container to docker/k8s is (nearly) zero config, and they are correct, with the caveat that only if you don't need persistence features.

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!

That's great. They make good points on securing databases as well. Everything has to be open with Heroku's basic dynos. It would be nice to secure PostgreSQL or Elasticsearch so the IP is not publicly available.

Our you can pay the premium and have that vendor lie to you. Some of us have pretty bed experiences with cloud support teams.

OK, I've changed the title. Submitted title was "Render: Redis that just works".

Can you explain what you mean?

Generally “me too” HN comments are frowned upon, but I also clicked because I thought this was a rewrite of a redis-compatible offering that perhaps offered something like zero-click sharding or something.