By Andy Hails, Senior Software Engineer, SAGE Publishing

You know the problem, you’ve arrived at the company meeting, and you’re looking for someone, anyone, in your team with whom you can sit. You looked out at a sea of people, all of whom you’ve seen around the office but none of which you know their name. If you’re anything like me, you sit down awkwardly on your own for the next hour hoping to bump into someone you know on the way out. The meeting ends and had you realized that the person next to you shares your passion for Extreme ironing (yes it’s a thing, yes I’m fantastic at it.) you would have felt very differently.

This is a familiar story in a lot of medium/large businesses, and it can be a problem when trying to encourage a friendly and open culture within the workplace.

What did we experiment with?

At SAGE, we recently heard about an approach to help alleviate this problem and wondered how easy it would be to implement it ourselves. ‘Operation Coffee Connector’ (Working title, no judgement please) is a scheme in which employees sign up, and each month they receive an email which encourages them to go for a coffee with someone in the company.

The idea was born out of one of our regular ‘Team Timeouts’, and we wondered how difficult it would be to build it. Before we started we decided on a few goals:

• Goal #1: Minimal code for maintenance - we didn't want this to be a project which will distract us from other projects.

• Goal #2: Minimal costs - we didn't have a budget and wanted to try it before moving it into production.

• Goal #3 (unofficial): Please our IT team by using Microsoft products.

How did we do it?

Firstly, we decided to break down the problem. There were two main components to the app:

1.      Sign up

2.      Creating new connections

The sign-up part was straightforward – it’s a web form which gets saved to a Database. In our case, we used Microsoft Forms which saved responses to Sharepoint list (this allowed us to access the answers in more easily when it came to creating new connections.). This part required no custom code and took all of 20 mins to set up. Things were going well!

Part 2, was a little tricky, we needed to schedule creating new connections based on signups and also based on their previous meetups – we didn’t want to keep connecting the same people! Then lastly, we needed to notify them.

It soon became clear that we needed both custom code and infrastructure to calculate new connections and then store those connections into a database. However, we still had our goal of ‘minimal code and minimal cost’. Plus, the app only needed to run once a month for a few seconds; there was no need for 24/7 hosting.

Introducing Serverless

We realised this was a perfect use case for serverless functions. Like in Maths, these functions take arguments in and output a result. In our case, we would feed sign-ups in, and the function outputs new connections.

Serverless Functions have the added benefit of being extremely cheap as you only pay for what you use. It works by using virtualised containers which are spun upon request and then disposed of immediately afterwards. This ‘just-in-time’ infrastructure is used for short intensive bursts of work which happen periodically (i.e. each hour, day, month etc…). As our app ran once a month for a few seconds, this was perfect. We decided to set up an Amazon Web Services (AWS) Lambda Function using NodeJS to create new connections. Next, we needed to store these connections. Since we were already using AWS for our Lambda Function, we also decided to use their NoSQL Database service called DynamoDB to save these connections even after the Lambda was gone. Integration between the two services is tried and tested with lots of documentation on how to do it with NodeJS.

Once we had written the algorithm (~ 100-150 lines of code) to calculate and save the connections, we still needed to solve how we were going to schedule sending the sign-ups to the Lamda and then also how we were going to notify them.

Introducing…..Everything Else

Microsoft Flow – it turned out that sending the sign-ups from the Sharepoint document was extremely easy if we used Microsoft Flow. We could set a schedule to trigger every month, and then some actions including extracting the sign-up items and sending them via an HTTP POST request to the Lambda Function.

Sendgrid – lastly, it was just a case of sending the email. We decided to use Sendgird – a third party service for sending emails. SendGrid allows us to send emails without needing to set-up an email server. With SendGrid, you get a lot of emails for free before you need to start paying. As it happens, SAGE has a SendGrid account anyway, so it made sense for us to use it. Integration with Sendgrid is straightforward as you send the details to an API endpoint and all the rest is taken care for you.

All together our workflow looked like this:

Challenges

• Asynchronous code does not behave well in Lambda! If an async operation happens, the Lambda thinks the code has finished and destroys the container before everything has finished running! We had to add in a few javascript async/await commands to stop this from happening

• AWS is excellent but can be a pain to setup especially when it comes to services talking to each other. We had to get very familiar with the Permission Roles policies to allow everything to work well together.

More ideas and what did we learn?

• Odd connections – Currently, an ‘odd’ number of people means one person will always miss out. Could we make a chatbot?

• Ex-employees – We need to remove signups who leave the company. It might be possible using MS flow. Let me know if it is!

• More in Flow – Since getting more familiar with MS Flow, I can see we could have done more within it. It would have been possible to store previous connections back into a Sharepoint/Excel sheet; this would mean even less code is needed. We could have also used Flow to send the user emails each month.