I am the former CTO of Just Software – a startup in Hamburg, Germany, providing the digital workplace JUST SOCIAL to communicate and collaborate in teams.
Our journey to Microservices was mainly product and organizational driven. We started with a monolith in every aspect: One team was working on one collaboration product implemented as one code base based on one technology stack.
After a while everything was evolving: Our team was growing, we added more and more features to our product, the code base got bigger and bigger and the number of users increased.
As a consequence, from the organizational perspective it took longer to get things done and with no clearly assigned responsibilities our processes were slowing down and our productivity suffered. From the product perspective the usability and user experience suffered through continuous feature amendments and instead of solving our users’ problem effectively we were increasingly confusing them. In addition, due to its monolithic software architecture it was quite complex to release a change since we had to rebuild and redeploy the entire monolith resulting in high risk deployments which occured less frequently – new features got released slowly.
The need evolved to split and shift things. More than 3 years ago, we focussed on usability and user experience improvements and split our one product into separate collaboration apps – each of them taking care of a specific use case. Meanwhile we split our one team into multiple smaller teams and assigned to each of them a specific set of collaboration apps to achieve well-defined responsibilities.
Our motivation to introduce Microservices was to enable autonomous teams working at different parts of the product independently at their own pace with minimal impact across teams. They shall be able to develop and deploy the collaboration apps independently – and scale them more effectively. In the long run we want to release changes of our collaboration apps quickly.
At Voxxed Days Microservices I am going to share some Microservices lessons learned from our startup perspective and what to watch out for if we would start the journey again. I am going to give a brief overview of how we started, what stepstones and pitfalls we were confronted with and how to overcome those challenges.
The talk also covers different aspects of service interactions and management of shared data that we experienced during our journey.
Microservices come with complexities requiring different skills and tools. But the transformation process from monolith to Microservices is challenging not only in technical perspective, instead it’s affected by a variety of different circumstances.
Your teams’ size, structure, skillset and mindset have a strong influence on what is manageable for you especially in the beginning. For instance, a small team with little devops practises in place, will definitely affect your transformation process velocity.
Especially, if you take into consideration that you still have to take care of your legacy system: You still have to maintain your current system which will reduce the time being available for your transformation process. Also your current runtime environment affects your journey: Are you running on-premises or on cloud-native? Can you rely on managed services, e.g. a managed API-Gateway or do you need to set it up, maintain and monitor it by yourself?
And if your strategy requires to implement new features in a short period of time due to sharp timelines and milestones you might struggle with the decision, where to implement these new requirements: As a new service or adding them to the legacy and risking to feed your monolith instead of shrinking it.
#microservices #ddd #eventdriven
Twitter: @suksr
LinkedIn: https://www.linkedin.com/in/susannekaiser1