Cloud native, Portable & Inter-cloud application architecture is more relevant in current economic scenario

In digital era, businesses need to keep evolving and innovating very fast to be relevant and align with changing customer paradigm. While large players need to aim to reach closer to consumer, small players need to aspire to widen the reach. In both the cases technology plays a differentiating role hence Cloud platforms and richness of cloud services become more relevant to address the need-for-speed, use-as-you-need and pay-as-you-use requirement of an enterprise.

While cloud will help to address above mentioned requirements, the challenge an enterprise need to address in current economic scenario is to avoid vendor lock-in by defining a cloud agnostic architecture including considerations for replaceability of consumed services across cloud service providers as well as on-premise so that portability & best ROI is ensured.

Let’s analyse relevance of cloud native, portable & inter-cloud architecture for high business value applications through following aspects.

  • What are typical requirements of a high business value application?
  • How Inter-cloud Architecture addresses non-functional requirements of such applications?
  • What are the cloud agnostic technology components which can be used to help in making it replaceable & portable across providers?

Common requirements of a high business value application

Some of the most common requirements of such an application include:

  • High availability: The application must be always available, with minimal downtime, to ensure uninterrupted business operations.
  • Scalability: The application must be able to handle increasing levels of usage as the business grows, without suffering performance degradation or downtime
  • Security: The application must be designed with security in mind, to prevent unauthorized access, data breaches, and other security threats.
  • Data integrity: The application must maintain the accuracy and consistency of data, even in the face of concurrent access, failures, or other errors.
  • Performance: The application must be able to respond quickly to user requests, with minimal latency or delay.

In summary, a high business value application requires a combination of robust architecture, reliable infrastructure, and ongoing monitoring and maintenance to ensure it remains highly available, scalable, secure, and performant.

Address these requirements through architectural interventions

The level of non-functional requirements implementation can vary based on the investment an individual application deserves hence design decisions must be backed by positive business case for the money spent.

While these requirements can be achieved in multiple ways, let’s look at how some of these requirements are addressed through an inter-cloud, cloud native & portable architecture and identify sample technology building blocks supporting such architecture.

Inter-Cloud architecture

Inter-cloud is a deployment model where an application is either fully deployed on a cloud with redundancies built on another cloud or its components are distributed across multiple cloud providers. An inter-cloud architecture essentially can bring in several redundancies that can help improve the reliability, availability, and performance of the overall system e.g. geographic redundancy, provider redundancy, resource redundancy, load balancing redundancy etc.

The redundant architecture across cloud providers 

Active-active and active-passive architectures are commonly used in inter-cloud environments to provide high availability and redundancy for applications.

No alt text provided for this image
Inter cloud deployment architecture

Active-active and active-passive architectures have their advantages and disadvantages, and the choice of architecture will depend on the specific requirements of the application.

Some of the common ways to handle traffic routing across multiple cloud & on-premises are Load Balancers, Software-Defined Networking (SDN), or DNS-Based Solutions.

Another ask is to establish connectivity between different clouds which can be achieved through Virtual Private Networks (VPNs), CSP provided dedicated Connectivity or through gateway.

It is important to consider factors such as redundancy, security, performance, scalability, and cost when selecting connectivity & routing solution.

Portability across CSPs

Another architecture consideration is to ensure application portability across cloud environments such as public clouds, edge & on-premise, which can be achieved through various techniques and strategies. Here are some of the common approaches

  • Use Cloud-Agnostic Application Architectures: Design application architecture in such a way that it is cloud-agnostic and can be easily deployed in any cloud environment. This means avoiding cloud-specific services or features and using more generic services that are common across all cloud providers e.g. common DB engine like PostgreSQL, Message Queue service like Kafka etc
  • Use cloud native architecture based on 12-factor compliance to enable seamless integration, portability & operations.
  • Use Containerization and Orchestration: Containerization using technologies such as Docker and orchestration using platforms such as Kubernetes can provide application portability across multiple cloud environments. By packaging application into containers and deploying them using Kubernetes, you can easily move application from one cloud environment to another.
  • Use Multi-Cloud Management Platforms: Multi-cloud management platforms such as Wipro’s BLE (Boundary Less Enterprise), Rancher for multi cluster Kubernetes, and Terraform can help manage applications across multiple clouds. These platforms provide a single interface to manage applications and their dependencies across multiple clouds. This enables portability and ensures seamless switchover to another environment.
  • Use Cloud Service Abstraction Layers: Cloud service abstraction layers such as Apache Libcloud and Fog provide a consistent API for interacting with cloud services. These abstraction layers can help minimize the differences between cloud providers and make it easier to move applications between different clouds.
  • Use Standardized Tools and Processes: Standardizing tools and processes can make it easier to move applications between different cloud environments. For example, using a common CI/CD pipeline, monitoring tool, health check, security tools, deployment automation tool, and configuration management tool can simplify the process of moving applications between clouds.

Achieving application portability across multiple cloud environments requires careful planning & design trade-offs across CSP managed services v/s self-managed deployments.

Enable such architecture with portable technology components

There are several application components and technologies that can be used to build portable applications that can seamlessly run on GCP, AWS, Azure, Edge & on-premise. Here are some examples in the below diagram:

No alt text provided for this image
Cloud agnostic technology components

  • Application Frameworks: There are several popular application frameworks that are portable across multiple cloud environments, including Spring Boot, Django, and Ruby on Rails. These frameworks provide a set of libraries, tools, and abstractions that make it easier to build and deploy cloud-native applications that can be run on any cloud provider.
  • Databases: Many databases can be used across multiple cloud providers, including MySQL, PostgreSQL, MongoDB as well as other DB products which are using these DB engines like YugaByte, Datastax etc. These databases can be easily migrated between cloud providers using standard migration tools.
  • Messaging and Streaming: Messaging and streaming platforms such as Apache Kafka and RabbitMQ can be used to build portable event-driven architectures that can be run on any cloud provider.
  • Containerization and Orchestration: Containerization and orchestration technologies such as Docker and Kubernetes are portable across multiple cloud providers.
  • API Gateways: API gateways such as Kong etc provide a consistent interface for accessing backend services, regardless of the underlying cloud infrastructure.
  • Service mesh is another technology e.g. Istio that can be used to build portable applications that can run seamlessly across clouds.
  • Security is a critical consideration when building portable applications that can run seamlessly. In an inter-cloud environment, there are additional security challenges that need to be addressed, such as managing access controls across different cloud providers and ensuring data security and compliance. By using a standardized IAM service, Cloud agnostic KMS solution like HashiCorp Vault etc you can ensure that access controls are consistent across all cloud providers. Network security, compliance & audit, incident management & disaster recovery are also key consideration areas.

To build redundancy at the component level, it may be beneficial to use a multi-cluster setup for Kafka and Istio. Using a multi-cluster setup for Kafka and Istio can help provide better fault tolerance, resilience, and scalability across different cloud environments. It can also help to isolate workloads and data to specific regions or clouds, enabling organizations to meet regulatory and compliance requirements. Additionally, using a multi-cluster setup can help to reduce latency and improve data locality, as data can be stored and processed closer to the end-users. Eventually, whether to use a single-cluster or multi-cluster setup for YugaByte DB, Kafka, Istio, or any other distributed system, depends on several factors, including the size of workload, performance and availability requirements, regulatory and compliance needs etc.

 Conclusion

Inter-cloud & portable solution needs a thorough deliberation on the requirements & corresponding business case to justify it because it comes with its own implementation complexities, operations overheads & cost. However very high business value applications with stringent non-functional requirements and needing portability across cloud providers can justify such architecture & investment. This PoV doesn’t claim to cover all possible architecture considerations and technology options however the intent is to identify foundational building blocks and build on top of it based on individual application requirements.   


To view or add a comment, sign in

Others also viewed

Explore content categories