Did I get your attention on false pretenses? Lets See. The SaaS I was referring to is Silo as a Service, or as I like to call it, the “Accidental Multi-Cloud”. Recently I have seen a number of IT departments struggle with the weight of expectation that their senior management has placed on them to exhibit the flexibility and agility of adopting cloud services. In addition, the benefits of cloud, such as ease of subscribing and the speed of provisioning if left unchecked is leading to a wild west approach to adopting cloud services.
I am increasingly seeing businesses with an ever growing cloud technical debt. For example, IT departments have some challenging times ahead of them:
- Line of Business (LoB) organizations are subscribing to what they feel are the best SaaS applications for their requirements leading to Cloud Vendor Sprawl
- Developers are adopting IaaS and PaaS services on an individual project basis leading to Cloud Service Sprawl
- The board are acquiring companies that subscribe to different cloud vendors then they are currently using. This adds to the already Cloud Vendor Sprawl
- Spiraling Cloud Costs especially network charges as the lack of tools and standards to address inefficiencies and complexity
- Increasing security requirements around the areas of secure identities, uniform role-based access control and audit compliance across the various cloud environments
- Data acquisition and replication is leading to data proliferation across multiple cloud vendors leading to low quality data sprawl. This also include data governance concerns with placing sensitive information in un-certified cloud vendors
- Increasing complexity to manage and monitor these hybrid / multi cloud including orchestrating, root cause analysis, performance management, and brokering
- Lack of integration strategy to standardize and govern application and data integration between different cloud vendors and services
- Lack of tools, interface standards and portability between different cloud providers
In reality, most businesses require a hybrid / multi cloud environment. Businesses rarely have the option of dismissing all on-premises systems or rely on a single cloud vendor for their entire cloud journey. The majority of large enterprises require a combination of cloud services from multiple cloud providers, services from a private cloud, and functionality from an on-premise system to address their needs. In an earlier blog I highlighted the difference between these different deployment models.
Rather then seeing a multi cloud approach as a hindrance, businesses should embrace this flexibility of being able to use the appropriate services from the appropriate cloud vendor.
There are many reasons why businesses embrace a hybrid/multi cloud strategy. For instance a business might want to transition some IT cost to OPEX, be quicker to respond to market conditions, increase current service levels, or avoid reduce vendor lock-in. There are many use cases that are applicable for hybrid and multi-cloud environments, I like to categories these into the following categories:
Workload Distribution
Workload distribution covers the situation where the application functionality is available in multiple environments (e.g. private cloud, multiple public clouds). This category covers use cases such as:
- Using the public cloud as a disaster recovery destination for on-premise systems. At the very least using the public cloud as the destination for backups.
- Using multiple public cloud vendors to address strict data sovereignty requirements.
- Using the public cloud for seasonal, or unpredictable loads. Depending on the architecture of the application this can be very challenging to achieve which can be transferred to the public cloud. This may be difficult to achieve where the applications transactions are synchronous, complicated transactions or where underlying data synchronization is complex.
- Using the public cloud for replicated temporary environments. A common use case is the replication of data for a data discovery lab environment.
Functional Distribution
Functional Distribution covers the situation where different components of an overall architecture are deployed in private and public clouds. This category covers use cases such as:
- Integrating applications together whether they are deployed on-premise or in multiple different clouds. I have a series of blogs dedicated to this topic.
- Extending existing applications with new innovative functionality, such as mobility, chatbots, blockchain, and AI. This approach is utilized where the technology in question may be deemed too complex to install and maintain in the existing on-premise environment or the business needs access to a innovative technologies via PaaS where might be difficult to build or buy themselves.
- Deployment of sensitive transactions and related data are confined to on-premise while distribution and caching could be performed in the public cloud.
- Using the public cloud for large predictable loads such as IoT, AI. This use case takes advantages of the large amount of compute and storage available in the cloud that a business may not want to invest in. One of the challenges with this use case is data gravity, and whether the data is already in the cloud.
Lifecycle Distribution
Lifecycle Distribution covers the use of a hybrid and multi cloud environments to distribute some parts of the application lifecycle. This category covers use cases such as:
- Environment propagation of development, test, and production environments between on-premise and public cloud. It should come to no surprise that this is one of the most common use cases where the use of cloud services is utilized to address an overall development lifecycle environment. This is not so surprising given that it can be accomplished without affecting one’s production environment and operations processes.
- Using a fan-out patterns to distribute applications and microservices to multiple production environments. This has network advantageous if your current public cloud vendor does not have a data center in the region where a good portion of your customers are. This use case also assists in reducing your vendor lock-in via application and data portability.
- Use the public cloud to adopt DevOps cloud services to address complexity and execution frequency of project pipeline. This covers not just cloud native software engineering applications but can also cover more traditional software engineering applications(e.g. client server). An additional area to consider is the use of DevOps for data engineering projects (e.g. move Machine Learning models to production)
Hybrid / Multi Cloud Strategy
Hybrid / Multi Cloud environments are becoming the new norm and must be addressed in an overall cloud strategy. With all of these options and benefits businesses need to define a strategy, an architecture, and a roadmap to identify, integrate, secure, manage, monitor, and broker the features and functionality of these hybrid / multi cloud environments.
In future blogs I am hoping to address each of these areas in more detail.
Good Luck, Now Go Architect…
An Enterprise Architect's Musings 