Why go cloud native?

A blog post by David Linthicum, managing director, chief cloud strategy officer, Deloitte Consulting LLP

The benefits of implementing cloud-native features typically include the following:

• Performance. You’ll typically be able to access native features of the public cloud services to provide better performance than is possible with non-native features. For example, you can deal with an I/O system that works with auto-scaling and load-balancing features.
• Efficiency. Cloud-native applications’ use of cloud-native features and application programming interfaces (APIs) should provide more efficient use of underlying resources. That can translate to better performance and/or lower operating costs.
• Cost. More efficient applications typically cost less to run. Most cloud providers send you a monthly bill based upon the number of resources consumed, so if you can do more with less, you save on dollars spent.
• Scalability. Because you write the application to the native cloud interfaces, you also have direct access to the auto-scaling and load-balancing features of the cloud platform.

The price you pay for these capabilities is portability. Applications that are localized for specific cloud platforms are not easily ported to other cloud platforms. Doing so tends to take a lot of rewrites or refactoring of the code. For all practical purposes, you are locked into that cloud platform.

If applications run on the target cloud platform for years, you’re likely to get your investment back in code changes and testing. You should look at the potential advantages of going cloud-native on a case-by-case, application-by-application basis.

Unfortunately, there are no premade checklists you can use to make these assessments. You simply have to get as smart as you can about the trade-offs and make the best decisions you can.

To fully utilize a cloud platform, including IaaS and PaaS, you should design the applications so that they’re decoupled from any specific physical resource. For example, if you access I/O directly from a platform such as Linux, you need to access the cloud’s abstraction layer or their native APIs.

Clouds can provide an abstraction or virtualization layer between the application and the underlying physical (or virtual) resources, whether they’re designed for cloud or not. But that’s not enough; if you’re going truly cloud-native, it’s important to directly control the native resources.

When this architecture is considered in the design, development, and deployment of an application, the utilization of the underlying cloud resources can be much more efficient. Greater efficiency equals saving money. You’re paying for the resources you use, so applications that work more efficiently with those resources are able to run faster and generate smaller cloud services bills at the end of the month. There are several cloud cost governance tools that can monitor these costs for you. I urge you to consider using one or more of these tools if you plan to spend the time and money to move and refactor applications to be cloud-native.

So, this will be another learning process. Very much like what we saw when applications were made platform-native, there was failure at first. Meaning that working around the native platform features led to applications that did not live up to the expectations of the business, and IT had to go back to square one to redesign and refactor the applications to meet the needs of the business.

I suspect that the same patterns will be followed here. Meaning, in a few years, cloud-native may likely become the leading practice. However, that won’t happen until we fall on our faces a few more times. Some things never change.