One company " discovered" microservices when a process broke their monolithic architecture, leading them to develop external services to speed up functionality.
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.
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, and external collaboration. It also includes the main function: the “compare function, ” i.e., fast and accurate comparison of multiple documents. Here’s a very brief description of how it works: the user uploads multiple documents to compare, and 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.
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 six-second process. In those six seconds, everything got blocked, including our server. All the running applications in the background stopped working.
Well, okay, you might say six 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 outside of the monolith, so that when the job was scheduled, the monolith would 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.”
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.
