Uncover implicit requirements for cloud software

Requirements / By /

In this post, we look at why creating “cloud software” has requirements that might not be explicitly defined:

High availability, low costs, performance and scalability.

We’ll talk about where these originate from and why it is a bad idea to ignore them – financial disaster looms!
In this article, we’ll walk along several layers of how requirements travel from a consumer to a manager perspective and from there to an actual technical implementation. Afterwards, we’ll take a look at how the results are perceived.

Consumer: “anywhere, anytime & fast”

As a consumer, cloud software is everywhere: There’s an app that you use in the morning to check the latest news, one giving directions and notes about traffic jams when driving to work, then there’s your e-mails, music and video that you consume during the day, until in the evening you sit down and watch some movie or TV series using your streaming provider while buying something online. All of these are backed by cloud software and they have something in common:

You expect them to

  • be available wherever they are,
  • anytime,
  • and you expect them to be fast.

The latter is backed by some publicly available numbers – where these are for websites and not apps, but the expectancy of the users is basically the same:

  • Akamai published in 2017 that a 100ms delay reduces conversion rates on websites about 7%, a two-second delay more than doubles the bounce rate
  • Google wrote 2018 that their modeled neural network predicted that bounce rates increase by 90% when a page load speed increases from 1s to 5s.
  • And there’s some additional rumors for which it’s harder to find public references:
    • Marissa Mayer of Google talked on Web 2.0 Summit in 2006 about how a 500ms delay decreased their search traffic by 20%
    • Amazon informed that a 100ms delay drops their sales by 1%, presumably in 2009

The products that we as consumers use everyday are not unavailable due to planned maintenance, product upgrades nor because there are a lot of other people using their service which overloaded the service. If that would happen, we’d right away start to think about using that other app, that other service, that competitors product to serve our needs – and might even decide to raise our voice against the company that does not deliver, e.g. by leaving a bad comment on their app in the stores or by dropping a quick remark in one of the social media platforms.

We, as consumers, grew used to these high standards, simply because the companies behind these products achieve them. And we are automatically disappointed, if they do not deliver – and that is true also for all other apps and websites we use, no matter if the big tech companies run them or any other company.

Manager: Implicit requirements for cloud software

Let’s change perspective: Assume Mr. E, company executive of a company wants to create a new app called fancyApp, which should boost revenue to new spheres. Let’s also assume that this new app is no special case and just like most other apps requires a server side software that contains some custom business logic and storage of the data.

In order to show my point, I’ll exaggerate this a bit. What Mr. E tells his employees:

Build the server side of fancyApp in the cloud.

Mr. E, Executive manager

What the executive manager thinks:

Since cloud works well from my personal experience, my requirement is to build this server-side software in the cloud. It is clear that this will enable us to have
– a good performance when using the app and
– have it highly available
just like the products of other companies.
Obviously, we will gain high amounts of new users constantly, to make the app more popular and ultimately to increase cash-flow.
This is what the marketing budget is planned for anyway, right?

And, of course, I expect the infrastructure in the cloud to be cheap, since hey, this is what everyone says. 

These are the things what everybody understands when talking about “cloud” anyway, right?

Mr. E, Executive manager (thinking)

Tech: Unknown requirements are unfulfilled

Now, let’s switch to our third perspective: The software architects and/or engineers who are tasked to build the server side of fancyApp. It is likely that their manager tells them only what he has been told: “build it in the cloud“. They are unaware of the thoughts and expectations that come along with it.

Nevertheless, translated to technical terms, everybody typically expects the following requirements to also be fulfilled, simply because it’s “cloud”:

  • High availability
  • High performance
  • Cheap-ish

And, in addition the constantly growing amount of users, which adds another requirement:

  • Scalability 

If you don’t have scalability but have a growing user base, at one point the performance will degrade and you will have outages which also breaks the availability requirement – since your non-scalable services simply start to crumple beneath the growing amount of traffic (read: amount of requests from the app to the servers).

These requirements are quite different from what is required of other types of software like enterprise software. We’ll discuss this in another blog post.

Tech: Build, go live and … crash

So, assume the software people built the system without these additional requirements in mind. They chose to use technology that they gained experience with during their enterprise software projects – to “keep it simple” and achieve a high feature velocity. They might’ve chosen to additionally use Platform-as-a-service and Software-as-a-service of a public cloud provider (e.g. hosted database products) so the complexity (presumably) stays low. Company-internal tests of the product with a small number of selected beta-testing users work fine and eventually they hit the big “deploy to production” button and go live. Everything keeps working fine for some time. 

Sooner or later though, the system will start to fail:

  • The performance cannot be kept up continuously, since sometimes the native cloud database of the cloud provider seems to be slow
  • sometimes the infrastructure becomes unresponsive (e.g. VMs, network) even though nobody changed anything
  • the cost of the infrastructure in the cloud explodes as operations tries to put more infrastructure in place to handle increased load, so there is no way to make money with the product anymore
  • the marketing team is so successful in gaining new users, that the system is overloaded and there is no way to scale it reasonably (e.g. classical SQL databases)
  • continued planned maintenance brings the system down

It is inevitable that some of these things happen, since not all of the requirements were not taken into account when designing and building the system – or at least not adequately enough.

Consumer: Reaction

Going back to what we’ve looked at in the beginning: The users of your app are now disappointed since “anywhere, anytime & fast” is not met, they will start writing bad reviews in the app stores.

Manager: Investment lost

As a result of the bad reviews, the app will be less visible to new users in the stores, which will lead to the marketing people being more and more helpless in finding new users which could theoretically give good reviews again to raise the rating in the stores. This is a downwards spiral that is very hard to stop – and the users will use apps of your competitors.

Your product has become obsolete and all of the invested money is lost.

This is true especially for consumer products (apps, webshops, …), but also affect other types of software, e.g. enterprise software.

Solution: Clearly define requirements & build accordingly

The solution to this problem is to put the users and the product in the center and clearly define the requirements to the cloud systems which need to be built:

  • How much availability is required from users point-of-view?
  • How fast should the system execute which feature (most of the time)?
  • How much infrastructure costs are acceptable?
  • How much users are targeted for in 6 months/1 year/3 years/…?

These questions typically can be answered by looking into the business plan that backs up the product – in the end the company wants to earn money and probably has prepared such a plan anyway. Also, the marketing team will align to that and there’s a clear goal everyone pursues – if the plan says there should be a million users in a year, marketing and sales will do their part to really achieve that number.

After these requirements are defined, build the cloud system accordingly and make educated decisions about where in the system to choose what solution and what risks to take. Do this right from the beginning, when implementing the first line of code.

Using a wholistic view of the overall technical system is crucial for this: The users don’t care if the problem that made the app break was in the scope of the company or it was a Platform-as-a-service of the public cloud provider that broke. They are not interested if it was that plugin of a large social network that you plugged into your app code that made the system unavailable or if it was that the public cloud provider had a large outage of a whole region or even globally. They only care about using and enjoying your app. Whenever and wherever they want.

Build such a product. Make your users happy and keep them happy. Everyone will profit from that.

scailio can support with this. Feel free to reach out to us.

Photo by Matt Duncan on Unsplash.