How We Built Our Stack for Shipping at Scale(product.hubspot.com)
product.hubspot.com
How We Built Our Stack for Shipping at Scale
http://product.hubspot.com/blog/how-we-built-our-stack-for-shipping-at-scale
11 comments
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 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.
Does not having a dedicated test/QA team affect productivity? How does this correlate with build quality in general?
Thanks,
Thanks,
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.
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.
Great answer. Thanks for the insight.
Roughly, how many dev teams are there at hubspot?
About 25 plus or minus.
teams are typically ~3 engineers, working with a Product Manager and a Product Designer