Dirty Old Code — Part Three
The third and final chapter of a series about how the Precogs team moved infrastructure and code from monolithic Ruby on Rails to a serverless environment.
You can read ‘Dirty Old Code: Part Two” here and if you’re really late to the party and missed Part One, you can read that here.
I’m going to make a good sharp axe
— Ewan MacColl (Dirty Old Town)
In Part Two of this series, I explained the general idea of how we decided to move from Ruby On Rails (ROR) infrastructure to a full microservice and serverless infrastructure. As I explained, we chose to move to AWS and connect the new infrastructure with the previous through SNS notifications.
I want to share the example of the mailing service, which we moved a few months ago. First, to fully understand the thinking behind this you need some more context about Precogs’ business model. Part of our business is to find better prices on available electronic components for our customers. The process is quite simple: by accessing the relevant data, we are able to identify customer component needs, and if we can match that need to a better price through our data sources and suppliers than they currently pay, then we push a new order to their system.
Customers have the right to confirm or dismiss the order. In the case where they confirm it, we send an email to the supplier of the better priced item so that the order can be processed. Here is a schematic of the decision making involved:
How did it work with ROR?
At the beginning, ROR was at the centre of all our processes. One of the first services which we moved to serverless was the file handling, moving from FTP to S3, with a Lambda function automatically triggered after each upload. Even after this move, we kept the ROR routine to check new confirmed orders and send mails through a Gmail SMTP service. You can see this in the schematic above and that’s the part I want to talk about here!
Building an email service — ROR and AWS working together
The first move was to build a new way to send email, while switching from Gmail to AWS services. We built a “send an email” service on AWS based on Lambda and SES, triggered by SNS. Nevertheless, as we didn’t want to make too many changes at the same time (who knows what could happen when updating dirty old code?), the SNS notification was first pushed by ROR.
So at this point, email was being sent through AWS but ROR was still in charge, monitoring newly confirmed orders and triggering new emails.
Fully managing service through AWS
After running this process for a few weeks, we were able to confirm all was working OK and then could finally remove all related parts from ROR.
Instead of having a routine to check newly confirmed orders, we’re now triggering emails as soon as an order is confirmed thanks to the Lambda function processing the confirmed order.
Using SNS to trigger the email in the first place is a huge advantage and a big reason why we decided to remove ROR. The only thing we had to do was “unplug” ROR and “plug” in Lambda to take charge of confirmed orders!
Time to experience it for yourself
There we are, in three simple parts that even your mother or father will be able to follow, our explanation of moving legacy ‘dirty old code’ to a brand new serverless infrastructure.
I hope it gives you some idea of how to go about it, what you need to think about and why!
Pssssstttt! Hey you! Yes, you! You can find a repo here based on Serverless Framework with Lambda triggered by SNS which sends an email through SES. Happy migrating :)
