Digital: From Impossible to Possible Thanks to Cloud Services

Today, it is entirely feasible for charities to have in-house digital capabilities, whereas a few years ago, this would have been cost-prohibitive. The influence of recently introduced cloud services in this revolution is significant. In 2006, Amazon offered its computing infrastructure to organisations to reduce the costs of procuring, installing, and managing the physical computing power required for modern businesses. Google and Microsoft followed suit in 2008 and 2010, respectively. Today, these services are referred to as "Infrastructure as a Service" (IaaS), or in my terms, "cloud v1."

While cloud v1 eliminated the need for physical infrastructure, organisations still required many technical resources to design, set up, administer, and operate the computers and their operating systems. These activities included post-implementation network monitoring, firewall configuration, and upgrading and patching various components of the infrastructure. All these tasks had to be completed before any work on building solutions could begin.

In reality, even in the corporate world, the resources we had for these tasks were not as qualified or certified as those available to Google, Amazon, and Microsoft. As a result, the quality of the infrastructure varied considerably in terms of uptime, security risk, and performance for end users. To address this, organisations hired specialist resources and set up various control gates and committees to mitigate the risk of poorly designed infrastructure.

A typical project during this period had a six-month ramp-up phase, requiring several team members whose sole purpose was to coordinate and manage meetings and sign-offs with over 10 individuals in 10 separate teams across the IT landscape. Each of these individuals and teams had separate management, budgets, committees, and administrative processes. Learning about the existence of each team and how to engage with them was a significant learning curve for every project.

This was infeasible for small charities. Commercially, any project below a certain size was not cost-justifiable due to the high costs of designing and setting up the infrastructure. Every project also had to account for increased IT operations costs (more staff) required to monitor, upgrade, and patch that infrastructure. This is what managers refer to as the "legacy" of having an internal digital capability.

I did a retrospective analysis of three of my projects during this period to understand the percentage of my budget spent on infrastructure. I found that an eye-watering 75% of a typical project's budget and timeline were attributable to managing cloud infrastructure. In this context, it was impossible to build software and deploy it to users on day one of the project, and also impossible to have a one-person digital capability.

However, in 2008, Google previewed a new product called "App Engine," which kicked off a new wave of technologies referred to as "Platform as a Service" (PaaS) and "Function as a Service" (FaaS) from all three vendors. I call these cloud v2. Cloud v2 products are pre-architected, pre-configured, and fully managed by the cloud vendor. Now, we don't need a single IT person to manage this in our organisation. For example, I have managed over 100 of these setups for one client without requiring a single IT resource.

This meant I could completely eliminate the pre-build ramp-up phase of every digital project I managed, which is significant when you consider that this phase accounted for 75% of the budget on most of my projects. The second major benefit of these newer cloud services is that even the smallest charity inherits a much higher quality of service in terms of uptime, resilience, security, and performance. Major cloud vendors can attract, pay, and retain a much higher calibre of infrastructure engineer than even the largest corporations in Australia.

I worked for many of these large corporates during the cloud v2 era, who were still emotionally tied to cloud v1 technologies. Despite their confidence in and defence of internal resources, they were never able to match the quality and reliability of the fully managed service offered by vendors. Not even close. A simple and important example of this is resilience to power outages. All cloud v2 services from major vendors have redundant computing across two power grids, which I've rarely seen implemented properly even in major Australian corporations.

Another way to think about cloud v2 is that it is fully automated, including provisioning and operation. This automation is developed and paid for by the cloud vendor, so you don't need your own team to handle it. It's now possible to have a one-person development team in a small organisation without inheriting 75% of the legacy of yesteryear. So all we have to do is avoid using cloud v1 technologies. This is easy—just hit me up and I'll give you a list for each cloud vendor. For example, in Microsoft Azure, the three core services are App Service, SQL Server Cloud, Cosmos DB, and Blob Store.

In the digital world, there is no sensible reason to use cloud v1 technologies—at least none that withstand two minutes of questioning. Cloud v2 ensures that 100% of your budget for integration and joined-up experiences can go into the solution instead of being wasted. From my experiences over the past decade, specialising in cloud v2 technologies has been one of the biggest factors in attracting and retaining the industry's best developers. Even better, with some simple guardrails in place, it's feasible to take your first steps with an external organisation before committing to hiring your own resource. Contrary to industry perception, attracting and retaining talent isn't as hard as the industry has been led to believe.

Let's unpack this by comparing the old world to the new and explaining the difference between old and new cloud technologies from a practical and commercial perspective. The legacy we used to inherit is no longer necessary if we simply make smarter choices about which cloud technologies to use. This shift in economics can be transformative for organisations willing to jump on board, and it’s easy to dip your toe in the water before committing to hiring your first resource.

Andrew Walker
Technology consulting for charities
https://www.linkedin.com/in/andrew-walker-the-impatient-futurist/

Did someone forward this email to you? Want your own subscription? Head over here and sign yourself right up!

Back issues available here.