Nuxeo Technical Vision, From the Beginning
In times of uncertainty, it’s always good to look back and think about what’s important. So I wanted to take this time to talk to you about how and why the Nuxeo Platform was created. I will publish a series of blogs to talk about: what we wanted to be, why we think differently, and how we envision the future.
But for today, let’s focus on our start as a company. What pushed us to do what we do today?
Nuxeo in 2006 — The Starting Point
From day one, we considered open source as the best approach to develop applications for our customers. Not only can you leverage the community and the components they’ve built, but you can also improve your software based on real-life use cases, and share code to find the best designs. Our initial framework, called CPS, was written in Python, on top of the Zope application server. This can sound like old technology today (and it actually is), however, at the time, this technical stack was advanced in many aspects: modular architecture, REST objects publisher, and integrated infrastructure.
Back in 2006, these technology choices allowed us to deliver customized projects with a much lower implementation time. We were already gaining momentum with quickly delivered projects. However, as we got more customers, as the technology landscape changed and as enterprise content kept growing exponentially, we started to face some new challenges.
Scalability was a Critical Challenge
The price of success is that you start having to address bigger projects: more users, more documents to store, more complex content types, and searches.
So, even if our infrastructure at the time was innovative in several aspects, we were quickly facing pure low-level scalability issues when trying to handle a few hundred thousand documents:
- the object database became inoperable
- the index system collapsed
Having more users and handling a high throughput was also creating challenges:
- data consistency issues
- Python concurrency issues (GIL)
As a result, scalability was our number one priority. We were working hard and digging deep inside the technical layers to build innovative custom solutions for our customers. But it became exhausting and frustrating for the team to spend so much time on infrastructure instead of building exciting new content management features. We needed to change something.
Corporate IT Acceptance Factor
Addressing bigger projects also implied working with more mature IT departments. At the time, IT departments were very aware of Java ), .NET or even Cobol.
On the contrary, Zope and Python were clearly not part of their world. I remember having to put together a slidedeck to explain that “Python is not (only) a snake” and that Zope was not the name of a superhero.
Operation teams were expecting WebSphere running with DB2, and we were offering Zope with an Object database: it was not easy to get them to feel comfortable with that idea.
As a result, convincing and reassuring IT about the technology and the operability was becoming a full-time job. Our goal was something else: we would have rather spent time and effort working on their business problems rather than calming IT fears.
So, this was our context in 2006, and how we initially decided to create Nuxeo. Even though we were quite successful with our technology, even though our customer base was growing up, we knew it was time for a big change. It was time to face organizations with growing content pains, with technologies evolving really fast. In my next blog, I will explain how we decided to fully re-platform Nuxeo in order to meet these new requirements from our customers. A scary, but necessary change in our history.
Originally published at https://www.nuxeo.com on May 26, 2020.
