Susanne Kaiser: When transitioning to microservices organizational changes have to follow as well

This is it! The final countdown to The 4th Gathering of IT Evangelist that will take place on April 19 in Iasi. But wait! Until then, we want to find a little more about microservices, so it is time to meet Susanne Kaiser, one of our amazing speakers from this edition of DevExperience!

DevExperience: When should a CTO decide to move from a monolith to a microservices architecture? Are there specific signs to watch out for?

Susanne Kaiser: One aspect worth analysing is your current software delivery performance. A 4-years research (by Nicole Forsgren, Jez Humble and Gene Kim) has revealed that software delivery performance has a strong impact on profitability, productivity and market share of technology organizations.

What effort does it take to add a new feature and how long does it take to release that change to production? Is it necessary to intensively coordinate across teams and is it complex to release simple change, because you have to rebuild and redeploy your entire application, even when changing just a single line of code? If your current architecture and team structure is slowing down your software delivery performance it might be an indicator to split and shift things by introducing microservices and align your teams accordingly.

DevExperience: On the journey to microservices, will there be organizational changes, the way teams are composed and interact with each other?

Susanne Kaiser: When transitioning to microservices organizational changes have to follow as well. Each team should be responsible or rather own one or multiple microservices reflecting semantic boundaries of your domain models (bounded contexts). This alignment to bounded contexts enables each team to work on different parts of the system independently at different speed and minimal impact across teams.

DevExperience: Why is a distributed monolith that bad? Isn't it enough that we do have different bounded contexts, even if we communicate through direct http calls?

Susanne Kaiser: One of the benefits of loosely coupled microservices is the possibility to develop and deploy your services independently to release changes quickly - with the downside of increased operational and infrastructure complexities.

When designing your microservices inappropriately there is a potential risk of accidentally introducing a distributed monolith, where your services are instead tightly coupled. With a distributed monolith your are combining the disadvantages of both worlds: Because of the tight coupling of a distributed monolith you cannot develop and deploy services independently, but you still have to handle the operational and infrastructure complexities.

DevExperience: From a testing perspective, what kind of tests would you need for microservices compared to a monolith?

Susanne Kaiser: With microservices service interaction is playing an important role. Service are interacting with each other either directly by the services' APIs or indirectly by publishing events through a message broker. That said integration tests and consumer-driven-contract (CDC) tests have become more important. On the other hand end-to-end tests becomes more difficult and potentially more brittle, since the test boundary has become larger.

DevExperience: What do you think it is the biggest misconception of microservices?

Susanne Kaiser: Microservices enable teams to release changes quickly (as I mentioned earlier). At first glance, it looks like that microservices eliminate complexities that a monolithic system faces. But microservices come with additional infrastructure and operational complexities that need to be considered from the very beginning and might even slow you down - at least in the beginning. In addition, handling infrastructure complexities bears the risk to shift your focus away from building your core domain.

DevExperience: If one of your clients would start a new big project would you chose microservices with a container orchestrator like kubernetes or go with serverless?

Susanne Kaiser: That depends on the use case, but in regards to the aforementioned infrastructure complexities I would rather go for an infrastructure fully managed by a cloud provider - as promoted by cloud provided Serverless technologies - than managing it by myself.
In my opinion, being able to focus on the core domain and to reduce total cost of ownership would be of higher priority than being able to fully control the infrastructure, e.g. with a Kubernetes cluster. But Serverless also come with tradeoffs, that make them not applicable for every use case.


You want to read more about it, right? You want to meet Susanne in person and speak with her about all this topics?
Then you should really register and get your ticket to the conference, because this is your final chance!