How this startup connected microservices in 15 minutes via elastic.io

Kevin Mobbs integration best practices

communication between microservices

We interviewed one of our platform users Dan Bruce, CTO and co-founder of mobile FinTech startup Albert about how they established communication between microservices within 15 minutes.

Albert helps freelancers create invoices as easily and as quickly as possible, all for free. “Invoicing is now as easy as email.”

What problem did you have that you wanted to solve with elastic.io?

Sure. I guess I’ll start with what our platform is. We’re building an online accountancy/ bookkeeping platform. We were frustrated with our experiences using other services such as Sage, Xero and FreeAgent, and wanted a product that was easy and familiar to us. That’s why we founded Albert where we model invoices on an email inbox.

We on-boarded our first users over the past few months with a monolithic server application that was built quickly to support what we considered our minimal desirable product. The goal was to develop something rapidly and prove people liked Albert, not build something extensible that would be able to handle all the ideas/problems that keep us up at night.

We received some great feedback and took this as a sign that we should grow Albert’s features and user base quickly, so we decided to move over to a microservices architecture that would be extensible.

We wanted to use RabbitMQ for the communication between microservices for its bulk message handling and fault tolerance. However, we also didn’t want to develop any software that wasn’t solving our core business problem. So, we looked around, came across elastic.io and it seemed to fit absolutely everything we needed to talk from one server to another server. It literally took us 15 minutes to build this integration.

Can you tell more about how you set up the integrations and what the exact steps were?

The first thing we did was break down our monolithic server application into microservices. Then we took the Webhooks from elastic.io and used them to communicate between those services. So, one microservice posts to an elastic.io Webhook, then the Webhook publishes it onto a RabbitMQ Queue and after that calls onto our next service.

The massive benefit of this is that if our receiving webservice fails for any reason, we can produce an error response code and then elastic.io shows us exactly what operations fail. Having the dashboard that shows us what has failed and what hasn’t would also allow us to retry those failed operations in the future.

So basically, you’ve connected a Webhook to a Webhook for now?

We did. We are using Webhooks at the moment, but we are also looking at the component templates you offer. There are a few among them that we would like to use, Dropbox is definitely one we are considering and when the time is right we would also like other services to be able to integrate with us through an elastic.io component too.

Did you find it difficult to write those component templates for elastic.io?

Most of what we did was effectively drag and drop using the webhook components. Having said that, I did make a few test microservices using the provided source code. It took me 45 minutes to an hour to build two custom components and to get them talking to each other.

Want to try it out yourself?


Request Demo

So, you mentioned before it had taken you 15 minutes to build communication between microservices?

Yes, for example, our REST API creates an invoice. It will then pass it on to a PDF server that generates a PDF. The latter will then be passed on to an email server and finally to a Dropbox server. The first thing we did was develop those 4 services. Because they were very focused, it didn’t take us very long to do. Wiring them then up with elastic.io was simply a 15-minute task of dragging and dropping webhooks to point from one service to another.

Which part of elastic.io provided you with the most value?

Since we are a startup, the biggest is avoiding writing software that doesn’t solve our business use case. Elastic.io can handle a lot of our communication infrastructure, while we can concentrate on solving our business problems. That coupled with the super-easy fault reporting system allows us to manage our service with an incredibly lean resource set. It saves a ridiculous amount of time and a lot of costs in both development and management. We probably would have needed to hire another developer to build up the infrastructure that holds our microservices together whilst we were building and expanding those core services.

Is that the reason you decided against integrating it completely on your own?

Yes, it is one of the reasons. Like I said, we are small and don’t have time for solving problems that are not our own problems. So, when we found elastic.io with a very reasonable pricing structure, it was a no-brainer to me. It saves a lot of time and money.

So, what are your plans with elastic.io?

Our first plan starting next week is to move our whole staging environment over to elastic.io and start running our app tests against it to make sure everything is working as we expect. Then we can tweak it and get it right, and then we bring our live environment over into it.

A question that we get very often is: How do you set up complex integrations with a simple data mapper? Did that work for you?

It worked perfectly. In fact, that was another huge benefit, again, because we are trying to move quite fast. If, for example, one of our microservices changes its interface, we usually then have to change the calling service and call the interface differently. Using elastic.io we can just change how the data is being mapped in the middle. So it helps us avoiding writing software. The flows are easy, because basically, you just paste your JSON in and then drag and drop the keys you want to send over. It’s that simple.

Would you recommend elastic.io to other developers?

I already have been doing! Any business that needs to connect services together and scale their product’s features should be considering elastic.io. The flexibility it provides will save a huge amount of time developing/debugging/tweaking communication infrastructures.

More about Dan’s experience or if you’d like to try the Albert app:
Visit www.getalbert.com

Want to try it out yourself?


Request Demo


About the Author
Avatar für Kevin Mobbs

Kevin Mobbs

Kevin has a background in Molecular Microbiology research and technological product development. Following a brief academic research career Kevin first experienced product development with the succesful startup Genera Technologies. This was then followed by seven-year’s experience as a Product Manager with QIAGEN and Lonza in the biotech devices industry, over 5 years successful innovation consulting for crowd-sourcing SaaS pioneers InnoCentive as well as the world’s largest re-insurer, Munich RE. Kevin is an advocate of design thinking methods and enabling ‘dumb questions ‘ to be asked and answered. ‘If something cannot be made fun, then it may not be worth doing!’


You might want to check out also these posts