Accelerate your software development lifecycle with AI

In the last few years, AI has made substantial progress. Large language models (LLMs) can now perform many complex DevOps-related tasks, and independent service vendors (ISVs) are building advanced DevOps features using the generative and agentic AI capabilities. As modern DevOps solutions enable teams to iterate on software faster while streamlining processes, enterprises are actively exploring ways to modernize the way they build and manage software. Software engineers are openly embracing the new AI-augmented approach as well. By empowering your team with modern tools that do the heavy lifting while relying on your team to ensure that output remains high quality, you can innovate much faster on behalf of your organization.

This Amazon Web Services (AWS)-authored article is part of a multi-part series that explores how teams can modernize the software development lifecycle using AI-powered tools and AWS services. In this multi-part series, you will learn how modern software and AI can help you reinvent how you plan, build, release, and monitor your applications more efficiently.

This series presents a hypothetical scenario involving a legacy web application that has been in maintenance-only mode for over a decade. Due to additional funding received, the application is now in for an overhaul.

Figure 1: The modernization journey of the example.com application

This series contains one parent article (this article), which dives deep into the hypothetical scenario, and multiple child articles (one article for each phase of the SDLC), which share how modern DevOps tools in AWS Marketplace and AI-backed features help this team improve the overall state of the application and processes they follow. 

Hypothetical scenario

Imagine that your company maintains an application hosted on example.com, a popular news lookup website that helps customers quickly find the information they are looking for in newspaper archives. The website, now almost 10 years old, has been in maintenance mode for a considerable time.

About the application functionality - The application is a single, highly coupled application with three distinct functionalities. Every day, a CRON job triggers the download module, which downloads daily newspapers from news websites. These documents are loaded into a tape storage, and their metadata is stored in a MySQL database. Whenever customers need to do a lookup, they submit a load content request specifying the dates for which they need data. The load content module loads the data from the archive into the local storage and lets customers use the Search/Filter functionality, including section lookups based on Optical Character Recognition (OCR) technology.

Figure 2: The example.com application architecture

About the application architecture - The application is written in Java, uses Spring technology for the backend, and the frontend is served using a combination of JSPs and jQuery. Metadata is stored in a MySQL database. The application is packaged as a WAR file and deployed using Tomcat on a single server, which also has the local MySQL database. The engineers test the application locally and then manually deploy the war file on the server.

About the application maintenance team - The application is maintained by three junior engineers. When you talk to engineers, it becomes clear that they are talented and have good knowledge of new skillsets. However, when you further dive deep, you realize that they learned the current tech stack, which is dated and has limitations, only after they joined the team. When you interview them further, they mention that despite working hard through the day, they are often pulled into solving a Priority 0 or a Severity 0 bug in the middle of the night. They further mention that leadership had explicitly denied their request to add an engineer to the team last year. Late-night and weekend participation in customer escalations has left them feeling dissatisfied at work.

Gaps in the example.com application and development approach

The application, as well as the process followed by the current team, is dated. There are significant gaps:

• Local application debugging takes time – The application is monolithic, which means a single line change requires rebuilding and deploying the entire application. Building and deploying the application locally is time-consuming and takes at least 15 minutes, which delays development.
• New feature development takes time – Building even small features takes time. Engineers code everything from scratch using the legacy IDE that the engineers who built the application used. As most of the team is busy addressing tickets, the team can hardly dedicate 30% of its time to new development.
• Changes do not work as expected in production – Engineers use their local environments to debug and often end up making changes to the application that work on their machine but not in production. Sometimes this is because their environment configuration does not exactly match production.
• Deployment is manual – As there is no CI/CD pipeline and explicit recording of the configuration state of the production environment, releasing new changes to production has become a trial-and-error affair involving manual rollbacks. Deployments are a time-consuming affair.
• Documentation mismatch and lack of test coverage – The original documentation that was authored 10 years ago does not match the current state of the application. The example.com application has references to libraries released more than 8 years ago. Although some libraries were renewed, many libraries are quite old, and some are only referred to by the commented code. Documentation hasn’t been updated in a long time. Testing is done manually.
• Troubleshooting issues takes time – Logs are not centralized. When the team gets a tricky issue, they SSH into the production server and have to check numerous log files manually to make sense of the user journey. This approach takes time.
• Issues recur – There have been instances when issues that were fixed earlier resurface in the production environment. This mostly happens when certain quick fixes were made directly in the production environment. As fixes were not merged back into the development branch, when the next deployment happened, these zombie issues reoccur.
• Performance – Over time, the application’s performance hasn’t caught up to new standards. When the application was built, the latency was acceptable. However, over time, the application has become even slower.
• Security – the application uses a large number of outdated libraries. With time, new vulnerabilities are detected in these libraries, leading to at least 2-3 security tickets being reported by the central security team every week.

Furthermore, the code itself has several anti-patterns. The application has commented code, unused libraries, and a general architectural debt. In this case, the application was built long ago, and a lack of technical leadership, culture, modernization, and redesign has led to a buggy application full of technical debt.

What is changing for the example.com application and team

Over the last decade, the leadership had moved on, releasing multiple other successful business applications while keeping example.com on hold.  However, recently, a leading TV channel known for its investigative journalism expressed a deep interest in the example.com application. They highlighted how the example.com application helps them build higher-quality content and how it is indirectly helping them increase viewership of their channel. The news channel expressed a deep interest in providing initial funding and in doing a multi-year premium contract deal with your company. However, the deal comes with non-negotiable requirements. You and your team must:

1. Improve overall application performance and stability.
2. Implement 5 major features, including credit card payments, and a similar-to-this-news recommendations system.
3. Get and maintain PCIDSS compliance.
4. Provide 1.2 seconds SLA for each API, 99.99% uptime, and more.
5. Commit to a release schedule and give the customer access to new features as soon as they are released.

As the multi-year contract deal value is significant, leadership has decided to bring the project back to life. Having heard about your impact as a principal engineer across other projects, they chose you to spearhead this project.

As a principal engineer with significant industry experience and experience in mature engineering teams, you know that it’s crucial to address the technical debt, so your team can enjoy more steady, meaningful, and innovative work while removing the uncertainty. You must bring the team to use new-age tooling for software development, deployment, operations, and observability. Furthermore, you must further optimize processes and systems using generative and agentic AI capabilities to mitigate common requirements and improve your application's reliabilityte common requirements while helping you improve the reliability of your application. And you cannot do it alone.

Based on your discussions, the leadership approves your request for hiring 2 new mid-level full stack engineers and introduces you to new members who will be joining your team to help make the project a success. A product manager, a project manager, and an SRE from the central shared services team will be involved in the revamp of the example.com application, with complete support from their leadership. Furthermore, you and your new team can choose from a wide array of third-party software tools that help you improve processes, operations, and overall stability of the application.

You and your new team spend a week-long offsite together. The entire team agrees that you not only need to revamp the application but also the way the application is built, deployed, and maintained. As a team, you agree that you must use an AI augmented approach for modernizing the application and processes followed while keeping human-in-the-loop. This will help ensure that the output remains high quality. You agree on an 8-month schedule and that you and your team must address the following common requirements to make the overall experience smooth:

Plan and design

• The engineering team must address documentation debt and bring the current application library versions/platform versions up to speed.
• You, the principal engineer, must fix the “it works on my machine” problem. By abstracting and unifying the software development environment, you want to ensure that precious engineering cycles are not lost due to broken/misconfigured development environments.
• The product manager must identify tooling to quickly build prototypes for new features while ensuring that the prototype code is reusable.

Code and verify

• The engineering team must break the monolithic architecture and adopt standard design patterns such as microservices.
• The engineers must use modern, AI-backed tools to improve software coding efficiency and documentation while significantly increasing software coding efficiency and documentation while significantly improving the test coverage.
• Furthermore, engineers must ensure that they do not introduce any new security issues in their code.

Module integration 

• The SRE must ensure that the integration phase happens smoothly by avoiding interdependent test case failures, unstable builds, and optimizing build times.
• Furthermore, when feature branches are merged, the security posture of the application must not go down.

Module release 

• Every change going to production must be documented and reviewed by the team before it is released to the production environment.
• SRE must monitor the performance of all microservices before each release.

Deploy 

• The SRE must automate provisioning of the software infrastructure and deployment using a newer, Infrastructure as Code (IaC) based approach.
• Furthermore, the product manager must be able to decouple code and feature release and conduct A/B tests wherever necessary. This will enable the product manager to mitigate release risks.

Operate 

• As the application gets ready and becomes PCIDSS compliant, the SRE team must implement mechanisms to ensure:
• That application stays compliant, even after the development is complete.
• The application auto-heals back to its desired state in case there are any manual, unauthorized changes made to the application or its infrastructure.

Monitor and observe

• You and the SRE must implement application performance monitoring to ensure that the team has visibility into application performance.
• Implement mechanisms to expedite issue identification, troubleshooting, and root cause analysis

Here is the high-level schedule you agree on:

• Months 1-2: In these two months, sprints must focus on addressing the majority of technical debt, stabilizing the application, addressing broken development environment concerns, and planning new features.
• Months 3-6: Sprints must focus on building new features while standardizing integration, infrastructure as code (IAC), and deployment.
• Months 7-8: Sprints must focus on achieving PCIDSS compliance, monitoring, and operating example.com well.

Check out articles in individual tabs to learn more about how the team modernizes the example.com application using modern AI-based tooling, over a period of 8 months, and sets the team and the application for success.