Cloud Migration Requires Organizational Transformation: Technical Transformation (1/3)

(Article Series, 1 of 3)

Exactly three years ago I began leading SAP’s Multicloud security operations team. A lot has happened since, not least the ten-fold increase of resources in public cloud providers deployed by SAP (and the tech industry more broadly), stress on the global economy and supply chains and upheaval in the geopolitical landscape. Though public cloud is not a new phenomenon, migration to providers has accelerated with many just beginning their journey.?

Both internally and in constant interactions with peers and large customers, SAP has encountered and worked through many challenges, at least making good progress on them - as have our peers. Some were planned for, many were not. Since true ‘best practices for cloud’ remain unwritten, this 3-part series explores challenges that illustrate the unexpected impacts and consequences of public cloud migration. Part 1 covers the technical aspects; Part 2 focuses on who cloud migration cascades throughout the organization; and Part 3 dives into how organizational nature determines where and how progress can be made.?

My perspective comes from experience as a large consumer of IaaS and managed infrastructure services, rather than SaaS offerings from cloud providers or 3rd parties. I interact daily with developer, DevOps and operations teams at multiple levels, as well as layers throughout the organizational hierarchy, as we make significant improvements in public cloud security. See here, here and here for specifics. I also keep in touch with peers, industry vendors and public cloud providers experts. I hope my experience proves useful to those still beginning or in the middle of their cloud migration.

Part 1: Technical Transformation

Executive Summary

• design for public cloud architecture
• put workload refactoring on your roadmap
• adopt cloud-native practices where practical
• explore where to begin, like cloud-native tooling
• prepare for continuous change
• continue learning
• foster collaboration amongst cloud-native talent and experience

A New Architecture

IaaS/Paas - the collection of IaaS and managed infrastructure services such as Kubernetes, managed databases, message queues and so on – is the most significant technological shift of the past 30 years. Its main features of creating and deleting cloud resources as needed, and ‘always-on’ are offered by all cloud providers through their own (near) global single architecture of networked cloud regions. Just like changing from one chip type (say from Intel to ARM) to another requires re-compilation and re-optimization, so does changing from a traditional data center approach to this new architecture where resources are dynamic and can be created anywhere.?

It also needs a new way of working suited to its architectural features (hence the rise of DevOps) driven and promoted by sometimes opinionated and self-serving cloud providers. It is also spurred on by organizations like the CNCF, and the general move to Kubernetes-based microservices. Like the cloud itself, cloud-native technologies and practices emphasize agility, resilience and scaling to demand.?

To benefit, you must adjust to public cloud’s own architecture, not least because everything is metered. Running unnecessary large instance sizes 24/7 because of unchanged data center habits can lead to high bills that wipe out expected cost savings, and still not deliver the promised agility, resilience and ability to scale. Since the cloud architecture is dynamic, with providers launching and retiring services all the time, cloud-native practices must be adopted for successful post-migration adjustments.

Shared Responsibility Model

Though much has been written about the shared responsibility model for public cloud security, it remains misunderstood outside the cloud security field. In a recent We Hack Purple podcast, Gabriel Wierzbieniec explained it as 'if you have to configure it, you're responsible for it'. Yet infrastructure misconfigurations are responsible for 50% of security incidents for organizations with high cloud adoption, as reported by Snyk in 2021.?

The freedom and agility developer teams enjoy to provision their own infrastructure comes at a price. In data centers central teams intermediate in some way, but a cloud account owner or admin acts as data center administrator and is responsible for configuration - picking instance size and storage options, configuring networks and firewalls, and setting up remote access. Cloud services default settings are for ease of onboarding, not secure-by-default. Data center experience or reliance on ‘IT’ or ‘the network team’ via a ticketing system doesn’t provide the technical team with public cloud skills.

Cloud-native practices using Infrastructure-as-Code (IaC) to ensure identical deployments and development pipeline management can help by avoiding configuration drift when managed through the admin console. Deployments can be created and destroyed at will, allowing for a rapid testing and correction cycle - exactly in line with contemporary cloud-native CI/CD pipelines and DevOps practices.

The False Attractiveness of ‘Lift-and-Shift’

Adapting workloads to the public cloud during a rapid migration and radically changing ways of working is easier said than done. Legacy applications may require significant refactoring to adjust and eventually reach cloud-nativity. Sometimes it seems attractive to ‘lift-and-shift’ data center workloads more or less as-is: to reduce organizational stress and try not to boil the ocean. It’s understandable. But a start can still be made with the low-hanging fruit opportunities around the edges (like tooling for monitoring, logging and security). It’s important because lifting and shifting comes with hidden costs that can have long term impact.

Cost and Stability Implications

For decades SAP has built sophisticated and resilient data center architectures with Disaster Recovery sites, including those I designed and deployed during my consulting days. They are becoming irrelevant. Cloud provider architecture has high-availability and resiliency baked in, through availability zones and multi-region capabilities. A workload outage in public cloud is a failure of architecture, not infrastructure. Infrastructure failure is calculated into the providers’ architecture and designed out.?

Refactoring, but when?

Lift-and-shifts propel existing technical debt into the new environment, restricting the ability to make future changes and delaying adoption of cloud-native practices. Though presented as acceleration strategies, they may delay expected benefits.

Be open to changes that can happen now and put workload refactoring on a roadmap. Investigate automation and cloud-native practices and develop from there. Map out your cloud-native destination, test decisions along the way against your yardsticks, and make conscious and temporary compromises.

Tooling

Core workload requires time to refactor, but opportunities still exist. Solutions don’t run in isolation, they have logging, monitoring, asset inventory, resource orchestration, network and security and other tooling supporting them. A single-tool strategy across data center and public cloud can seem attractive. But a cloud-native solution - offered by the cloud provider, or a 3rd party leveraging the provider’s Cloud API - will almost certainly be more operationally practical. Agent-based solutions require network or privileged administrative access, add to cloud run cost, increase security risks, may be difficult to deploy or unavailable on your preferred cloud providers.?

Cloud-native security offerings are rapidly improving and include a wealth of open source solutions.

Cloud Migration Requires A New Way Of Working

This new cloud-native way of working can be illustrated with another security example. The Snyk report mentioned above states 45% of security incidents involved in its source known vulnerabilities.?

Patching is hard. In-place patching in public cloud is much harder. Updating the vulnerable component or otherwise mitigating, testing and then rolling it out across the landscape would be much better. This is possible but requires a modern CI/CD pipeline and IaC deployments, leading back to the adoption of cloud-native processes. Cloud migration is not a one-time event that you prepare for, work towards and then complete.

Once you’ve arrived in public cloud, you’re not done: now you adapt to the constant rate of change of the environment alone. To optimize use of the architecture, don’t prepare for today. Prepare and organize to adjust to the pace of the platform.

Continuous Learning

Continuous change means continuous learning. Both fascinating but frightening, those already at the front-line are pushing the boundaries of what’s possible in public cloud and learning faster than those just coming to IaaS. Many training offerings provide a grounding, but keeping course material up-to-date is challenging. Nothing beats hands-on experience, and I strongly recommend providing your technical staff with their own cost-limited test cloud accounts to enable them to create and destroy resources, try out new things and remain current.?

Collaboration Between The Experienced And The Cloud-Native

Continuous learning goes for new talent early in their careers as well as experienced seniors and experts. The rate of change itself demands it, and dialogue between cloud-native only talent and those who know how we got here is invaluable. We should not throw out everything we know and have learned. Our best and most practical solutions are developed when talent and experience come together in respectful dialogue.?