Skip to main content

HOW MUCH WOULD COST ME TO BUILD A SYSTEM TO RUN ON TWO CLOUD VENDORS SIDE-BY-SIDE?

 One common question that I hear lately is: 

HOW MUCH WOULD COST ME TO BUILD A SYSTEM TO RUN ON TWO CLOUD VENDORS SIDE-BY-SIDE?

It is a simple question that a business person has. Nevertheless, the response is not simple. Without running a workshop and invest time to understand the business requirements, the current technology stack and expected quality attributes, providing a cost of building the same solution on another CSP (Cloud Service Provider) is hard.

There are tools on the market that provide the mechanism to assess costs on each CSP or what would be the cost of running the same on-premises payloads inside a CSP. Analogies and mapping between different CSP services can be made, making running cost estimation an easy job.

Useful tools:

The challenge is not the running cost! It is THE EFFORT COST to make a system run on another CSP. It is possible? How much ($100k, $1M, 10% of the initial effort)? 

The complexity of building such a system is higher and, in most cases, can be compared with migration from one cloud vendor to another. Trade-offs like using fewer SaaS services and cloud features of a CSP to provide that cloud interoperability level can impact the quality of the final product. Still, they help us to keep costs under control. All the juice that is provided by a specific CSP is diluted when you use less CSP specific features.

When you want to run a solution side-by-side on two CSP, additional effort is required on:

  1. Architecture
  2. DevOps and Automation
  3. Application Development
  4. Operational and Management
  5. Infrastructure
  6. Testing
The main affected layers of a system are:

  1. Application
  2. Database
  3. Infrastructure
  4. Communication
The actual cost of a side-by-side solution
I had the opportunity to discuss directly or indirectly with 51 cloud experts with solid experience with the cloud (Azure, AWS and GCP). Each of them provided input related to the additional cost of building a system that side-by-side VS a system that runs only on one CSP.

The additional effort per layer:
  • 30% for the Application layer
  • 25% for the DB layer 
  • 10% for the Communication layer
  • 15% for the Infrastructure layer
The additional work per work type:
  • 30% for the Architecture
  • 20% for the DevOps using Terraform
  • 70% for the DevOps with cloud-native solutions (e.g. ARM, CloudFormation)
  • 50% for the Operational and Management
  • 10% for the Testing
  • 30% for the Development
  • 25% for the Database
The monthly running cost of a solution side-by-side is not 2 x 100% because tradeoffs need to be done. Taking this into account, the running costs are:
  • 215% for the cloud running costs in the best case
  • 250% for the cloud running costs on average
  • 300% for the cloud running costs when you don't use SaaS and PaaS services anymore, and you need to use only IaaS services

The discussion and estimations were built for the following type of system: A standard business application, built using Kubernetes and Docker, using an RDMS DB, where an ESB and REST API endpoints are used for external communication. In front of the system, an API Gateway and a Load Balancer is required. A VPN connection exists between the cloud and the on-premise office together with basic cloud-native monitoring tools. 

Conclusion
Taking all the previous effort estimations into consideration and the effort required to develop a cloud solution, we expect that to develop 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 cost for Operational and Management
  • 215% additional cost to run the solution on AWS and Azure, side-by-side

Comments

Popular posts from this blog

Windows Docker Containers can make WIN32 API calls, use COM and ASP.NET WebForms

After the last post , I received two interesting questions related to Docker and Windows. People were interested if we do Win32 API calls from a Docker container and if there is support for COM. WIN32 Support To test calls to WIN32 API, let’s try to populate SYSTEM_INFO class. [StructLayout(LayoutKind.Sequential)] public struct SYSTEM_INFO { public uint dwOemId; public uint dwPageSize; public uint lpMinimumApplicationAddress; public uint lpMaximumApplicationAddress; public uint dwActiveProcessorMask; public uint dwNumberOfProcessors; public uint dwProcessorType; public uint dwAllocationGranularity; public uint dwProcessorLevel; public uint dwProcessorRevision; } ... [DllImport("kernel32")] static extern void GetSystemInfo(ref SYSTEM_INFO pSI); ... SYSTEM_INFO pSI = new SYSTEM_INFO(

ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded

Today blog post will be started with the following error when running DB tests on the CI machine: threw exception: System.InvalidOperationException: The Entity Framework provider type 'System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer' registered in the application config file for the ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded. Make sure that the assembly-qualified name is used and that the assembly is available to the running application. See http://go.microsoft.com/fwlink/?LinkId=260882 for more information. at System.Data.Entity.Infrastructure.DependencyResolution.ProviderServicesFactory.GetInstance(String providerTypeName, String providerInvariantName) This error happened only on the Continuous Integration machine. On the devs machines, everything has fine. The classic problem – on my machine it’s working. The CI has the following configuration: TeamCity .NET 4.51 EF 6.0.2 VS2013 It see

Navigating Cloud Strategy after Azure Central US Region Outage

 Looking back, July 19, 2024, was challenging for customers using Microsoft Azure or Windows machines. Two major outages affected customers using CrowdStrike Falcon or Microsoft Azure computation resources in the Central US. These two outages affected many people and put many businesses on pause for a few hours or even days. The overlap of these two issues was a nightmare for travellers. In addition to blue screens in the airport terminals, they could not get additional information from the airport website, airline personnel, or the support line because they were affected by the outage in the Central US region or the CrowdStrike outage.   But what happened in reality? A faulty CrowdStrike update affected Windows computers globally, from airports and healthcare to small businesses, affecting over 8.5m computers. Even if the Falson Sensor software defect was identified and a fix deployed shortly after, the recovery took longer. In parallel with CrowdStrike, Microsoft provided a too