Presentation: The Microservices Journey: A Startup Perspective

Susanne: When we decided that we would like to break up our monolith into microservices, we started with mistakes.At the very beginning we took too many steps at once. We wanted to achieve too many things at once.

For example, what we do is we provide collaboration apps for communication and collaboration within organizations. After we identified good candidates for microservices, we started to extract one of the collaboration apps as a coarse-grained service from scratch as a coexisting solution - more a kind of a self-contained system.

This was a good approach in general, but in particular we added more complexity to our extraction process since we also introduced new features, a new user interface and a totally new data structure than the original one residing in the monolith The problem was that it took a very long time dealing with these complexities. We had no experience at all, and it turned out to be a too big chunk at the very beginning.

We learned that it was a good approach to build a coexisting solution from scratch, but the problem was we had a lot of steps involved in the extraction process -- including adding all the new features to the previous version of the collaboration app existing in the monolith.

So, from that point we derived a different pattern. We wanted to do it in smaller steps that we could manage rather than extracting things in big chunks. We followed a top-down pattern as an incremental approach. We started with the user interface. The next collaboration app that we identified as a potential candidate for a microservice, we started extracting the user interface first and then connecting to the monolith still. The monolith was still there and the business logic was still residing on the monolith.

The next step was then extracting the business logic. At that time, the monolith and new candidate addressed still the same data storage.The last step then was to split the data storage, too. In case our new service has to keep some data redundant we need to make sure the redundant data is updated as soon as the original data got modified. We introduced a message-driven architecture to publish update events that our new service consumes and can update its local replicate accordingly.

Instead of doing everything from scratch as a coexisting service, we went to do it from top to bottom as an incremental approach.

Susanne: People often get puzzled about what to extract first. One approach could be to start with those candidates that are easy to extract. We did not choose those that were really heavily coupled into the monolith. For example, our profile management is so central so it's still residing on the monolith. I guess that will be the last thing we will extract because it has so many dependencies so we will start with more easily extractable collaboration apps and transforming them to microservices.

The other approach could be to select those with different resource requirements. After you have extracted those you could run them on separate hosts with different capacity and allows you to scale your system more easily. One example is our document preview generation - whenever we upload a document we are generating a document preview. This preview generation consumes more CPU and disk space than other services and can be considered as next candidate to be deployed on hosts with higher CPU and disk capacity.

Susanne: And another approach that we followed is also like the ones that are changing a lot because we have so many different requirements and are adjusting and adding new features for our end users. These are also candidates for extracting microservices as well and this is also what I will talk about in my presentation.

Susanne: It's both of them; because it might be helpful to those that are thinking about starting with microservices or starting to figure out whether they should start and how to start. Because we are still in the middle of our transformation journey, so I guess it will take another year or years.

Susanne: Exactly. That's totally true. I had one person at a conference ask me when do you think you will finish the journey and I said “never”.

Susanne: I would say serverless because it could be very well integrated into a microservices architecture as well. It could be combined. It's not about everything having to go serverless, but if you have some microservices that require a function as a service approach, that could be combined with a microservices architecture. So that's the reason that a serverless architecture can benefit the microservices architecture, too.