posted

0 Comments

Guest blog by Gautham Pallapa Vice President, Systems and Platforms at West Corporation

Driving a digital transformation for an organization with a lot of brownfield applications in its portfolio can be extremely hard, and the journey can be arduous and perilous. Since legacy applications usually grow organically based upon the culture, structure, domain, and clientele of the organization, it is hard to sift through the entire application portfolio and comfortably search for common patterns or design patterns that would help select the right applications that could make the transformation less painful. We went through a similar application selection procedure and wanted to share some of our learning with you, with the hope that it might help in your transformation journey.

Apps are like people; The older they get, the more complex baggage they contain.

One of the most common anti-patterns that companies embarking on a digital transformation into a cloud native space commit is transforming the wrong applications (apps) for the wrong reasons. Since all applications (especially legacy apps) are not created equal, there are some simple checks that we can proactively perform to start the vetting process:

  • Was the application older than 12 years and/or does it not use languages supported by public IaaSes? – 12 years or before, software applications were developed with different patterns, were mostly monolithic, and might have a lot of technical debt.
  • Are the application and data tightly coupled? – If data is not decoupled from the application, then it would be difficult to run data and app in separate workspaces. The tighter the coupling, the more time it will take to refactor the app to have performance and reliability advantages.
  • Was the app designed with performance and optimization in mind? – If the app was designed poorly and runs inefficiently today, then chances are that they will run equally if not more poorly in a cloud native environment. Refactoring might be considerable, and sometimes it might be cheaper to rewrite rather than refactor.
  • Does it take a lot of effort for operations to keep the application running today? – Chances are, if the app takes a herculean effort from the operations team today, it would be compounded in a cloud native environment in addition to dealing with a learning curve of newer toolsets.

For the next round of elimination, we used the following additional criteria for our specific app portfolio. The objective of this exercise was not to whittle down the list of apps that can be transformed to a minimum, but instead to strategically identify the right kind of applications that will act as exemplars to a successful app transformation, thereby driving the digital transformation forward, and providing necessary proof to the organization that we are all on the right and more importantly, successful path to a digital transformation.YMMV depending on your domain and the class of apps, so pick and choose the elimination criteria that work for you:

  • Apps that are sensitive to latency – these usually are apps utilizing UDP or SIP traffic in their flows. This gets even more complicated when some workloads are in a cloud native environment and have to reach out to on-premise databases or other legacy functions.
  • Apps that depend heavily on third party software or components – Usually third party software or components could potentially introduce compatibility issues, latency and bandwidth constraints, licensing issues, or additional policies for utilization.
  • High security compliance apps or apps requiring federal requirements – increased cost based on need for dedicated circuits, virtual private centers, isolated segments, etc.

With the remaining set of applications, we then started looking at how we could prioritize and create an ordered sequence of applications that need to be transformed based on the criteria listed below:

  1. Cultural alignment – This was our primary criterion for prioritization. We evaluated the teams that owned apps in the selected portfolio and assessed their alignment with our culture of Lean, Agile, and DevOps, in addition to their maturity on the continuum of Agile Engineering practices.
  2. Apps that are Service-oriented Architecture (SOA) based – Service oriented architecture will generally lean toward having a clearly defined interface and clearly defined encapsulated functionalities, which make them easier to transform.
  3. Apps where we have abundant internal knowledge – If our internal developers have a deep technical understanding of the app, there is some to good documentation, and the developers have been supporting the app for a while, it definitely becomes easier for refactoring or rewriting.
  4. Apps with high utilization or with high Input/Output Operations Per Second (IOPS) requirement are acknowledged to use higher tiers for throughput needs in evaluation
  5. Apps that require vertical scaling or “scaling up” – these are applications that require more resources as the load increases on the application. Preferred behavior is horizontal scaling or “scaling out”

Once we sequenced the apps, we chose one of three approaches to transformation. We tried to “lift and shift” apps whose architecture was well-designed and already performed 4 or 5 of the 12 factors – one codebase tracked in revision control, explicitly declaring and isolating dependencies, treat backing services as attached resources, executing the app as one or more stateless processes, and running admin tasks as opportunistic/one-off processes.

We chose these apps as first candidates since there was minimal work to transform the apps, and we could guarantee demonstrating success quickly and also test out our release mechanisms, deployment techniques, governance approaches, and the new DevOps toolset that we were switching to for continuous integration/ continuous delivery (CI/CD).

Refactor or Rewrite – that is the question!

The next class of apps required some portion of refactoring in order to decouple data from the application before we could make the workload more cloud native. We introduced microservices patterns and event streams, and while being sensitive to the amount of refactoring we were introducing, we tried to bring in some of the 12 factor apps while we were refactoring the code. I want to express a note of caution here. There is an inherent temptation for the business partners to ask for new features to be added to the app since the code is being refactored (“Since you are touching the code anyways, why not add this small feature list in?”). While this sounds like a reasonable ask, our experience is that it increases the complexity and cost of partial refactoring, and slows down the migration effort overall. It also potentially introduces new points of failure and compounds triage and troubleshooting efforts should an incident occur post-deployment. I would recommend not adding new features while partially refactoring an application.

Finally, we targeted to have a complete refactor/rewrite of the third class of applications. In order to optimize the app transformation effort, we decided to have concurrent release trains (similar to SAFe v4.0). Our combination of release trains was 1 complete refactor, 1 partial refactor, and 3 lift and shifts. We ran experiments with various combinations initially, but found that increasing the velocity of deployments of partial refactoring apps and lift and shift apps exponentially increased the risk of incidents in a predominantly brownfield ecosystem. Hence, we decided to slow down our deploys and be more strategic and purposeful in the selection and deployment of apps being transformed.

Digital transformation is not for the faint hearted!

We have been going through our digital transformation for a little over 14 months now, and the results are very encouraging. It is exciting to bring in a culture of DevOps, continuous experimentation, and intrapreneurship within an organization, and extremely fulfilling when we start seeing the release trains adapt the “Build, Release, Run” methodology combined with environmental parity. We still have a long way to go on our journey, but I hope that our validated learning can help you avoid a few anti-patterns, and failures that we experienced, and accelerate your digital transformation.