4 ms·

(Render CEO) Funny story. I first used Netlify in 2017 after being thwarted repeatedly by S3+Cloudfront deploy hacks. I loved the product so much I became a voc

by anurag 3y ago

(Render CEO) Funny story. I first used Netlify in 2017 after being thwarted repeatedly by S3+Cloudfront deploy hacks. I loved the product so much I became a vocal advocate and eventually decided to build the same DX for the entire application stack. When Render first launched, it didn't have static sites because we assumed developers would just use Netlify with their Render backend; unfortunately at the time (but fortunately these days) our customers have always wanted everything under one roof, so I begrudgingly built static sites into Render in late 2018. However, to this day, Netlify's static site product remains ahead of Render, and we haven't invested as heavily in it as other products in our portfolio. Why? Because static site hosting is now a commoditized market, and we can differentiate ourselves better elsewhere. Netlify sees this too and is changing course accordingly (based on bobfunk/Matt's comment above). I know they will be successful, and they deserve all the good things that come their way because they've materially advanced web development over the last several years (even inspiring ZEIT to pivot into Next.js+Vercel). Jared: I think your beef might actually be with serverless compute and the restrictions that come with it, especially when vendors try to force it down developers' throats as the only way to build apps. The A in JAM can (and often should) be a long running server instead of a thin Lambda shim, but Netlify is a lot less guilty of pushing this narrative compared to their peers.

stringtoint 3y ago
Love Render and Netlify. I've been meaning to try Render's capabilities for static websites but Netlify has just worked so far that I haven't bothered yet.
jaredcwhite 3y ago
Original author here, and I appreciate your perspective! Interesting to know the connection of how one shift in the market helped influence another. A couple of short thoughts: > offer everything under one roof To me this is THE value prop. I don't want to deal with the headache of setting up multiple providers and API services and a pandora's box of integrations just to get a straightforward project up and running. In addition, I ideally want my production software choices to mirror what I can run on my local machine. The fact I can run PostgreSQL/Redis/Ruby/Node/SSGs/whatever here, and then push it all up somewhere and expect that It Just Works is fantastic. Bonus that it's all just accessible FLOSS tooling for the most part. > I think your beef might actually be with serverless compute and the restrictions that come with it That is indeed a beef I have…not that there aren't good uses for FaaS architecture, but it's just generally not been anything that solves real problems I have besides simply spinning up a "boring" monolith. Certainly we can't say it's all Netlify's fault this became a big buzzword, but let's be honest: it's been a real slog to claw back recognition and mindshare that server processes are pretty cool actually, and Netlify certainly hasn't helped in this regard. You guys, Fly, Railway, and plenty of other hosting companies out there are innovating in this space, and it's truly great to see.
- skybrian 3y ago
  There's value in that, but I think dealing with two vendors (web servers and database) is not terrible, based on my limited experience so far as a hobbyist developer with Deno Deploy and Neon. The differences between Deno running locally and Deno Deploy can be a bit annoying, such as not supporting npm's on Deploy yet. I expect that will improve. My development environment is pretty light: Deno itself and VS Code. So far I haven't needed to set up a database locally, or even install any client-side Postgres tools. (The database driver is an npm library that wraps fetch.)
Justsignedup 3y ago
I used render for a bit and I have to say, basic static site building is more than enough. What you had perfectly met the needs I had for netlify so I got to save a ton. My biggest issue with render was lack of command line tools that allow you to do things like change env vars during builds. It was the biggest hurdle for me. I'm rooting for you guys. I see tons of potential.
friendly_wizard 3y ago
I, like I assume everyone else who read this article, was interested in Render so I clicked through and started perusing the docs. I don't understand at all how secrets are meant to be managed by secret files when deploying docker containers. The secret sauce (haha) of secret files is that they don't survive the layer they're used in. How is that going to help at runtime? For accessing private repos to compile your go app in a build layer, sure. Hitting the DB or another API with a bearer token though? Seems like a non-starter. The docs even reference this > Unlike build args, secret mounts aren’t persisted in your built image.
- deleted 3y ago
  [deleted]
- anurag 3y ago
  The doc you saw refers only to how secret files are treated at build time. At runtime, Render mounts your secret file at `/etc/secrets/FILENAME` in your container. Your application can then read it like any other file on the local filesystem. Of course, you can always store your secrets in Render environment variables and use them via ENV statements at runtime.

by anurag 3y ago

stringtoint 3y ago

Love Render and Netlify. I've been meaning to try Render's capabilities for static websites but Netlify has just worked so far that I haven't bothered yet.

jaredcwhite 3y ago

Original author here, and I appreciate your perspective! Interesting to know the connection of how one shift in the market helped influence another. A couple of short thoughts: > offer everything under one roof To me this is THE value prop. I don't want to deal with the headache of setting up multiple providers and API services and a pandora's box of integrations just to get a straightforward project up and running. In addition, I ideally want my production software choices to mirror what I can run on my local machine. The fact I can run PostgreSQL/Redis/Ruby/Node/SSGs/whatever here, and then push it all up somewhere and expect that It Just Works is fantastic. Bonus that it's all just accessible FLOSS tooling for the most part. > I think your beef might actually be with serverless compute and the restrictions that come with it That is indeed a beef I have…not that there aren't good uses for FaaS architecture, but it's just generally not been anything that solves real problems I have besides simply spinning up a "boring" monolith. Certainly we can't say it's all Netlify's fault this became a big buzzword, but let's be honest: it's been a real slog to claw back recognition and mindshare that server processes are pretty cool actually, and Netlify certainly hasn't helped in this regard. You guys, Fly, Railway, and plenty of other hosting companies out there are innovating in this space, and it's truly great to see.

skybrian 3y ago
There's value in that, but I think dealing with two vendors (web servers and database) is not terrible, based on my limited experience so far as a hobbyist developer with Deno Deploy and Neon. The differences between Deno running locally and Deno Deploy can be a bit annoying, such as not supporting npm's on Deploy yet. I expect that will improve. My development environment is pretty light: Deno itself and VS Code. So far I haven't needed to set up a database locally, or even install any client-side Postgres tools. (The database driver is an npm library that wraps fetch.)

Justsignedup 3y ago

I used render for a bit and I have to say, basic static site building is more than enough. What you had perfectly met the needs I had for netlify so I got to save a ton. My biggest issue with render was lack of command line tools that allow you to do things like change env vars during builds. It was the biggest hurdle for me. I'm rooting for you guys. I see tons of potential.

friendly_wizard 3y ago

I, like I assume everyone else who read this article, was interested in Render so I clicked through and started perusing the docs. I don't understand at all how secrets are meant to be managed by secret files when deploying docker containers. The secret sauce (haha) of secret files is that they don't survive the layer they're used in. How is that going to help at runtime? For accessing private repos to compile your go app in a build layer, sure. Hitting the DB or another API with a bearer token though? Seems like a non-starter. The docs even reference this > Unlike build args, secret mounts aren’t persisted in your built image.

deleted 3y ago
[deleted]
anurag 3y ago
The doc you saw refers only to how secret files are treated at build time. At runtime, Render mounts your secret file at `/etc/secrets/FILENAME` in your container. Your application can then read it like any other file on the local filesystem. Of course, you can always store your secrets in Render environment variables and use them via ENV statements at runtime.