Micro Everything - Our Road to Scale

www.beamery.com
Private & Confidential – Do Not Share
© Beamery Inc. All rights reserved.
Micro Everything
The Road to Scale
Ahmad Assaf
@ahmadaassaf
Head of Engineering @Beamery

www.beamery.com
Talent Marketing
Bring consumer grade marketing
capabilities to your talent team
Comply
For the global enterprise,
GDPR is just the beginning
Connect No more data silos, a single connected experience for candidates and recruiters
Talent CRM
A true CRM built on a foundation
of data intelligence
Our Talent Engagement Platform helps enterprises attract, identify and engage
candidates on one unified platform, to deliver better talent acquisition—at scale.
The Beamery Platform

www.beamery.com
About Beamery
Founded in
2013
on a mission
to empower
companies to make
talent a priority
$40M
raised from leading investors
from Silicon valley and Europe
Headquartered in
London with offices
in San Francisco
and Austin
We partner with the best to support the success of our customers

www.beamery.com
#1 US Insurance
Company
We’re powering market leaders
#1 Swiss Bank
#1 Social
Network
#1 eCommerce
Company
#1 Beverages
Company

www.beamery.com
2017
Series A
~20 People (11 Engineers, Sales and
Customer Success teams formed)
- Enterprise clients
- Early scaling problems
2018
Series B (Beamery 5)
130+ People, 3 Offices
50+ Engineering, Product, Design (EPD) Team
- Tribes, Cross Functional teams
- State of the Art architecture and
platform
2015
Foundation of Beamery
Angel and Seed Funds
8 People (4 Engineers).
- Seeking a Product Market Fit (PMF)
2016
PMF (Beamery 1)
11 People (6 Engineers, 1 Designer, 4
Commercial roles)
- Adoption of “cool” technolgoies
and moving away from legacy code
- Onboarding customers
A Walk Down Memory Lane

www.beamery.com
bjectives
N
O
M
M
S
orth Star
ilestones
easures
prints

www.beamery.com
Move Fast and ….
=== Lots of Tech Debt
Ignore Things

www.beamery.com
Micro-apps (FE)
Scale Single Page Applications
(SPAs), move away from
legacy, attract and retain talent
Micro-ops (DevOps)
Scaling ownership, CI/CD,
Mono repos and meta repos,
tooling, logging and
orchestration
Micro-services (BE)
Scaling to meet the demands
of enterprise customers, use
the right tool for the right job
Micro-teams
Splitting teams into
independent cross-functional
units. Tribes, guilds and how to
scale management

www.beamery.com
● Code moves forward for a reason. Developers are intelligent,
forward-thinking people, always trying to solve the next problem
in the smartest possible way.
● If you don’t keep up, hiring will become difficult. Have you tried
to recruit an AngularJS developer recently?
● Is your tech stack a sinking ship? You’ve automatically alienated
the very people you want to attract. The good developers will
not come to you, and they will not stay.
Legacy Hurts Business in Surprising Ways

www.beamery.com
Micro-apps
The Frontend Monolith
Legacy is a constant in JavaScript

www.beamery.com
What’s wrong with the monolith?
● Ownership
○ Drawing the line can be difficult
● Monolithic apps have more code conflicts
○ How do we keep developers interested?
● Learning & New Frameworks
● Horizontal scaling is difficult (Long build times, long startup
times)

www.beamery.com
What are micro frontends?

www.beamery.com
Micro-services
The Backend Monolith

www.beamery.com
Micro-ops
Scaling DevOps

www.beamery.com

www.beamery.com
Where did we start?
● Beamery had around 25 backend and 15 frontend repositories, both
mixtures of deployable artefacts (4 APIs, 10 apps and microapps,
queue workers and cron jobs), internal plugins and libraries
● The codebase was entirely NodeJS, with various parts owned by
different teams with either a backend or frontend focus
● As the codebase was written entirely in a single language, it became
convenient to share code between repositories, especially from
libraries
Libraries and plugins became dependencies of each other, as well as dependencies of our
deployable artefacts

www.beamery.com
What’s wrong with doing it this way?
● Our testing process has become significantly more difficult, lengthier
and more complex.
● Our developers can test their code locally, but without the api core
pulling from a full list of dependencies lots of bugs are constantly
slipping through the net
● Onboarding new engineers is slow, and getting slower!
● Collaborating within or between teams becomes a tiresome process
since a major part of sharing code is now documenting and explaining
where changes have been made.
● Retaining great engineers is harder too. The best want to work with the
best environment, and would rather spend time coding than wading
through a mess.

www.beamery.com
So what did we do? We Created Story !
● A ledger for code changes- a layer on top of meta to aid development,
continuous integration, testing, container building and deployments
when working with meta-repos with larger numbers of inter-dependent
node projects.
● Keeps track of the blast radius of any set of changes, applied to any
part of the codebase, at any stage of the development process
● Gives a clearer idea of what needs to be tested for regressions and
what needs to be deployed, as well as showing how tightly coupled
codebases with multiple repositories become over time

www.beamery.com
Not every team will have this problem like us. But, we’ve seen it a lot
because the conditions which drove us to make these early decisions are
pretty ubiquitous for startups in the position we were in:
● A small team working on an MVP,
● Barely enough time to ship features for clients
● Limited resources we could allocate to building infrastructure
Yes, we could have versioned all of our repositories and published to a
private registry, or transitioned from Metarepo to a Monorepo, but neither
felt feasible at the time since both would have required a significant
development freeze.
Is this the only way?

www.beamery.com
Micro-teams
Scaling Management

www.beamery.com
Independent Cross Functional Teams
● Embedded Front and Backend Engineers (whenever needed)
● Embedded DevOps Engineers (rather than a separate DevOps function)
● Each team will have a Product Owner/Product Manager
● Embedded Designers (for teams with FE engineers)
● Scrum Master responsibility is split across team members on rotation basis
● Internal delivery model is applied
● BE/FE contracts is internal for each team and cross teams contracts are in place
Team Iceberg Team Rocket Team Engage

www.beamery.com
Tribes Model
A tribe consists in a pool of 15-30 engineers aligned with Product/Marketing
teams. Each tribe has an Engineer Manager and a Solution Architect.
Types of tribes
● Product - Focus in adding more value to the product (new features)
● Core Engineering/Architecture/Infrastructure - Focus building/maintaining
core systems, libraries and architectural improvements.
Can have more, it depends how big the company is e.g., Marketplace, Mobile, Data, Warehouse

www.beamery.com
There are two main processes using this model
Missions and Launchpad

www.beamery.com
Mission Process
The main goal of a mission is to create value to the product. A mission must
be specific, clear and have a target. It takes around 1-4 months and are
composed by a team of 2-5 engineers.
The tribe consists of the following personas:
EM: Engineer Manager
PM: Product Manager
ML: Mission Lead
SA: Solution Architect
D: Designers
LL: Launchpad Lead

www.beamery.com
Example Mission
Goal: Due a market research 25% of the inquiries would love to have integration
with workable. The main goal of this mission is to integrate with workable
provider. Users must be able to sync their contacts with Beamery platform.
Target: Increase our customers by 5% after 3 months.
Resources: 1 BE, 1FE and 1 Mission Lead

www.beamery.com
Sneak Peek … RICE
RICE is a simple equation that models out the relative value of any given set of
potential projects
Reach: The proportion of your users, customers, or potential users and/ or customers that you can impact with
a project
Impact: The degree to which those users or customers would benefit from this solution
Confidence: The degree of confidence that you feel in saying that, should you commit engineering resources to
a problem, that you’ll achieve a given predicted impact with a predicted share of your potential user base.
Effort: The amount of work necessary to achieve the functionality necessary to achieve some desired impact
and reach.

www.beamery.com
Step Accountable Informed
Product team have ideas, improvements to the product and align them
with the company strategy.
PM
Align possible mission with EM PM EM
Mission Process
EM: Engineer Manager PM: Product Manager ML: Mission Lead SA: Solution Architect D: Designers LL: Launchpad Lead

www.beamery.com
Product Manager introduces mission PM EM
Validates technical aspects EM SA, D
Prioritize mission with business, validate resources PM EM
Assign mission lead PM, EM ML
Define Scope PM ML, D
Research Users PM, D
Estimate team size and resources ML EM
Preparation

www.beamery.com
Pitch Mission PM Tribe
Get a team EM, ML Developers
Define/Validate technical solution ML, Team SA
Define Landing Requirements Team, SA QA
Agree mission conduct (process, methods). All team must agree. Team
Launch

www.beamery.com
Implement, adjust, iterate mission process ML, Team
Adjust solution if needed Team
Deliver Team
Review and adjust mission Backlog PM, Team
Execution

www.beamery.com
Team will move to launchpad Team EM
Prepare support team for the new feature (training) PM, Team SA, D
Validate the release checklist PM, Team EM
Mission retrospective PM, Team ML
Clean cleanup tasks (technical debt, improvements) Former Team LL
Retrospective with business, publish knowledge PM EM
Landing

www.beamery.com
Team can ask for more 25% of time (confirm with EM) ML EM
Team can ask for more resources ML EM
Mission finished but code does not have the required standards ML
Emergency

www.beamery.com
Launchpad Process
During the launchpad, developers must be focused in the following tasks:
● Refactor Code (reduce technical debt)
● Fix bugs
● Research new technologies
● Support & Operations
● Engineering Projects
● Hiring tasks (interviews, task reviews)
● Vacations
● After 3 months is a priority to go to mission
● Clear mission backlog (former team who was in this mission)
● Organize Guild events● Organize Guild events

www.beamery.com
Guilds
● Gathering of people who share the same skills
● Encourage knowledge sharing on deep technical topics across teams
● Guilds meetings are open for anyone to attend
● Can be used for big architecture decision meetings, controversial code reviewes and rants
Backend Tribe Frontend Tribe DevOps Tribe

www.beamery.com
Tribes You Say, But …. Why ?
● Developers motivation (no stuck in same project for
years)
● Spread knowledge about projects (rotation)
● Launchpad focusing in code quality and
improvements, missions on product value
● Easier to evaluate people (mission success)

www.beamery.com
Micro …. Managing

www.beamery.com
Bits of Wisdom
● The competitive advantage of culture, values, and rituals
● Nail the problem statement
● Achieve ambitious outcomes by having even more ambitious goals
● Think of your org design as a product
● Premature Scaling
○ Almost all the successful microservice stories have started with a
monolith that got too big and was broken up
○ Almost all the cases where I've heard of a system that was built as a
microservice system from scratch, it has ended up in serious
trouble.

www.beamery.com
Ahmad Assaf
ahmad@beamery
@ahmadaassaf
http://ahmadassaf.com

Micro Everything - Our Road to Scale

Recommended

Recommended

More Related Content

Similar to Micro Everything - Our Road to Scale

Similar to Micro Everything - Our Road to Scale (20)

Recently uploaded

Recently uploaded (20)

Micro Everything - Our Road to Scale

Editor's Notes