Current-day literature regarding digital disruption and technology modernization commonly discusses legacy-monolithic infrastructure/applications and modern-day architectures such as microservices. However, less literature exists on the journey from legacy to modern infrastructure architectures. In this blog post, I aim to provide a high-level roadmap to help organizations navigate their technology (infrastructure/application) architecture modernization journey.
To start, let’s introduce the concept of greenfield and brownfield. In the second edition of The DevOps Handbook, authors Gene Kim, Jez Humble, Patrick Debois, and John Willis discuss these concepts in their original terms. Initially used in urban planning and building projects, greenfield is when buildings are built upon undeveloped land. Brownfield development is when we build on land previously used for industrial purposes, potentially contaminated with hazardous waste or pollution [1, p. 66]. In this blog post, greenfield represents new, unbuilt infrastructure and systems, and brownfield represents existing infrastructure and systems with complex interdependencies.
An organization’s strategy has a lot to do with how IT disciplines move forward with building infrastructure and systems. Many organizations have a “cloud first” strategy today or are striving to become “cloud first” throughout their modernization journey. This means greenfield initiatives should be built in the cloud before traditional on-premises (on-prem) infrastructure is used. Using cloud-native technologies to build new infrastructure architectures that support application and data architectures is a surefire way to modernize an organization’s technology stack. In fact, many start-up companies use a “cloud-only” strategy that ensures they don’t introduce legacy systems and technology to their ecosystems from the beginning.
While it’s fair to say that greenfield builds are easier to modernize than brownfield builds is true, it’s not necessarily “easy.” Arun Chandrasekaran (2022) from Gartner, Inc. depicts an illustration showing that the IT workforce has more skill and experience with traditional infrastructure architectures than modern serverless and container infrastructure architectures [2]. From experience, I can attest to Chandrasekaran’s illustration. Unless an organization brings in a small army of highly skilled and experienced cloud practitioners, either via direct hires or consultants, they are bound to experience their share of bumps, bruises, lessons learned, and re-work as they continue to learn and mature in the cloud.
The story changes significantly when it comes to brownfield or already existing systems. This is frequently where digital modernization becomes a journey, and strategy is a major factor in how organizations move their technology architecture forward. Assuming an organization is just beginning its modernization journey, it potentially has a long road in front of it. Even if an organization’s digital modernization journey has already started, the road forward is usually full of turns and hills.
To help with cloud migrations, Amazon Web Services (AWS) describes four phases of cloud migration. The phases include (1) Prepare, (2) Plan, (3) Migrate, and (4) Operations [3]. These phases are an essential component of digital modernization and can be used to help your organization with its migration. Check out AWS’s knowledge article “Phases of migration” for more details on their four phases.
Looking deeper into the migration process, Stephen Orban, author of “Ahead in the Cloud,” Chief Technology Officer at the New York CTO Club, and Vice President at Amazon Web Services [3], outlines six different migration strategies for moving applications to the cloud. AWS commonly refers to these migration strategies as “the 6-R’s.” The 6 R’s include (1) rehosting, (2) replatforming, (3) repurchasing, (4) refactoring/rearchitecting, (5) retire, and (6) retain [4]. All six strategies apply to brownfield builds.
Figure 1: The 6 R’s of cloud migration strategy.
- Rehosting, or “lift-and-shift,” is moving your existing infrastructure/systems “as is” to the cloud.
- Replatforming, referred to Orban as “lift-tinker-and-shift,” involves using some cloud services to optimize a system, but it doesn’t change the core of the system.
- Repurchasing or moving to a different product. This typically involves eliminating brownfield builds and replacing them with Software as a Service (SaaS) solutions.
- Refactoring/Rearchitecting is described by Orban as re-imagining how an application is architected and developed, typically using cloud-native technologies.
- Retire or simply get rid of. Orban says that between 10% and 20% of an organization’s IT portfolio is no longer useful and can be retired.
- Retain usually means “revisit” or do nothing, at least for now. This strategy may be best suited for systems recently brought online on-prem or for organizations early in their cloud migration journey.
Orban says that enterprises usually begin to contemplate how to migrate an application [to new platforms and infrastructure] during the second phase of the migration process – Portfolio Discovery and Planning. A firm understanding of the systems existing in an organization’s IT portfolio is key to creating a migration strategy. Differentiating the low-hanging fruit that can be easily harvested from complex monolithic architectures with multiple interdependencies will help organizations choose the right combination of strategies to suit their migration needs.
“This [portfolio discovery and planning] is when they determine what’s in their environment, what are the interdependencies, what’s going to be easy to migrate and what’s going to be hard to migrate, and how they’ll migrate each application.” – Stephen Orban
As you can see, greenfield initiatives are easier to build in the cloud as they are not subjected to the monolithic and interconnected infrastructure that exists within an organization’s IT ecosystem today. Brownfield initiatives require significantly more strategy, planning, and often time to migrate into the cloud. Organizations will encounter use cases for greenfield and brownfield builds throughout their journey. Having the strategy and skills is vital to a successful digital modernization journey.
References
[1] G. Kim, J. Humble, P. Debois and J. Willis, The DevOps handbook, 2nd ed., Portland: IT Revolution, 2021.
[2] A. Chandrasekaran, Compute evolution: VMs, Containers, Serverless – Which to use when?, Gartner, Inc., 2022.
[3] Amazon Web Services, “Phases of migration,” 2022. [Online]. Available: https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-database-migration/phases.html. [Accessed 9 October 2022].
[4] S. Orban, “Linkedin – Stephen Orban,” [Online]. Available: https://www.linkedin.com/in/stephen-orban-7086471/. [Accessed 9 October 2022].
[5] S. Orban, “6 strategies for migrating applications to the cloud,” Amazon Web Services, 1 November 2016. [Online]. Available: https://aws.amazon.com/blogs/enterprise-strategy/6-strategies-for-migrating-applications-to-the-cloud/. [Accessed 9 October 2022].
[6] Y. Perry, “AWS migration strategy: The 6 Rs in depth,” NetApp Cloud Central, 25 July 2019. [Online]. Available: https://cloud.netapp.com/blog/aws-migration-strategy-the-6-rs-in-depth. [Accessed 9 October 2022].
Tony – This is an excellent summary of the challenges involved in building out new architecture by leveraging cloud based models and a great analogy to greenfield and brownfield from the DevOps handbook. The largest cost we typically encountered in all our projects involved people resources, either well paid consultants or on-boarding highly skilled workers. and this was exacerbated by cost overruns as the time estimates were often too conservative (meaning aggressive) or there was significant re-work if we got it wrong/picked the wrong partners. It would be great to have some perspective then of how costly subsequent migrations, cloud to new cloud architecture, would be if new cloud partnerships had to be forged. I imagine that journey would be less costly but still challenging and likely lead to multi-cloud, if not already part of the first move, technology architectures.
Often so many of our tiers have vendor partnerships and preferences which drive us to incorporate their cloud solutions into a cloud architecture journey. I think of Microsoft Office 365 and possible their SQL Server relational database management systems (RDBMS) leading to Azure cloud needs, Salesforce customer relationship management (CRM) systems that are already cloud based and other possibilities if you had another RDBMS either SAP/Hana or Oracle or IBM’s UDB. Very often we already have skilled IT workers familiar with the existing vendor systems we use and cloud exploration naturally extends to integrations with their offerings. Interesting challenges and food for thought. Great post.