Speed seems to be the imperative behind digital. Service Providers and customers seem to race with each other in this digital space. We can see huge, successful solution providers moving from rigid monolithic structures to loosely coupled service based architectures.
Cloud based solutions together with API-based communication and container-centric applications seem to have helped in this shift. And they have surpassed the initial hick ups. For some time, cloud providers, especially the most famous ones such as Amazon,
Microsoft Azure and Google Cloud, have driven business processes globally. As the technology continues to mature, the company's business processes are now questioning which cloud platform is more efficient, what could be easily maintainable, which option is
potentially more beneficial in the long term. At this juncture comes the debate: cloud native vs cloud agnostic. This is the point where companies decide whether to stick to one vendor or to be omni-present on all clouds.
Cloud Native: See the power of sticking to one provider
When a beginner like me tries finding the meaning of cloud nativity I get tons of different answers and end up as confused as I was when I started the process. Cloud platforms require applications to run in a distributed nature with systems that are scalable,
automatic and fault tolerant, but is that it? Or is there something more to it? According to a leading author on the topic,1 being cloud native is to surrender yourself to a platform and build for it. This means your application takes advantage of the strengths
of the underlying platform instead of trying to be present in all clouds.
Pros: Cloud native services have better performance, better efficiency and lower costs. One can inherently use auto scaling and load balancing features of cloud offerings by providers such as Amazon, and Google.
Cons: Cloud native would mean we end up using native APIs, but when a client has to move to a different cloud provider, it can involve a lot of code rewriting. Moreover, if the cloud provider changes the API/services during upgrades, the application will
also have to react accordingly and this can be both time consuming and costly. So does being cloud native efficiently solve your business objective?
Cloud Agnostic: Free yourself from vendor lock-in
Agnostic in the IT context would mean to be interoperable and it can refer to either software, hardware or even business practices. Thinking on the same lines, cloud agnostic means moving from one cloud to another without much impact to the IT systems and
business processes. To put it in mere technical terms, each of the cloud services say the infrastructure, platform and software, could be taken from different service providers and yet must not have impact the services provided. So in a way the data should
be portable and the applications should be platform agnostic. Containerization2 helps in being cloud-agnostic, it enables building the platform within the container and the applications can be run anywhere.
Pros: For clients working on multiple clouds, cloud agnostic service platforms will provide the required consistent and standard performance in every environment.
Cons: However, hopping between cloud providers will come with its own cost and complexities. It could mean the client is not using the complete capabilities of one vendor. Performance can also take a hit due to internal design differences of each vendor.
Moreover, logging and monitoring is really difficult with multiple cloud providers. They may not really provide a way to maintain and aggregate logs across platforms. So is being cloud agnostic worth the costs associated with it?
Let Business make a choice
While portability is clearly an issue with being cloud native, the rest of the benefits definitely tempt the clients to go ahead. If we want our developers to focus completely on building great application features rather than being bogged down by underlying
platform tools and infrastructure hassles, then cloud nativity is the answer.
The decision to go cloud agnostic needs to be more organization-driven. It involves some questions which the leadership needs to answer like: Do we hire outside developers? Do the apps the company builds need to undergo major changes as we deploy them across
the globe? Do we need to upgrade versions frequently? Does the business process change drastically across the globe? Is the problem being addressed a short term problem or does it have long term repercussions? Being cloud agnostic is mostly preferred when
application features are likely to undergo faster changes but in smaller chunks. More over for clients with geographically dispersed sustainable operations being cloud agnostic is the way to go.
Ultimately the decision to build for a specific cloud platform or remain cloud-agnostic depends on the application and the constraints of budget, time, etc. Considering the life-expectancy of a software, the requirement for modularity and standards-based
architecture design, it's best left to the business and its process teams.
Reference:
https://medium.com/humio/what-is-cloud-native-anyway-6ff0aa0b311d
https://www.cloudpro.co.uk/leadership/cloud-essentials/6325/can-you-really-be-cloud-agnostic