The cloud journey of Duuoo
By Chris Raphael Mora-Jensen, CTO at Duuoo
Sometimes you make a decision and sometimes the decision is made for you.
As I joined Duuoo back in 2019, one of my first challenges was to gain an understanding of the platform our service was built upon. I came from positions where I had used both AWS and good old fashioned datacenters. The kind of datacenters where you buy a physical server, which you will install into a rack. But Duuoo was using something I hadn’t used before. Duuoo was originally built using Heroku. By using Heroku we reduced the need for configuration of our infrastructure, it made it much simpler for us. We were therefore able to quickly spin up the needed resources and we could even have several versions running while creating the prototype of our service, with very little effort.
In 2019 we had our standard platform and we had a client specific platform running on several sets of Heroku Dynos. But we grew, and at some point not long after I joined, we recognised we would eventually need to move out of Heroku. Despite the ease of use, Heroku comes with some restrictions, so we needed to evolve out of it.
Decisions made and remade
We had two environments to maintain, one was our standard platform, and the other was a client specific platform only catering one client. The client specific platform was in many ways already far more complicated than our standard platform, so the choice was easy. We set the standard service in maintenance mode, used a digital forklift and moved the standard out of Heroku. Back online.. Pop the champagne... Duuoo standard platform was now running on AWS directly rather than on another service on top of AWS, and we could now take full advantage of all offerings made available through AWS.
This was early in 2020, we now had our standard platform running on AWS, while a client specific platform was still running on Heroku.
But... the celebrations were short.. Not because it became too complicated for us with the AWS cloud, not because it didn't work, not because of any technical reason... no, as with all problems an engineer or programmer can face.. all reasons point to sales
Just as we were getting used to our new infrastructure and starting to take advantage of the offerings available, sales struck.
While, we in the tech department were optimising and streamlining our platform, sales just had to start talking to clients who had a different view on platforms and cloud providers.
Oh yes, six month after our move to AWS, it became clear, AWS was a no go. And since it wasn't just one new client, but in reality it was also a point of critique from an existing client and a set of potential new clients, we were pointed towards Azure.
Of the cloud providers they could accept, the Microsoft operated Azure cloud platform was the one they would accept. So once more, we had to move our service.
Luckily the cost of switching wasn't high since we could utilise the free tier available on Azure for preparations, and with careful planning, experience from moving to AWS and a few steep learnings on this new cloud provider (new for us anyway), we made a switch. Pop the champagne... again... Never miss a chance to celebrate the small things right?
Simplifying for our own sake
Now settled in Azure, all stabilised and running smoothly, we started looking towards the client specific platform we had in running on Heroku. This platform was in many ways quite different from the standard platform, but not in an incompatible way, some poking around revealed. The platform was really just ahead in many of the features it had available to its users. But it is a bad use of resources to maintain different environments. Especially when the features available on both platforms combined would benefit every user.
While glancing at the client specific platform, we evolved the standard platform. We added the features we had already developed, and even made sure to “right the wrongs” we had made early. Collaborating with a very patient client, we managed to forklift (digital forklifting of course) the users from the last Heroku environment into the prepared and feature upgraded standard platform.
In Duuoos short life we have had several versions of our service running on Heroku, moved the standard version to AWS, before we had to move it to Azure, and during this year we even managed to merge the last unique version of our service into our standard version. As a result we only have one codebase to maintain and only one platform to service. Hence, making our use of resources much more efficient.
In the end, our current platform solution is far more cost effective both in terms of development and in terms of infrastructure.
Lesson learned: plan ahead and be prepared for changes