(Part I)The Importance of Adaptability in Cloud Software Architecture
By Sathya Srinivasan, Senior Staff Software Engineer
1. Introduction
Any piece of software being developed nowadays that runs on numerous devices and machines faces several challenges across multiple dimensions. Adaptability is one of the top challenges. Since the software world is huge, this article will concentrate on cloud software.
Why is Adaptability an important aspect of cloud software architecture?
The ecosystem in which cloud software functions expects the software to have the utmost flexibility in various slabs of the traffic it serves. The ability to handle the traffic is expressed typically in terms of a service level agreement (SLA) in which the different slabs would translate into several levels of load, performance, availability, and so on. The “utmost flexibility” can be expressed in terms of reusability/extensibility, robustness/fault tolerance, performance, monitoring/tracing, testability, customization of supported features and use cases. If the cloud software isn’t adaptable to these factors, it will reach the end of its adoption lifecycle soon. Hence, adaptability plays a vital role in the long-term success of the cloud software (as measured through adoption).
Why is it hard to build a cloud software architecture that is highly adaptable?
Many of the requirements and objectives of cloud software, such as the total cost of ownership (TCO), SLA promise, and flexible and robust architecture, are in competition with one another, making it hard to meet them. The architecture must always find a balanced approach to meet these competing demands – a process that is neither simple nor straightforward.
This is part one of a two-part article that will discuss the importance of adaptability in cloud software architecture. Part one will address the top challenges and part two will discuss the solutions to overcome these challenges.
2. Challenges
These are the top challenges that prevent cloud software architecture from being highly adaptable:
- Time to market (TTM) expectations
- Rapid scope bloat
- Competition between TCO vs. SLA vs. reusability
- Future-proof architecture
- Testability and coverage
TTM drives organizations to deliver world-class products as soon as possible. Customers continue to demand rapid feature availability that leads to increased revenue. TTM expectations pose significant challenges for a true long-term solution from the software architecture perspective, as any long-term solution (that is extensible/adaptable) requires a significant amount of time to develop. This is one of many examples of the two opposing goals influencing the adaptability of the software architecture.
With the increasing offerings of cloud-based software applications, the complexity of the back-end cloud software has grown exponentially. This market research report estimates that the global software-as-a- service (SaaS) market is expected to grow from $130.69 billion in 2021 to $716.52 billion in 2028 at a CAGR of 27.5%. This translates into the exponential growth of incoming traffic, new features, and technical debts to the respective cloud software applications. This poses another example of opposing goals influencing the adaptability of the software architecture — interplay between the existing and new features without compromising the guaranteed performance at high return on investment (ROI) for the customers and the product.
The SLA (performance, availability, reliability/fault tolerance, etc.) expectations vary significantly from customer to customer. It’s normal to expect the same (cloud software) architecture to cater to these varying SLA expectations. The architecture’s ability to deliver these varying SLA expectations at the least TCO is another example of opposing goals, as typically it demands higher TCO to satisfy higher, significantly varying SLA expectations. To add to this challenge, the software architecture must be reusable to further lower the cost of adopting it across multiple product offerings. This in turn stretches the TCO vs. SLA adherence challenges for the architecture.
A future-proof architecture of a cloud software will isolate the actual underlying cloud infrastructure from the core business logic that makes use of it. For example, abstracting the message queue processing makes it easier to migrate to the new cloud vendor. Thus, keeping the generic queue processing software modules and cloud vendor (AWS SQS vs. GCP Pub/Sub vs. other) specific modules will make the architecture future proof. However, if the cloud application is using only one cloud vendor, then keeping the modules for other vendors won’t be useful. Keeping only the module for a single vendor may not guarantee an immutable interface while migrating to another vendor in future. Achieving a fine balance between what is necessary and sufficient for today vs. being future proof is challenging.
Testability and coverage are vital to assure the functionality and SLA expectations of the cloud software. The exponential growth of the features, incoming traffic, and technical debts pose challenges to the coverage, as the scope of the testing grows exponentially as well. As more features are added, the permutation/combination of features increases coverage exponentially. The cloud software architecture would be challenged to accommodate the testability aspects as its scope grows. Moreover, the coverage growth poses challenges to meet the TTM as well.
When the hardware, platform, and other components of the underlying cloud infrastructure continue to shift towards several ground-breaking features over a period of time, the cloud software architecture will have to continue to adapt itself to those changes. Such a migration to adapt to the new technologies along with meeting the product requirements brings challenges in terms of TCO and TTM.
Having said all this, the ability to find a sweet spot between efficient TCO, future-proof, and reasonably meeting TTM at a high level of quality , as per SLA expectations, will be cloud software architecture’s most pressing need.
The challenges discussed so far set the stage for the architecture to overcome and resolve them.
