Presentation: The Microservices Journey: A Startup Perspective

Track: Microservices: Patterns & Practices

Location: Broadway Ballroom North Center, 6th fl.

Duration: 4:10pm - 5:00pm

Day of week: Monday

Level: Intermediate

Persona: Architect, CTO/CIO/Leadership, Developer, General Software

What You’ll Learn

  • Learn how an organization using small teams embarked on a journey to break up its monolithic software architecture into microservices. 
  • Understand that this is an ongoing journey for Just Software and it will be a year, if not years, before the effort is completed.
  • Hear how the startup learned from early mistakes of trying to bite off more than it could chew to taking a top-down approach to establishing its microservices architecture.


Splitting our organization into multiple, smaller teams and dividing our collaboration solution JUST SOCIAL into single smaller apps were the driving force at our startup to trigger the transformation of our monolithic software architecture into Microservices. During this talk I would like to share some experiences and challenges we faced and still face during our Microservices journey.


QCon: You were saying how you wanted this talk to show that you can break up a monolith with microservices using small teams -- that it's not just the domain of big companies. Could you talk a bit more about that?

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.

QCon: You spoke earlier about small versus large companies; nothing you just described is specific to a small company. I think that's fantastic. In fact, that was the very first question that someone asked me in a talk about microservices. They asked me where do we start. How do we go about starting to break this down? So, I think that what you described is a great story.

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.

QCon Yeah absolutely it totally makes sense. Literally, when I left the organization I was talking about, it was a .NET app I was helping somebody with. They had a problem with a processor running away and it basically was because they were doing a document merge on a web tier because they had a monolith. So, what I was designing when I left was how to break out that merging of all these virtual documents into one onto s separate server. So, it totally makes sense.

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.

QCon: Who is the main persona you are talking to? Are you talking to a developer, an architect or some variation of that?

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.

QCon: It's funny you say that because the director of operations at Netflix told me that one thing about microservices is once you start you never stop. It's an evolutionary architecture that never ends.

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”.

QCon: If a senior developer came up to you and said what is the most important thing I should focus on today -- the new technology, hot thing that I really need to focus on. what would you answer?

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.

Speaker: Susanne Kaiser

CTO @JustSocialApps

As the CTO at Just Software, Susanne is responsible for the software development of JUST SOCIAL - providing apps for collaboration and communication in organizations. She has a background in computer sciences and experience in software development for more than 15 years.

Find Susanne Kaiser at


Monday, 26 June

Tuesday, 27 June

Wednesday, 28 June