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(

Azure AD and AWS Cognito side-by-side

In the last few weeks, I was involved in multiple opportunities on Microsoft Azure and Amazon, where we had to analyse AWS Cognito, Azure AD and other solutions that are available on the market. I decided to consolidate in one post all features and differences that I identified for both of them that we should need to take into account. Take into account that Azure AD is an identity and access management services well integrated with Microsoft stack. In comparison, AWS Cognito is just a user sign-up, sign-in and access control and nothing more. The focus is not on the main features, is more on small things that can make a difference when you want to decide where we want to store and manage our users.  This information might be useful in the future when we need to decide where we want to keep and manage our users.  Feature Azure AD (B2C, B2C) AWS Cognito Access token lifetime Default 1h – the value is configurable 1h – cannot be modified

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