Cloud software is different. It’s different to enterprise software, embedded software and user interface software, be it in web browsers or mobile apps. In Uncover implicit requirements for cloud software, we looked at what the oftentimes implicit requirements to cloud software are. In this blog post, we’ll learn why these requirements are special to cloud by comparing them in enterprise, embedded and UI software.
Defining Enterprise, Embedded and UI software
For the sake of simplicity, in this blog post we use the following definitions:
- Enterprise software
- Software that is used by employees of companies for their work. Examples could be machine control software, financial/HR management software etc.
- Embedded software
- Software (or “firmware”) that is typically executed on microcontrollers. Examples are software executed in cars, devices such as webcams etc.
- User Interface software (“UI”)
- Any software that provides a user interface, be it mobile apps, websites or desktop applications
Obviously, we assume typical representatives of these types of software – there definitely are exceptions to the below-mentioned views, but they tend to be rare.
Comparison
We’ll compare the requirements for High Availability and Scalability to the above-mentioned types of software – the other typical cloud requirements mentioned in Uncover implicit requirements for cloud software – namely high performance and costs – are depending heavily on the actual project so we skip them here. These are the results:
| Type of software / Requirement | High Availability | Scalability |
|---|---|---|
| Enterprise Software | + | 0 |
| Embedded Software | + | 0 |
| UI Software | 0 | 0 |
| Cloud Software | +++ | +++ |
Let’s look at the detailed reasoning.
High Availability
High Availability means that the software stays available for its users, even if parts of its infrastructure break down.
Enterprise software is most of the time not required to be highly available. Assume a software that runs in a company and the employees need to use it on a daily basis. If that software does not work, e.g. because the database server broke down, the employees will complain, but eventually they will go grab a coffee, have a chat, and then come back to continue working when the systems are back up. It’s not their fault in the end, anyway. The managers will have a chat with the IT department on the reasons for the outage, but eventually they realize that it is fairly unlikely that the systems breaks down (since data centers are fairly small and therefore have a low likeliness of something breaking down) and they probably will not spend the extra amount of money to increase availability. Work that was ongoing by the employees when the system broke down simply has to be repeated. It’s cheaper to pay money for that instead of for increasing the availability.
Sometimes companies engage “simple High Availability” by having a backup system with another system in front of it that decides whether to use the actual or backup system (often called “loadbalancer”). Though in a scenario where this the backup is activated typically still some intermediary data will be lost – and that loadbalancer itself might break down as well, being a “single point of failure”.
Embedded software is typically executed on a single PCB with one or a small number of microcontrollers. If anything on that PCB fails, it is typically fine if also the other components on the device stop working. There might be exceptions like the braking system in cars, but these are rare.
With User Interface it’s roughly the same way: This software is only executed on a single device e.g. a mobile phone – or at least that’s the only execution that a single installation of the software needs to care about simultaneously. Therefore, if that device is broken, then the UI will not work anymore – and this is just fine: Broken mobile phone -> cannot use the app.
For cloud though, when a single piece of the infrastructure breaks (e.g. a single VM), it is typically expected that the software keeps working. After all, it is rather likely that things fail in a cloud environment, as numbers show (Jeff Dean of Google, slide 56+57). This means, that hardware continuously fails in these large data centers, be it computers, network switches or power supplies. This has effects on the cloud software: Disks will get slower, services will suffer from network partitions, VMs will be restarted without notice, services will start returning errors or timeouts suddenly. According to the expectations though, the overall software should keep being available. There shouldn’t be any “single point of failure”.
Scalability
Scalability is the capability to grow the system with the amount of its users.
Enterprise software does not need to scale as fast as cloud software since it is typically used by the employees of a company. That group of users does not grow that quickly – which company hires multiple thousand employees each month, after all? And even if it did, due to company internal processes this growth can be managed and is known in fair advance – so there’s typically enough time to prepare – and save the money that would go into building a fully scalable system. Also, a company might choose for new employees to temporarily switch to a different system to manage its core processes under such large growth (e.g. paper forms, limiting access to the software to a single person in a team etc.), which at least provides some time for adjustment of the system.
For embedded and user interface software, again, this software is typically executed on a single device concurrently and does not communicate with a quickly growing number of other partners during its lifetime: A user interface typically communicates with a single user and a small number of backend services, whereas embedded software communicates to up to a small number of other devices and backends.
Cloud software though communicates with all the end users of the product, typically through the user interfaces or devices with embedded software. They all hit a single instance of the server side solution. So the more users the product has, the more devices are sold, the more load this single instance needs to be able to handle. It therefore needs to scale.
Cloud vs. Enterprise, Embedded and UI
We’ve seen that the importance of both requirements, High Availability and Scalability, are special to Cloud. Cloud software typically cannot go without these requirements, whereas Enterprise, Embedded and UI can – and typically do.
Therefore Cloud is different to these other types of software. When taking these requirements seriously, a different approach is needed to implement the Cloud Software and approaches that work for other types of software oftentimes do not work.
Contact us at scailio if you want to get more insights. We can help you build Cloud software that fulfills these requirements, is loved by your users and will ultimately allow you to reach your economic goals.
Photo by Simon Connellan on Unsplash.