5 Cloud Myths Where Engineers Need a Reality Check

Object Management Group releases its top cloud myths. Here are the ones relevant to engineers.

The cloud is becoming a popular tool for engineers of all stripes. Manufacturing processes, product functions and IoT databases are increasingly moving to the cloud. And design engineers have already been using the cloud for years to enable the high-performance computing (HPC) and data storage needed to design, optimize and simulate during product development.

(Image: Bigstock.)

(Image: Bigstock.)

Unfortunately, many myths around cloud technology persist. And they could scare engineering firms, or leadership, away from the cloud tools needed to bring on digital transformations. Worse yet, it could lead organizations to cloud-service providers (CSPs) ill-equipped to handle engineering applications.

Fortunately, the international technology standards organization Object Management Group has just released a paper from its Cloud Working Group that discusses cloud myths and their impacts. Here are the myths most pertinent to engineers.

Myth 1: Move Everything to the Cloud, You Won’t Regret It

The truth is that engineers may want to keep some of their internal systems and tools in-house instead of moving them to the cloud. For example, the cloud may have been selected to test and deploy a new tool or process. And once testing is completed, engineers might find that the computational resources needed to run this innovation can be handled by the HPC resource already on-site. As those systems are already paid for and being maintained, it could be cheaper to have the new tool live there.

“Another situation in which a customer may not move to the cloud is when it has developed a proprietary system that gives it a competitive advantage,” reads the Object Management Group report. “Therefore, there is no equivalent Software as a Service (SaaS) offering, and there is little technical or financial incentive to move this code onto an Infrastructure as a Service (IaaS) or Platform as a Service (PaaS) solution.”

Yet another reason why engineers might want to keep a new tool on on-premises HPC is because of some technical limitation, such as the need to transfer large swaths of data. Or, perhaps the company may fall into an industry governed by laws and policies that limit the distribution of its intellectual property and data. In other words, it may not be financially, legally or logically relevant to move everything to the cloud.

Myth 2: Leaving the Cloud is As Easy as Joining It

According to the Object Management Group, migrating systems off the cloud can be more expensive and difficult than moving to the cloud. This myth that leaving the cloud is easy plays well with the previous discussion and goes to show that engineers need to properly assess whether a product, process or system should be moved to the cloud—because reversing that decision might not be possible or feasible.

It’s no different than when a design engineer discovers an error late in development. The late-stage changes and redesigns needed to fix the issue are often more expensive than if the issue had been found and solved earlier in the development cycle.

“During the use of a cloud solution, which will usually last several years, it is likely that the data will have become more massive and more complex,” reads the report. “Columns will often have been added to databases. Proprietary features and services offered by the cloud provider (e.g., validation rules and triggers) may have been leveraged, making the resulting data harder to extract and reload onto a different platform. It is easy to believe that you can stay away from such non-standard add-ons, but in practice they are impossible to resist. As a result, recovering all your data in a way that makes it easy to transfer to another service is more complicated and costly than most customers realize.”

Intuitively, it should make sense that leaving the cloud can be a challenge. The CSP has no incentive to help you move to another system, but every incentive to help you move towards their services. So, they can often be helpful when you join, and contract litigators as you leave. Additionally, once relationships with the CSP close any data left on that cloud could be lost forever. As a result, Object Management Group notes that in many situations, third parties are needed to support the transfer from one cloud to the next, or from one cloud to internal systems.

Myth 3: Cloud Solutions are Cheaper than On-Premises High Performance Computing

If a product or system needs to move to the cloud to ‘update with the times,’ then it’s going to happen one way or another. So, this myth might be moot to many engineers—but it is still worth mentioning.

The reality is that when moving to the cloud, expenses shift from capital expenditures—on-premises HPC systems—towards operational expenses, through the CSP. For the engineers producing a project’s budget this can translate into short-term gains for long-term losses.

“If … you have made the right choice and use the same solution for more than (typically) two or three years, the accumulated monthly payments for the solution may well exceed what you would have paid for an outright purchase, whether the system is installed on-premises or at a traditional hosting service provider,” reads the report. “But you will only know after the fact that the cost curves have crossed and that your total cost of ownership (TCO) has become greater in the cloud. You may also realize that some TCO studies are biased in favor of cloud solutions: they may include overinflated data center savings, operational savings that never become realized, or neglect to factor in all costs such as software licensing.”

Think of it this way: if on-premises HPC is utilized to capacity on a regular basis and sized properly to the needs of an engineering team, then it could be less expensive in the long run. However, if situations change or the computational resources needed for a project are fluid, then HPC systems could collect dust. In this case, the cloud is often the better option.

The report adds, “Because it is uncertain whether a cloud solution will be cheaper or not in the end, it is wrong and dangerous to use this as the major argument to ‘sell’ the cloud to executives. There are many other advantages of the cloud that can justify such a move, especially agility—the speed of deployment of a solution in response to new or changing business needs. Selecting and procuring the hardware and software to deploy an ERP or a CRM system in-house typically takes several months; while a rash decision should not be made for a cloud solution either (this could be another myth in itself), it is possible to subscribe to a cloud-based solution and start using it within weeks, if not days.”

Myth 4: The Cloud is an Infinite Resource

Engineers can typically see when a marketing team claims to have access to a perpetual motion machine, so the notion that the cloud provides infinite computational power has always been suspect. But the ramifications of this reality, and why it occurs, may not be as obvious—especially for complex engineering applications.

“Certain applications may require specific hardware or network configurations to deliver maximum performance,” reads the report. “The cloud environment is usually a ‘common denominator’ that works well for most customers, but is not specifically optimized for any of them. Most cloud environments include virtualization layers in order to emulate the operating system required by the application on top of a common base kernel, and those layers consume resources. To avoid this for a high-performance application, the customer may need to configure the entire stack from scratch on top of a bare metal IaaS offering. The more esoteric or specialized resources—such as HPC servers equipped with GPUs, used for visualization, scientific computations or AI and machine learning—will typically be offered in more limited numbers. A customer who depends on such resources may need to pay for ‘reserved resources’ to ensure that they will be available when needed.”

CSPs will have their own technical limitations and they can’t let every customer scale up indefinitely. As a result, they will likely set up contractual, physical and financial barriers to keep an engineering team’s foot off the gas when requesting HPC resources. The result is that even though rapid elastic HPC and on-demand resources are available, they need to be spec’d just like any other HPC resource.

Myth 5: The Cloud is Less Secure Than In-house Systems

When discussing the first myth, the legal limitations some organizations have with respect to how data is stored were mentioned. And these limitations, among other challenges, have led many to suspect that the cloud is less secure than on-premises tools.

The report points out that, “comparisons between reported security incidents affecting cloud providers vs. end user companies are misleading, as end users often keep quiet about incidents, unless required by law to divulge data breaches, therefore those numbers are understated.”

The truth is often that the cloud is more secure. There is an incentive for CSPs to provide customers services that are safe from data loss, corruption and nefarious actors. As a result, they will employ more security professionals, technologies and systems than most engineering organizations can afford to protect their own internal systems. Additionally, as data is stored in locations containing the data of other organizations, anything that is intercepted is obfuscated beyond the encryptions already in place.

So, if it’s beneficial to have data in the cloud, and legally that can be done in your field, then it can be the safest, best option. But remember that the cloud isn’t a silver bullet. You still must assess it properly for your engineering systems.

Written by

Shawn Wasserman

For over 10 years, Shawn Wasserman has informed, inspired and engaged the engineering community through online content. As a senior writer at WTWH media, he produces branded content to help engineers streamline their operations via new tools, technologies and software. While a senior editor at Engineering.com, Shawn wrote stories about CAE, simulation, PLM, CAD, IoT, AI and more. During his time as the blog manager at Ansys, Shawn produced content featuring stories, tips, tricks and interesting use cases for CAE technologies. Shawn holds a master’s degree in Bioengineering from the University of Guelph and an undergraduate degree in Chemical Engineering from the University of Waterloo.