Turning off the LAMP, part one
This is the first part of our two-year journey starting from a monolithic in-house dog food ERP, written in PHP 5 to running our platform completely serverless in AWS.
In early 2017 I joined the Reseller Gateway shortly after the founders had realized that the codebase really wasn’t shipshape. Soon, to be frank, I found out that this was bit of an understatement. The codebase was a mess. Not only was it a mess, but it was an outdated mess without documentation and with no tests whatsoever.
On the plus side, we had a working platform with a somewhat reasonable REST API that worked as advertised. The bad news was that it was running on a single virtual machine that was capable of serving approximately one request per second. The worse news was that it was running PHP5.
The worst news was that the MySQL database had well over a hundred tables and the data was duplicated all over the place and used seemingly randomly by various part of the code that instead of saying it was unnormalized, I’d rather say that it was in the minus seventh unnormalized form.
Given that the task at hand was daunting, we did what any (in)sane engineer does in such a situation: decided to rewrite everything from scratch. We soon realized that since we had no documentation, no specification and only the API was documented, this could prove a bit of a challenge. So naturally we went for the next thing you always try; pick the low hanging fruit and hope that somehow at least part of it will start making sense.
A few days later we had successfully performed an SQL-ectomy on the patient and the databases were running in RDS while the other parts of the stack were in m4.large instances, now effectively being only the L, A, and P of the stack. The code- and databases still were the messes they were, but at least now they were two distinctly separate messes on separate computers – and we had automatic database backups.
Now that our API - and the server side rendered web shops – were in a real cloud, we could start planning the decentralization of the platform and start bringing the tech stack to the 21st century.
Since the vision was to implement everything as microservices we first needed to enable ourselves to do that. It was surprisingly simple: create a CloudFront distribution that has its default origin and behavior pointing to the EC instance mentioned earlier and change the API’s CNAME to point there - and everything worked just as it did before.
Now we at least theoretically could route our API calls based on the paths to wherever we implemented a service. As said, this was still a theoretical possibility, in the strict meaning of the word, since in practice the only API implementation still was the monolithic PHP/yii 1.1 application. However as a bonus we now got some caching for GETs and our TSL certificates automatically and for practically free from AWS Certificate Manager.
While at it, we also synced the PHP servers’ uploads folders to S3, changed some URLs in the database and added some CloudFront caching in front of the server side rendered pages because why not - we were still picking the low-hanging fruit here...