ENDAVA PLC
Architecture | Radu Vunvulea |
08 February 2022
One common question that we've been hearing from our customers and the market lately is:
How much would it cost me to build a system running on two cloud vendors side by side?
It is a simple question that is usually raised by businesses who want to increase the reliability of their systems. However, the answer is not that simple. Without running a workshop and investing time to understand the business requirements, the current technology stack and the expected quality attributes, providing a cost estimate for building the same solution on another CSP (Cloud Service Provider) is hard.
Here is a list of some of these useful tools:
But these tools cannot provide us and our customers with the information to answer the question about the effort required to build such a parallel system. The challenge is not the running cost itself! It is the effort cost to make a system run on another CSP. Is it possible? How much effort is required - $100k, $1M, 10%, 30% of the initial investment?
The complexity of building such a side-by-side system is higher and, in most cases, can be compared to the migration from one cloud vendor to another. Trade-offs, like using fewer SaaS services and cloud features to ensure that cloud interoperability level, can impact the quality of the final product. Still, they help us to keep costs under control. In general, the 'juice' provided by any CSP is diluted when you use fewer CSP-specific features.
When you want to run a software solution side by side on two different CSPs, additional effort is required for:
Furthermore, the following system layers will mainly be affected:
THE ACTUAL COST OF A SIDE-BY-SIDE SOLUTION We had the opportunity to get feedback through a survey answered by 51 cloud experts with solid experience with Azure, Amazon Web Services (AWS) and Google Cloud Platform (GCP) and some more in-depth conversations with some of them. Each of them provided input on the additional cost of building a system that runs side by side on two CSPs versus a system that runs only on one.
The additional effort required per layer was given as:
The additional effort per work discipline was:
Furthermore, the monthly cost of running a side-by-side solution is not simply double the cost of having one CSP because of the trade-offs mentioned above. Taking this into account, the running costs for the cloud are:
Our discussion and estimations were based on the following type of system: a standard business application, built with Kubernetes and Docker and using a relational database management system (RDBMS), where an enterprise service bus (ESB) and REST API endpoints are used for external communication. In front of the system, an API gateway and a load balancer are required. We also assume that a VPN connection exists between the cloud and the on-premises office as well as basic cloud-native monitoring tools.
CONCLUSION Taking all the estimations above and the effort required to develop a cloud solution into consideration, we expect that developing a side-by-side system that runs on AWS and Azure would require:
The data shows that it can be significantly more expensive to build a system that runs on two cloud vendors side by side. Therefore, the decision on whether to use one or more CSPs needs to take into account all the advantages, trade-offs and the added complexity. In the end, the business impact should dictate the cloud approach that a company needs to take.
How much would it cost me to build a system running on two cloud vendors side by side?
It is a simple question that is usually raised by businesses who want to increase the reliability of their systems. However, the answer is not that simple. Without running a workshop and investing time to understand the business requirements, the current technology stack and the expected quality attributes, providing a cost estimate for building the same solution on another CSP (Cloud Service Provider) is hard.
Planning cloud architecture needs focus
There are tools on the market that provide the mechanism to assess the costs for each CSP or what would be the cost of running the identical on-premises payloads inside a CSP. Analogies and mappings between different CSP services can definitely be made, making running cost estimation an easy job.Here is a list of some of these useful tools:
- Azure Pricing Calculator
- AWS Pricing Calculator
- Total Cost of Ownership (TCO) Calculator
- AWS to Azure service mapping
But these tools cannot provide us and our customers with the information to answer the question about the effort required to build such a parallel system. The challenge is not the running cost itself! It is the effort cost to make a system run on another CSP. Is it possible? How much effort is required - $100k, $1M, 10%, 30% of the initial investment?
The complexity of building such a side-by-side system is higher and, in most cases, can be compared to the migration from one cloud vendor to another. Trade-offs, like using fewer SaaS services and cloud features to ensure that cloud interoperability level, can impact the quality of the final product. Still, they help us to keep costs under control. In general, the 'juice' provided by any CSP is diluted when you use fewer CSP-specific features.
When you want to run a software solution side by side on two different CSPs, additional effort is required for:
- Architecture
- DevOps and Automation
- Application Development
- Operations and Management
- Infrastructure
- Testing
Furthermore, the following system layers will mainly be affected:
- Application
- Database
- Infrastructure
- Communication
THE ACTUAL COST OF A SIDE-BY-SIDE SOLUTION We had the opportunity to get feedback through a survey answered by 51 cloud experts with solid experience with Azure, Amazon Web Services (AWS) and Google Cloud Platform (GCP) and some more in-depth conversations with some of them. Each of them provided input on the additional cost of building a system that runs side by side on two CSPs versus a system that runs only on one.
The additional effort required per layer was given as:
- 30% for the Application layer
- 25% for the Database layer
- 10% for the Communication layer
- 15% for the Infrastructure layer
The additional effort per work discipline was:
- 30% for Architecture
- 20% for DevOps using Terraform
- 70% for DevOps with cloud-native solutions (e.g. ARM, CloudFormation)
- 50% for Operations and Management
- 10% for Testing
- 30% for Development
- 25% for Database
Furthermore, the monthly cost of running a side-by-side solution is not simply double the cost of having one CSP because of the trade-offs mentioned above. Taking this into account, the running costs for the cloud are:
- 215% in the best case
- 250% on average
- 300% when you don't use SaaS and PaaS services anymore, and you need to use only IaaS services
Our discussion and estimations were based on the following type of system: a standard business application, built with Kubernetes and Docker and using a relational database management system (RDBMS), where an enterprise service bus (ESB) and REST API endpoints are used for external communication. In front of the system, an API gateway and a load balancer are required. We also assume that a VPN connection exists between the cloud and the on-premises office as well as basic cloud-native monitoring tools.
CONCLUSION Taking all the estimations above and the effort required to develop a cloud solution into consideration, we expect that developing a side-by-side system that runs on AWS and Azure would require:
- 35% additional effort to build and design the solution
- 50% additional effort for Operations and Management
- 215% additional cost to run the solution on AWS and Azure side by side
The data shows that it can be significantly more expensive to build a system that runs on two cloud vendors side by side. Therefore, the decision on whether to use one or more CSPs needs to take into account all the advantages, trade-offs and the added complexity. In the end, the business impact should dictate the cloud approach that a company needs to take.
Attachments
- Original Link
- Original Document
- Permalink
Disclaimer
Endava plc published this content on 08 February 2022 and is solely responsible for the information contained therein. Distributed by Public, unedited and unaltered, on 07 February 2022 12:29:00 UTC.
