4

Cloud Native & Microservices Readiness Assessment

 1 year ago
source link: https://keyholesoftware.com/projects/cloud-native-readiness-assessment/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

Cloud Native & Microservices Readiness Assessment

June 14, 2022 Application Rewrite, IT Strategy, Modernization

The project included an assessment of an existing monolithic application and recommendations for modernizing it to achieve the goals of the initiative—mainly a cloud-first, performant, and microservices-based implementation. Specific technology suggestions were proposed in addition to the reasoning behind each recommendation. While proprietary details cannot be shared, generalized takeaways are included.

Client Consulting Relationship

The client was a global leader in inventory supply chain solutions for the digital economy. It helps its clients manage inventory throughout the supply chain by increasing visibility, accuracy, and execution.

Though the client is a global leader in its field with a reputable technology team, the organization’s leadership understands the value of an outside perspective. Keyhole Software was engaged to provide a detailed assessment of a large legacy inventory management solution and the best paths for its strategic modernization.

The application architecture, UI, and Cloud-Native subjects were assessed independently. There were a number of key points uncovered during this assessment that we feel will benefit any company seeking to modernize. These have been included to assist a company in its modernization journey.

Part 1: Application Architecture

One overarching thread throughout all Keyhole Software modernization services is the imperative that all actions are taken to ensure that the business and functional requirements of the application can be satisfied in both the near and long term future. Specifically, it is important to consider not just the current known requirements of the application, but also look at how the application could accommodate growth and change over time.

It is important that the approach is manageable, meaning that the current staff is capable of building and maintaining it, as well as resourcing it over time with “external” developers. It is also important to consider how “legacy” subsystems can be incrementally improved, reducing the need for wholesale rewrites before benefits can be realized.

Common Client Goals

  • Data Model Extensibility: Ability to extend/augment the data model quickly to support specific and/or changing customer requirements
  • API Extensibility: Ability to include “extended” data into the API dynamically (data schema extensions). Ability to add “logic” to extend/augment standard logic for specific actions and/or events
  • UI Extensibility: Ability to define “standard” UI components that can be “configured” to support customer requirements – i.e. hide/show specific attributes
  • Upgradeability: The approach to the extensibility must NOT inhibit the process of future upgrades, releases, and/or patches being applied.
  • Multi-tenancy: Ability to host on a shared platform, but isolate customer data, user management, and unique customer-specific configuration/extension points.

Assessment Details

The architecture assessment included a detailed analysis of the various layers of the application architecture. This included the:

  • Schema Layer—what the structure of the data was;
  • API Layer—how the application interacted with the available schema; and the
  • UI Layer—how the application presented the data and allowed behavior.

Select Client-Specific Recommendations

With the knowledge gained during the assessment, Keyhole recommended the client move toward a “schema” driven approach that manifests as a declarative API to the underlying data and behavior.

Specifically, we suggested using a GraphQL API approach to provide the needed flexibility for the API to change and customize over time. The prototype suggested included the Hasura GraphQL Engine. It provides a powerful way to create and maintain a GraphQL API driven by Postgres data.

Part 2: UI Technology

This assessment covered how the UI of the application could be modernized, componentized, and easily extended. General objectives included the need for less specialized skills in developing new features and the ability to reuse code wherever possible. Most modern, open-source, JavaScript-based frameworks provide a solid component model for developing applications in a way that is well-organized and maintainable.

Common Client Goals

  • Modernize the UI
  • Use industry-standard libraries and tools
  • Use open-source options

Assessment Details

In general, the importance of moving toward a modern and approachable client-side solution for the UI is key, as demonstrated by the common experience Keyhole Software has often alleviated—the proprietary nature of legacy UIs and the need for specialists for updates and client interactions.

Some clients require offline-first capabilities and the ability to perform tasks without a constant internet connection. There are also varying types of devices used, which depend on what role the user has at a given time. For example, admins are more likely to use a desktop-based inventory screen while users may need access to different features via a mobile device.

Select Client-Specific Recommendations

Based on the details uncovered in the client assessment, Keyhole recommended a modern, component-based JavaScript framework. We also encouraged that JavaScript framework leveraged TypeScript or another typed language. The ability to create applications with reusable components is a huge advantage for sharing and composing functionality. Leveraging TypeScript types along with GraphQL or other strongly-typed tools compounds these benefits.

Given the details uncovered in the assessment, the suggested prototype to meet client requirements was React-Native Using Expo for Web. Rather than the traditional approach where one would normally develop for native devices and then possibly use web features to run the same application in a browser, we suggested the client use Expo to create a first-class web application that would allow a native application to be generated at a later time. This approach more closely fit the client-specific requirements.

Part 3: Cloud Native

While “cloud native” is a term that is a bit hard to pin down to a single sentence, in this context, we defined it as the ability to build and run scalable applications seamlessly on public, private, or hybrid cloud environments. The primary objectives are to reduce the time from idea to value, to manage complexity, to improve the reliability of the infrastructure and applications, and to use resources more efficiently.

A key recommendation to this client was to not try to “boil the ocean.” Becoming “cloud native” is not a project, but rather an evolution involving the introduction of new disciplines, techniques, and technology over time.

A common mistake is to take on too much change at once, which ultimately can have a negative effect by increasing complexity, decreasing quality and agility, and increasing overall costs. It is vital to incorporate new techniques. However, it is just as important to formalize them and test at scale before applying them as production solutions.

Common Client Goals

  • Agility: Increase the efficiency across the entire IT organization including:
  • Software Development: Decreasing the gap from Idea to Value
  • Infrastructure: Efficiency in provisioning, management, maintenance
  • Insights: Monitoring, troubleshooting, analytics
  • Cloud Agnostic: The ability to move the cloud infrastructure to any public cloud with minimal changes to the overall approach.
  • Ease/Simplify/Automate Provisioning: A simplified, repeatable, automated approach to infrastructure and application provisioning.
  • Reduce Footprint and Cost: Minimize infrastructure costs as much as possible.
  • Scalability: The ability to scale the infrastructure with relative ease as needed to support the application(s) needs.

Assessment Details

Some specific requirements can make an incremental migration challenging. The clients’ legacy application was assessed at length for potential problem areas that would impede modernization. An example of key factors assessed included:

  • Multi-tenancy: as the current database was monolithic and not multi-tenant.
  • Customer Extensibility: if the new approach would not be compatible with existing data schemas, APIs, nor UI implementation.
  • UI Rewrite: the transition path from the proprietary “legacy” UI implementation to a modern, open-source solution.

Additionally, certain factors can contribute to the difficulty in migrating to cloud-native. Each of these factors was discussed at length as to their impacts on the migration process.

Select Client-Specific Recommendations

With this client, there was a significant distance between the current state and any conceptual “cloud native” future state that was desired. Ideally, we seek to recommend a path to move the application to its future state incrementally, but how that migration looks is highly dependent on the decisions made regarding application architecture.

The goal was to define a path forward that will offer some immediate improvements, but also create building blocks on which future phases of the evolution can be built.

Given the specific requirements of this client, Keyhole recommended key elements of a cloud native movement that can be addressed in the near, mid, and long-term future including the establishment of Kubernetes as the runtime orchestration platform and Argo CD as a declarative, continuous delivery tool.

Final Notes

The assessment was presented to the client and received praise. It was noted that there was a significant distance between the current state of the enterprise application and the desired conceptual future state. Throughout the assessment, we sought to consider how the application subsystems could be incrementally improved and made recommendations. While an application is never “done,” many of the suggested recommendations have since been applied by the client.


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK