How We Discovered Microsevices Even Before We Knew They Existed

Kristijan Arsov
Microtica
Published in
3 min readMay 31, 2017
Exploring is in our genes

We can’t deny that in the past several years, the term ‘microservices’ has become widely used, if not over-used. But do we even know what they really are, how they were created, and what the main benefit from using them is? This emerging technology will reshape how software is built and delivered in the ‘era of the cloud’.

‘The concept of microservices is not new. Google Inc., Amazon.com Inc., and Facebook Inc. have been running microservices for over a decade. In fact, every time you search for a term on Google, it calls out to roughly 70 microservices before it returns your results.’ says Matt Miller in an article in The Wall Street Journal.

The team behind Microtica share their story on how they first discovered microservices before knowing they existed. Specifically, how they benefited from them while creating Dox Bee — the platform for document collaboration.

Microservices as kitchen appliances :)

THE CREATION OF DOX BEE — THE DOCUMENT COLLABORATION PLATFORM WITH NO HICCUPS

Roughly 4 years ago, still in the era of monolithic infrastructure, almost no one had used external services outside of the monolith. Today, these external services are known as microservices. We were also using monolithic infrastructure and everything was functioning perfectly up until the creation of Dox Bee.

To make it clearer, Dox Bee is a platform for online document collaboration that consists of multiple key functions, including editing and commenting, working in parallel, external collaboration. It also includes the main function — the ‘compare function’, i.e. fast and accurate comparison of multiple documents. Very brief description of how it works — The user uploads multiple documents to compare, the system identifies and highlights the differences and mistakes. Sounds easy, right? But what happens to the server when a heavier document is uploaded?

“At the time, we were using node.js to build all of our software in a monolithic architecture. Everything was working perfectly fine until we uploaded 700 pages for comparison on our monolith module.”

DoxBee Document Sharing

WHAT HAPPENED WHEN WE PUT 700 PAGES TO COMPARE ON A MONOLITH STRUCTURE IN NODE.JS?

With the testing of Dox Bee’s MVP, we had to make sure that our platform would be able to handle anything. To test our ‘compare function’, we uploaded 700 pages for comparison to the monolith. You can assume what happened during the 6-seconds-process. In those 6 seconds, everything got blocked, including our server. All the running applications in the background stopped working.

Well ok, you might say 6 seconds is not a long time, but imagine facing this problem over and over again, every time a user requires a ‘heavier’ function.

That’s when we decided to completely move the ‘‘compare function’’ to a different machine and outside of the monolith, so that when the job is scheduled, the monolith will function without hiccups and, at the same time, ‘all the heavy lifting’ will be left aside. This worked perfectly!

At that time, we named our innovation ‘the external service’.

IF THIS IS POSSIBLE THEN…WHAT IF?

So, imagine, if only one ‘external service’ had such a disruptive impact, then what if we created more external services which would function separately and individually? In the era of instant gratification, we are all chasing that one extra second.

The horizons and possibilities are wide open.

--

--

Kristijan Arsov
Microtica

Digital marketing samurai, in a world full of ninjas. Writing about life, marketing, and all things digital.