Date: 2016-Oct-20
Presentation by: Arjen de Ruiter
Meetup: Engineering Culture: Scaling Up!
PDF text:
@coostodev
@arjenderuiter
Scaling up and keeping the fun
Alicante Tech Meetup, October 2016
We offer a solution
for social media monitoring,
web care & publishing
Started in Eindhoven 6 years ago
Development office in Alicante since 2016
Many customers in 6 years time
We expect many more, so we need to scale up and keep the fun
How to fix anything
Problem Solution
OUTPUT >
INPUT >
5ways to put WD-40 in your organization
so you can scale up and keep the fun
Why do teams need to be autonomous?
Software has dis-economies of scale
OUTPUT > Example:
Add 1 feature and you have 1 feature to test
Add 2 features and you have 3 tests
Example:
th
Add a 4 member to a team of 3 and the
communication paths go from 3 to 6
INPUT >
Source: Allan Kelly,
Allan’s Blog – Agile, Lean, Patterns
Organizational scalability improves when you
remove dependencies
Build Test Deploy
Horizontal
dependencies
on ops teams
(or platform operations
teams)
Vertical dependencies on other dev
teams (or business capability teams)
Teams with high level of autonomy scale well
Teams are loosely coupled and highly cohesive/well aligned
Each team owns its part of the roadmapRoadmap & backlog
They work according to our principles
They decide on their own practices
Team manager: They own their services
multiple related teams They organize themselves
70% business innovation
PO = Your 30% production support, professionalization, unplanned work
entry to the
team
Product Owner, Guild
Scrum Master and Team Manager
facilitate team in delivering
the roadmap
Some guilds are for alignment: we need to have rules and frameworks
Some guilds are for cross-pollination: learn, explore, share cross team
Teams work according to agile principles
However … if you change your mind every sprint, you become less predictable
Increase predictability with a product
development roadmap
Strategic roadmap +
High XP, scrum
agile principles
Speed & flexibility
? Detailed planning
Low
Low High
Predictability
Agility to respond to market changes
Although we have a strategic roadmap, we can respond fast if market requires so
Plan with a goal in mind ….,… and we value responding to change (agile principles)
Now you have more autonomous teams,
but they are still dependent as they work in
the same code base on the same platform
We need an architecture that supports
independence
Our architecture reflects who we are
Conway’s Law asserts that organizations are constrained to produce application designs which
are copies of their communication structures. This often leads to unintended friction points.
Yesterday
Commercially very successful,
first make it work with a small team,
functional stuff (visible features) first,
non-functional (operational ftrs) …
we’ll see when it breaks!
We want horizontal scalability (most of the times)
Scalability is an example of a non-functional
requirement, just like performance, availability,security, etc
Non-functional requirements
Requirements if not met,
will make a system …
non-functional
Source: @littleidea
Our architecture reflects who we are
Conway’s Law asserts that organizations are constrained to produce application designs which
are copies of their communication structures. This often leads to unintended friction points.
Yesterday Tomorrow
Commercially very successful, Speed up,
first make it work with a small team,now make it better with a large team,
functional stuff (visible features) first,independent services help,
non-functional (operational ftrs) … loosely coupled and highly cohesive,
we’ll see when it breaks! horizontal scalability and
performance are required
Drives a need for
resilience,
zero-down time deploys
and compatibility > new complexity
Services help us become less dependent
on each other Business logic & database are internal!
> makes services less dependent
Engagement
One PHP app for Search, Monitoring,
Publishing & Engagement Search
Publishing
Monitoring
A service a day, keeps the monolith away!
Services help us to scale in multiple ways
• Scale independently
• Separate change cycles
• Easy to learn
• Tech stack commitment for shorter period
Beware of micro-services: from one big
ball of mud, to orchestrating a lot of sh*t
Source: Hadi Hariri, ‘The Silver Bullit Syndrome’, Devoxx 2015
1.All teams will henceforth expose their data and
functionality through service interfaces.
2.Teams must communicate with each other through these
interfaces.
3.There will be no other form of interprocess communication
allowed: no direct linking, no direct reads of another team’s
data store, no shared-memory model, no back-doors
whatsoever. The only communication allowed is via service
interface calls over the network.
4.It doesn’t matter what technology they use. HTTP, Corba,
Pubsub, custom protocols — doesn’t matter.
5.All service interfaces, without exception, must be designed
from the ground up to be externalizable. That is to say, the
team must plan and design to be able to exposethe interface
to developers in the outside world. No exceptions.
6.Anyone who doesn’t do this will be fired.
7.Thank you; have a nice day!
Tip: align organization with new architecture
The ‘Inverse Conway Maneuver’
recommends evolving your team and
organizational structure to promote your
desired architecture. Ideally your
technology architecture will display
isomorphism with your business
architecture.
Source: ThoughtWorks
Now teams can build independent from
each other and demand for speed
increases
We need to improve the delivery process
Being dependent on others is no fun
Even if you remove dependencies, it is still very crowded
in shared test environments
Shared test environments
are like Beijing subway
stations:
•wait until everyone is
set
•still many are left
behind and have to wait
for the next train
•lots of coordination
required (guys in yellow
shirts)
One track to production creates dependencies
You have to pass the same stations: test and acceptance
In other words: no isolated environment
30
Isolated development
You are more autonomous if you can lay a track for each train
that you want to take to production
Hourly Weekly
Daily
Photo: Bailey Yard, Nebraska
31
How? Isolated development & testing by
creating environments on demand
Made possible with infrastructure automation and dynamic infra
How? Smaller services and the right
branching model makes it easier
Source:Robert Chatfield, Youtube, https://www.youtube.com/watch?v=j7YDbrS9I48
One team can go fast
34
The other team can take more time
35
Take calculated risks.
That is quite different from being rash.
George S. Patton
36
Our future platform: autonomous
development, testing and deployment
Dev Test Pro Isolated test environment to remove team dependencies
Stubbing and test data management for autonomous testing
Test automation for fast feedback cycles
Performance test platform
Independent deployment features
Metrics, logging and alerting platform
So no ‘vertical dependencies’ like this
So our speed will be increasing, we deploy
new features faster than ever … in parallel!
Demand for a more scalable platform
increases
We provide infrastructure faster via an API
Our DC needs to run on auto pilot
Our future platform: treat databases, queues, files
storage, etc. as resources > Platform as a Service
We still need Operations
and their role will be even more fun!
So no ‘horizontal dependencies’ like this
Our future platform services:
high performance, scalability and high availability …
provided to teams via an API
No single point of failureSmall fault domainsHorizontal scalability
Think: dynamicinfra (cluster management) instead of static servers
Think: infrastructureas code
Tear down The Great Wall of IT
New stuff Keep it running
It works on my machine! Who designed and developed
this cr*p!
Development
team
Operations
team
Architects
That’s not how we designed it!
41
Renewed direction impacts culture
In the long run our way of thinking, behaving and working will change
•Ownership & responsibility
•Results & principles count
•Learn & adapt; fail fast, fail cheap
•Risk taking & blameless discussions
•Confidence besides speed & flexibility
•First production, then innovation
•Aware of your environment
•Internal open source
Isolated
development &
Independent testingTier down the wall
services
High level of team Self-service Roadmap for more
autonomy platform predictability
OUTPUT >
INPUT >
