-
What is more painful? 🧵 About past experiences with poorly designed microservices architecture.Permalink On twitter.com
Mood -4 🙁
-
Context is essential. Otherwise, we tend to overestimate ourselves and underestimate others' decisions. This is a situation of 3 developers doing 3 products simultaneously that evolved into 3 teams after one year. The initial 3 developers left previously I joined the company.Permalink On twitter.com
-
Some mistakes were, IMHO, avoidable, while others needed to be made to learn.Permalink On twitter.com
-
🟠 Business/Product learnings Do not start three products in parallel. Even though their product needs might differ slightly initially, it's never the case in the long term. The more time you spend in the game, the more their domains/journeys differ.Permalink On twitter.com
-
🟠 Engineering learnings If you only have 3 developers for 3 products, the pressure on them is high and unachievable. Best case scenario they will tell you that's not possible and let's start with one. Worst case scenario, there is no psychological safety to saying no.Permalink On twitter.com
-
This is the case with the latter. The team proceeded to create the products. What will a team of non-experienced developers with a considerable challenge ahead do? Aim to create the best architecture to fulfill our unknown business needs.Permalink On twitter.com
-
Did you make this mistake in the past like me? 🙋 What did we all do to face the highly uncertain future? Do what most experienced people tell you in their blogs. 👉 Microservices 👉 Hexagonal ArchitecturePermalink On twitter.com
-
Until this point, we all might come to this path in some way or another.On twitter.com
-
Which are the avoidable mistakes, IMHO? 👉 Entity based microservices. Splitting too early into microservices where the domain was still unknown and the product understanding too immature led to entity-based microservices calling each other. #DistributedMonolithPermalink On twitter.com
-
👉 Hexagonal architecture with Ktor and custom persistence layer. When you start a new product with little domain understanding, your entities look like CRUDs. If you start with low domain knowledge, you spend more time coding ports and adapters than doing actual domain logic.Permalink On twitter.com
-
This is an over simplification, but what would we do instead? 👉 Purpose another approach instead of developing 3 products at the same time.Permalink On twitter.com
-
👉 Start small with one monolith to speed learning and experimentation. You can help business and product realize that there are more unknowns by exposing the inner complexities soon and often. Collaborate with the different stakeholders and show your learnings continuouslyPermalink On twitter.com
-
👉 Use well-known technologies instead of niche ones. I would have chosen Spring Boot over Ktor. Talend, good integrations with most technologies, proven in production, ...Permalink On twitter.com
-
👉 Buy time until more people join. Focus on onboarding speed versus production speed. Preparing for feature scalability (by joining new people and splitting into different teams) is the right architectural choice. Modular monolith > Too early microservice.Permalink On twitter.com
-
👉 Help product and business to understand the domain model by fast collaboration involving end customers as well. 👉 Externalise generic subdomains, but be careful not to externalize core domains. 👉 Learn fast.Permalink On twitter.com