By Amit Vij, Business Systems Analyst

The NetApp Support site, which provides our customers with self-help, interactive chat, and other forms of digital support, has been rebuilt on smaller, easier-to-manage services. The site has been transformed from an application with monolithic stacks to a modern microservices-based architecture, front ended by an Angular-based single-page application (SPA) UI. 

This is part of a wider movement by NetApp IT towards microservices. The flexibility and option to leverage best-in-class solutions is attractive to the enterprise and allows us to better serve the organization.

I talked about our approach in a recent webinar:

Our approach to the Support site is an example of this approach.

One key back-end system for the Support site is our Enterprise Content Management (eCM) application and its content repository. The team analyzed the functionality associated with the legacy monolith eCM and identified granular services that needed to be exposed. One identified service was the Software Download (SWDL) function in eCM.

An important piece of our transformation was the continued need to retrieve vital data from several back-end systems that would remain monolithic, at least until modernized in the future. Our challenge was to develop services that interface with the legacy back-end monolithic applications. We chose a solution that delivered RESTful APIs, exposing the desired functions, abstracting the legacy systems, and interfacing through an API Gateway platform. 

API Abstraction Layer

RESTful APIs were developed to provide the identified services. These RESTful APIs were registered in the API Gateway platform and accessed by the microservices from the service layer. The RESTful API completely abstracts the legacy systems and masks its complexity. The SWDL service can then be reused by other front-end applications that require software download functionality. Other applications that need SWDL function can also access the SWDL APIs directly. The back-end eCM system is completely abstracted from this function.

This new mechanism offers a way to break down our legacy monoliths and convert them into modern microservices-based applications. The legacy system can be transitioned to any modern application framework, providing that it preserves the API signatures, so that consumers can seamlessly access them. API signatures acts like a contract between provider and consumer.

Our DevOps platform handles all infrastructure setup through automation as part of our deployment pipeline. It provides all the cloud and other technologies needed via quick initial setup through a self-service portal that triggers automated processes to set up everything, end to end. 

Lessons Learned

– The first step in our journey was having a robust cloud CI/CD infrastructure; expect a steep learning curve to adapt these new mechanisms.

– A deep understanding of business requirements and an implementation plan are necessary to define the boundaries of microservices; those boundaries are not always clear. In our case, we grouped subfunctions with the business process into a single microservice.

– Compared to a monolithic infrastructure, there are many layers and parts in the new design. Troubleshooting issues could take more time than usual; however, once the teams is familiar with all aspects of the design, the time to market new features is greatly reduced. 

– A DevOps approach brings change to people and processes as well as to technology. Successful DevOps adoption requires a consistent push and support from senior management.