The purpose of this tutorial may sound a little counterintuitive, but bear with me…
As startups grow and evolve, so does their architectural complexity. Early on, as companies iterate rapidly on business ideas to find market fit, the focus must necessarily be on pushing out new functionality early and often. Over time, as product-market fit is established, the architectural needs and complexity of an organization change dramatically.
I’m not an expert on these matters, and frankly, companies’ needs, requirements, and organizational physics are so varied that no expert can prescribe a universal path to painless evolution of an applications architecture. Instead, this series is based on one engineer’s experience helping grow and scale an application and engineering organization.
Having joined a company as its sixth hire in the engineering organization, I’m well aware of the pressure to move fast and expand product functionality. In my first two years I experienced first hand what it looks like for a previously nimble engineering organization to grind to a halt as 30+ engineers fight to simultaneously maintain, extend and scale a large monolithic code base. In two years following I watched and participated in extended thrashing trying to find the foothold and develop a strategy to move past these dark days (the first non-monolithic services, the new hosting providers, containerization, more new hosting providers, obervability, etc.) growing to an engineering organization of over 60 employees.
As I mentioned above, there is no silver bullet when it comes to evolving an organizations architecture. The goal of this series is to provide some pragmatic guidance about some of the decisions that can be made early on in a company’s life to ease some of the pain as growth happens. Throughout the series you will be building an actual application for a fictional business and then scaling out that architecture as the business grows.
The posts in this series are going to cover a lot of ground quickly and use a large variety of tools. This is done for two reasons; to inject some mock complexity to better emulate what actually happens in high-growth organizations (tools are chosen which must continue to be supported, teams grow and make choices incongruent with existing paradigms, etc.); and secondly, to provide a survey of tools being used in the current era of application architecture (but note that widely used/supported tools are being selected, not the popular new kid on the block).
In many cases tools and technologies will be given a quick enough overview to enable implementation, but not given their due time for a full exploration. In these cases, Deep Dives will be taken outside of the main tutorial flow. Code in Deep Dives are probably best followed in the order they are presented, but are completely optional and will not add or change anything in the tutorial application.