DevOps.com

  • Latest
    • Articles
    • Features
    • Most Read
    • News
    • News Releases
  • Topics
    • AI
    • Continuous Delivery
    • Continuous Testing
    • Cloud
    • Culture
    • DataOps
    • DevSecOps
    • Enterprise DevOps
    • Leadership Suite
    • DevOps Practice
    • ROELBOB
    • DevOps Toolbox
    • IT as Code
  • Videos/Podcasts
    • Techstrong.tv Podcast
    • Techstrong.tv - Twitch
    • DevOps Unbound
  • Webinars
    • Upcoming
    • Calendar View
    • On-Demand Webinars
  • Library
  • Events
    • Upcoming Events
    • Calendar View
    • On-Demand Events
  • Sponsored Content
  • Related Sites
    • Techstrong Group
    • Cloud Native Now
    • Security Boulevard
    • Techstrong Research
    • DevOps Chat
    • DevOps Dozen
    • DevOps TV
    • Techstrong TV
    • Techstrong.tv Podcast
    • Techstrong.tv - Twitch
  • Media Kit
  • About
  • Sponsor
  • AI
  • Cloud
  • CI/CD
  • Continuous Testing
  • DataOps
  • DevSecOps
  • DevOps Onramp
  • Platform Engineering
  • Sustainability
  • Low-Code/No-Code
  • IT as Code
  • More
    • Application Performance Management/Monitoring
    • Culture
    • Enterprise DevOps
    • ROELBOB
Hot Topics
  • Checkmarx Brings Generative AI to SAST and IaC Security Tools
  • Linux Foundation Europe to Host RISE Open Source Project
  • I Guess This is Growing Up: Devs and CISA’s Secure-by-Design Guidelines
  • Forget Change, Embrace Stability
  • Finding Your Passion

Home » Features » Swapping Engines In Flight: Transforming Brownfield Enterprise Applications

Swapping Engines In Flight: Transforming Brownfield Enterprise Applications

By: Varma Kunaparaju on April 17, 2015 Leave a Comment

As DevOps thinking becomes more mainstream, enterprises will need to incorporate new ways of developing and delivering applications into their standard IT processes. Enterprises that are often complex and constrained by existing legacy infrastructure, organizations and processes must consider how and when to transition brownfield enterprise applications to an agile approach. With production applications on legacy infrastructure, how do you think about “changing the engine on a flying plane”?

Recent Posts By Varma Kunaparaju
  • DevOps Teams: Containers Will Help You Become Future Ready
More from Varma Kunaparaju
Related Posts
  • Swapping Engines In Flight: Transforming Brownfield Enterprise Applications
  • IoT Developers: Get Familiar With LoRaWAN for 2022
  • How DevOps Can Nurture the IoT Brownfield For Results
    Related Categories
  • Features
    Related Topics
  • apps
  • greenfield
Show more
Show less

DevOps guru and practitioner Rob Berger joined me on a recent DevOps.com webinar to deep dive on these topics.

TechStrong Con 2023Sponsorships Available

What Is Brownfield?

The EPA defines brownfields as “real property, the expansion, redevelopment, or reuse of which may be complicated by the presence or potential presence of a hazardous substance, pollutant, or contaminant.”

It’s humorous to think about our enterprise legacy apps being toxic dump sites and might feel that way at various points in our efforts to transform them, but in our world, brownfield simply refers to an existing application or service that is already in production. It was likely built using previous generation tools, serving mainframe or client server architectures, any time from decade(s) to a few years ago.

While “legacy” conjures images of a sleepy, backwater enterprise, brownfield is actually ubiquitous. Any company with existing computer based services has brownfield transitions to figure out because you can’t just throw away what’s in production today. Even when doing startups, it’s amazing how fast legacy can happen.

So how do you think about continuing to serve customers with an existing brownfield application in production, while transforming it into a modern web-scale application?

A Note On DevOps

Remember that first and foremost, DevOps is a process and journey. Different organizations are going to be at different stages at being DevOps.

Rob referred to Conway’s law, which states that “organizations which design systems… are constrained to produce designs which are copies of the communication structures of these organizations.” The takeaway is, make sure that the organization is compatible with what you’re trying to achieve. It is so critical that you break down silos and improve communications between all parties involved, even more so than the technology.

So, What Apps?

Enterprise applications largely fall into three categories. Many are going to be pre-existing custom applications, the kind that are wrapped around core organizational structure or business functionality. They are both the most challenging applications to transform, as well as the highest reward to figure out. You want to figure out how to offer things like mobile or web apps that leverage the existing app to slowly transform to the new way of doing things.

Related to the pre-existing applications are packaged applications from vendors because they can be as much wrapped up in the way you do business as the custom apps. Some vendors can support the migration, but more often you will have to identify the most critical new business functionality and move that to the new DevOps style.

In some ways, the easiest to deal with are new applications. They are greenfield opportunities to start from fresh with a new DevOps style team, with continuous integration, test driven development, and an organizational structure that reflects that.

Let’s say that you have a monolithic existing application that was written 8-10 years ago using standard open source technology C++ or Java in a waterfall model by a large system integrator. The market demands that the service modernize beyond the incremental changes that occur in the long cycle releases. What are the steps that you would go through to transform this app to the DevOps world?

Step One – Minimum Viable Product

You don’t want to create a complete replacement of your legacy application, and certainly don’t want to disrupt your existing business. But you do want to evolve it so that you can meet the needs of your more modern demands.

At the organization level, identify the most critical thing that you must deliver. What is the highest priority demand and what gives you the most bang for your buck? What is the “minimal viable product” for this new thing you want to do? Figure out the smallest scope to transform that will have the biggest impact. A easy example might be to add a mobile interface to your existing system because it just maps the user interface with the same business logic in the back end.

Step Two – Create The (Right) Team

You need a small team that has a mix of the right people to deliver this minimum viable project. It requires representation across functional groups

  • Business group or product manager,
  • Key developers,
  • IT operations who will automate the creation of the service (not just jockey a server)

Look at your current organization and architecture to identify the people that can adapt to the new way of doing things. Finding the right people who believe in the new way of doing things is critical to building responsive apps, per Conway’s law. Understand the internal politics and how to mitigate interpersonal dynamics. Don’t get bogged down in the past, but you need functioning teams that collaborate well to not disrupt your business.

Step Three – Build REST APIs

Your new application will built as self contained services for manageability and scalability, exposed through REST APIs. Identify what services you need from the legacy system, and create REST API around the legacy system that can expose the services from the legacy system to the new system. You will need people that understand both the legacy and new system to make this work.

One of the biggest variables will be how to most gently and elegantly wrap a REST interface around the legacy app. You want the new system to just talk to REST, and it doesn’t need to know anything about legacy app.

Step Four – Design The New Service

Use modern tools. Microservices should be at foundation of whatever you do. Figure out the components that can be considered independent and have its own lifecycle, tied together by REST or JSON interfaces. By identifying the minimum viable product, you should be working in 2-3 week cycles so that you can see the results fairly quickly.

Why Microservices

Your new apps should be loosely coupled architectures that are called microservices. Microservices tend to use RESTful APIs as the primary way that they communicate.

Think of each microservice as a functional block, like in functional programming where there are specific inputs and outputs, and the side effects should be non existent or very controlled. This allows you to know precisely to know what’s going on inside each box. Interoperation is explicit through REST or streaming interfaces. In both cases you can have schema repository that becomes the definition of how microservices talk with each other.

Automate Everything

Every time a software developer commits code into a Git repository, it should automatically be deployed into a QA or staging environment. Lay that rule down from the beginning. If you’re building individual servers by hand, that’s a good indication that you’re going to have problems. The goal is for everything to be scripted or your infrastructure represented as code, using configuration automation system like Chef and Puppet at the core of how you are deploying services.

You almost want to treat servers like immutable things that you throw away when you want to update it. The only way to do that is to automate, which leads to the application side concept of continuous delivery or continuous integration. Get to policy driven management, where policies are embedded in code.

Remember, You’re Not Replacing Your Legacy

This is a journey and you’re just starting on the evolutionary path for independence.

Keep in mind that you will likely have both the old and new running in parallel for a short time. You’ll want to figure out how to use your legacy system as a back end, with a decoupled front end that can then evolve independently to the back end. And leading to the next point, remember that your team running the new components and the legacy app will have to collaborate closely as you transform the enterprise.

About the Author / Varma Kunaparaju

YaCNNVuUVarma Kunaparaju is CTO at Vistara and a seasoned technologist with over 20 years of experience leading engineering teams to deliver enterprise software. Reach him on twitter: @varma1

 

 

 

Filed Under: Features Tagged With: apps, greenfield

« Cyber-Ranges, Cloud Automation and DevOps
DevOpsQA NJ Meetup – Virtual Networking with Project Calico »

Techstrong TV – Live

Click full-screen to enable volume control
Watch latest episodes and shows

Upcoming Webinars

App-Solutely Necessary: Why Modernizing Your Apps Is A Must Hosted By The Cloudbusting Podcast Team
Thursday, June 1, 2023 - 11:00 am EDT
Confident Cloud Migrations: How A Top 5 Bank Ensured Reliability With AWS And Gremlin
Thursday, June 1, 2023 - 1:00 pm EDT
Securing Your Software Supply Chain with JFrog and AWS
Tuesday, June 6, 2023 - 1:00 pm EDT

GET THE TOP STORIES OF THE WEEK

Sponsored Content

PlatformCon 2023: This Year’s Hottest Platform Engineering Event

May 30, 2023 | Karolina Junčytė

The Google Cloud DevOps Awards: Apply Now!

January 10, 2023 | Brenna Washington

Codenotary Extends Dynamic SBOM Reach to Serverless Computing Platforms

December 9, 2022 | Mike Vizard

Why a Low-Code Platform Should Have Pro-Code Capabilities

March 24, 2021 | Andrew Manby

AWS Well-Architected Framework Elevates Agility

December 17, 2020 | JT Giri

Latest from DevOps.com

Checkmarx Brings Generative AI to SAST and IaC Security Tools
May 31, 2023 | Mike Vizard
Linux Foundation Europe to Host RISE Open Source Project
May 31, 2023 | Mike Vizard
I Guess This is Growing Up: Devs and CISA’s Secure-by-Design Guidelines
May 31, 2023 | Pieter Danhieux
Forget Change, Embrace Stability
May 31, 2023 | Don Macvittie
What Is a Cloud Operations Engineer?
May 30, 2023 | Gilad David Maayan

TSTV Podcast

On-Demand Webinars

DevOps.com Webinar ReplaysDevOps.com Webinar Replays

Most Read on DevOps.com

CDF Marries Emporous Repository to Ortelius Management Platform
May 26, 2023 | Mike Vizard
US DoJ Makes PyPI Give Up User Data ¦ Tape Storage: Not Dead
May 25, 2023 | Richi Jennings
Is Your Monitoring Strategy Scalable?
May 26, 2023 | Yoni Farin
The Metrics Disconnect Between Developers and IT Leaders
May 25, 2023 | Mike Vizard
Dell Looks to Expand Pool of Available DevOps Expertise
May 25, 2023 | Mike Vizard
  • Home
  • About DevOps.com
  • Meet our Authors
  • Write for DevOps.com
  • Media Kit
  • Sponsor Info
  • Copyright
  • TOS
  • Privacy Policy

Powered by Techstrong Group, Inc.

© 2023 ·Techstrong Group, Inc.All rights reserved.