Forem: Anurag Goel

Why Render

Anurag Goel — Wed, 29 Sep 2021 16:46:02 +0000

When I joined Stripe in 2011, the company had four full-time engineers. Even then, one of them was focused exclusively on managing our AWS infrastructure. By the time I left in 2016, the engineering organization had grown to 120, and the team that managed AWS to 25. We had one of the strongest engineering teams on the planet, but more than a fifth of it was focused on undifferentiated AWS heavy lifting that our customers didn’t know or care about.

Assuming a typical Bay Area cost-to-company of $200K per engineer, managing AWS likely cost Stripe at least $5 million in 2016. This was in addition to their AWS bill, equity compensation, and the often ignored organizational overhead that increases with every new hire.

Stripe is hardly alone in spending millions of dollars on DevOps each year. According to data published by the U.S. Bureau of Labor Statistics, businesses spent $78 billion on DevOps salaries in 2020. Ironically, this number is greater than global spending on public cloud providers, estimated at $65 billion in 2020.

DevOps engineers cost much more than the cloud providers they manage.

What do we get for $78 billion? Most DevOps time is spent on tasks that are painfully similar across every organization. Nearly every software stack requires the same infrastructure, tooling, and automation to operate reliably and to enable developers to focus on unique business concerns. There are, of course, minor yet important differences across companies, but the decision to build an internal deployment platform is typically made well before these differences emerge, and is often based on what’s fashionable or familiar. As a result, businesses end up with an ever-expanding DevOps footprint to maintain and expand undifferentiated platforms. Sadly, all this effort and expense is irrelevant and invisible to their customers.

Why don’t more companies choose to scale on a platform like Heroku that minimizes the need for DevOps engineers? When it launched in 2007, Heroku provided a uniquely incredible experience for developers building web apps with an up-and-coming framework called Ruby on Rails. In many ways, this power duo of technologies focused on the developer experience helped usher in Web 2.0 and all the innovation that accompanied it. Sadly, after Salesforce acquired Heroku in 2010, the rate of innovation on the platform began to slow, eventually coming to a standstill in recent years. For companies that needed more than a simple web app, Heroku’s feature set was often incomplete. The lack of persistent disks meant tools like Elasticsearch couldn’t run on Heroku; missing private networking was a deal breaker for security-conscious companies. Websockets support came very late, and HTTP/2 didn’t show up at all. In contrast, AWS kept adding new features and products at an incredible pace, ultimately conditioning new companies to skip Heroku and go straight to AWS while resigning themselves to poor developer experience and reduced iteration speed.

Fast-forward to today, and most new applications are being packaged and deployed as containers, often with Kubernetes. Let loose on the world by Google in 2015, it has quickly replaced VMs as the target management layer for infrastructure, promising portability and automation for containerized workloads. Large corporate marketing budgets have certainly helped, making Kubernetes the tool of choice for DevOps teams managing applications in the cloud. However, in adopting Kubernetes we have traded the mostly well-understood complexity of AWS for a labyrinthian ecosystem that is as convoluted as it is inconsistent in quality. This has forced every company to build their own internal PaaS so application developers can focus on code. Ironically, these custom platforms look more similar than ever, since they're all based on Kubernetes.

This is the $78 billion question: if every internal PaaS looks the same, why waste inordinate amounts of time and money on building and managing these platforms at every company?

Render is the answer to this question: we’re building the modern PaaS every team and company needs to ship better software faster, effectively becoming the ever-expanding devops team for our customers.

Our relentless focus on developer experience is matched only by our resolve to offer customers all the infrastructure flexibility they need without the associated complexity. This has helped us evolve from what started as a passion project in late 2017 to something that looks very different today:

Tens of thousands of developers and businesses have created more than 300,000 services on Render. In addition to APIs and full stack apps, we now support static sites, cron jobs, managed PostgreSQL databases, background workers, private services, and of course, Docker containers, with more managed services on the way.
We've launched multiple industry-firsts in the PaaS market, including private networking, persistent storage, managed wildcard SSL, and true resource-based autoscaling, effectively blurring the boundaries between PaaS and IaaS.
Most importantly, Render has grown to include immensely talented, kind, and diverse humans with stellar backgrounds at companies like Stripe, Twitter, Uber, Lyft, Twitch, LinkedIn, and Heroku. We're always hiring!

As we grow, our goal remains the same: empower developers and businesses to ship better products faster by eliminating DevOps. We’re working to end the tyranny of complexity forced on developers by cloud providers who’d rather sell certifications than focus on developer productivity. We are deprecating antiquated definitions of PaaS and IaaS, combining delightful developer experiences with the flexibility today's applications need. Most importantly, we are asking developers around the world to expect much more from the cloud. Let's get started.

Distributed Elixir with Mix Releases and libcluster

Anurag Goel — Tue, 30 Jul 2019 18:21:48 +0000

This is a guide to deploying a distributed Elixir cluster on Render using libcluster, Phoenix and Mix releases. The cluster is set up to discover nodes automatically and keep the node list current as they join or leave the cluster.

We'll start off with a bare Phoenix project, modify it to use Mix releases and libcluster and deploy it on Render. The full source code for this example is available at https://github.com/render-examples/elixir_cluster.

Create a Phoenix App

Create a new Phoenix app in the terminal. We don't need a database in this example, so we're passing the --no-ecto flag to mix.

   # install phx.new; feel free to change 1.4.9 to a different version
   $ mix archive.install hex phx_new 1.4.9
   # create a new Phoenix app
   $ mix phx.new elixir_cluster_demo --no-ecto # also fetch and install dependencies
   $ cd elixir_cluster_demo

Update mix.exs to add libcluster to deps.

   defp deps do
     [ ...,
       {:libcluster, "~> 3.1"}
     ]

Then run mix deps.get in your terminal to update dependencies.

Configure Mix Releases

Create runtime configuration needed for Mix releases.

Rename config/prod.secret.exs to config/releases.exs.
Change use Mix.Config in your new config/releases.exs file to import Config.
Uncomment the following line in config/releases.exs:

   config :elixir_cluster_demo, ElixirClusterDemoWeb.Endpoint, server: true

Finally, update config/prod.exs to delete the line import_config "prod.secret.exs" at the bottom.

Configure libcluster

Our setup will create nodes with names like elixir-cluster-demo@10.200.30.4, where the IP addresses are dynamic. Render assigns IPs to nodes when they first start, and every deploy results in a new node IP. This is where libcluster comes in: it enables automatic cluster formation through multiple configurable cluster management strategies.

Given dynamic node IPs, DNS is the best way to reliably form a cluster and keep it up to date. Consequently, we will use libcluster's DNS strategy for cluster formation.

Let's add libcluster to our production config. Add the lines below to rel/prod.exs.

dns_name = System.get_env("RENDER_DISCOVERY_SERVICE")
app_name = System.get_env("RENDER_SERVICE_NAME")

config :libcluster, topologies: [
  render: [
    strategy: Cluster.Strategy.Kubernetes.DNS,
    config: [
      service: dns_name,
      application_name: app_name
    ]
  ]
]

Render automatically populates RENDER_DISCOVERY_SERVICE and RENDER_SERVICE_NAME based on the name of your service.

Finally, add libcluster to the application supervisor by adding the lines highlighted below to application.ex:

  def start(_type, _args) do
    # List all child processes to be supervised
    topologies = Application.get_env(:libcluster, :topologies) || []

    children = [
      # start libcluster
      {Cluster.Supervisor, [topologies, [name: ElixirClusterDemo.ClusterSupervisor]]},
      # Start the endpoint when the application starts
      ElixirClusterDemoWeb.Endpoint
      # Starts a worker by calling: ElixirClusterDemo.Worker.start_link(arg)
      # {ElixirClusterDemo.Worker, arg},
    ]

    # See https://hexdocs.pm/elixir/Supervisor.html
    # for other strategies and supported options
    opts = [strategy: :one_for_one, name: ElixirClusterDemo.Supervisor]
    Supervisor.start_link(children, opts)
  end

Display Connected Nodes

Once everything is wired up, you can access the current node using node() and other nodes in the cluster using Node.list().

Our sample app displays all connected nodes on the homepage. Edit the index view and template in your own app as shown in this commit.

Update Your App for Render

Update config/prod.exs to change the code below.

   config :elixir_cluster_demo, ElixirClusterDemoWeb.Endpoint,
     url: [host: "example.com", port: 80],

to this:

   config :elixir_cluster_demo, ElixirClusterDemoWeb.Endpoint,
     url: [host: System.get_env("RENDER_EXTERNAL_HOSTNAME") || "localhost", port: 80],

Render populates RENDER_EXTERNAL_HOSTNAME for config/prod.exs.

If you add a custom domain to your Render app, don't forget to change the host to your new domain.

Create a Build Script

We need to run a series of commands to build our app on every push to our Git repo, and we can accomplish this with a build script. Create a script called build.sh at the root of your repo:

   #!/usr/bin/env bash
   # Initial setup
   mix deps.get --only prod
   MIX_ENV=prod mix compile

   # Compile assets
   npm install --prefix ./assets
   npm run deploy --prefix ./assets
   mix phx.digest

   # Remove the existing release directory and build the release
   rm -rf "_build"
   MIX_ENV=prod mix release

Make sure the script is executable before checking it into Git:

   $ chmod a+x build.sh

Build Your Release Locally

Compile your release locally by running ./build.sh. The output should look like this:

   Generated elixir_cluster_demo app
   * assembling elixir_cluster_demo-0.1.0 on MIX_ENV=prod
   * using config/releases.exs to configure the release at runtime
   * skipping elixir.bat for windows (bin/elixir.bat not found in the Elixir installation)
   * skipping iex.bat for windows (bin/iex.bat not found in the Elixir installation)

   Release created at _build/prod/rel/elixir_cluster_demo!

       # To start your system
       _build/prod/rel/elixir_cluster_demo/bin/elixir_cluster_demo start

   Once the release is running:

       # To connect to it remotely
       _build/prod/rel/elixir_cluster_demo/bin/elixir_cluster_demo remote

       # To stop it gracefully (you may also send SIGINT/SIGTERM)
       _build/prod/rel/elixir_cluster_demo/bin/elixir_cluster_demo stop

   To list all commands:

       _build/prod/rel/elixir_cluster_demo/bin/elixir_cluster_demo

If everything looks good, push your changes to your repo. You can now deploy your app in production! 🎉

Deploying to Render

Create a new Web Service on Render, and give Render permission to access your new repo.
Use the following values during creation:

Key Value

Environment Elixir

Build Command ./build.sh

Start Command _build/prod/rel/elixir_cluster_demo/bin/elixir_cluster_demo start

Under the Advanced section, add the following environment variables:

Key Value

SECRET_KEY_BASE A sufficiently strong secret. You can generate a secret locally by running mix phx.gen.secret

Key	Value
Environment	`Elixir`
Build Command	`./build.sh`
Start Command	`_build/prod/rel/elixir_cluster_demo/bin/elixir_cluster_demo start`

Key	Value
`SECRET_KEY_BASE`	A sufficiently strong secret. You can generate a secret locally by running `mix phx.gen.secret`

That's it! Your distributed Elixir web service will be live on your Render URL as soon as the build finishes.

You can add nodes to your cluster by increasing the number of instances for your service under Settings.

You should see the second node on the homepage as soon as the instance update is live.

Congratulations! You've successfully set up distributed Elixir in production, and your cluster will automatically update as nodes are added or removed from it. 🎉

Deploy a Phoenix App with Mix Releases

Anurag Goel — Mon, 22 Jul 2019 04:12:19 +0000

This is a guide to deploying a Phoenix application with Mix releases on Render, a new cloud platform with native support for Elixir.

The finished code for this example is available on GitHub.

Getting Started

Create a new Phoenix app in the terminal. We don't need a database for this example, so we're passing the --no-ecto flag to mix.

   # install phx.new; feel free to change 1.4.9 to a different version
   $ mix archive.install hex phx_new 1.4.9
   $ mix phx.new phoenix_hello --no-ecto # also fetch and install dependencies
   $ cd phoenix_hello

Configure Mix Releases

Create runtime configuration needed for Mix releases.

Rename config/prod.secret.exs to config/releases.exs.
Change use Mix.Config in your new config/releases.exs file to import Config.
Uncomment the following line in config/releases.exs:

   config :phoenix_hello, PhoenixHelloWeb.Endpoint, server: true # uncomment me!

Finally, update config/prod.exs to delete the line import_config "prod.secret.exs" at the bottom.

Create a Build Script

We need to run a series of commands to build our app on every push to our Git repo, and we can accomplish this with a build script. Create a script called build.sh at the root of your repo:

   #!/usr/bin/env bash
   # Initial setup
   mix deps.get --only prod
   MIX_ENV=prod mix compile

   # Compile assets
   npm install --prefix ./assets
   npm run deploy --prefix ./assets
   mix phx.digest

   # Remove the existing release directory and build the release
   rm -rf "_build"
   MIX_ENV=prod mix release

Make sure the script is executable before checking it into Git:

   $ chmod a+x build.sh

Update Your App for Render

Update config/prod.exs to change the lines below.

   config :phoenix_hello, PhoenixHelloWeb.Endpoint,
     url: [host: "example.com", port: 80],
     cache_static_manifest: "priv/static/cache_manifest.json"

to this:

   config :phoenix_hello, PhoenixHelloWeb.Endpoint,
     url: [host: System.get_env("RENDER_EXTERNAL_HOSTNAME") || "localhost", port: 80],
     cache_static_manifest: "priv/static/cache_manifest.json",

Render populates RENDER_EXTERNAL_HOSTNAME for config/prod.exs.

If you add a custom domain to your Render app, don't forget to change the host to your new domain.

Build and Test Your Release Locally

Compile your release locally by running ./build.sh. The output should look like this:

   * assembling phoenix_hello-0.1.0 on MIX_ENV=prod
   * using config/releases.exs to configure the release at runtime
   * skipping elixir.bat for windows (bin/elixir.bat not found in the Elixir installation)
   * skipping iex.bat for windows (bin/iex.bat not found in the Elixir installation)

   Release created at _build/prod/rel/phoenix_hello!

       # To start your system
       _build/prod/rel/phoenix_hello/bin/phoenix_hello start

   Once the release is running:

       # To connect to it remotely
       _build/prod/rel/phoenix_hello/bin/phoenix_hello remote

       # To stop it gracefully (you may also send SIGINT/SIGTERM)
       _build/prod/rel/phoenix_hello/bin/phoenix_hello stop

   To list all commands:

       _build/prod/rel/phoenix_hello/bin/phoenix_hello

Test your release by running the following command and navigating to http://localhost:4000.

SECRET_KEY_BASE=`mix phx.gen.secret` _build/prod/rel/phoenix_hello/bin/phoenix_hello start

If everything looks good, push your changes to your repo. You can now deploy your app in production! 🎉

Deploy to Render

Create a new Web Service on Render, and give Render permission to access your Phoenix repo.
Use the following values during creation:

Field Value

Environment Elixir

Build Command ./build.sh

Start Command _build/prod/rel/phoenix_hello/bin/phoenix_hello start

Under the Advanced section, add the following environment variables:

Key Value

SECRET_KEY_BASE A sufficiently strong secret. Generate it locally by running mix phx.gen.secret

Field	Value
Environment	`Elixir`
Build Command	`./build.sh`
Start Command	`_build/prod/rel/phoenix_hello/bin/phoenix_hello start`

Key	Value
`SECRET_KEY_BASE`	A sufficiently strong secret. Generate it locally by running `mix phx.gen.secret`

That's it! Your Phoenix web service built with Mix releases will be live on your Render URL as soon as the build finishes. Going forward, every push to your GitHub repo will automatically update and deploy your app with zero downtime. 💯