Like many companies, NetApp runs some old, large enterprise applications that are maintained like zombies. Barely kept alive, these apps are important to the company yet are complicated to keep updated and are expensive to support. As the IT leader for the developers who focus on custom business app development inside NetApp, my team and I know firsthand the challenges of rebuilding customized apps that are founded on monolithic architectures.
Rebuilding Our First Critical Business App
With approximately 350,000 unique visitors per month, the NetApp Support site is one of the most important channels for our customers to get help when they need it. They can use self-help, interactive chat with a support agent, or other forms of digital support. It is an important part of our enterprise landscape and is an award-winning support site.
Still, until recently, the Support site had never undergone a major overhaul, only fragmented enhancements. Certain parts of the site were still running 20-year-old original code. It had become harder and harder for us to maintain and to improve the site. New features were added as bolt-on applications, resulting in a mixture of technologies and integrations that became risky with the security challenges that are prevalent with older, cobbled-together code.
When it became clear that something had to be done with the site, we also recognized that our business models were changing faster than ever and that digital support was of the utmost importance. From an application support perspective, we needed to be able to react to change requests quickly and cost-effectively. The only way to achieve this goal was to rebuild the entire site from scratch.
For the new architecture, we decided to use a microservices-based approach that was developed with DevOps principles. This approach was a great fit for our needs. As the following figure shows, we went from monolithic stacks to an Angular-based single-page application (SPA) UI that uses microservices running in containers.
By using microservices running in containers, we could break down a complex, large monolith app into smaller, easier-to-manage services. Such services are easier to test automatically through unit and contract-based testing. This testing is a key aspect because it’s important to “trust” any changes that are being made. Only then can we roll out updates quickly and with confidence.
The scalability of a container application to handle peak usage periods is another important aspect. Because the Support site is a large public-facing site, we must be prepared to handle peaks without disruption. Running an application in containers gives us a great abstraction layer from the infrastructure, and it makes the application more fluid. We can now easily move parts, or even the whole application, into the public cloud or back to our private cloud if we want to. Microservices running on containers were clearly the right architecture choice for the rebuild of the site.
Also, the timing is perfect for the Support business team which had just completed a user-centered design to modernize the Support site. The new design optimizes operations around user choice, provides rapid content publishing, and supports low-effort customer experiences. The timing also aligns perfectly with an effort that my coworkers on the IT Foundational (Infrastructure) Services team had just delivered: a new DevOps-based platform called CloudOne.
The CloudOne platform was built to provide all the cloud and other technologies that my developers needed. It starts with a quick initial setup through a self-service portal that triggers automated processes to set everything up end to end. But it does not stop there. It handles all the infrastructure setup through automation as part of our deployment pipelines and provides a rich set of monitoring and management tools. With all the CloudOne features, for the Support site rebuild, my team could simply focus on developing code to run in the provided containers without having to worry about anything infrastructure related.
With our maiden voyage into the world of microservices and containers, we have learned several things. Among those lessons, we discovered that:
- No system lives in isolation, which is especially true for the Support site. Bringing this new, modern world together with our legacy environments was certainly a tough task. And although DevOps is about getting things done with speed, it is not necessarily true for large legacy systems. Starting the integration as early as possible is therefore important.
- DevOps comes not only with technical processes such as continuous integration and continuous deployment (CI/CD), but it also applies strong agile practices on a project that affects everyone. All the speed that you get from the architecture and platform automation requires the inflow of work, the testing, and the feedback loops to be performed in a timely manner. Getting everyone into the right “flow” takes some time and practice across all parties who are involved in the project. And proper change management is vital to get there quickly.
Although rebuilding the NetApp Support site wasn’t always easy and required collaboration and support from different levels, it was totally worth the effort and was a great experience for my team. And there’s more to the story. Check for future NetApp IT blog posts where I will share how we determined what technologies to use in our microservices architecture, what choices worked well, and what mistakes were made along the way.
The NetApp on NetApp blogs feature advice from subject-matter experts from NetApp IT who share their real experiences in using NetApp® industry-leading data management solutions to support business goals. Visit www.NetAppIT.com to learn more.