This week, we’ll hear about using Lambda along with Scala/Akka to back an information exchange for Bitcoin trading.

Cluda built the the TradersBit platform as a market for trading signals. A trading signal is a recommendation that it’s a good time to buy, sell, or short Bitcoin.

What TradersBit provides is a way for publishers of data to sell subscriptions to different signals, and for traders to buy subscriptions to improve their trading. The publisher of the signals gets 70% of the revenue, and Cluda gets a %30 share to cover hosting and other costs. Of course, you can pay for subscriptions in Bitcoin.

The Interview

Tell me a little about Cluda and the TradersBit project, how did you arrive in the business of brokering trading signals?

Cluda is located in Nesbyen, Norway. It was founded February 2015. Currently, the company has only one employee (me). I hope to have the opportunity to hire one or two more employees by the end of 2016.

Cluda was started to build TradersBit. I got the idea for TradersBit while working on my master’s thesis. For my thesis, I created and tested trading systems based on machine learning, specifically artificial neural networks. I tested the trading systems on the Bitcoin market. I used the Bitcoin market because I am interested in Bitcoin and because data is freely available. I did not have capital myself to use this trading system, so I started thinking about how it would be possible to sell the signals from my trading systems to people with the money to trade. I found out that there was no good solution for this. Since I needed it, I thought there were probably other people that needed it as well. So when I finished my thesis, I founded Cluda and started building TradersBit.

What parts of TradersBit are on Lambda? Is it something you consider small, or is it a key part of your user experience?

I would say maybe half of TradersBit is Lambda and half in more traditional microservices. Almost all new features are powered by Lambda, unless there are some specific requirements that needs it to be running constantly. I have found that maybe 80% of everything I am developing/have developed for TradersBit could soon run on Lambda.

In TradersBit, what are the time and latency constraints you have? For trading Bitcoin, I imagine there's a lot of sensitivity to latency, since trading too late might be bad for the trader.

The autotrader feature (which is in progress, so it’s not available to customers yet) will make it possible to execute trades on behalf of customers when new signals are published. For autotrader, there is a lot of emphasis on latency. Therefore, autotrader doesn’t run on Lambda (for now).

At this time we only provide signals by email to subscribers, so they manually need to execute trades themselves. Email isn’t the fastest medium for sending trading signals, so the latency constraints are not as high for this. I have measured, the normal time from when I send a signal to seeing it in my inbox is around 5-6 seconds. I think this is acceptable for email. However, the autotrader needs to be much faster.

When a signal comes in, how does it reach subscribers? A publisher would call a TradersBit API to send a signal, but what happens next?

Upon receiving a new signal, we save the signal together with the current Bitcoin price, etc., then we send the signal by email and at the same time, we calculate stats for the stream that received the signal.

Other than Lambda, what other technologies did you use? This includes frontend, mobile, databases, whatever you can share.

Because I am the only employee, one of my main emphases when selecting a technology to use is that it needs little or no maintenance and is as productive as possible.

I started out developing microservices with Scala, Akka, Docker to run on ElasticBeanstalk. Then I found AWS Lambda and started experimenting with it. First with Java, but this resulted in very large file sizes for each Lambda function. Also, it’s no fun to go back to Java after working with Scala. I also looked at using Scala for the Lambda functions, but this did not seem to be a popular use case and I’d rather not use my time on solving Scala/Lambda integration problems. Then I looked at Node, but I’m not a big fan of Javascript. Therefore, I started using Typescript for Lambda functions. This works great for me.

I quickly found that I had to have a framework to organize my Lambdas. So I started setting up my own system using gulp. Luckily for me, I saw the Serverless (at that time JAWS) presentation at Re:Invent 2015, I tried it out, and it was a great fit, so I switched to that.

The price of using such a new framework (Serverless) has been that I have had to do some heavy refactoring to adapt it to newer framework versions. I think this price is small compared to the ways the framework has helped me with things like organization and deployment. Also, the Serverless framework seems to introduce fewer breaking changes nowadays.

At the frontend, I use AngularJS with Typescript.

How large was the team on this project? Did any/all of them have experience with Lambda already, or were they coming from other areas of expertise?

Only me. I had no experience with Lambda before starting this project.

About how long did you spend developing the app? Was it any faster than if you were writing in another framework? (Express, Rails, whatever your "home turf" is)

I started a year ago. I wish I had known about Lambdas before I started. I think the process would be faster. After I started using Lambda, the development seems to go faster. Even though I had not used Typescript before beginning development on TradersBit.

How are you deploying the application?

I am using Serverless for deployment.

It is very nice to be able to deploy only a function at the time. This makes me deploy new functionality much more frequently than I would if I had to redeploy a whole service each time. I also have seen that in the next version of Serverless it will be very easy to go back to a previous version of a function if a new function breaks something.

Are you using a CI/CD service? How are you testing changes before they go to production? Do you have testing/staging environments?

I’m using CI/CD for the Scala/Akka microservices, but have not found (or had the time to find) a good solution for doing the same with Lambdas. So I test the lambdas locally, deploy them to staging, and if everything works I deploy to production.

Are you using Lambda primarily through API Gateway, or is it also used for backend operations like fanning out trading signals to your clients?

Lambdas in also used on the backend, for sending emails and some other things. Some of the triggers we use are SNS, DynamoDB Streams and Scheduled Events.

Are there any tools or libraries you found particularly helpful that you'd like more people to know about?

I would definitely recommend developing Lambdas with Typescript and the Serverless Framework.

Wrapping Up

Thanks again to Asgier for showing us what’s under the hood at Cluda, and if you’re interested in Bitcoin trading, check out their TradersBit product.

Keep up with future posts via RSS or subscribe to the mailing list. If you have suggestions, questions, or comments feel free to email me ryan@serverlesscode.com.

Tweet this, send to Hackernews, or post on Reddit