7 Key Tenets to Help ISVs Optimize Products for Multi-cloud
By Siddhartha Bhattacharya, Sr. Solution Architect – Cloud & Emerging Technologies
Businesses are moving their intellectual property and IT assets to public and private cloud platforms with a new sense of urgency. Due to the economic impacts of the global Covid-19 pandemic, enterprises across industries are banking on digital enablement to accelerate the speed and reach of their business operations. This trend is quickly becoming a game changer for ISVs.
By 2021, more than 90% of enterprises will rely on multi-cloud platforms. To keep pace, ISVs like you are cloud enabling products to support your clients’ digital transformation journey to the cloud. Likewise, cloud providers are scaling up infrastructures to enable customers to more easily migrate business applications, data and platforms to one or more cloud environments. Depending on their product infrastructure strategy and clients’ business requirements, ISVs are also adopting a multi-cloud model to host and secure applications and data, and enable seamless interoperability.
Some key elements to enable ISVs to achieve multi-cloud adaptability for product optimization are explained in this blog.
Evolving multi-cloud model for cloud enablement
As the name suggests, multi-cloud involves using more than one cloud within a single, heterogeneous architecture to perform tasks and meet specific infrastructure/application requirements.
Insights from IDG CLOUD COMPUTING Survey, 2020
For example, an enterprise may leverage a public cloud for business continuity services and a private cloud to store sensitive data. Additionally, applications, systems and datasets can be built, deployed and managed across multiple public/private clouds so that they are consistent and consonant to each other.
Scenarios where the multi-cloud model can be considered are:
- To run agile, highly containerized platforms featuring the latest and greatest microservice architectures. These platforms can have split deployments with the multi-cloud model.
- To manage client applications and ensure compliance or adherence to data norms and practices in different geographical locations.
- To secure your data stack on an alternate cloud as part of a data resilience strategy, mainly during cloud migration.
- To retain an existing cloud service provider to facilitate onboarding an ISV client.
7 tenets for multi-cloud adaptability
Based on our experience and exposure to challenges across multiple engagements, we have identified the following elements as essential for ISVs evaluating multi-cloud adaptability:
With the increase in multi-cloud adoption, software vendors must rollout customer applications across multiple environments using the same image make and application state, managed and configured through scripts. For you, containerization is the way to go. Containerized applications can share the OS and image abstraction layer and be ported to and from different environments based on applicability. Nothing needs to be built from the ground up. And containerization streamlines development especially for DevOps teams. One important note: the ecosystem must support your choice of containerization software – whether only Docker containers with Kubernetes orchestration or Docker Swarm clusters with bare metal capability.
Gartner predicts that, by 2023, 70% of organizations will be running three or more containerized applications in production. To prepare, most cloud providers are offering new managed services to support major container-based virtualization platforms like Kubernetes and Docker. However, for an ISV to adopt multi-cloud, it is essential to evaluate the features and chart out the ease of lift-&-shift from each cloud vendor. Virtualization can fill any gaps by providing the ability to port, plug and play within a containerized environment.
2. Single-pane Automation
In broader terms, an ISV cloud-agnostic product should be able to:
a) Automate the deployment process of application and release management. Here, you can deploy your product in one environment, and host the backup on a different cloud, based on costs.
b) Make the systems auto-scalable to meet your cloud computing needs.
c) Schedule the multi-cloud switchovers in a Blue-Green scenario. Let’s say your product is undergoing an upgrade. Here, the blue environment is where you will put the upgrade and the green or live environment will run ongoing workloads. Gradually, you can start moving your traffic from green to blue.
d) Auto-schedule Backup and DR activities for applications and data.
e) Templatize environment layout policies to ensure an environment can be built quickly to exact specifications. This is critical for any multi-cloud model.
f) Assess and validate interoperability with the other cloud providers to facilitate workload automation and other operations in a multi-cloud environment. For example, if your products are using AWS as a cloud platform and using CloudFormation Templates, they should be able to run with Azure or GCP. Another alternative is to use third-party tools like Terraform with Ansible, which is fully compliant with all major cloud service providers.
g) Automate job schedules and script runs to effectively manage resources in a distributed environment.
h) Allocate one unified platform to perform automation workloads. This makes the process more efficient and accessible to operations admins at any given point.
Now here, the caveat is to compare and contrast the cloud provider costs for the managed services you require. You may, for instance, choose to have deployment with one cloud provider, but use third-party software for DR and Backup. Or you can store specific types of data in a cloud environment where the ingestion and hosting charges are cheaper. This multi-cloud approach will be less costly, if you do it right the first time.
3. Security and Compliance
One of most critical tenets to consider is Security and Compliance. These are two sides of the same coin. Security can be for an application, data, network or user type. Compliance can apply to data, corporate or industry standards, and government policies and regulations. Here are a few points to consider:
a) Security by Design principles is strongly recommended to prepare an application for the cloud. If this requires re-design or refactoring, the ISV should walk the critical path. Without taking this step, customers will always hesitate to consider the solution bid, especially for the cloud.
b) While moving into a multi-cloud environment, you should synchronize security policies across cloud service vendors to efficiently manage and secure the total surface area. Monitoring and maintaining visibility of the surface area is also critical.
c) Security and compliance policies should be developed in consultation with experts and should be well-documented and updated as needed.
d) Data encryption must be considered from a global perspective, especially in high penetration markets.
e) You should establish a robust monitoring mechanism in one location which consolidates logs and other key information pertaining to security.
f) Follow the concept of ‘single plane of glass’ to provide key admins with a single point of management and control of the application and data security across cloud operations.
g) For User Identity and Access, there is a new normal called “Trust but Verify” which should be applied across all operations involving the solution and the ecosystem.
Infrastructure overhead adds significantly to an ISV’s product development and management costs. Therefore, when you decide to proceed with cloud adoption, one of the key focus areas should be how much infrastructure cost can be saved by moving to the cloud. Some of the areas to investigate include compute, storage, network, software licensing, and re-usability of the existing application.
From the infrastructure perspective, here are a few points for software vendors to think about:
- You should plan to build a self-healing environment where concepts like autoscaling, HA and DR can be practiced. To ensure that failover will occur, you should build failover policies, single-point failures and circuit breakers around the application and systems.
- Even with a multi-cloud Infrastructure/environment, you should ‘short circuit’ dependency on one cloud vendor. In case of an emergency or failover, you should have a switch mechanism to shift resources to a different cloud vendor with minimal changes.
- It is also important for ISV team leaders to document their goals and KPIs, if possible before they go multi-cloud. These may be cost optimization, reliability, flexibility, and/or regional proximity.
Other cost considerations related to cloud enablement include hiring or up-skilling for cloud technologies and proximity to cloud service providers. The latter can impact data transfer, data hosting and data archival charges. However, today, the major cloud vendors have a regional presence in geographies around the world. Just make sure the proximity meets your operational and cost goals.
5. Third-party Integrations
You should gain an understanding of how well the multi-cloud model interoperates and integrates security with third-party service providers. For example, an application may have integrations with an e-commerce shipping data provider or a payment gateway solution. It is therefore essential to assess the standards, dependencies, and third-party integrations supported by cloud service providers.
6. Service Pricing and Inventory
In a multi-cloud environment, you should compare the cost of deploying a particular offering on Cloud A vs. Cloud B. Some cost factors to consider are solution hosting, data storage, data archiving, traffic ingestion and managed service offerings. For instance, if one of the solution services has more load than others, while another has less utilization, you can determine which expense to prioritize.
When considering a multi-cloud model to optimize products, how the revenue model gets planned out matters. For example, you can create short- or long-term plans based on factors like whether to have a go-no-go call. Or whether the solution will be license-based or user-based. Your investment decision may also be based on the potential benefits from a holistic perspective.
In a nutshell, an ISV can benefit from the multi-cloud model, but in-depth research and planning, and a well-defined cost structure should be in place. It’s a two-edged sword that, if not used correctly, can jeopardize your margins – and your client satisfaction.
To effectively plan and implement the multi-cloud strategy, our cloud enablement experts are ready to support you. To connect today, write to PE@Xoriant.com.