Client Snapshot: The client is FINSYNC, a company offering a complete cashflow management solution. FINSYNC’s platform helps businesses manage banking, payments, payroll, and projects all from one portal. They work with clients across industries and across the nation.
Project Overview
A senior Keyhole Consultant led an architectural assessment for a cash flow management client. The goal was for the consultant to lay out a roadmap for the incremental migration away from legacy Ember.js front-end and Rails-based monolithic architecture to a microservices and React front-end implementation.
They estimated for designated high-priority project areas and provided a variety of recommendations for architectural elements in new stack, deployment platforms, development tooling, and code organization.
Services Performed
Requirements Gathering
The project began with a phase to explore the client’s needs and goals for the project. Through this phase, the Keyhole Consultant determined that FINSYNC was using a monolithic Rails application and associated PostgreSQL database, serving a legacy Ember.js frontend from a single Heroku deployment.
The Rails application, as well as the majority of the frontend implementation, existed within a single GitHub repository with minimal deployment automation. Subsets of the user interface were bundled separately and deployed to S3 buckets, which the main application would serve upon users navigating to the relevant routes.
The Keyhole Consultant then followed up with FINSYNC, asking a series of probing questions to ensure the full scope of the project was understood. The following list includes some of the determined requirements.
- Incremental migration away from a legacy monolithic architecture to microservices
- Migration from Ember.JS to a React front-end implementation
- Recommendations for architectural elements in the new stack including deployment platforms, development tooling, and code organization
- Review of current automation setups and recommendations for improvement and expansion
- Recommendations to achieve a unified set of UI components to be shared across front end projects, asynchronous fault-tolerant consumption of third-party services, and version management of artifacts from individual business units
Once the requirements had been discussed at length and agreed upon, the Keyhole Consultant was granted access to FINSYNC’s project repositories and the project proceeded to the next phase.
Project Exploration
After gathering initial requirements, the Keyhole Consultant began investigating the current implementation to find conceptual boundaries for the prioritized migration targets. For each migration target, they located its related scope and devised ways to break it apart into an independently deployable service, identifying common functionality that would need to be shared across new and legacy implementations.
During this phase, they paid particular attention to FINSYNC’s current HTTP routing implementations and their user session logic to make this migration as passive as possible for existing users.
POC Projects
As we explored the project and began compiling a set of recommendations, the Keyhole Consultant began creating proof-of-concept projects to validate their ideas.
One POC project surrounded code organization strategies for the UI. After discussion and testing, they settled on a monorepo setup using Turborepo, allowing for business units to contribute their own individual React projects while allowing for shared peer dependencies
- They also introduced a shared UI library using Storybook, providing a set of common components as a single “source of truth” with its own interactive deployment dashboard for experimentation.
- A second POC was the Ember-React project. The idea was to integrate React into the existing Ember.JS projects as a short-term solution for interfacing between the legacy app and projects currently being moved over.
- A third POC project functioned to recommend stack IaC, a Terraform repository used for validating architectural recommendations of migrated AWS platform. It includes the following components ECS cluster and services (using Fargate provisioning), VPC, API Gateway (with Okta custom authorizer configuration), S3 bucket, and CloudFront distribution.
SOW Creation
Upon completion of project exploration and validation of our recommendations, we compiled the information into a unified Statement of Work document. This document was structured into the following main sections:
- Recommendations: A set of stack suggestions for the client’s application after migration, complete with diagrams for architecture and code organization.
- Migration Plan: A high-level breakdown of the individual work items anticipated as progress is made toward the migrated state. Items were separated between those necessary to migrate to the new stack versus those recommended but not required.
- Statement of Work: A traditional Statement of Work proposal detailing efforts to be accomplished within this phase of the migration, including estimates in implementation time as well as an estimated cost breakdown for new services to be provisioned.
Delivery and Future Project Work
After the delivery of the SOW document mentioned above, we held an additional meeting with the client to review the document as a whole, as well as discuss the particular decisions made regarding technical recommendations and scoping of the proposed work. A communication channel was kept open with the client to discuss any outstanding questions or concerns leading up to approval or revisions to the document.
