6 Cloud Computing Myths, and 1 Teaser DevOps Myth

Cloud Computing Myth 1: Cloud is Cheaper than On-Premise

Our first cloud computing myth is that Cloud is cheaper than on-premise solution. That migrating a server to cloud is cheaper.

Myth Busted

One FTP server on-premises moved to the cloud with decent specifications running on Linux would probably cost $600 USD monthly or $7,200 USD annually. Why is that not cheaper? Your cloud migration will probably take you 2 years to complete. While it is not complete, the OPEX and CAPEX in your on-premises data center remain the same until all workloads are migrated. Additionally, a company should be able to buy a decent FTP server on-premises for the cost of $7,200 USD.

Myth Confirmed

A batch job running on-premise report consolidation at the end of the day for 2 hours, migrated to the cloud as a spot instance M54.XLARGE, would cost 1.5 USD in 2 hours or $540 USD annually. That is far cheaper than running in an on-premise data center.

Conclusion

Cloud computing is not about cost. It is about a company's long-term strategy. When done right, cost savings will follow your company. When done wrong, costs can go way higher than expected. Cloud Computing Myth not proven.

Cloud Computing Myth 2: Apps running in Cloud are Highly Available

The first thing that comes to people's minds about the benefits of the cloud is its 99.999999999% availability. When downtime occurs, they start to wonder why that is the case.

Myth Busted

A monolithic customer management system consists of a web front-end, web server, API, and MySQL all in a single on-premise instance. When migrated to the cloud via lift and shift, it will not inherit any high availability attributes of the cloud. However, often, every time there is downtime, the first question you receive is "I thought we were in the cloud?" I thought the cloud is 99.999999999% available. This is a misrepresentation of the cloud.

Myth Confirmed

The same customer management system mentioned earlier was migrated to the cloud using a re-architecture strategy. The front-end was decoupled into EC2 instances with a load balancer and auto-scaling. The database was migrated to RDS with multi-AZ enabled. Lastly, the API was deployed to another EC2 with a load balancer under an autoscaling group. This setup assumes that the app is stateless and would meet the high-availability attribute in the cloud. This setup will make it high available.

Conclusion

Cloud is not highly available unless your strategy makes it highly available. One has to evaluate and look at the business continuity plan whether high availability is a must or not. High availability comes with a price, and the investment of your high availability will be justified by your business continuity plan where the criticality of applications is defined. Cloud Computing Myth not proven.

Lastly; an app needs to meet the following minimum requirements to be qualified for high availability setup:

1. loosely coupled - no dependency

2. Stateless - do not store data

3. API Based - API driven or micro services

4. Infrastructure Architecture - purposely built cloud infrastructure

   
   

Cloud Computing Myth 3: Migration to Cloud Removes Security Vulnerabilities

There are those that I've met, many of them (not all) in fields like Information Security, Executives, Leaders, and Operations, where the common belief is that moving workloads from on-premises to the cloud will fix existing vulnerabilities and is the fastest way to address audit findings.

Myth Busted

A Windows 2013 server running MSSQL with outdated OS patches, .Net runtime libraries, and SQL updates hypothetically has 50 critical and high findings when migrated to the cloud using the lift-and-shift strategy via AWS Migration Service. It will inherit the same vulnerabilities as it had on-premise. However, the approved strategy is lift and shift due to a tight deadline.

Myth Confirmed

The same setup as above with Windows Server 2013 running MSSQL Server, when migrated to the cloud using either the re-host or re-platform strategy into AWS RDS database, where data is directly loaded via AWS Data Migration Service, will fix almost all vulnerabilities on-premise.

Conclusion

Though re-hosting and re-platforming is a viable strategy compared to lift and shift when addressing vulnerabilities, one has to be cognizant that there are chances batch jobs on the old on-premise server will no longer run in AWS RDS. Thus, choosing the right strategy is very important. That is why domain knowledge comes into play for cloud migration more than what the book or search engine says. Cloud Computing Myth not proven.

Cloud Computing Myth 4: Apps Running in Cloud are Highly Scalable

I had heard many times that people pitch cloud to be highly scalable. An e-commerce company, for example, might have the impression that simply running apps in the cloud will allow them to scale during peak season. When peak season comes and they fail to scale, people then face the realization or may still be in denial.

Myth Busted

An e-commerce website running on M5.8XLarge, where both the web server, database, API, and front end are hosted, can only be vertically scaled up to M5.24XLarge at most. Therefore, there will be a point where transactions will reach the hardware limit threshold and can no longer accommodate more traffic.

Myth Confirmed

A well-architected e-commerce website where the front end is running in S3 lightweight, APIs are micro services running in EKS, and transactions are queued in SQS or maybe RabbitMQ. Data is written in a NoSQL database like MongoDB / Document DB, which would scale horizontally to accommodate virtually any size of transactions.

Conclusion

It is not true that clouds are horizontally scalable by nature. It only holds true when proper architecture, planning, and design considerations are put in place. Most of all, if companies are willing to spend on such a setup. Cloud Computing Myth not proven.

Cloud Computing Myth 5: Cloud Produces Cost Savings

I often hear people who rely on Reserved Instances and Savings Plans as their source of cost savings. While this may be true, it is not always the case. Let us debunk the myth.

Myth Busted

Let us say we have 100 servers running in the cloud. Our excitement hypothetically says that purchasing Reserved Instances or a Savings plan will give us $10,000 per month of savings. I've seen many times people become trigger-happy to purchase such a commitment for 3 years. All of a sudden, there is a change in business requirements where 30 of those servers are to be decommissioned due to End of Life.

You actually end up paying more than your cost savings.

Myth Confirmed

In the same hypothetical situation as above, there are 100 servers running in the cloud. However, a competent cloud professional would perform due diligence before making a Reserved Instance (RI) or Savings Plan (SP) commitment by aligning with the business. They will forecast the 3-year demands before purchasing RIs and SPs by conducting workload discovery to understand the lifecycle of those apps. They will also align with business units to anticipate future projects. As a result, the cloud professional can then make data-driven RI and SP purchases to maximize cost savings while avoiding over-purchasing.

Conclusion

Cloud is a double-edged sword. In the hands of competent professionals, it does produce cost savings; in the hands of novices, the cloud will be costly. Cloud Computing Myth not proven.

Cloud Computing Myth 6: Cloud to Cloud Migration Solves Past Mistakes

Ever heard of a rogue cloud account? The cloud account that your company had when they were starting out? The account where developers made their POC to production, the account where all security groups were open, the account that runs forgotten apps yet everybody uses it, the account where development, QA, and production all run in one environment. The time will come when your organization has to address this account by closing it.

But I've met many people whose idea of fixing these problems is by moving all these apps to a new cloud account. Voilà! You've dodged all the problems in the past.

Myth Busted

Imagine a server running in the old cloud account, where that server has no asset tag, and neither a single person in the organization is willing to raise their hand for ownership. Yet when threatened to be turned off, everyone says it is being used. That means it was later found out to be repurposed into another function. Then suddenly, a novice person suggests that moving the app to another cloud will magically solve the issue.

Wrong; you are simply bringing a rotten tomato to another account that is sanitized. As a result, one may be creating a bigger mistake. Since the server is a Pandora's box, one may even cause unexpected downtime because we do not know how much or how many people have repurposed such a server.

Myth Confirmed

Same server as stated earlier. When proper due diligence is done, put AWS Application Discovery Service in place to uncover connectivity and usage so that a proper cut-over can be performed. Conduct proper planning, sanitation, and communication with the business before moving these rogue servers to a new landing zone to address potential vulnerabilities and properly account for users. This strategy can lead to success.

Conclusion

Be cautious with this strategy. Unless you know what you are doing, this strategy should be a last resort and may be ineffective. There may come a time when not all apps from the old account can be migrated. Consequently, you may still have the same vulnerabilities in the old account because you cannot decommission it. This can result in duplicated work and effort. The most you can do is be very clear about your purpose, objectives, and expectations when doing cloud to cloud migration. A good statement would be: "We want to perform a cloud-to-cloud migration to salvage some apps that are still in use in the old. We also understand that not all apps can be salvaged and that the old account may not be decommissioned, but at least we can address some." Cloud Computing Myth not proven.

DevOps Myth 7: Mix everyone and change Title to Build DevOps

I've seen this many times. An organization mixes everyone to form a DevOps. There will be inflation of IT Title Change. A person with 0 DevOps background suddenly has a title of Site Reliability Engineer or DevSecOps Engineer or Chaos Engineer. Yet over and over again. This will fall short.

Myth Busted

I have never seen this succeed. This is myth busted. Think of a basketball team. Buying new shoes, new uniform, and change point guard with new role as center will never produce a championship material. A DevOps should be built like MoneyBall. Hard work is needed top down and bottoms up.

Myth Confirmed

This myth can not be confirmed and will never work.

Conclusion

Have a look on this article I had written. It discusses what a competent executive should do to build DevOps. This is own version of DevOps Adoption Framework. Though it is an adaptation of many style, I got to prove this to work after I build DevOps CICD pipeline in my current organization where we got to do the following:

• From 4 hours window time to 15 minutes

• From 4 hours of downtime to 5 minutes

• From 7 days preparation time to 1 day

• From 1 deployment per schedule to as many times as needed basis