About a year ago we thought it was a great idea to transform our monolithic application into microservices. But since then we came back on that thought. Our plan was to build the homepage of our website in a new way. It would involve doing asynchronous calls to a public API, which was backed by small services which were specialised in giving the requested response as fast as possible… and nothing more. This way we would end up with a very scalable solution that would be fit for the future. Of course we did not want to take a big-bang approach on this and therefor we would cut out small parts of the ‘old’ application and replace them with some new parts. If all worked well, the user would not even notice that things under the hood were changed. It sounded like a solid plan and the step-by-step approach looked very promising. So what happened…
There was a lot of functionality on the homepage that we did not see at first. So something that was seemingly small suddenly became bigger and bigger. And getting things functioning exactly the way they were doing is very hard (if not impossible). We had a lot of moments where we thought we could go into production, but there was always some seemingly small issue that needed to be fixed first. This way we ended up with a lot of ‘bandaids’. And all of them turned our system into a hard to maintain system that still did not do exactly what we wanted it to do.
At one point we just had to admit to ourselves, that it was not working out the way we planned it. But then your conscience kicks in and tells you that you cannot give up, otherwise you would have delivered absolutely nothing to the business. Especially since we are not talking about a couple of weeks of work, but rather numerous months.
One thing you will notice in the team then, is that people are getting frustrated. And that certainly is not good in a team. So at one point we talked to our product owner about it and said that we failed and did not want to continue working on it anymore (for now). He was actually pretty glad that decision was made. What followed then was a big retrospective where we talked about what happened and what we should do better in the future.
One of the main items that came out of this retrospective was, and is pretty much a open door, to fail fast! Do not try to struggle and try to deliver what we promised. Failure is also possible and not a problem, as long as you admit as soon as possible. Looking at it from ‘outside’ of the team, you might say that it would have been logical, but when you are actively building something and constantly see possibilities to ‘not fail’. It is very easy to keep going for those possibilities.
After some lessons learned, we decided to generate some business value again by building new features in the current codebase of the monolith.
Another lesson learned was that the approach we took for transforming our monolithic application into microservices was not working. Another approach that probably works better is to gradually change the code itself so that it is easier to split. So right now we improve a lot of code we touch (boy scout rules). Decomposing the application into functional packages, could be a first step into isolating functionalities which eventually can be cut out and moved into smaller services (not calling these microservices is intentional).
Even though we had to ‘throw away’ lots of code, there was a lot we learned. Not only as developers, but also as a team. The most important thing one was, that you are a real professional if you admit that something is not working the way you expected it to do. And then stop working on it. The sooner you are able to admit this, the better it is. Maybe there are other ways to come to the same result and maybe the time was not right yet.
So whatever you do, you should fail fast!