When deciding how to proceed with their cloud strategy, enterprises often debate whether to choose cloud-native solutions or standard/partner tools and solutions. This is an easy decision when migrating a physical server to the cloud, though it becomes more difficult when migrating a private cloud to the public cloud. During these discussions, some stakeholders may confuse cloud-native architecture with cloud-agnostic, but the two are quite different and have different benefits depending on the intended application(s).
Cloud-native architecture involves services and components tied to the Cloud Service Provider (CSP) itself. For example, using Azure Monitoring services for Azure, CloudWatch for monitoring services with AWS, and Cloud (performance) monitoring for GCP. Generally speaking, there are four key considerations when choosing cloud-native services.
1) Agility in Design
In principle, a cloud-native approach is dependent upon native cloud services. Their flexibility and ability to be upgraded/enhanced can benefit the design and architecture as it doesn’t depend on any third party services and tightly integrated to native services which has higher flexibility to integrate with other services and cost efficient.
2) Lightweight Services
The service combinations in a cloud-native approach are quite CSP friendly. This makes cloud-native architecture lightweight and convenient to configure, with a uniform pattern of setup mechanisms even when using template solutions like ARM (Azure Resource Manager) or CloudFormation.
3) Easy Integration
Native services can communicate with each other easily based on the CSP’s maturity, which makes them easily integrated as there is no third-party service dependency, license requirement or in-built native security to adhere to, based on configuration.
4) Acceptance of Vendor Lock-in
When an enterprise chooses cloud-native architecture, it is locked into that vendor. From that point forward, the company’s roadmap for cloud adoption should not deviate for multi-cloud or plan to move to another CSP at a later stage, or the enterprise may risk significant setbacks.
Ideally, the architect should have the flexibility to choose cloud-native or cloud-agnostic/open based on the company’s state of applications, the complexity of implementation (including re-architecting or refactoring applications), and the technology stack. It can be cost effective to choose a cloud-native approach, as all the services are home-grown by CSP. But a cloud-agnostic approach has benefits as well.
A cloud-agnostic approach has a more flexible architecture with a wide range of choices. For example, for cloud monitoring, a company could choose Grafana dashboard with Prometheus rather than a cloud-native solution. The key factors that influence the selection of a cloud-agnostic architecture include:
1) Agnostic Design
If an enterprise is moving from a cloud-native solution, it is often to reap the benefits of a cloud-agnostic approach that makes it relatively easy to migrate from one cloud to another. In the above example, if monitoring services are implemented with Grafana and Prometheus, it is relatively easy to move from GCP to AWS using same workload provisioning script (with or without minor changes).
2) Suitable for Multi-cloud Strategy
It is important for each cloud provider to save effort and cost during rework activities. This can be aided by a uniform pattern of services and component choices across multi-cloud application deployments. A cloud-agnostic approach is best in these situations, as it offers flexibility to reuse the solution design for multi-cloud environments (e.g. using Terraform templates for server provisioning or Kibana service for data querying and visualization).
3) OpenSource Integration
A cloud-agnostic approach offers many choices, from OpenSource to proprietary tools, which in turns offers better community support and flexibility to customize the service. These can be important considerations as companies seek to evolve and innovate with speed and scale.
4) Cost Effectiveness
The possibility of OpenSource integration and availability of service choices (depending on the volume and usage) can make cloud-agnostic solutions relatively less expensive.
In summary, before choosing a cloud-native or cloud-agnostic approach, businesses should keep in mind their roadmap for cloud adoption and long-term vision of application usability. The two options, though sometimes confused, are quite different and present varying pros and cons. Without carefully considering the best long-term option, the business may select a non-ideal architecture and ultimately endure higher costs – both financial and effort-related – as they scramble to switch strategies over time.