What’s up with Cloud Computing lately?

The term “cloud” and cloud computing can be broadly interpreted. However, for this post, I will be focusing on a specific definition: renting compute resources and services to facilitate the operation of a product or application.

A lot has been written about the cloud lately, and some stories have been getting a lot of attention and come with some controversy as some have tried to generalise their conclusions and sometimes give the cloud a bad rep.

Last year 37signals announced they’d be leaving the cloud and explained why they were doing so. There have been multiple reasons, but it mostly boiled down to cost savings.

The engineering team at Amazon Prime Video recently explained how they stepped away from AWS’s serverless computing offering, moved to a monolithic architecture, and reduced costs by 90%.

Cost Consciousness

Both stories are very different, and much can be said about each, but cost savings binds them. For 37signals, it meant stepping away from the cloud entirely and owning their hardware again. For Amazon Prime Video, it was re-architecting a fundamental part of their system and stepping away from serverless. Sure, Amazon Prime would not be stepping away from AWS entirely, as that would be bad marketing and make no sense, right?

In the past year or so, it has become evident that the days of growth at any cost have ended for many organisations, at least for now. Of course, being cost conscious has always been essential, but it has been given some extra attention in the current economic context, and cloud spend is one of the things being looked at.

Does it mean most of us must step away from the cloud or cloud-vendor-specific compute resources to be more cost-efficient? Are there clear categories of solutions and organisations which belong in the cloud or not? I don’t believe so because every organisation and product has unique properties which can’t be generalised.

Instead, look at and evaluate your solution and ask yourself if you are operating it efficiently, looking past the current or past hypes. Here are some areas you should be looking into when currently running in the cloud:

Dynamic Scaling

Is there a highly fluctuating load which can benefit frequent scaling?

Don’t just think about sudden unexpected surges in load. Depending on your customer base and product, there might be predictable seasonality month over month or between business and non-business hours.

• Is the solution already sufficiently using dynamic scaling of compute resources?
• What are the current units of scaling? For example, scaling out a massive computing resource might not be as efficient, but scaling tiny computing resources, such as what’s often the case with serverless, might also not be efficient. Pick what makes sense for your solution and performance requirements, and weigh the benefits by cost.
• Is the current choice of scaling unit still the right one? Cloud providers and the underlying hardware they use constantly evolve. Make sure you keep track of which options are available to you.
• Have you considered reservations? Most cloud vendors allow you to commit to and reserve compute resources for 1 or 3 years, and they are often quite flexible in allowing changes of those commitments as you go - as long as you don’t do it excessively. Cost savings can be huge when reserving your minimum amount of computing resources.

Licensing and Vendor Agreements

Even in cloud computing, licensing can be complicated; make sure you and your team know all the options and use what’s most optimal.

Depending on your scale units, start by comparing operating systems. But it’s also worth looking deeper; depending on your setup, you might be eligible for discounts or free licenses. Also, look into potential partnerships and yearly commitments vs pay-as-you-go.

It can also be worth setting up vendor agreements with your cloud providers, as those can give discounts in return for a commitment.

Multiple Regions

There can be multiple good reasons for running in multiple regions. But it can be easy to over-engineer as well.

• Even if you are able, do you need it? For example, a CDN cache or a subset of systems running in each region with the bulk in a single one could be sufficient.
• Don’t forget about regional requirements and who your clients are; things like GPDR or governmental requirements must not be overlooked and impact deciding where to store data. If you have a primary region, factor this into the decision on where this primary region should be located.
• What about disaster recovery? Do you need to have multiple regions up and running all the time, or is it sufficient to have a multi-regional backup of data and a streamlined way to provision your infrastructure and applications quickly?

Cost Awareness

Cloud costs can be complicated depending on your organisation’s size and your solution’s complexity. One thing I found very powerful is to be transparent about these costs within the organisation.

I encourage you to share cloud costs regularly, for example, during Architectural Advisory Forum meetings or any similar meetings within your organisation. It will help spread awareness of the potential impact on costs of any architectural decisions and empower everyone in your team to contribute to being more critical about the current setup, not just from the technological point of view.

Conclusions

I am not advocating for staying with the cloud, but a lot of optimisation can be done and are worth looking at first. If you already did all those optimisations and you still know that going away from the cloud can make you much more efficient, go ahead and do what’s suitable for your organisation. But don’t forget about hidden costs.

When making more extensive changes, ensure this is the appropriate priority for your organisation. Even when the changes can be implemented relatively quickly, they will likely come with a period of new surprises and new learnings. Ensure your team can handle the added cognitive load, and it does not become a distraction away from what might matter more at that time.