In the previous blogs in this series, you read about why the new architecture is a good thing. But what are its benefits for you? Are there any new features which make your TOPdesk experience better? Luckily, there is enough to write a whole new blogpost about, so let’s see what’s in it for you!
Marketplace of services
You most likely don't use every feature offered in TOPdesk. No one really does. You currently have licenses that unlock parts of TOPdesk that contain the features you need. You only get to choose functionalities on a macro scale. In the future, you will be able to download, activate and separately update features via a built-in marketplace. This way you only pay for what you actually use. Your TOPdesk is suited exactly to your needs!
Multiple TOPdesks in one cloud
The new service-oriented architecture will also allow new features that otherwise would not be possible. The fact that all TOPdesks operate in the same cloud opens doors for us to find new and easier solutions for making them communicate amongst each other.
APIs, APIs, APIs, APIs
We are working (together with the service-oriented architecture) towards a situation where APIs are first-class citizens. We could have done it without services, but they are a catalyst to this as well.With more APIs, we can integrate TOPdesk with more third party solutions and (custom) integrations with other tools.
On SaaS, powerful systems are working in the heart of the new architecture. These systems provide a very nice feature: load balancing. If you and your colleagues are using a specific service, the system detects that load and another instance of this service is spawned. This way, large workloads are balanced much better. You no longer influence each other while working in the same TOPdesk at the same time.
For example: currently, if you are working and TOPdesk and a colleague runs a heavy report, you will notice TOPdesk runs slower. This won’t be the case anymore.
Since any given microservice can have multiple instances, the system handles problems more smoothly than ever before. If a service goes down, another instance takes over automatically. Microservices run in isolation, so a failure of one service won't affect the others.
With the new architecture, we can also do stealth updates. We can deploy a new microservice and switch to it whenever it is correctly deployed.
So this setup will help increase uptime because a failure will not result in a disruption and we don't need to pause our microservices for an update.
The benefits listed above are what we can think of at the moment. If we will be facing new requirements, we will have a wider range of possibilities to tackle problems with this new setup.
Interested how it all works? In the upcoming post we will go into more details what the new architecture looks like under the hood.