My Personal Theory of the Universe of Staying Nimble in the Technology Age

There are 2 different, competing theories of the universe. One is what Hoyle (when he rejected it) called the Big Bang theory - that it's constantly changing, expanding, exploding. The other, much older, idea is Aristotle's notion that the universe, or nature, abhors a vacuum - where our desire to remove something from our lives gets sucked into oblivion and things carry on as if nothing has changed.

But things are always changing, aren't they?

Look at technology - massive change - massive acceleration to the rate of change. Here we are as business operators looking at where to jump in. We make a call, take a leap, and by golly we want that to pay off. I figured out my thing, I get a Virtual Machine (VM) running in the cloud, now stop the universe, I want to get off this ride.

But the second theory, nature abhors a vacuum, doesn't let us do that. We try to take change out of it, even just a little bit, to stop that from happening, it doesn't work. We just get flung off into space at a sharper tangent than we originally wanted. It's a derivative, like calculus, in a manner of speaking, to try .

So we can't stop change, and we are out in the universe. Lost in the cloud. And we didn't want to change, but now, more than ever before, we really need to change, and as Stephen Covey puts it, "begin with the end in mind." We need to be nimble, agile. We need to do more with what we have.

That's where we want to be.

My Personal Cloud History

2005

Edentity (precursor to Agility) had a Private Cloud - in the back room of our office on Soho St. All I remember is a bunch of nasty loud Dell servers and a UPS that kept konking out.

2006

We moved our server infrastructure into Q9 Networks in downtown Toronto. A really great facility that always seemed to sound like it was about to take off somehow - like a plane on the runway. Mike Iskiw will remember that first day well. He and I installed an IBM BladeCentre. I don't remember much else. It was the opposite of fun.

2010

Agility went to the public cloud - Microsoft Azure. We deployed our first production Cloud Service, and by 2011 we had Virtual Machines running the entire Agility platform. That's what's known as Infrastructure as a Service (IaaS) and this process is often called "Lift and Shift".

2017

We moved to a much more flexible Platform as a Service (PaaS) model, using Azure App Services with highly advanced DevOps for deployment and releases to each service and data region, including support for geo-redundant failover. A long way from "did the servers shut down properly when the battery ran out on the UPS?"

2018

100% of our Business is in the Cloud - no server room at all - we moved to a shared WeWork space and we no longer have a server, domain controller, or UPS (universal power supply). We just a bunch of folks with some laptops and dreams of creating more awesome stuff.

It's all in the cloud, and it's pretty great.

Change is Hard

Getting from 2005 to 2018 was hard. At every step of the way I made mistakes, I screwed up the caching, I made inefficient database queries that I later had to fix. There were rumors of stack overflow in an infinite loop. That was just in the code, too. My goal for a long time was to write less code, but I found that as I brought on more product developers, I just accelerated my work as I became more inspired by the team around me. Every time I find myself plateauing, something changes somewhere. Code is a constant for me, but it's not the only thing.

I've recently taken on a great deal of the Product Management execution for Agility, including writing the release notification emails, help documents, and I get notified whenever someone wants to do a live chat on support. That's not something I ever saw myself doing, but it has put me in much closer in touch with our customers and partners. I really appreciate seeing how folks are using the platform, how they are breaking it, and what is causing them grief. It's both humbling and also gratifying; knowing what to focus us from a product perspective is golden, and making your users happy is never a bad place to start.

Becoming Geo-Redundant

The idea that I could create a platform that was geo-redundant (where a service can be redundant across geographic regions) with automatic failover seemed like the holy grail. Yes, it was possible, but the tools were so knew, and good luck finding anyone to actually help you implement it. Anyone who's got it figured is guarding their secret like their careers depend on it.

Starting just over a year ago, we completely switched over all of our platform code from the aging Web Roles and Worker Roles of the original Azure Cloud Service era circa 2011, and moved them to what is known as App Services. At the same time, we swapped out our entire build and release process for a fully automated pipeline that includes builds and releases to multiple regions with approval steps from QA. We've now dropped in a service called "Traffic Manager" which allows us to have failover between multiple regions. We are at a place now where the release management practices we are executing would have taken a 10-15 person team before now happen behind the scenes due to the amazing tools that we are using.

The Right Tools For the Job

I remember a keynote speech by Steve Job many years ago when he was talking about development tools on the Mac, and how Apple enabled developers to "start on the 5th floor instead of the floor." Anyone who has used a great base class library and had access to many frameworks and packages knows what this idea means. It's easier to build an app when you don't have to write windowing code; it's easier to build a website when you don't need to write a web server and the browser is well defined. You do have to use the right tools for the job, though. Anyone who knows the difference between Assembly languages, C, C++, third generation languages such as Java and C#, and interpreted languages such as JavaScript can easily understand the idea that using the wrong tool can be disastrous.

Today it's all about tooling, one could surmise, especially in the B2B, but even when selling director to consumers who create things, or who need to be enabled to do so.

What tools are you using? What tools are you creating for your customers?