Architecture
| Radu Vunvulea |
07 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 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.
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
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.
Tags
Radu Vunvulea
Group Head of Cloud Capability
Radu is a technology enthusiast. He has vast experience in different technologies and industries and spends most of his time working with the cloud, helping companies to innovate and finding solutions to their business problems. He enjoys connecting people and helping them to grow. When he isn’t blogging or speaking at events, Radu likes to build his own IOT devices, he enjoys an early morning run or a hike up a mountain. His feet seem to be his preferred method of transportation, he would do anything not to be stuck in traffic.All Categories
Related Articles
-
25 January 2022
Scalable Microservices Architecture with .NET Made Easy – a Tutorial
-
24 August 2021
EHR to HL7 FHIR Integration: The Software Developer’s Guide – Part 3
-
20 July 2021
EHR to HL7 FHIR Integration: The Software Developer’s Guide – Part 2
-
29 June 2021
EHR to HL7 FHIR Integration: The Software Developer’s Guide – Part 1
-
30 October 2020
API Management