Introduction
Multi-cloud architecture, an advanced IT strategy that has been gaining popularity in the industry, involves utilizing multiple cloud computing services from various providers, such as Azure, AWS, and GCP. This approach is gaining traction as it allows organizations to meet their diverse needs by integrating the strengths, features, and capabilities of these cloud platforms. In the ever-evolving landscape of technology, it is becoming increasingly apparent that Independent Software Vendors (ISVs) are exploring diverse approaches to meet specific customer demands.
One such emerging trend is the adoption of a multicloud strategy that focuses on leveraging the distinct advantages of various cloud providers. When ISVs use multicloud architecture, it enables them to offer clients a tailored solution with regard to cloud selection, security, scalability, and flexibility. While this does not imply an outright endorsement of a multicloud strategy, it certainly highlights the growing inclination of ISVs to remain competitive by embracing innovative solutions that cater to the unique needs of their customers.
ISV solutions typically fall into one of three deployment models: pure SaaS, customer-deployed, or dual-deployment SaaS. More details about different ISV deployments models explained here (https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/isv-landing-zone... )
Common/Observed multi cloud scenarios in ISV.
The significance of multi-cloud architecture has grown more prominently for Independent Software Vendors (ISVs) in comparison to enterprises for various reasons. While ISVs concentrate on creating, marketing, and selling software products, enterprises mainly utilize software solutions to support their business operations, without generalizing their scope. Although these use cases are not limited to ISVs, they have a more direct impact on their operations and success.
- Compliance and Data Requirements: ISVs have adopted multi-cloud strategies to address specific regulatory requirements, such as government mandates or customer preferences for a particular cloud provider. Additionally, these ISVs utilize multi-cloud architecture to meet data regulations that require local storage by employing providers with data centers in different regions.
- Performance Optimization and Disaster Recovery: Many ISVs have expanded their customer base and increased market share by supporting multiple cloud platforms. These ISVs have also optimized application performance based on workload requirements and ensured redundancy in their applications, which remain available even during outages or issues with a single provider. This is a scenario when a particular cloud is not available in a specific region.
- Cost Reduction, Vendor Flexibility, and Innovation: ISVs have leveraged different cloud providers to take advantage of cost-effective pricing models and optimize cloud spending. They have also avoided vendor lock-in by maintaining control over application performance, security, and cost. Multi-cloud architecture has led to innovation and collaboration among development teams, resulting in a more agile approach to software development.
It’s important to note that ISVs should carefully evaluate each cloud provider’s capabilities and limitations before adopting multi-cloud architecture. They should also ensure that their applications can seamlessly integrate with different clouds and that they have the necessary infrastructure and resources to manage and monitor their multi-cloud environment effectively. By staying neutral to all cloud platforms, ISVs can make informed decisions based on their unique needs and requirements, ensuring the best possible outcomes for their applications and services.
The scenarios mentioned above multi-cloud architecture are not exclusive to ISVs. Enterprises, despite often having more specific requirements and a smaller customer base, may still find value in the flexibility and scalability provided by multi-cloud architecture. Some enterprises are adopting multi-cloud strategies to capitalize on the benefits mentioned above.
Common challenges and possible solutions.
Adopting multi-cloud architecture can provide numerous benefits for Independent Software Vendors (ISVs). However, they may encounter certain challenges in implementing this strategy. Here, we discuss some common multi-cloud challenges and their possible solutions. This will help ISVs make informed decisions and effectively address these challenges without preference to a specific cloud provider. Here are some common challenges and their possible solutions:
- Challenge: Complexity in management and operations
- Solution: Implementing a multi-cloud strategy can increase the complexity of managing and operating various cloud platforms. To address this issue, ISVs can use cloud management platforms, integrated tools, and automation solutions to streamline operations, monitor resources, and centralize control across different cloud environments.
To address this issue, ISVs can use cloud management platforms like Azure Arc (https://azure.microsoft.com/en-us/services/azure-arc/), integrated tools, and automation solutions to streamline operations, monitor resources, and centralize control across different cloud environments.
- Challenge: Data transfer and latency
- Solution: Moving data between various cloud providers may result in latency and higher data transfer expenses. To tackle this issue, ISVs can employ data caching, edge computing, or content delivery networks (CDNs) to reduce data movement and enhance application performance. Utilizing the same database on both clouds can aid in synchronization and replication of databases. Some of the services are Azure CDN (https://azure.microsoft.com/en-us/services/cdn/), Microsoft SQL Server (https://learn.microsoft.com/en-us/azure/azure-sql/virtual-machines/windows/sql-server-on-azure-vm-ia...) , 3rd party solutions like YugabyteDB Anywhere (https://www.yugabyte.com/anywhere/)
- Challenge: Security and compliance
- Solution: Ensuring consistent security and compliance policies across multiple cloud platforms can be challenging. ISVs can adopt a unified security management approach, implement strong access controls, and use encryption for data at rest and in transit. Additionally, they should stay updated on each cloud provider's security and compliance offerings and best practices. One of the services from Microsoft is Microsoft Defender for Cloud (https://azure.microsoft.com/en-us/products/defender-for-cloud/)
- Challenge: Skills and expertise
- Solution: Managing multiple cloud platforms requires specific skills and expertise. To address this issue, ISVs can invest in continuous training and certification programs for their technical teams or partners with managed service providers (MSPs) with multi-cloud expertise.
- Challenge: Integration and interoperability
- Solution: Integrating applications and services across multiple cloud platforms can be complex. ISVs can use containerization, microservices architecture, and API-based integration to ensure seamless interoperability between cloud platforms and services. One of the services from Microsoft is Azure API Management (https://azure.microsoft.com/en-us/services/api-management/)
- Challenge: Cost management
- Solution: Managing costs in a multi-cloud environment can be challenging due to different pricing models and resource usage across providers. ISVs can leverage cost management tools, set up budget alerts, and implement tagging strategies to monitor and optimize their cloud spending. One such tool is Microsoft Cost Management (https://azure.microsoft.com/en-us/products/cost-management/).
- Challenge: Vendor support and SLAs
- Solution: Ensuring consistent support and service level agreements (SLAs) across multiple cloud providers can be challenging. ISVs should carefully evaluate each cloud provider's support options, SLAs, and response times, and establish clear communication channels with their providers, such as Azure Support (https://azure.microsoft.com/en-us/support/options/)
While adopting multi-cloud architecture can present certain challenges, implementing the right strategies and solutions can help ISVs overcome these hurdles and reap the benefits of a flexible, reliable, and innovative cloud environment.
Special emphasis on database deployment models
The fundamental aspect of an ISV's business strategy involves offering solutions suitable for numerous clients. Such multi-tenant solutions necessitate the use of multi-tenant database services.
Some of these patterns are explained in the articles here:
- Multi-tenant SaaS database tenancy patterns (https://learn.microsoft.com/en-us/azure/azure-sql/database/saas-tenancy-app-design-patterns?view=azu...)
- Tenancy models for a multitenant solution (https://learn.microsoft.com/en-us/azure/architecture/guide/multitenant/considerations/tenancy-models)
When ISVs must go for a multi-cloud approach, it is crucial for them to emphasize database deployment models in multi-cloud architecture, as the choice of deployment directly impacts the performance, scalability, cost, and reliability of their applications. The reason we are discussing database deployment patterns is that the database is the most complex component in multi-cloud architecture. By carefully evaluating different deployment options, ISVs can optimize their database infrastructure and ensure seamless integration with various cloud platforms.
This section explores different deployment patterns, or relationships, which include:
- Partitioned with no inter-database dependency
- Unidirectional replication with asynchronous communication
- Bi-directional replication with conflict resolution
- Synchronized distributed system with full active-active capability
The architecture is highly simplified for the concept purpose.
Partitioned with no inter-database dependency
In the partitioned deployment approach with no inter-database dependency, each location or cloud has its own distinct database containing partitioned datasets that operate independently. This means that every piece of data is stored in a single database, and individual data partitions reside within their respective databases. A common example of this pattern is a multi-tenant application where a dataset is allocated to a specific database. In this setup, an application is deployed across multiple locations, with each location managing a separate partition of the entire dataset. Each data item is stored exclusively in one of the locations, ensuring a partitioned dataset without any replication between them.
An alternative method for deploying partitioned databases is to maintain a fully partitioned dataset within a single database. In this case, there is only one database containing all the datasets. Although the datasets are stored in the same database, they remain entirely isolated from each other (partitioned), so changes to one dataset do not affect others. This configuration can be seen in two applications that use a single shared database. One potential issue that may arise from this setup is the latency between two clouds.
The following diagram represents this scenario:
- Two separate application deployments that use a shared database located in the first location.
- Each application has access to the entire dataset within the deployment since the dataset is not partitioned.
Unidirectional replication with asynchronous communication
In the deployment pattern with unidirectional replication, a main database replicates its data to one or more secondary databases. These secondary databases are primarily used for read access. For instance, the primary database might be chosen for a specific use case, while the secondary database is employed for analytical purposes. The diagram below demonstrates two applications interacting with unidirectionally replicated databases.
As illustrated in the diagram, one of the databases acts as a replica of the other. The arrow within the diagram indicates the direction of replication: data from the database system in location 1 is replicated to the database system in location 2.
Bi-directional replication with conflict resolution
The deployment pattern being discussed consists of two main databases that engage in asynchronous replication with each other. During replication, a conflict resolution mechanism is needed to handle any write-write conflicts that might occur when both databases are simultaneously written to with the same data, such as using the same primary key. This pattern is ideal for situations where write-write conflicts are less likely to happen.
A diagram illustrating this concept would show two applications interacting with two databases that are bidirectionally replicated. Each database is replicated to the other, with both replications functioning independently, as demonstrated by separate arrows in the diagram. Conflicts may arise if the same data item is modified concurrently by both applications and then replicated, necessitating conflict resolution in these instances.
Synchronized distributed system with full active-active capability.
This deployment pattern features a single database configured with an active-active setup, also known as primary-primary or master-master setup. In this configuration, data updates made to a primary database are transactionally consistent and synchronously replicated, ensuring that each application consistently accesses the most recent state without delay or conflict risks. The pattern is suitable for distributed computing scenarios.
A diagram illustrating the concept would show two applications interacting with a fully synchronized primary-primary database. In this setup, any modification made in one database is synchronously reflected in the other database. When a transaction commit takes place, changes are synchronously applied to both databases, maintaining consistency and synchronization between them.
Comparison of database deployment models.
Here, we discuss four database deployment options with a brief description and their respective pros and cons:
|
Deployment Model |
Description |
Pros |
Cons |
|
Partitioned with no inter-database dependency |
Data is divided into independent partitions, with each partition residing on a separate database and no dependencies between databases. |
- Simplified management - Scalability - Improved performance |
- Limited data sharing - Inconsistent data |
|
Unidirectional replication with asynchronous communication |
Data is replicated from a primary database to one or more secondary databases in a unidirectional manner with asynchronous communication. |
- Data redundancy - Reduced data transfer costs - Failover support |
- Data latency - Potential data loss |
|
Bi-directional replication with conflict resolution |
Data is replicated between multiple databases in a bi-directional manner with conflict resolution using predefined rules or custom logic. |
- Improved data consistency - Enhanced availability - Flexible data distribution |
- Complex conflict resolution - Increased management overhead |
|
Synchronized distributed system with full active-active capability |
Databases are deployed in a fully synchronized, active-active configuration with real-time data consistency across all instances. |
- High availability - Load balancing - Real-time data consistency |
- Complex setup and management - Increased cost |
Technology choices
Dapr (https://dapr.io/) is a powerful option for building microservices architecture, particularly for multi-cloud and multi-tenant SaaS solutions. Nonetheless, it's important to recognize that alternative methods and technologies exist, each with their own benefits and drawbacks.
In order to choose the most suitable approach, ISVs must thoroughly evaluate its requirements, current infrastructure, and technical expertise. During this evaluation, key factors to consider include:
- Ease of development, deployment, and maintenance
- Support for multiple programming languages and frameworks
- Integration with existing tools and platforms
- Scalability, performance, and security
By carefully assessing these factors, ISVS can make an informed decision on the best approach to adopt for building a microservices architecture tailored to their unique needs and technical constraints.
|
Areas |
Choices |
|
Compute |
Containers: Docker, containerd Container orchestration: Kubernetes, Amazon ECS, Azure Kubernetes Service (AKS), Google Kubernetes Engine (GKE)
Some resources. https://github.com/Azure/fta-isv/blob/main/docs/AKSReference.md
|
|
Database |
Azure Cosmos DB PostgreSQL on Azure MySQL on Azure. Amazon Aurora AWS DynamoDB Google Cloud Spanner Google Cloud Firestore MongoDB Atlas CockroachDB Apache Cassandra
https://learn.microsoft.com/en-us/azure/?product=databases https://learn.microsoft.com/en-us/azure/cosmos-db/ https://learn.microsoft.com/en-us/azure/mysql/ https://learn.microsoft.com/en-us/azure/managed-instance-apache-cassandra/
|
|
API Gateway (Dapr integrates with several API gateways) |
Ambassador Gloo Kong Microsoft Azure API Management NGINX
|
|
Service Mesh (Dapr can be used alongside service meshes |
Istio Linkerd Consul Connect
|
|
Service Discovery (Dapr provides built-in service discovery) |
Kubernetes service discovery HashiCorp Consul Etcd |
|
API Communication (Dapr supports various communication protocols) |
RESTful APIs gRPC |
|
State Management (Dapr provides state management building blocks) |
Redis Cosmos DB Azure Blob Storage AWS DynamoDB PostgreSQL Apache Cassandra
|
|
Pub/Sub Messaging (Dapr provides a pub/sub building block) |
NATS Redis Streams Azure Service Bus Azure Event Hubs Google Cloud Pub/Sub AWS SNS, SQS RabbitMQ
https://learn.microsoft.com/en-us/azure/?product=integration
|
|
Actors (Dapr provides an actor programming model) |
Service Fabric Reliable Actors (Dapr uses a similar model) |
|
Distributed Tracing (Dapr integrates with distributed tracing systems) |
Zipkin Application Insights (Azure Monitor) OpenTelemetry (future integration)
https://github.com/Azure/fta-isv/blob/main/docs/GovernanceReference.md https://github.com/Azure/fta-isv/blob/main/docs/LoggingAndMonitoring.md |
|
Secret Management (Dapr provides secret management building blocks) |
Kubernetes secrets HashiCorp Vault Azure Key Vault AWS Secrets Manager Google Secret Manager |
|
Security |
Authentication and Authorization: OAuth, OpenID Connect, JWT mTLS for service-to-service communication (built-in with Dapr) Encryption: TLS, HTTPS, Key Management Services
https://learn.microsoft.com/en-us/azure/defender-for-cloud/ https://learn.microsoft.com/en-us/entra/identity/ https://learn.microsoft.com/en-us/azure/?product=security
|
These technology choices are tailored for a Dapr-based microservices architecture in a multi-cloud, multi-tenant SaaS solution.
Possible architecture
Here are possible technologies for each cloud provider.
Azure:
For a multi-cloud multi-tenant microservice architecture based on Dapr in Azure, you can consider the following Azure-specific components:
- Compute:
- Container orchestration: Azure Kubernetes Service (AKS)
- Database:
- Azure Cosmos DB
- Azure PostgreSQL
- API Gateway:
- Microsoft Azure API Management
- Service Mesh:
- Dapr can be used alongside service meshes such as Istio or Linkerd
- Service Discovery:
- Kubernetes service discovery (built-in with AKS)
- API Communication:
- RESTful APIs and/or gRPC
- State Management:
- Azure Cosmos DB
- Azure Blob Storage
- Pub/Sub Messaging:
- Azure Service Bus
- Azure Event Hubs
- Actors:
- Dapr provides an actor programming model similar to Service Fabric Reliable Actors
- Distributed Tracing:
- Application Insights (Azure Monitor)
- Secret Management:
- Azure Key Vault
- Security:
- Authentication and Authorization: Azure Active Directory with OAuth, OpenID Connect, and JWT
- mTLS for service-to-service communication (built-in with Dapr)
- Encryption: TLS, HTTPS, Azure Key Vault for Key Management Services
Conclusion
Based on recent trends observed in the ISV landscape, it is evident that multi-cloud considerations are becoming increasingly crucial for designing and implementing scalable, flexible, and resilient SaaS solutions. Dapr, one of the many approaches to building microservices architecture, offers a robust and portable framework that simplifies the development of distributed applications across Azure, AWS, and GCP. Its modular, event-driven runtime, standardized API support, and seamless integration with various cloud services make it an appealing option for multi-cloud, multi-tenant SaaS solutions.
When it becomes absolutely necessary for ISVs to adopt a multi-cloud architecture, they should use these guidelines to make an informed decision rather than opting for a default choice. By carefully evaluating their organization's needs and goals, ISVs can choose the most suitable approach for building their multi-cloud, multi-tenant SaaS solution. Ultimately, the optimal choice will depend on the organization's specific needs and constraints, as well as its technical requirements, ensuring the SaaS solution's success in a competitive and constantly evolving market.