INVISTA refactors critical legacy shop floor application using AWS

About INVISTA

INVISTA is a global manufacturer of chemical intermediates, polymers, and fibers. From parts for the automotive industry to medical equipment, air bags, food packaging, carpet and clothing, our ingredients in the nylon 6,6 and polypropylene value chains help bring many of life’s essential products to market. A subsidiary of Koch Industries since 2004, INVISTA is committed to innovation and responsibly creating more value for its customers and society, while consuming fewer resources to make these products. See the bigger picture at INVISTA.com.

Overview

INVISTA embarked on a journey to completely refactor a critical legacy application, the Pigment Mix Check Advisor (PMCA), while implementing a modern application architecture. PMCA helps INVISTA’s business avoid costly material mismatches in their production pigment mix. Focusing on this manufacturing use case, this blog post illustrates how a static shop floor application can be transformed from a static Windows solution with Internet Information Services (IIS) to Linux containers running on Kubernetes, new methods of authentication and authorization, an integrated continuous integration and continuous delivery (CI/CD) pipeline, a JavaScript framework, representation state transfer (REST) APIs, and a serverless database. Using Amazon Web Services (AWS), INVISTA created a modern product while maintaining a balance between modern and ultramodern architecture design. In doing so, the company improved the user interface (UI) for operators, reduced IT support, removed spreadsheet integrations, added data historian tables, and corrected recipe data for its manufactured product.

Challenges to overcome

During its modernization journey, INVISTA needed to consider the value proposition of modernizing and allocating the necessary resources to be successful. The company needed to answer the following questions:

• Which migration strategy is applicable? When we talk about migrating an application there are 6 different strategies that one can take – Rehost, Replatform, Repurchase, Refactor, Retire and Retain. Typically, enterprises begin to examine how to migrate an application during the application discovery and planning phase. The complexity of migrating an existing application varies on few things like, application architecture, licensing, integration with systems, etc and based on these factors you can chose the right migration strategy.

Figure 1 above represents the 6 different migration strategies we see customers implement to migrate applications to the cloud.

• Can we build enough domain knowledge to have sustainable and usable knowledge for the future?
• What cost savings can we expect from the hardware and software changes?
• Can we expect any noticeable performance improvements?

Answering these questions was necessary to warrant INVISTA’s investment in time and resources. To achieve the best modernization results, the INVISTA team knew it had to do the following:

• Empower an agile working team made up of many diverse skill sets
• Learn and apply a unit testing strategy
• Define a modern authentication and authorization strategy without major Active Directory (AD) dependencies
• Shift mental models on compute and storage requirements and use containers and serverless solutions
• Aggregate and create container/serverless application observability when tools are designed around server infrastructure monitoring

Key design decisions

In addition to overcoming the above challenges, it was important for INVISTA to be forward thinking with its design to mitigate challenges for future developers on the project. Beyond considering the initial development team, the company needed to set itself up for long-term success with the application. If the company were to lose domain knowledge through natural attrition, it wanted to be in a position where others could simply pick up where the original team left off. This concern became the basis for INVISTA’s design decisions throughout the project.

Before getting started, INVISTA outlined some key tenets to align the development team on the modernization vision. One of those tenets was to keep the total cost of ownership low. The team knew that it would be simple to celebrate a “modern” refactor. But it would be difficult to gain support for modernizing applications if there is not a business value in addition to the technical advancements. In addition to hardware and software costs, INVISTA also needed to consider the cost of its team’s time: the team knew that one way to optimize for developers in the future would be to define a secured, reliable, and efficient CI/CD code pipeline that promoted transparency and a complete deployment process with embedded versioning capabilities.

Selection of hardware

Infrastructure plays a critical role in sustaining and reliably running production workloads for millions around the world. In years prior, organizations heavily invested in on-premises centralized computing to manage, secure, and scale infrastructure for their needs. INVISTA is heavily invested in cloud and distributed computing infrastructure, and its team also sees the value in fully managed cloud infrastructure. At the end of the day, the company needs its developers to be focusing on solving complex problems and moving the needle forward for its business, not managing the underlying infrastructure on which its systems run. Because INVISTA does not have a comparative advantage in infrastructure management, it chose to use an AWS-managed offering for the compute, storage, and databases. Amazon Aurora Serverless, an on-demand and automatic scaling configuration for the MySQL- and PostgreSQL-compatible relational database Amazon Aurora, offered INVISTA the perfect mix between performance, infrastructure management, and a cost model driven by consumption.

Software design

Many passionate developers tend to gravitate toward decisions surrounding their design of a software layer and the method of decoupling an application. At times, they are guilty of focusing on these decisions before they do any other planning. It’s common for these developers to think about the desired state and skip key design principles to set themselves up for long-term success. During their discussions, INVISTA’s team realized they needed to make a few decisions in response to the following questions before moving forward:

• Do we need decoupling?
• Should we choose a single-page application (SPA) or multipage application (MPA)?
• Can we design a solution that is less dependent on AD?

Addressing decoupling

There are many ways to design container/serverless applications using cloud and edge distributed computing. INVISTA decided to align its decision regarding the first question about decoupling with the goal of providing the developer the extensibility in the future to run the application wherever was necessary with little rework involved. So, the INVISTA team chose to use containers for the front end and backend because they had confidence it would be reusable on compute solutions that it already used (on-premises servers, edge nodes, cloud clusters, local development machines, and more). The team’s decision to separate the backend from the front end gives them additional autonomy to change the REST layer, reuse it for reporting, scale up as required, and add additional security controls without coupling them with front-end dependencies.

Addressing the application framework structure

SPAs vs. MPAs: Is there a right or wrong answer? It depends. Speed, coupling, search engine optimization, and user experience are areas of consideration when selecting between the two. There are plenty of big solutions that run as SPAs and MPAs. For INVISTA, the question became what was “modern” enough and right for the company.
INVISTA chose to develop an SPA for two primary reasons: speed and coupling. SPAs load resources or compartmentalized components on demand while MPAs load everything upon user requests. As a result, MPAs tend to be slower because they are loading content from scratch. A major benefit of an SPA design is developers can create components or “blocks” of functionality that they can invoke on demand without adding significant load time for the user. SPAs also tend to be decoupled by nature. The development of an SPA assumes that the backend is separate. SPAs use APIs of a developer’s choice that run server side to create, read, update, and delete data. With an MPA, the front end and backend are more dependent on each other. Further, all of the application code is typically housed in the same project, limiting options for development frameworks.

Addressing—and trying to get away from—AD
AD first launched as a capability in Windows 2000 Server, and it has played a key role in application design and security for years. AD was designed to simplify access control between all types of clients, servers, and end points for Microsoft environments. This design continues to be popular in manufacturing applications in 2021, but it can limit users’ ability to modernize. AD’s design is largely built around domain constructs and trusts across all organizational units. As enterprises grow, it can become increasingly difficult to secure and maintain AD authorization in applications.
For its authentication component, INVISTA decided to use an enterprise Identity Provider (IDP) called KochID, which does validation on user emails and other attributes for the company. For authorization, INVISTA is yet to have a standard (AD-free) solution. But in its deployment, the INVISTA team used Amazon Cognito, which lets users add sign-up, sign-in, and access control to web and mobile apps quickly and easily. INVISTA found Amazon Cognito simple to implement due to the thorough documentation that AWS provides on Amazon Cognito and the amazon-cognito-identity-js npm library. Using KochID and Amazon Cognito, INVISTA was able to integrate its IDP, register new users with ease, and allocate appropriate roles for the different operating roles within the application.

Architecture

Figure 2 – New architecture diagram of Pigment Mix Checker Advisor (PMCA) application.

Figure 2 – Above describes the new architecture diagram of Pigment Mix Check Advisor with modern application architecture utilizing AWS services.

Improvements

As a result of its effort to refactor its legacy PMCA application while implementing a modern application architecture, INVISTA achieved the following benefits:

• Cost improvements
  • Compute costs are now 2.5 percent of the previous server costs.
  • Storage costs are now 12.5 percent of the previous database costs.
• Enhancement improvements
  • Speed and navigation are now considerably faster using the JavaScript framework.
  • Scaling on multiple devices (tablet, mobile, desktop, etc.) is more usable.
  • The team created a setup screen that removed the need for users to pass around spreadsheets before attempting to update the database.
• Data integration improvements
  • The team gained direct access to programmable logic controller (PLC) input/output (I/O) values (through the removal of legacy middleware).
• Hardware/software abstraction improvements using containers
  • The team achieved extensibility for the runtime.
• Authentication and authorization improvements
• • The team removed dependencies on AD.

Conclusion

In this blog, we learnt about how one of the world’s leading manufacturer of chemical intermediates, polymers, and fibers implemented a modern application design and a complete re-haul of a critical legacy application using AWS services. Apart from the cost improvements this enabled site operators with an improved UI, reduction in IT support, removed the need for spreadsheet integrations, updating data historian tables, and correcting incorrect recipe data for their manufactured product. Please feel free to contact us with any questions specific to this implementation, (Kyle.A.Marfise@invista.com, saurbhsh@amazon.com). For more such articles on how AWS is helping manufacturing companies with innovative solutions do checkout the AWS manufacturing page.