1. Simple Services

2. naive alternative to common patterns :
one language fits all (ok, two)
Front - Backend split, due to different skillsets

3. policy of maximising code reuse
=> frameworks, libraries, etc.
even when the problems are ill-fitting
over-engineering
design by comity

4. SSOA
Simple Service Oriented Architecture
We don’t like the name that much either, but
we got used to it.
It’s SOA, except simple... real simple...

5. Challenging the patterns
Not a full blown solution
Just enough rules to force a fresh look
Causing people to think before applying any
pattern
If the pattern survives the challenge, use it

6. Don’t build anything before you have a clearly
identified need
Applies to features, as well as complete services
While you’re not banging your keyboard, use
your brain.

7. Solve your problem, not what you think might
be someone else’s problem...
...or tomorrow’s problem
Solution is usually pretty lame, so temptation to
invent needs is low.

8. Don’t push for reuse by adding features
Wait for people to express what they’re
missing, and most often tell them to implement
themselves
But expect new needs, so don’t lock yourself in
closed quick fixes
Not obvious to find a balance, but aiming for
simplicity helps

9. No Side-Effects
Unless the goal is to explicitly change a state,
you’re not allowed to do it.
Treat calls to the service as algebraic functions
Allows chaining, parallelising, etc.
Keeps things dead simple

10. Side Effects
Sometimes you want side effects
Keep the rule in mind and feel dirty
Compensate that guilt with 2x as much
documentation
Document the obvious

11. No Versioning
As soon as you have a customer, you can’t
change the service
Any API change means a new service
With a negotiation from scratch
That rule is non-negotiable

12. HTTP is the framework
Good enough for 99% of the cases
Language agnostic
Plenty of deployment options
Real easy to debug
Easier to scale than the alternatives

13. Serialisation
Whatever makes sense :
XML
JSON
CSV
Text / Binary
Thrift / Protocol Buffers

14. Performance
Not an issue until it hurts so bad it’s the only
thing that matters
If you followed the rules, it won’t hurt
It should just be a matter of fine tuning
load balancing, keepalives, pipelining, etc.
specialised data stores, etc.

15. Human Aspects
We use “loaded words”
specifications form a “contract”
consumers are “clients”
the maintainer “provides a service”
the “contract” specifies a “Service Level
Agreement”, “negotiated” between “provider”
and “clients”

16. Human Aspects
Popular mostly with frontend people
allows them to solve their problems faster
in isolated silos

17. Producer often the 1st consumer
=> eat your own dog food
less bitching
better quality over time
quality meaning “fitting the requirements”

18. Disadvantages
Potentially mess...
Requires discipline
We encourage deploying over the load-
balancers.
Means talking to Sysadmins, who ask where the
documentation is...
And can make your life hell until you comply

19. Require documentation in the form of a wiki
page with
• Description of the service
• Named maintainer
• Named consumers
• LB Health Checks
• Nagios Heatlh Checks
You build it, you own it

20. Being the owner of a service encourages
people to take pride
=> higher reliability

21. Conclusion
Naive by design
does not try to solve 100% of the problems
the 50% it does solve is solved with a 100%
match on the requirements
those 50% are solved in simple, maintainable
ways, by people taking pride in doing things
right

22. Frees up time / resources for the complicated
stuff
Makes developers more critical of complex
solutions

23. Q&A