Simple Services
- 1.
- 2. naive alternative tocommon patterns : one language fits all (ok, two) Front - Backend split, due to different skillsets
- 3. policy of maximisingcode reuse => frameworks, libraries, etc. even when the problems are ill-fitting over-engineering design by comity
- 4. SSOA Simple Service OrientedArchitecture 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 Nota 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 anythingbefore 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 forreuse 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 thegoal 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 youwant 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 soonas 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 theframework 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 issueuntil 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 mostlywith frontend people allows them to solve their problems faster in isolated silos
- 17. Producer often the1st consumer => eat your own dog food less bitching better quality over time quality meaning “fitting the requirements”
- 18. Disadvantages Potentially mess... Requires discipline Weencourage 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 inthe 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 ownerof a service encourages people to take pride => higher reliability
- 21. Conclusion Naive by design doesnot 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.