eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

Also see: Deloitte’s David Linthicum on Optimizing Your Multicloud 

First, a quick refresher: cloud native means we leverage services and systems found only on a specific cloud provider.

When developers and architects refer to “cloud native,” they are typically referring to specific cloud services that won’t be found on other clouds or traditional platforms. These cloud services include things like security, management, databases, serverless systems, and financial operations (FinOps).

We employ cloud native services from within applications or other solutions, for reasons that include:

• More advanced. Cloud native services are typically more advanced than non-native services. They provide direct access to other native resources such as storage, compute, and databases. Thus, cloud native means more modern functionality that you don’t have to build, test, and deploy.
• Better performance. Cloud native services typically perform better. Performance is generally better because the services are built and owned by the cloud provider and are purposed built for their multitenant platform.
• Interoperability. Cloud native services typically work and play well with other cloud native services. Again, since they are purpose-built for a specific cloud provider, they typically support plug-and-play integration with other native services. For example, a cloud native messaging system talks to its cloud native databases without the need to do custom integration.
• Lower costs. Cloud native services typically cost less than non-native services. Since they are built for a specific cloud provider, and do not support any other provider, they are typically tuned to leverage fewer resources. This means the cloud bill should be lower than if you leveraged non-native services.

If the above list is true, why would we ever leverage non-native services?

The answer: Because like everything else in the world of computing, there are no free lunches. When you leverage cloud native services there will be benefits and liabilities, winners and losers.

Also see: Why Cloud Means Cloud Native 

Cloud Native Losers

Some will find that cloud native is not a particularly good solution for their problem domain, and then there are those who want to avoid vendor lock-in. If you leverage cloud native features of a specific cloud provider, this makes your application and data storage systems less portable across clouds or traditional systems.

If we take advantage of the benefits of cloud native services as listed above, that’s a good thing. However, a cloud native solution cannot move to another cloud or non-cloud platform without a great deal of modification.

Modification will require removal of any couplings to cloud native services on the existing cloud. The couplings then need to connect to the cloud native services of the new target cloud platform, or leverage more open services that can be found on most platforms, or non-native services that include storage, compute, and databases.

Enterprises that don’t plan ahead to move an application off a specific cloud but are forced to do so at some future point will also become losers. There is a lot of cost and risk involved in modifying applications to remove specific cloud native services and replace them with other cloud native services or open services.

Clearly, this is the dreaded “vendor lock in.” Most applications that move to cloud platforms won’t ever move off that platform during the life of the application, mostly due to the costs and risks involved.

Another drawback is that you’ll need cloud specific skills to take full advantage of cloud native features. This talent may not be available in-house or in the general labor pool, and/or it could drive staffing costs over the budget.

The pandemic drove a massive rush to public cloud providers, which meant the demand for cloud migration skills exploded as well, driving up salaries and consulting fees. Moreover, the scarcity of qualified skills increases the risk that you won’t find the skills needed for cloud native systems builds, and/or the required level of talent will be unavailable to create optimized and efficient systems.

This leads some enterprises down a scary path of budget overruns. More likely than not, cloud native systems with runaway budgets will not meet the expectations of the business.  Thus, it often becomes more difficult and costly to gain cloud native advantages than anyone anticipated. The lack of cloud native talent clearly drives up the risk, which in turn could make cloud native architecture and development not worth the effort.

Also see: Top Cloud Service Providers & Companies 

Cloud Native Winners

Although the value of cloud native may increase or decrease over time, any enterprise that can leverage cloud native services with at least two of the value drivers listed above (e.g., performance and cost) will end up a cloud native winner.

Typical cloud native winners can absorb and justify the risk and cost of going cloud native.  For example, let’s say we want to migrate an inventory management system from a traditional LAMP (Linux Apache MySQL and Python) stack within a data center to the same LAMP platform that runs on a public cloud.

Rather than do a simple lift and shift, the migration team decided to leverage some cloud native services such as security, clustering, serverless, and management and monitoring.  Therefore, the application must be modified, retested, and redeployed to leverage these specific cloud native services.

The team expects all the benefits listed above to exist within the migrated application, to some extent. The additional work to go cloud native will add about 300 percent more cost versus just lifting and shifting the application with minimal modification. Will the final cloud native solution be worth the costs and risks?

It’s time to place some bets. First, you’re betting that the additional expense of adding cloud native features will come back in longer term value, such as performance and cost advantages. Second, to be true winner, you’re also betting that this value will come back to the business during the life span of the application.

Speaking in generalities, the average cost to go cloud native is about 300 percent of non-modification approaches. So, if a lift-and-shift with minimum modifications would cost $50K all in, then a cloud native application would cost about $150K for the same application. In this example, the migration team bet $100K that the enterprise will get back at least $100K in value by going the cloud native route.

Many factors determine if the cloud native bet will pay off, and you’ll have to take this one application at a time to determine if you’ll win or not. Also, remember the wild card.  If the cloud native system must someday move to another cloud, or back to the original systems, all bets are off and you’re back to being a cloud native loser.

Also see: Best Practices for Multicloud (That Cloud Providers Prefer You Not Know) 

Some Advice – But No Easy Answers

If going cloud native was an easy, straightforward choice, everyone would do it. On the surface, cloud native offers more efficient applications with greater functionality and less use of cloud resources. But it’s another tradeoff in the world of computing. The migration team must consider all parts of anything that moves to the cloud and make the cloud native bet based upon the attributes of each potential migration solution.

My advice is to compile a comprehensive comparison list for each cloud migration project to illustrate the benefits, costs, and risks associated with lift and shift versus cloud native. As we gain experience and get better at cloud computing, it follows that we’ll get better at picking the right applications to become cloud native. In turn, we will generate more winners than losers.

Also see: Tech Predictions for 2022: Cloud, Data, Cybersecurity, AI and More