Code Obsession

Originally published on April 14, 2017 at  https://www.pluralsight.com/tech-blog/system-architecture--messaging-business-events When we started on our journey towards bounded contexts , we wanted to maintain the small-team, focused, feel that we had enjoyed with as a single team supporting a monolith. One strategy we adopted was to limit our dependencies between the teams and, by extension, the different bounded contexts. We did not want to introduce temporal runtime coupling between components developed by different teams because that would reduce the autonomy of these teams and limit our ability to develop the products that we wanted to develop in the ways we wanted to develop them. For example, imagine one team is developing an API and they have a goal of a 50 millisecond response time for 98% of requests. If they have to take a runtime dependency on another team that has 20 millisecond response time for 90% of requests but a 200 millisecond average response time for the rem...

Originally posted on Dec 2, 2016 at https://www.pluralsight.com/tech-blog/system-architecture-bounded-contexts Microservices architectures are currently highly fashionable. The question of how small a microservice can be is asked regularly. Is micro even small enough? Can we build pico-services? At Pluralsight, we have chosen to go a different direction. We are focusing on team size. In order to maximize throughput, how big should a team be? One pair of developers? Ten pairs of developers? For the time being, we have settled on two to three pairs of developers with a Product Manager, a UX Specialist and a DevOps Engineer. Given this team structure, we ask ourselves how big of a chunk of our system can that group truly own? We expect a team to own the discovery, design, development, delivery, and production support of their part of the overall system. This means that we have to divide the system carefully. If the creation of a new feature requires coordination across multiple tea...