Nitro is changing the way the world works with documents. From the desktop to the cloud, the company’s solutions make it easy to create, edit, share, sign and collaborate—online or offline. Learn more at: https://www.gonitro.com
When Tihomir Bajic joined Nitro in 2011 as VP of Product Engineering, the company was embarking on its vision to build Nitro Cloud, and his responsibility was to evolve its popular software for document productivity and workflows from desktop-only to a SaaS distribution model.
Nitro’s migration to the cloud was no small challenge - the company already had millions of users and a massive code base of C++ for desktop apps for document processing and workflows. Nitro’s desktop products were supported by .NET web services running in a public cloud. At the time, it was uncertain exactly what Nitro Cloud would look like as a product platform, but Bajic understood that what was most important was that platform decisions could support the journey from proof of concept, to prototyping and beyond. Along the way, Lightbend technologies enabled Nitro’s journey to Reactive.
Prior to joining Nitro, Bajic had seen Play Framework being used by a friend to bootstrap a production-ready application in only a couple of weeks. That startup, AppHero, was an Apple Store recommendation engine based on social and user preferences (acquired in 2013 by mobile app publishing firm Fuse Powered). In addition, through sponsoring a Play Framework hackathon in December 2011, he became convinced it was a framework others could pick up over a single weekend.
Based on his exposure to using Play for rapid prototyping, Bajic selected the framework in late 2011 as a development framework. Initially his team used Java Play 1.2 hosted on Heroku, and Git Push Remote for code deployment - for what he called “a very cheap but effective version of continuous integration.” Nitro found it exceptionally easy to write code with Play and show working versions to internal and external users - and the process of iterating on his product went very smoothly.
As Bajic and his team got further along in the migration from desktop to cloud, the team recognized how unpredictable and compute intense their users’ document management jobs could be. Sometimes doing something as simple as converting a 1-page resume from PDF to Word - depending on the doc structure - can require a great deal of computation. Even knowing the size of the file or number of pages in advance, it was impossible to predict how long certain operations would take in the cloud.
Bajic realized that the team needed to build an asynchronous platform for document processing, and opted for a combination of Akka and RabbitMQ. Nitro adopted Akka because they liked the Actor model, and Akka’s message-driven architecture.
In the process of leveraging Akka Actors to achieve asynchronicity in the cloud, Nitro saw an opportunity to stop using Heroku/AWS (no longer scaling compute cost efficiently) and build its own co-located document processing platform. Nitro Cloud’s vision became more ambitious as the company moved towards customized networking, hardware and middleware to handle compute-intensive document processing, where Heroku still handled the web application layer, but all of the heavy lifting in document processing was occurring on the new Akka platform running in a collocated data center.
On Nitro Cloud, documents are atomic objects, and Actors can exact actions on those documents - such as changing their state or forwarding their revisions. Everything is designed to be highly asynchronous and message-driven. And despite all of the many transformations that can be imparted on the documents themselves, the relationships between the Actors and the documents are simple and scalable, and any failure is properly isolated and easy to manage.
As Nitro continued its push towards the cloud, and continued to deconstruct its monolithic C++ applications into cloud services, the company also started to take a hard look at existing assets running on .Net. A number of Nitro’s customer facing web services, its corporate web site, and a giant master record database were running in a sprawling .Net monolith.
The .Net platform was proving unscalable, due to the size of the code base (already six years old) and how difficult it was to release to production. It was a blocker to hiring developer talent - on such a large code base on .Net, just compiling and seeing changes locally took a long time, and amounted for a “huge turn off” according to Bajic.
As Nitro moved towards a “web services first” attitude, it aggressively replaced .Net with Play, to increase its development cycles and release velocity. In just over a year (by start of 2013), Nitro was off of .Net completely.
Nitro has continued to scale, and continued to add new applications on top of its Cloud platform. The company’s first app was Nitro Cloud. Account management portals and Salesforce integration came next, and along with it the requirement for a centralized Nitro platform. As more applications have been built on top of the Nitro platform, complexity has increased.
In late 2013, Bajic and his team were focused on how they were going to go “10x” - how they were going to completely eliminate perceived downtime, increase responsiveness for true web scale document processing and continue to evolve. Ultimately the goal for Nitro is for the platform to be available to third party developers to build smart document workflows on top of its platform, so this continuous performance evolution is key to the business strategy.
Right around the time we were pondering these questions, we came across the Reactive Manifesto,” said Bajic. “And it was like someone was telling us exactly what we’d gone through over the last two years - importance of being message-driven. How responsiveness is the number one customer expectation. Need to make your product more elastic. It all resonated very highly for us."
Shortly after, Nitro adopted Scala (it had been running Play on Java previously). The company has favored Scala’s strengths with asynchronous business logic, its expressional simplicity, its ability to help them structure and compose their code functionally in pieces that are easy to reason on their own.
Read the published article.
Inspired by this story? Contact us to learn more about what Lightbend can do for your organization.