It is refreshing to see that analysts, bloggers and many of the vendors are finally catching up to what the Digital Transformation Strategists have known for nearly a decade — Cloud is not always cheaper. What is disappointing though is that the advice such as the one posted in October on TechTarget only scratches the surface and may in some cases hurt the evaluator by trusting tools or solutions that only view a small portion of the cost.
In my books: iSpeak Cloud Crossing the Cloud Chasm (2014) and iSpeak Cloud Embracing Digital Transformation (2016), I touch upon the 5 Phases and identifying the total costs that will impact an application workload. Many of the articles I read oversimplify and/or overlook the hidden costs, political, and user impact that either a Hybrid, Multi-Cloud, or Public Only may have. When you are looking to migrate to Cloud it is important to view it from a business — not just a technologist — perspective. When you evaluate the various tools, ask yourself if they do the same.
License Changes to Fit Vendor Market Conditions
It is not just existing legacy licensing agreements that can get you in to trouble at the time of migration. You can also get into trouble if your provider charges a different price based on what cloud provider you chose or having the wrong private cloud architecture. Why? Licensing rules change and workloads change even faster.
Some large vendors have been notorious for quietly raising their license fees on a given cloud (private or public) and using audits to achieve their revenue goals. IT has to be diligent on who these vendors are and changes when deciding on architecture approaches during refactoring. Otherwise they risk being caught off guard. Don't take my word for it — ask Mars Candy why they decided to settle for $100 million out of court.
Migrate ONLY What You Can MAP
Part of solving the Cloud Cost Conundrum is understanding exactly how not just an application but the entire Business Service Workload maps to that given application. Before you can connect an application to the Hybrid Service, you must first understand what the application is comprised of.
One implementation I managed originally thought only 11 applications were impacted but in truth it was 48. Why? Because of microservices, program calls, and overall service dependencies needed by the business to service their customers. If you cannot map not only what the application but attached services are, you cannot determine true cost of Cloud Implementation.
Understand Costs Beyond the Tools
There are many hidden costs that typical calculators are hit or miss on that can significantly impact costs. My contributors and I provide a laundry list in my latest book but here are a few to be aware of that are not typically thought of that often lead to business cases off by millions:
1. Proximity of:
■ Users to Edge Workload: A term often referred to as "Last Mile." It is the distance for all the stay at home, remote, and even in-office workers to the nearest access point to download not only the application but the data. The amount of hops, time etc. all impacts costs, agility and in some cases compliance.
■ Application Components to Each Other: This is also known as the middle mile. It is the distance between the data and each application component (UI, microservice, etc) needed for the Application and/or Service to work. The transactional costs of pulling and pushing across multiple cloud providers can add up over time.
■ Data and Data Aggregators: This one is trickier to explain. Essentially not all the data created is needed by a given application, only a subset. In many cases it is better to aggregate the data at the edge versus send all the data up and pay extra storage and transmittal costs. There are also trade offs between the distance from the data aggregators, data origination points, and data storage that may impact cost, agility, and or compliance.
2. Number of Users and Amount of Data they Typically Push/Pull
This goes into the chart above. The Law of Diminishing Returns is the tipping point from where the number of users, their increased data usage, and cost increases surpass savings. Yes, you need to project data usage not just from the pilot but existing application. Otherwise the Digital Native ability to consume and multi-task with data will create a sharp "Oh Sugar Honey IT" moment months into your rollout.
3. Internal Infrastructure Impact and Costs
Not just the cost for AWS, Microsoft Azure or what the cloud providers charge for the upload/download of data but also what your ISP charges. You also have to consider physical infrastructure impact or what your switches, routers, hubs etc can handle in terms of load. Often times when I speak to clients, they are surprised by the impact that their decision to move to SaaS, Public or Virtual Private Cloud has on other operational costs that were not included in the tools or business case.
