Launching a Cloud Status App: Our Development Approach

By Harry Wincup, Founder, Design Lead at Server Density.
Published on the 18th February, 2016.

Something seems off. Things are slower than usual.

We grab the nearest screen and—with bated breath—navigate to our provider’s cloud status page. Our WiFi might be having a bad day. Those fifty Chrome tabs might be killing our laptop. A whole host of benign little things might be at play. But no, the provider’s cloud status page is our first and most immediate stop.

Sound familiar?

As natives of the cloud, our entire business model (and sanity) relies on how well the cloud performs. Those UPS backed, temperature controlled, fully redundant bunkers that hold our servers, are not supposed to fail that often. But when they do, our uptime is at risk. So we err on the safe side, and check. Given our provider, zone, and geographical setup, each of those checks is several minutes’ worth of tedious, stressful, non-productive work.

Painful isn’t it?

Enter Cloud Status

As a small company with finite resources, we are religious about our time.

We try and avoid doing anything more than once. Once we figure out how to do things, we look for the right tool to automate them with. When there is no such tool we go ahead and build our own.

Such was the case with our latest iPhone App release.

Cloud Status monitors the status of cloud services (AWS, Google, Linode, Rackspace, DigitalOcean, et cetera) so you don’t have to. No more compulsive checks throughout the day (and night). If something is off kilter, a timely notification will let you know.

Oh, and you don’t need an account. Just install the app, select all providers and locations you need to monitor, and that’s about it. You can go back to doing things that matter.

How we built Cloud Status

Work on this project started on August 14th last year. Most of my previous work centered around frontend development, so I pretty much had to learn everything from scratch. Think learning curves. Think steep.

The silver lining? I was not invested in the old way of building apps, so I was free to embrace newer development methodologies. Here is what I’ve learned.

Swift is Amazing

Swift is way more approachable than Objective-C. The folks at Apple are very transparent about where the language is going. That’s a welcome departure from the typical black box approach the company employs in many other areas. I could easily see the appeal of Swift spread to things outside mobile (backend, for example).

From MVC to MVVM

For the purposes of Cloud Status, I decided to adopt the MVVM architectural pattern.

MVVM (Model View ViewModel) is a relatively recent refinement of the much older and more prevalent MVC (Model View Controller). MVVM has three components: i) Model handles pure data in its raw format, ii) View presents the data, and iii) Viewmodel passes data between the view and the model, i.e. converts data to a presentable form.

The MVVM pattern helps further-abstract the application logic from the view layer. Which means, all information can now be tested in isolation. This has obvious benefits in terms of software resilience.

ReactiveCocoa – from Imperative to Declarative programming

Most programming efforts out there are imperative, i.e. the computer executes a set of instructions in a sequential and linear fashion. That is how most software was developed over the last three decades. Declarative programming is different. In this case, the programmer specifies what the code should do, without prescribing how it should be done.

Once you embrace this new paradigm, everything becomes easier to understand (and debug). You can just look at the code and see how everything is connected to everything else—instead of studying code. The relationships are obvious.

Thinking in declarative terms is substantially different from what I was used to as a programmer. In order to embrace ReactiveCocoa I had to learn and think in a functional way. Getting my head around (and adjusting to) this new mindset took some time. But after going through this journey, I can attest that functional reactive programming is the future.

As it turns out, ReactiveCocoa works well with MVVM. And from RAC3 onwards, ReactiveCocoa has converted to Swift. So yes, it looks like the stars are aligning. However, it’s not all peaches and cream with our stack. Frankly, things are nowhere near there yet.

During the early development of Cloud Status, RAC was releasing significant Swift-related updates on an almost weekly basis. This hindered our development efforts as various bits of the framework were missing and I had to keep refactoring as I went along.

Apple released Swift 2 halfway through the project. I used an alpha version of RAC (to get the Swift API) which obviously broke a lot. To make matters worse, all current iOS frameworks are built for imperative work. That left me with a weird combination of declarative and imperative code, which was not what I had in mind when I started.

Employing RAC at that point in time—for a production app—was not ideal. While both RAC and Swift adhere to the same development ethos, we could have waited a bit longer to work with a more mature stack.

Our experiments with Cycle.js and Elm in the frontend demonstrate what a fully FRP product looks like. We can’t wait to realise those benefits in iOS.

A small aside: To make life easier, I tried to stick with technology that helps integrate things. As part of Google App Engine, I used Google Cloud Endpoints. Those allow me to generate client libraries that I then drop into our iOS app to make use of the API calls. All detail is abstracted and handled by Google. We could have done this by hand, but there was no point reinventing the wheel.

Environmental Choices

One of our key priorities as a company is to be 100% carbon neutral, both in terms of our office location and cloud infrastructure alike.

Google is 100% carbon neutral, which means all our backend code is carbon neutral because the app APIs runs on Google App Engine.

For our push notifications, we use the AWS simple notification service (SNS). The situation with Amazon is slightly different. While they committed to 100% renewable energy, they are yet to offer concrete timelines. After reviewing all their datacenter locations, we settled on Frankfurt and Oregon as provisioning regions. That’s because those two sites are already 100% carbon neutral and we can use them both to provide redundancy against regional outages.

The Marketing Value of “Free”

The audience for Cloud Status is vast. Pretty much everyone setting up shop these days will invariably store and compute on the cloud. If we can make a tiny impact on their workflows, that means a lot.

There is great marketing value in offering valuable things for free. If marketing is a path to our goals (profit, growth, eyeballs), those valuable “things” are a path to our customers’ goals.

Need something from other people? Then pay it forward. Help people do what matters to them. Help customers before they even become customers. That’s one way we can differentiate ourselves, at Server Density. By adding value (not serving ads). By doing what we do best, and sharing it. Karma takes care of the rest.

Offering Cloud Status to folks that haven’t heard of us, or used our products, is a good way to get to know them. Cloud Status serves as a Server Monitoring primer of sorts. It’s a taste of what Server Monitoring with Server Density feels like (hint: great).

Summary

The timing of our app was at the confluence (and maturing) of several technologies and architectures.

If you plan on taking up Functional Reactive Programming, you need to know that the learning curve in steep. Please, stick to it. As soon as you start reaping the benefits, it’s really amazing. I will never go back to the way I used to do stuff.

The Cloud Status app stands for all the things we’re passionate about.

We are religious about our workflow and see great value in automating repetitive tasks. Checking the status of multiple cloud providers is one such task. We’re passionate about offering value to customers as a way of building relationships with them. There is significant marketing value in offering things of value to your customers, even before they become customers.

What about you? Have you tinkered with those technologies yet? What have you learned? Take a look at Cloud Status and let us know what you think.