Foresightedness is advantageous in most matters. In enterprise cloud adoption practices, the advantages of future planning can be monetary too, right from the pre-adoption phase. Here are 10 methods I recommend our INFOLOB customers:
1. Streamline tech to facilitate rapid idea-to-value processes
Numerous companies, whether operating in the cloud or traditional data centers, adhere to outdated and bureaucratic work methods that infuse delays and frustrations. To monetize cloud adoption earlier than anybody else who began around the same time, it becomes essential to enable the swift progression of ideas from conception to implementation in a production environment, without compromising safety and security.
In practical terms, this involves taking preparations to automate various steps in the production journey, such as sandbox requests, firewall modifications, creating isolated networks on-demand, identity and access management (IAM), application registration, certificate generation, compliance procedures, and more. Automating these processes is equally valuable in traditional data centers and the cloud. However, the cloud offers distinct tools that facilitate automation, and therefore, the initial stages of migrating to the cloud present an opportune time to transform IT operations.
2. Leverage existing cloud capabilities
Many companies operate with the anxiety of being locked into a specific CSP, driving them to adopt strategies that mitigate such risks. However, excessive reliance on containers, for instance, can prove expensive, and time-consuming while preventing organizations from fully harnessing the benefits offered by CSPs. An illustrative example is when a company develops its own container platform in the cloud instead of utilizing the cloud provider’s resiliency offerings. In the event of an outage, the impact can be severe, resulting in prolonged system downtime due to the underlying flaw in the non-cloud tooling.
There are alternative approaches to addressing CSP lock-in, such as setting a defined timeframe for lock-in and implementing practices and systems that enable rapid shifts if necessary. Attempting to build non-native resiliency capabilities often places companies in a direct face-off with CSPs without the same experience, expertise, or resources. The root of this issue lies in treating CSPs as hardware vendors rather than strategic software partners.
3. Eliminate redundant application design and deployment in the cloud
Granting application teams complete autonomy to migrate applications to the cloud often results in a disparate collection of cloud competencies and configurations. This heterogeneity hinders the ongoing maintenance of the entire application inventory.
To address this, organizations should treat application deployment capabilities as stand-alone products, solving common challenges once using standardized application patterns. These patterns can handle the configuration of shared resources, impose consistent deployment pipelines, and guarantee quality and security compliance. By minimizing the number of patterns required to support the application inventory, organizations can maximize their ROI.
4. Design a scalable cloud architecture
When executed correctly, a well-designed cloud architecture can accommodate exponential growth, supporting hundreds or even thousands of users without significant modifications. As the cloud footprint expands, the architecture should seamlessly incorporate additional components, including diverse application patterns, isolation zones, and capabilities.
Achieving scalability necessitates establishing simple, well-designed interfaces between these components. Given the inherent challenges, organizations can greatly benefit from the
expertise of cloud architecture engineers experienced in scaling such systems.
5. Align the organization with the architecture
Conway’s law asserts that the structure of teams within an organization shapes the technology they develop. Consequently, the organization’s teams often build solutions that do not align with the cloud architecture’s intended design.
For instance, some companies maintain separate cloud teams for each business unit, resulting in each team developing distinct cloud capabilities tailored solely to their respective unit’s needs, neglecting considerations for broader reuse. This approach can lead to delays and complications when changes made by one team affect the usage of others.
To mitigate this issue, IT should first design the cloud architecture and then establish an organization that mimes that structure. This entails forming core, application-pattern, and isolation-zone teams to reduce dependencies and redundancies between groups, ultimately delivering well-architected components at a reduced cost.
6. Develop cloud products rather than providing ad hoc services
Commonly, companies establish internal cloud service teams to assist IT and business units in leveraging cloud services. Yet, these service teams often operate as fulfillment centers, answering requests for access to various cloud services. Consequently, different business units independently utilize numerous cloud services devoid of a coherent architecture, translating into complexity, defects, and narrow transparency into usage.
Alternatively, companies should establish dedicated product teams comprising experienced cloud architects and engineers. These teams can create and manage simple, scalable, and reusable cloud products specifically tailored for application teams. By aligning around cloud products, organizations can ensure the proper utilization of capabilities in a consistent manner.
Upon the product team developing a catalog of cloud products, application teams can be encouraged to leverage these products to expedite their cloud migration. However, the velocity and ease of adoption may vary depending on each application team’s proficiency and interest in cloud technologies. Accordingly, the product team should adopt an operating model that supports different levels of application team involvement in the cloud migration journey.
This can be achieved through three layers of engagement:
- Steward layer: The engagement team builds all the required components for an app crew
- Intermediate layer: Engineers from the core cloud team join app teams to assist in constructing appropriate app patterns
- Expert layer: A partner crew architects and manages its self-isolation zone harnessing key capabilities out of the base foundation including identity and networking
7. Implement targeted change management through isolation
Isolation zones serve as dedicated cloud environments for hosting applications. In a bid to accelerate cloud migration, CSPs and systems integrators often start with a single isolation zone to accommodate all applications. However, this approach carries a high risk since configuration changes to support one application can inadvertently impact others. Conversely, assigning one isolation zone per application impedes the efficient deployment of configuration changes, necessitating redundant work across multiple zones.
As a general guideline, companies should maintain a moderate number of isolation zones, typically ranging from 10 to 100, depending on the business’s size and specific considerations:
- Does the application require public internet exposure?
- What grade of resiliency is indispensable?
- What are the risk-assurance and security posture requirements for apps in the zone?
- Which business unit possesses decision powers regarding legal changes to the zone?
8. Build one-time core capabilities for multi-CSP
Many companies operate on multiple cloud platforms, with workloads distributed among different CSPs. Instead of duplicating core capabilities, such as network connectivity, identity, routing, logging, and monitoring, across all CSPs – companies should build these capabilities once and leverage them across all isolation zones, including those residing in different CSPs from the base foundation.
9. Expedite acquisition integration by establishing an add-on instance of the base
Melding IT assets during acquisitions is often a complicated and time-consuming process. To supercharge and simplify this integration, the acquiring company can create an ‘integration-base foundation’ capable of running the acquired company’s assets. This approach allows the acquired company’s existing IAM, network, and compliance policies to continue functioning, guaranteeing the uninterrupted operation of its workloads. Over time, these workloads can be cautiously migrated from the integration base to the main base at a measured and predictable pace.
By embracing this approach, companies can effectively manage their core cloud infrastructure alongside the assets of the acquired company, utilizing the same underlying software with different configurations. This typically reduces integration time from several years to a matter of months.
10. Prioritize proactive cloud security and compliance on autopilot
Every software component and system must undergo a rigorous security regime. Traditional cybersecurity techniques reliant on human oversight and review cannot keep pace with the agility and speed offered by the cloud. To address this, companies must adopt new security architectures and processes specifically engineered to fence their cloud workloads.
One compelling approach is security-as-code, which enables the programmatically defined implementation of cybersecurity policies and standards. These policies can then be autonomously referenced in configuration scripts used to provision cloud systems. By evaluating cloud systems against predefined security policies, organizations can bypass changes that would violate compliance and jeopardize the security of their workloads.
For all cloud adoption and management, please write to:
