Recently, I was given the opportunity to help a growing small online business with some technical challenges.
After studying their business and technology environment, I realized the following:
- The organization carries many of its business operations utilizing a CRM (Customer Relationship Management) system.
- The end user product is delivered through an LMS (Learning Management System).
- Integrations between both of these systems are handled through a series of PHP Endpoints that are bundled in a WordPress plugin and hosted on a virtual private server.
The most apparent problems of this setup were:
- Requesting changes to the layer can be costly and time consuming.
- It is difficult to work with the integration layer because it is written in dated PHP code that most new programmers would have a hard time understanding.
- The layer is bundled up as a WordPress plugin that is written by a vendor. This makes it difficult for a developer to modify it, even if the developer knows how to work with the code.
- The layer is hosted on VPS with limited resources and through a WordPress website. This results in poor performance which leads to failed calls and ruptured integration processes. Additionally, the current codebase is not written in a defensive manner and provides no logging or crash reporting.
After learning the problem, I quickly realized that rewriting this integration layer would be a great candidate for a serverless solution. I am opting to utilize a Firebase solution. Here are some of the benefits:
- The business has limited IT resources, thus offloading the server maintenance to a platform like Firebase will help keep support costs in check.
- Server performance will no longer be an issue as Firebase can handle their volume load without a problem.
- The integration layer costs will come in at a fixed $25 for the Flame pricing plan. The free tier would work, but the integrations require outbound networking. Either way, it is a substantial savings from the current cost as the current layer is hosted and marked up by a vendor.
- The new integration layer will be built under accounts owned by the business, unlike the previous layer, which means that they will not suffer vendor "lock-in".
- Upgrading the integration layer will facilitate new integrations with other new systems that they're bringing in, such as new ticketing systems that expose APIs.
- Additionally, the new solution will feature source control, logging, crash reporting, and a clean code base.
- The implementation strategy I am pursuing is quite simple:
- Set up the Firebase project with 1 integration function
- Consume this integration through a new business process
- Once the model is proven, we can template the solution for future integration endpoints
- At this point, we can also test out integrations with other systems (i.e. the support ticketing system)
- Once everything is solid, begin the migration of the previous PHP endpoints to the new set up
Hope you enjoyed reading. I enjoyed writing :).