Cloud Agnostic vs. Cloud Native

blog-post-image

As we help our clients bring to life their applications in the cloud, an early discussion point centers on whether to build a cloud-native or a cloud-agnostic architecture. Each approach offers benefits as well as risks. First, let’s define each approach. Cloud-native architectures use one cloud provider’s proprietary offerings, putting down deep roots into a certain cloud provider. Cloud-agnostic architectures take advantage of open source technologies and portable components, making it easier to change cloud providers, or in some cases, use multiple cloud providers at once.

Cloud-native architectures are suitable when a client wants to go all-in on a particular cloud vendor. Often this approach is taken with an application which is born in the cloud, rather than one that is lifted-and-shifted to the cloud. This type of architecture uses vendor-specific offerings, such as AWS’ function-as-a-service solution called Lambda or Azure’s globally-distributed database offering called Cosmos DB. Choosing to use these services creates lock-in to one cloud provider, which can be difficult to undo should the need arise. However, there are b enefits as many vendor-specific cloud solutions reduce the amount of effort required to build resilient cloud architectures. A good example of this is Amazon DynamoDB – a NoSQL database solution that requires no server setup, capacity planning, or software upgrades.

A cloud-agnostic approach builds using open source tools and standards and can make migrating from one cloud to another relatively easy. If one runs a PostgreSQL database on an Azure VM and wants to move it to AWS, it’s as simple as exporting the data from Azure and importing it into a PostgreSQL database server on AWS. However, it can be more expensive and difficult to build highly available architectures without using the unique services and platforms that cloud providers offer.

It’s important to define your comfort level with locking in to one cloud provider from a technology perspective. Then weigh that against the implications of the choice to be cloud agnostic or cloud native.