As an engineer at HubSpot, I find our small team structure particularly empowering - though I'd be curious to hear of other orgs that run well with much larger teams as a counterpoint.
Hi ! thanks for the sharing the post. just a quick question .
was the architecture same from the beginning ? more specifically microservices ? or did you made a move from a monolithic application to this new architecture .
I'm not sure how to best characterize it in the very beginning (and I wasn't there) but in the 3.5 years I've been here it has largely been smaller services -- even down to things like the app's nav is its own service. More recently I think we've really embraced microservices (the number of deployables has grown ~2x in the last year).
Personally I think after 5 (and definitely 10) engineers working on a single app I would look at whether you can break it down into independent services.
Personally I've been a fan as it aligns incentives for developers to care deeply about code quality/stability/etc. YMMV if not working on a SaaS product where build/deploy is measured in just a few minutes.
We've invested in a mix of both automated testing, of course, and a lot of monitoring/alerting/tracing to detect problems quickly. That can act as a safety net for deploying frequently that problems will be caught early and can be corrected (rollback or fix & roll-forward).
I'm a fan of saying we've chosen to optimize for MTTR instead of MTBF.
11 comments
[ 4.2 ms ] story [ 35.4 ms ] threadPersonally I think after 5 (and definitely 10) engineers working on a single app I would look at whether you can break it down into independent services.
Thanks,
We've invested in a mix of both automated testing, of course, and a lot of monitoring/alerting/tracing to detect problems quickly. That can act as a safety net for deploying frequently that problems will be caught early and can be corrected (rollback or fix & roll-forward).
I'm a fan of saying we've chosen to optimize for MTTR instead of MTBF.