Home » Security Bloggers Network » Your Cloud Journeys is Unique, but Not Unknown

Your Cloud Journeys is Unique, but Not Unknown

by [email protected] (Securosis) on February 17, 2020

Posted under: For Research Library

This is the first post in a series on “Network Operations and Security Professionals’ Guide to Managing Public Cloud Journeys” which we will release as a white paper after completion and time for public feedback. Special thanks to Gigamon for licensing. As always, the content is being developed completely independently using our Totally Transparent Research methodology.

Cloud computing is different, disruptive, and transformative. It has little patience for traditional practices and existing architectures. Cloud requires change, and while there is a growing body of documentation on the end states you should strive for, there is a lack of guidance on how to get there. Cloud computing may be a journey, but it’s one with many paths to what is often an all to nebulous destination.

Although every individual enterprise has different goals, needs, and capabilities for their cloud transition, our experience and research has identified a series of relatively consistent patterns. One way to think of moving to cloud is as a mountain with a single peak and everyone starting from the same trailhead. But this simplistic view, which all too often underlies conference presentations and tech articles, fails to capture the individual nature of the opportunities and challenges you will face. On the other end we can think of it as staring at a mountain range with innumerable peaks, starting points, and paths… and a distinct lack of an accurate map. This is the view that ends up with hands thrown in the air, expressions of impossibility, and analysis paralysis.

But our research and experience lands us between those two extremes. Instead of a single constrained path that doesn’t reflect individual needs, or totally individualized paths that require you to build everything and learn every lesson from scratch, we see a smaller set of options with consistent characteristics and experiences. Think of it as starting from a few trailheads, landing on a few peaks, and only dealing with a handful of well-marked trails. Knowing these won’t cover every option, but can be a surprisingly useful way to better structure your journey, move up the hill more gracefully, and avoid falling off some really REALLY sharp cliff edges.

Introducing the Cloud Adoption Patterns

Cloud adoption patterns represent a consolidated set of cloud adoption journeys compiled through discussions with hundreds of enterprises, and dozens of hands-on projects. More nebulous than specific cloud controls, they are a general way of predicting and understanding the problems an organization will face when moving to cloud based on their starting point and destination. These patterns have different implications across functional teams and are especially useful for network operations and network security since the adoption pattern tends to fairly accurately predict many of the architectural implications, when then map directly to management processes.

Sponsorships Available

For example, there are huge differences between a brand new startup or cloud project without any existing resources, a major data center migration, or a smaller migration of key applications. Even a straight up lift and shift migration will be extremely different if it’s a one-off or smaller project or if it’s wrapped up in a massive data center moved with a hard cutoff deadline thanks to an existing hosting contract expiring. Both cases take an existing application stack and move them to cloud, but the different scope and time constraints dramatically affect the actual migration process.

We’ll cover them in more detail in the next post, but the four patterns we’ve identified are:

Developer lead- where a dev team starts building something in cloud outside normal processes and pulls the rest of the organization behind them.
Datacenter transformation- an operations lead process defined by an organization planning a methodical migration out of existing datacenter and into the cloud, sometimes over a decade or more.
Snap migrations- where an enterprise is forced out of some or all of their datacenters on a short timeline due to contract renewals or other business drivers.
Native new build- where the organization plans to build a new application (or applications) completely in the cloud using native technologies.

You likely noticed that we didn’t mention some common terms like “refactor” and “new to cloud”. Those are important concepts but we consider those options on the journey, not the definition of the journey itself. Our four patterns are defined by the drivers for your cloud migration and your desired end-state.

Using the Cloud Adoption Patterns

The adoption patterns provide a framework to think about your upcoming (or in process) journey and help identify both strategies for success and potential points of failure. These aren’t proscriptive like the Cloud Security Maturity Model or the Cloud Controls Matrix; they won’t tell you exactly which controls to implement, but are instead more helpful in choosing a path, defining priorities, mapping architectures, and adjusting processes.

Going back to our mountain climbing analogy, the cloud adoption patterns point you down the right path and help you decide which gear to take, but it’s still up to you to load your pack, know how to use the gear, plan your stops, and remember to wear sunscreen. The patterns represent a set of characteristics we consistently see based on how organizations move to cloud. Any individual organization might experience multiple patterns across different projects. For example, a single project might behave more like a startup while you may concurrently be running a larger data center migration.

In our next post we will detail the patterns with their defining characteristics. You can use this to determine your overall organizational journey as well as those for individual projects that might not be totally aligned with the organization at large. To help you better internalize these patterns we will provide fictional examples based on our real experiences and projects. Once you know which path you are on, our final sections will make top line recommendations for network operations and security and tie back to our examples to show how they play out in real life. We will also highlight the most common pitfalls and their potential consequences.

This research should help you better understand what approaches will work best for your project in your organization. We are focusing this first round on networking, but future work will build on this based and cover additional operational areas.

Cloud migrations may be tough and confusing. While nothing will let you skip over the hard work, learning the lessons of those that already climbed the mountain will save costs, reduce frustrations, and increase the chances of success.

– Rich
(0) Comments
Subscribe to our daily email digest