Technical FAQs
Where we came from
In July 2015, Accusoft’s SaaS Applications team was tasked with integrating the recently acquired edocr application with our existing Prizm Share community for publishing and sharing documents. While this integration offers numerous challenges with data migration, feature parity, and cohesive branding, we are going to focus on the architectural changes that resulted from the project.
Both projects were initially built as LAMP applications—edocr on Drupal 5 and Prizm Share being built in-house by a fledgling apps development team. Throughout their independent evolutions, they each had the expected increase in features and correlated increase in code base size and technical debt. The decision to merge the two products under a single brand and code base meant choosing a target platform.
Initially, we considered two options:
Migrate Prizm Share data to the existing edocr platform
With edocr being the dominant service for traffic between the two, it made more sense to merge on that base when looked at from a customer-centric perspective. However, edocr was running on a very dated Drupal 5 and in need of an approach that could be supported well into the future. Along these lines, we also considered adopting the Drupal platform and then going through the upgrade process from 5 to the current release, 8. Tests of these upgrades did not have good results, however, as numerous plugins and custom modules in edocr were not available or supported in the latest version.
Migrate edocr data to the existing Prizm Share platform
With the edocr application being based on the very outdated Drupal 5 platform, the primary contender was to move the application to our existing PHP Prizm Share code base and extend the features that we didn’t currently support in order to serve the existing customers of both products. The problem with this was that the code for Prizm Share was already starting to show signs of rigidity based on a lack of foresight on the initial architecture decisions. New features were increasingly difficult to work in with the existing framework and the team had been looking to move to something more modular.
Our Decision
What the team eventually decided on, however, was a complete overhaul of the whole system, targeting the existing feature sets of both products along with a specific list of MVP requirements for our new consumer document platform.
To ensure flexibility in the future and to keep a positive connotation on the word legacy, we decided to adopt a microservice architecture built on a lightweight application framework we developed in Node. This would handle configuration and dependency management for each of our services. By separating out our functionality into independently managed components and updating our build and deployment system to deploy as docker containers, the team was able to reduce friction with code changes, improve code testability, and drastically reduce the time from commit to production.
Read on in the coming weeks for details on our migration, including failures, successes, and lessons learned.