Hybrid is the new Cloud
(aka. Hybrid Cloud Redux)
tl;dr
Optimal Cloud adoption is not only about selecting the cheapest pay-wall for your workloads — building your tech and people stack to be cloud agnostic to use hybrid architectures will future-proof your multi-cloud adoption journey
Lately, there have been many topics trending around the usage of cloud services and vendors, hybrid and multi-cloud architectures. These topics get amplified with how the post-pandemic and global economy is evolving cloud usage patterns, the shift in priorities amongst hyperscalers, the infamous supply-chain shortages, and how many IT organizations are moving their innovation funds to optimization efforts around security and sustainability. In this article, I discuss perspectives on how organizations can continue to benefit from the Cloud by optimizing their strategy, improving architecture decisions, towards setting themself up for future success.
Cloud is a journey, not a destination; this is one of many journeys your technology will make.
Although lock-in and tech debt are unavoidable, it is more manageable when it has lesser external dependencies and relies on open standards. This principle allows us to create optimized technologies that self-sustain and minimize lock-in into a particular vendor. Selection of a specific technology stack and vendor is not a cost-only or initial time-to-market entry discussion — consider how you can sustain, grow and scale into the future.
Hybrid architectures composed of both monolithic and microservices systems will result in less abrasive and more manageable transformation — avoid big bang approaches.
Many organizations are going through an application modernization journey leading toward microservice-based architectures; this will allow organizations to be agile by decoupling business processes and distributing their development lifecycle, realizing faster time to market. Two points to note here — in most enterprises, business applications are multi-generational, and the monolithic to microservices journey will have different nuances for each application. Hybrid architectures allowing monolithic and microservices to run in parallel will result in a better sum of the parts, more manageable operations, and less abrasive transformation.
Focus on building cloud-agnostic microservices aligned to your business capabilities and needs, this will allow the organization to fit-for-purpose any cloud vendor easily.
Working backward from business capabilities and aligning them to microservices needs to be the focus — this allows a domain-driven design, and with the right technology stack, will enable organizations to fit for purpose any Cloud vendor to optimize operational aspects — cost, resiliency, reach, and people skills. Working backward from business capabilities to microservices also aligns technology and business teams closer in an enterprise — with microservices, technology capabilities can be further decoupled and tiered based on consumption — for example — business revenue streams and entry channels, user experiences, linked to processing layers, going into data and platforms.
Both containers and cloud vendor services are lock-ins; the lock-in with containers is more sustainable in the long term as its not under one vendor.
Every technology decision has its advantages, disadvantages, and risks — using a Cloud vendor native service has its benefits like faster time to market and narrow multi-cloud people skill-set requirements. It is, however, prone to vendor lock-in — and only allows us to use one vendor missing out on the strengths of services others have to offer. On the other hand, running services across multiple Cloud vendors is easier said than done. The amount of engineering needed to build production-grade Kubernetes clusters can introduce lock-in with a particular distribution. Factors like data gravity, user affinity, compliance, and people skills come into play against this state of achieving multi-cloud nirvana.
Hybrid cloud is not a choice, in most cases its evolution to multi-cloud is organic.
In most cases, hybrid workload deployment is not a choice. These patterns evolve and take shape organically — only a few enterprises are in one cloud vendor — most mid-large enterprises will have many of their services in data centers and colocations, and many use multiple Cloud and SaaS vendors. The focus should be on how these ecosystems integrate and are managed better. Hybrid architectures with proper integrations will allow for a more robust middle ground — alongside the broader cloud adoption strategy, focus on things that make integrations easier — API Management, Servicemesh, Datamesh, and SaaS integration standards.
Cloud FinOps is beyond just technology and infrastructure acquisition and is a continuous process — consider at scale spend visibility, optimization and chargeback
Another critical area to rethink is Cloud FinOps and growing beyond just aspects of infrastructure acquisition. A proper FinOps program comprises multiple phases of cloud cost management — acquisition, visibility, optimization, and chargeback. Focus on all of these aspects, and in a multi-cloud landscape, it is simpler to consolidate processes and use tools that aggregate spend data for optimization actions. Also, cost management and optimization is a continuous process and needs an organization-wide approach, governance, and effort to succeed.
Vendor-native security services go deeper into one platform, multi-cloud security tooling goes wider and makes management of multiple vendors easier — both have their place and significance.
In any Cloud discussion, security is a big area to rethink and optimize. In general, vendor-native technologies will allow deeper capabilities of security posture management — with multiple cloud vendors using multi-cloud tools will simplify overall platform security management and operations.
Operating in the Cloud is not only about moving to a particular tech stack or a vendor — it is also about transforming the organizations workforce and culture to use its features
Another buzzword in the Cloud Developer community today is Platform Engineering — a software delivery method that further decentralizes Ops tasks from siloed DevOps teams and promises to provide more autonomy to developers within an organization. Large enterprises adopting Cloud should realize just like their applications (monolithic and microservices) — the workforce, cultures within teams, and cultures are also divided. Monolithic applications are usually best managed by System Administrators; pros — are lower friction as they do not have to coordinate a lot with other teams, and cons — almost always become a single point of failure. DevOps teams are tuned towards developing microservices — smaller groups with more nimbleness and agility, providing higher feature throughput. The evolution of platform engineering is a solid middle ground providing control to service developers and user autonomy. Hybrid Cloud allows many enterprises going through this transformation shift from traditional system administration to DevOps to Platform Engineering to be easier to manage.
Building with ability to run workloads in a hybrid cloud environment takes service resiliency beyond just single vendor multi-regional availibility
In terms of building resilient ecosystems of services, containerized microservices that do not heavily rely on cloud vendor services are typically easier to mobilize for resiliency needs. Public cloud vendors provide a muti-az (availability zone) and multi-regional high availability. The ability to deploy workloads agnostically across vendors and locations allows enterprises to break the “all eggs in one basket” resiliency barrier. It is often much cheaper and more beneficial to run workloads in multiple locations close to each other geographically than building multi-regional single vendor resiliency. Resiliency is not only about service availability; factors like service fulfillment time and latency come to play — flexible multi-cloud deployment ability for workloads allows for a robust resiliency baseline to build upon.
Alongside your application modernization efforts also evolve your integration, network and data consumption patterns
The ability to run workloads in hybrid patterns requires more than services that run on multiple cloud vendors and locations. Successful multi-cloud workloads require a strong foundation of data and the network underneath it to function seamlessly.
Decentralizing data is an excellent north-star goal for multi-cloud adoption — “data as a product” enabled by the adoption of data mesh evolves the organization towards making it a platform offering and allows for economies of scale, provides service to data affinity and reduces data gravity barriers.
With servicemesh, enterprises can decentralize network infrastructure and distribute services across multiple vendors. Servicemesh patterns also provide granular observability across services and adopt multi-cloud service availability patterns.
Two other things to consider — API Management and Observability — microservices architectures give teams granular control and feature-based agility. However, this comes with a price of setting proper standards of how services are accessed and management standardization of APIs; it is otherwise prone to become snowflakes that are hard to integrate. Observability is the next area to architect and invest in — this has a big pay-off in day-2 operations and overall manageability of a hybrid services ecosystem.
Wrapping up, future-proofing technology strategy and investments are not easy — decisions are constantly torn between business needs, time-to-market urgency, availability of resources and skills, budget, and trends of a particular tech stack — investing in a strategy that focuses on technology enabling business capabilities at its core agnostically regardless of a vendor or location goes a long way.
Go as far as you can see; when you get there you’ll be able to see farther. — Thomas Carlyle
