Architecture: Clouds only charge you for what you use, so design for minimal idle cost

As businesses move to the cloud in the hopes of being agile and able to cope with change while reducing costs, many are finding that using cloud with the architecture they have designed is actually more expensive than what they had before.

Cloud offers major benefits around scaling, infrastructure as code, and only paying a minimal amount for any single service they offer. New startups are building on cloud and running reliable, scaling services while keeping their costs down. This leads us to the question, why do other businesses find their cloud costs are high?

Some possible answers are:

They tend to be paying for cloud resources which are not doing much.
The applications and infrastructure they have deployed are not designed "cloud-native" to keep costs low and work together.
The architects and infrastructure teams have prioritised availability, layers of security/separation and business level constraints over optimised value. This often comes with retained traditional data centre thinking, where they have just re-platformed and use on-prem procedures and designs to the cloud.

If your cloud applications and infrastructure has been designed where the running cost is much the same when not servicing any requests as when under full load, then it’s an indication of room for improvement. Many cloud applications when designed for cost can have their idle running costs as low as a few dollars per day.

The re-platforming approach in "The 6 R's" of the cloud migration strategy can be a cause of poor cost optimisation when non-cloud infrastructure has been migrated without being redesigned to optimise for scalability, reliability and cost.

Designing a cloud infrastructure for cost optimisation

Cloud infrastructure can be carefully designed following strategies for cost optimisation so that the cost to run several web applications serving your customers will be low and only increase as your customers use it more.

When designing an application for the cloud, your application design team should consider the following questions:

Does it need a server at all? If it does need one, how small can that be? Can it be an on-demand container, can it use caching? What is the lowest cost storage that it needs?
Do you need a full database or can you use a serverless database? What can you do to keep its costs optimal?
Should you use a lightweight language?
If you’re looking at deploying an off-the-shelf application, is it suitable for the cloud? Does it support horizontal scaling, can it run in a container?

We, at OSS Group, promote looking at your business needs and designing a way to keep your idle costs down. Designing so that costs increase as your customers use your service will often lead to applications that meet other cloud standards such as scaling, stateless and automated infrastructure as code.

Decisions are too often made without considering the cost

Let's say an architect is asked to design a solution for a business that will host their new job booking site. The architect might ask some basic questions or make assumptions such as:

Should it be highly available?
Should the sysadmin team be able to use AD to login to manage it?
Will it be backed up daily following our standard?

Decisions are often made without considering the impacts on costs, design, maintenance. These decisions are often made separately from the application design. But often cloud applications design actually needs to take these into account as to be efficient, applications don’t just run on a cloud, they run using integrated cloud resources and services.

If you simply ask a business user: “should the booking site be highly available?” They will say yes. But, imagine if you explain that to make the booking site highly available, it will cost you more than double to run and take twice as long to build and still not be reliable due to complexity. Imagine if you explain that if you design to be cost-effective, you might have a short self-healing outage once every few years, which has a cost of almost nothing in lost revenue. It's suddenly a different option.

Making assumptions like that support people should be able to login to the host operating system for an application, is a design decision. It is easy however to just default to this because it’s the way it's always been done, and that they *need* logins. Many default decisions, overheads and practices can be tracked back to these assumptions. Challenging default assumptions and decisions leads to things like having to ship logs, having to have monitoring, and designs that are resilient to failures.

Your business IT standards need to be designed for cloud

Standards are another source of inefficient cloud design. Some businesses have defined standards which were designed for non-cloud environments and around a traditional application. We see this happening with things like custom firewall appliances, traditional management systems for servers, policies around backup methods and what requires backup, and separation of concerns being applied outside of the IaC layer.

As an example of designing for cost efficiency on cloud, backups generally need to use cloud-native tools to ensure speedy recovery and consistency. The typical way to meet these requirements is to use snapshots, which tick all the boxes, except do have a significant cost over time. An AWS cost- optimised approach might be that historical data is stored in s3 and glacier, rather than on EBS, or that older backups are not stored as snapshots.

Keeping what is defined in the cloud and the cost to a bare minimum, designing it to it scale on-demand, while using resources you have paid for to a reasonable extent, will help your bottom line.

Application design and architecture that follows the design for cost optimisation at idle principles also facilities the ability to prototype and change rapidly, and to have similar environments for testing. Cloud infrastructure should aim to provide a cost structure that has meagre costs when idle, and costs that follow the amount of use. On top of all the technical aspects discussed in this article, it is worth considering your business model. For example, it could be designed so that increased customer use of your cloud service results in matching increased revenue.