Before we take a look at today’s challenges, it helps to first see what big changes happened in our market, and how TOPdesk responded. Read on to see the major changes we've made throughout the years.
Below you can see the milestones of our product’s history. These steps are all reactions (or in some cases pre-emptive actions) to the demands of actual times. They were all expensive, time-consuming and risky changes. These changes needed to be made, otherwise the software would have become outdated really fast.
Present and future
All our previous architectures had something in common: every single module was coded in a single huge codebase. Our current codebase found its origin in the web application first released in 2001. It has been growing ever since. As a result, our codebase is gigantic.
Because of the size, we are becoming slower and slower when it comes to adding new features to our product. And more often, our good choices made in the past are holding us back in making the good choices today. So we need to zoom out and innovate, instead of keeping up with maintenance only.
In order to tackle these problems, we started to look into different solutions. Eventually we chose the path of having a new type of code architecture: Microservices. This type of architecture separates responsibilities and ensures these components function autonomously. Curious about what Microservices are? Read this article. In an upcoming post, we will explain in detail how we are implementing it.
But this path towards our goal is a massive amount of work. It requires a lot of research, configuration and development. At the moment, the basic fundamentals of a healthy architecture for services are set. A newly finished project - a new cooler version of the Audit Trail - has been put into production within this new architecture. We started it as an experiment and only released it internally to see how it works (since we are also happy TOPdesk users ourselves). So far it does the job really well, so we also started rolling it out slowly to other customers.
In case you are wondering, switching to the Microservices Architecture does not mean that we are going to rewrite everything. Only newly written modules will be implemented as services. Older things (Call Management for instance) will remain in the Big Old Codebase. The old codebase will function as a very big microservice in this new setup, but it’s not going to be that much different from all the other brand new services. Although for a while, this part will store a lot of data that is needed for other services.
At this point, it’s also important to mention that currently the new architecture is only available on SaaS. We are about to start a project to enable this fo On-Premises too.
In the next post, I will explain what other benefits you get from the new architecture, besides receiving new features quicker. So keep an eye out for the next post!