When being cloud-native is a bad idea
It’s good to be cloud-native, or at least that’s what everyone is telling you. The idea is that you refactor (meaning partially recode) your applications to take advantage of the native features of the host cloud, such as its native APIs, storage systems, database systems, or security systems, depending on what that host cloud services offers.
The promise you’re being given is that being cloud-native will provide enhanced performance, lower operational costs for your applications, easier operations, and a bunch of other benefits as the cloud platform improves over time.
However, there is a dark side to being cloud-native, and it’s worth some consideration before you spend a significant about of time refactoring your code. The considerations include:
The lockin issue. You’re not going to make an application cloud-native application without giving up some or all of its portability. If you’re localizing an application for Amazon Web Services, Google Cloud Platform, or Microsoft Azure, you’re coding to the native APIs of those clouds. By using native APIs, it will be difficult to move that code to other clouds, or back to on-premises systems, without refactoring again.
Depending on the complexity of the applications, that could be a significant investment in time and added risk.
Native benefits are not always there. Using native services can generate a benefit in some way, shape, or form. But not always; many IT organizations use native APIs but don’t see the benefit of using those APIs during operations.
You need to understand what benefits those APIs will provide, and measure the benefits once deployed.
Native features often change. It’s hard enough to refactor an application around cloud-native APIs to call cloud services. It’s even harder when those services change. Although your API calls are static, the services they access are dynamic, and the cloud provider will change them to meet its own needs. As such, you need to consider what’s changed in the application and react accordingly.
The fact that services change is not in and of itself bad. But it means you can never rest easy, and in some cases the cost of keeping up with the service changes is not worth using the cloud-native services in the first place. API monitoring and governance tools come in handy here, because they can alert you to API/service changes as they occur, so you have time to react.
The cloud-native allure is real, and for the most part it’s a good thing. However, like any other technology choices, there is both an upside and a downside. You need to understand both before you refactor.
Source: InfoWorld – Cloud Computing
Recent Comments