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”?
DevOps guru and practitioner Rob Berger joined me on a recent DevOps.com webinar to deep dive on these topics.
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
Varma 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
