A Crash Course in The Cloud with a Google SRE

The age old adage “If it ain’t broke, don’t fix it” does not apply to Emmanuel Klu. In fact, Emmanuel, an amazing Google Site Reliability Engineer, is an expert at breaking things on purpose so he can figure out how to prevent those failures in the future.

We launched our 2018 Accelerator with Emmanuel’s talk on the cloud (including the types of cloud computing), because according to Emmanuel, it’s extra critical for tech nonprofits to build strong infrastructure. When things break in a tech nonprofit’s product, vulnerable populations are at risk, so mitigating failure is key.

Three Truths and No Lies

• Startups in accelerators get free stuff
• Nonprofits get even more free stuff
• But NOTHING is free

That’s right. Sorry to break it to you, but nothing is free. That “free trial” you’ve been promised is laden with human and financial capital. Free credits incentivize you to build with one cloud company over another, but once your credits run out you need to be cognizant of how this will impact your organization financially. If you didn’t build things right from the beginning, you could have a ridiculously high monthly cloud spend once your credits run dry.

Shannon Farley and Emmanuel Klu

The cloud platform decisions you make now will have a long-term impact on your organization.

Impact Unit Economics Matter, People!

You need to be able to tie your impact unit to a cost. This impact unit will serve you any time you’re reporting impact, and is critical in fundraising conversations. The cost includes staff time, free licenses, and even the in-kind costs of volunteers. If you don’t bake in the full cost, you can’t show the full impact.

Here’s a simple way to calculate your impact:

Before building anything, carefully consider the cost in human and financial capital. Even though you have discounted product licenses or cloud credits, it’s imperative to think about how the features you plan to build will translate into future infrastructure costs.

You need to make sure that as you scale, your cost per impact unit goes down. Did you hear that? YOU WANT YOUR IMPACT TO INCREASE AND THE COST PER IMPACT TO DECREASE AS YOU SCALE.

Infrastructure is Not a Feature. It Will Affect Everything You Do

By infrastructure cost, we mean everything it costs to support and maintain your product’s software. This mostly translates to storage costs, processing costs, and the engineering time it takes to maintain your infrastructure.

Engineering time is expensive, so it’s critical to work with your tech leads to determine how much your infrastructure will cost in maintenance. Understanding this cost will keep you more informed on the technical side of your product. To do this, require that your engineers (volunteer or hired) document their code and roadmaps in a way that’s readable and understandable.

Fast Forward teams absorbing Emmanuel’s presentation.

To Build or to Buy… That is the Question

The decision about whether to build or to buy depends on what stage your product is in. For example, imagine you’re using someone else’s API to complete a function, like a phone call. If that function costs 1 cent per call and you plan to eventually support 100,000 calls per day, your costs will be high.

According to Emmanuel, if you can buy infrastructure tools in the beginning, you probably should. Maintaining something you’ve built can be expensive and difficult. Even though buying usually costs more money up front, it may save you in the long run. If you do decide to buy, the first step is to decide between service providers by comparing the various types of could computing, and you’ll need to get an engineer to review your options. They should understand how high your usage will be, and how set up your integrations with the right interfaces so if you ever find a cheaper option, you can swap dependencies.

Pro Tip? Focus on building an adapter for one specific API, so that at some point in the future if you need to change it, you just have to write a new adapter instead of rewriting everything.

Virtual Machines, Containers, Serverless, Oh My! The Types of Cloud Computing

There are four main types of cloud computing products that you can build your software on. They get easier to develop on as you go down the list.

Virtual machines: This means you own the operating system of your environment. It’s yours alone and nobody else is running software on it. Consider a virtual machine if you run a consistent load, like processing 10 requests/second or for batch processes. This is because the costs are fixed, so you’ll have to determine the resources you’ll need upfront, and pay for the lifetime of ownership. Examples include Amazon EC2 and Google Compute Engine.

Virtual Machines

Container Engine: This type of cloud computing product provides a thin container around things you’re running. Your code is isolated from other products, but other people are running code on the same operating system. The risk is that you may be affected by neighbors. Examples include Amazon Elastic Container Service and Google Container Engine (GKE).

Container Engine

Hosted apps: Running on this type of compute product means you share more resources with other products. After you build your app, you hand it over to the cloud provider and they’re responsible for scaling it. Placing that control in the hands of the service provider reduces costs for you. Examples include Amazon Elastic Beanstalk, Google App Engine, and Heroku. Pro Tip? Don’t accept huge bills.

Hosted Apps

Serverless: Within your product, if you have certain tasks that require event-driven behavior, consider outsourcing those tasks to a serverless computing service. You can rest assured that the computing service should reliably complete the task, and will be able to scale with load. Examples include Amazon Lambda and Google Cloud Functions.

Serverless

Document, Document, Document!

Emmanuel’s final piece of advice was to require your engineers to document all of their code. Really, it’s advice worth mentioning twice. It’s imperative to have technical and architectural documentation showing how things work together so other people can help you! And, so you can understand the map of what your product is doing.

Surprising but true – having your site architecture clearly mapped is helpful when fundraising. Most funders are not technical, so an infrastructure map is a great storytelling trick. Funders can generally understand a map much more easily than code.

So, what are you waiting for? Time to get building! Thanks again to the incredible Emmanuel Klu, and the Google.org team for supporting our Accelerator year after year. Your dedication to Fast Forward helps our teams level up and we’re so grateful to benefit from your wisdom and support.