About a year into my tenure at Focus camera, a request was made from upper management to implement a unified system for email signatures. This is quite a standard thing at a large company. We analyzed a few options and looked around, but I wasn’t satisfied with any of them.
I started a project on my own to implement a signature system using Microsoft’s Office365 add-in system. Thanks to Microsoft’s well-designed architecture, I was able to get a lot accomplished in very little time. Take a look here if you’re curious. Email signatures using this system turned out to be something well-supported, as you’d expect from a business-centric company like Microsoft.
The Journey
In any case, this add-in developed initially as a side project of mine. Digging through the docs, I managed to put together a manifest file. Manifest files in Office365 add-ins are the foundation upon which all add-ins are built. They define all required resources, as well as a list of authorized domains, among other things fundamental to the add-in. Beyond that, there are many required JavaScript and HTML files that are required as a part of even the most basic of add-in.
Once I figured out all the details, the next step was: how do I get the signature to Microsoft, to display in Outlook? There are many answers to this, and the project has gone through many iterations, but initially my solution was Python. Now, I will say that I did not code it very well initially. Version 1.0 of any project is rarely something you want to put on your resume. Indeed, my project was no different. Version 1.0, written in slow Python, was hosted on an EC2 instance, and relied on a VPN to pull data from an on-premise database. The entire architecture stank.
The First Cleanup
So, this architecture wasn’t going to work, as you can no doubt imagine. It was something I threw together quickly, but quite clearly needed some work. The majority of the cleanup took the form of removing the reliance on a VPN connection. This should seem obvious, but sometimes I like to experiment with complex architectures just as a sort of proof of concept. Removing the reliance on a VPN was certainly preferable, and probably should have been my first thought. This new design made API calls directly to the various services that the system needed to function, and relied heavily on memcached to reduce the frequency of those calls.
This was an improvement, but the obvious issue to anyone who has designed cloud architecture is that this reliance on an EC2 instance meant that a lot of cost had to be incurred for running this instance even when no signature was requested by anyone. This encouraged me to come up with a better architecture that resolved this issue.
The Second Cleanup
Realizing that the first cleanup, though an improvement, wasn’t completely optimized, I decided to attempt a second cleanup. At this point I had gained tremendous experience with AWS, and was well into studying for my AWS Solutions Architect certification. This knowledge was key to producing the architecture I settled upon.
First off, let me fully describe the system’s design.
The Design
The first step is the manifest file, the entrypoint of the program, as described above. The second part is a combination of HTML and JavaScript that define a series of events and dependencies that allow Office365 to do what it needs to do.
For this project, I kept the JavaScript very simple. I wanted to move the code out of JavaScript into a more normal language (sorry devs, I hate JavaScript 🙁 )
The third part is the “normal” language, but here’s where I did something neat. I used server-side Swift. Why? The answer requires some background. Entering the world of software development through my interest in Apple devices, I was fascinated with how they work, and how the intuitive and fluid interfaces that Apple is known for work under the hood. I spent many years experimenting with things such as AppleScript, moving into Objective-C, and from there to Swift. Swift is an excellent language, and borrows heavily from C#. I must admit I’ve grown rather fond of the language.
The next question must be: How is it hosted? Well, as we know it used to be on an EC2 instance. The solution for the issues with that architecture, as anyone certified with AWS can tell you, is a Lambda. Lambdas are a great way to have short-running, low-resource code run in AWS in as cheap a way as possible. It just sits there until someone needs it, costing basically nothing in the interim (although production-grade infrastructure associated with it will have some cost even during idle periods). I use a docker container to upload my code to the lambda, and from there it does its thing seamlessly.
This was a much better architecture from my previous design, and is what’s being used to this day, except for one thing.
The Final Design
This architecture was mostly perfect, but there was one problem. As it turns out, I had been uploading the config for the Lambda with the docker container. This clearly was not ideal. It meant that even the smallest changes required a complete re-upload of the container into ECR (Elastic Container Registry). This mostly worked for me, but I wanted to design the system in such a way so that someone besides myself could manage the basics of updating signatures.
The final piece of the puzzle, and is where the signature is at today is implementing Parameter Store. Parameter Store is a great way to store a collection of parameters to be used in the runtime of an application. It can be stored securely, and is easy to use. Using this I was able to grant access to my colleagues to be able to manage the system I had put in place. I defined each config option as a parameter. I relied on paths (as is recommended) to make it easy to use AWS’s APIs to retrieve the data in a structured way.
Conclusion
It was quite a journey, but I ended with a fully-functional easy to use email signature system. It pulls from Office365 for most of its data, and the phone system for the rest. It’s cheap, efficient, and a great example of trial and error, and I hope my tale enlightens others. The only advice I’d give is to never give up until it’s perfect. A beautiful architecture is something that should be celebrated. Put it on your resume. Look at it. Just appreciate its existence, and let it motivate you to do it again.