PART 3 : Lift and Shift or Move and Improve
February 10, 2020
How to Modernize
In our previous posts we talked about Why it is necessary to modernize. In this post, we move on to the How.
Most of the people we talked to during our customer development interviews told us they were looking for quick wins at the beginning of their modernization journey. Often, the first decision to make is whether to take existing infrastructure and lift & shift that to the cloud or to evaluate whether there are some opportunities to get those quick wins by incrementally adopting some cloud native identity services.
Let’s take a look at each approach.
Lift and Shift
Quick wins and speed are characteristics that make this an attractive option to enterprises. But there are other factors motivating this approach as well. One we heard quite frequently was that the CIO has a mandate to get the company out of the data center business. The servers and networks and other infrastructure running legacy identity and apps are simply going away, which means that those applications and supporting services must be quickly moved onto a cloud platform.
If you drew a picture describing how legacy identity is delivered to apps and put it next to the picture below, they would be essentially the same picture. The difference is that now the identity infrastructure is deployed onto compute on a cloud platform such as AWS or GCP. Sometimes, this infrastructure is “modernized” by deploying into virtual machines.
The downside of this approach is that it often looks like moving the mess. The baggage of years-old deployments is carried into the cloud, leaving functional gaps, problems with stability or resiliency, and unaddressed security vulnerabilities.
It’s worth noting that A LOT of customers take this approach, probably because this is the quickest path to a win.
Move and Improve
When we interviewed customers, they often told us that they had no identity in the cloud. But when we probed on that, we found that customers had SaaS applications — sometimes dozens or hundreds of them — and so had some cloud-based identity service to protect those SaaS apps. In some cases, that was using the built-in identity capabilities of a SaaS platform, such as Salesforce or Workday. In other cases, there was actually an Identity as a Service product deployed, although perhaps only on a departmental level.
Customers also told us they had a cloud platform such as AWS and had some number of applications running on that platform. And that means they are using the built-in identity capabilities of that platform, synchronizing users, setting up authentication, and creating access control policies.
Using these cloud-native identity capabilities is necessary and useful but introduces a new complexity to the organization. It’s not always clear who in the organization owns and has responsibility for the ongoing management of those identity services. Often, customers would say to us, “oh, the cloud platform team owns that” even while describing projects where the IT team traditionally responsible for IAM would own and implement cloud identity services.
We learned that some customers were further along their modernization journey and had already implemented a cloud-native identity approach. In the next part of this series, we will talk about the ways in which cloud native architectures and deployment patterns — where apps, data, and services are highly distributed — challenge the traditional centralized approach taken by legacy identity-management systems.
To view all the posts in this blog series, go here.