This document provides advice for scaling applications from a monolithic architecture to a microservices architecture delivered as a service. Some key points include: - Scale out by splitting work across many stateless workers rather than scaling up a single heavyweight instance to avoid bottlenecks. - Use an event-driven architecture with an event broker like RabbitMQ to modularize applications. - Store data in multiple data stores suited to the usage like databases, files or object storage. Avoid using the file system or memory as the primary data store. - Automate deployments and use containers to easily deploy modularized code. - Innovate by rewriting parts of applications as smaller, independent services using different technologies best suited to problems.

1. FROM DELIVERING
PLUGINS TO
DELIVERING "AS A
SERVICE", SOME
ADVICES TO RUN IT EASILY
QUENTIN ADAM AT
ATLASSIAN CONNECT WEEK 2017
@WAXZCE
2013

2. Quentin ADAM from the Clever Cloud
@waxzce on twitter – github- soundcloud – instagram ….
WHO AM I ?

3. MY DAY TO DAY WORK :
CLEVER CLOUD,
THE IT AUTOMATION COMPANY

4. KEEP YOUR APPS ONLINE. MADE WITH
NODE.JS, SCALA, JAVA, RUBY, PHP,
PYTHON, GO…
Cloud & on premise ;-)

5. AND LEARN A LOT OF THINGS ABOUT
YOUR CODE, APPS, AND GOOD/BAD
DESIGN…

6. GIVE BACK TO THE COMMUNITY
NEVER
GONNA
LET YOU
DOWN
clever-cloud.com

7. FROM
SHIPPING
JAR TO
OPERATE A
SERVICE

8. WHEN YOU
NEED TO
SCALE
THERE ARE 2 WAYS

9. GROWING AND GROWING
UNTIL YOU EXPLODE OR
BECOME WEIRD

10. OR SPLIT THE WORK AND
MAKE YOUR SOFTWARE
WORK AS A TEAM

11. Build an army of fat app
YOU CAN DO BOTH

12. SO WE NEED TO BE ABLE
TO DISPATCH THE WORK
SCALE OUT
• Many workers
doing the same
thing
• No SPOF
• Growing is more
easy
• Introduce best
practice
SCALE UP
• 1 Fat instance
• 1 Fat application
• SPOF (single point
of failure)
• Hard to maintain
• Always has a limit
• Short term
meaning

13. IF YOU ONLY SCALE UP,
YOU GONNA HAVE A BAD TIME

14. SO, HOW TO
SCALE OUT
?
JUST SOME FACTS

15. SPLIT PROCESS AND
STORAGE
Storage
• Databases
• Files
• Sessions
• Events
• …
Code
• Can be replicated
• Stateless
• Process

16. Picking one instance or another doesn’t matter
STATELESSNESS IS THE KEY

17. CONSIDER MORE
THINGS AS DATA
• User account
• Users data
• Files
• Sessions
• Events

18. UNDERSTAND WHAT
IS PROVIDED

19. TRUST YOUR
MIDDLEWARE

20. USE AN EVENT BROKER
TO MODULARIZE YOUR
APP

21. USE AN EVENT BROKER
TO MODULARIZE YOUR
APP
• AMQP
• Celery
• 0MQ
• Redis
• JMS
• Even some http chunk or websocket
• Some case : hadoop, akka…
• …
My talk about rabbitMQ: https://www.youtube.com/watch?v=15mzY2MfDgM&t=3s

22. My talk about rabbitMQ: https://www.youtube.com/watch?v=15mzY2MfDgM&t=3s
CRON + FS IS NEITHER AN EVENT
QUEUE NOR A JOB SCHEDULER

23. BIG CHANGE IN
SOFTWARE INDUSTRY
One instance
One organization
One data repository
One instance
(distributed)
Multiple organization
+ a lot of users
One data repository
YESTEDAY NOW
Multi-tenant

24. INSTANCE FOR ONE
ORGANIZATION
ACID
• Atomicity
• Consistency
• Isolation
• Durability
Powerful
data
management
• Transaction
• User
management
• One above one
Take advantage of ACID
database

25. BUT IT DESIGNS A BOTTLENECK

26. EXAMPLE : E-SHOP ON
CLASSIC MODE

27. EXAMPLE : E-SHOP ON
CLASSIC MODE
User A buy a
hdd
Database Transaction :
• Stock management
• Order management
• Invoice generation
• Customer Account reward
• …
Transaction
user A is
processed
Stock &
Order are just
perfectly
synchronize

28. EXAMPLE : E-SHOP ON
CLASSIC MODE
User A buy a
hdd
Database Transaction :
• Stock management
• Order management
• Invoice generation
• Customer Account reward
• …
Transaction
user A is
processed
Stock &
Order are just
perfectly
synchronize
User B buy a
hdd Transaction
user B is
processed
then

29. EXAMPLE : E-SHOP ON
MULTI-TENANT MODE
i.e. : Multiple shop of various sellers on the same instance

30. EXAMPLE : E-SHOP ON
MULTI-TENANT MODE
User A buy a
hdd on seller A
Database Transaction :
• Stock management
• Order management
• Invoice generation
• Customer Account reward
• …
Transaction
user A is
processed
Stock &
Order are just
perfectly
synchronize
User B buy a
book on seller B Transaction
user B is
processed
then

31. WHO CARE THE SYNCHRONIZATION OF
VENDOR A & B ?

32. CHOOSE
YOUR
DATASTORE
WISELY
YOU CAN SHOULD USE MANY DATASTORES

33. DATASTORE CHOICES
ARE DRIVEN BY USAGE
Make
decisions
based on
needs
Do I need
atomicity of
requests ?
Do I need
concurrent
access ?
Do I mostly
read or
write ?
Do I need
relational ?
Do I need
big storage
capacity ?
Do I need
high
availability
?

34. USE ONLINE
DATABASE / BE
READY TO TEST
IN JUST A FEW
MINUTES
NO NEED TO TRASH YOUR COMPUTER

35. {P, DB, S} aaS
USE OPS FREE SOLUTION TO LEARN
AND START

36. COMMON MISTAKES

37. DO NOT USE THE FILE
SYSTEM AS A DATASTORE
File system are POSIX compliant
• POSIX is ACID
• POSIX is powerful but is a bottleneck
• File System is the nightmare of ops
• File System creates coupling (host provider/OS/language)
• SPOF-free multi tenant File System is a unicorn
STORE IN DATABASE, OR IN A DATASTORE LIKE
S3/RIAKCS DEDICATED TO FILE MANAGEMENT

38. DO NOT USE THE FILE
SYSTEM AS A DATASTORE

39. LOGS IN FILES
I HATE IT

40. USE STREAMING I/O TO
STREAM DATA DIRECTLY
TO DATABASE
HTTP Post data
Temporarily
store as file
or in memory
Store it into
your storage
backend
Say OK to
client

41. USE STREAMING I/O TO
STREAM DATA DIRECTLY
TO DATABASE
HTTP Post data
Directly stream
your data to
Storage
backend
Say OK to
client

42. DO NOT USE
MEMORY AS
DATABASE
LIKE : SHARED / GLOBAL VARIABLE,
CACHE “IN THE CODE”, INTENSIVE
SESSION USAGE…

43. DO NOT USE A VARIABLE
FOR MORE THAN ONE
REQUEST

44. F(X) = X * 2
F(2) = 4
^ WE ASSUME THAT
FOR SAME INPUT, SAME OUTPUT

45. IT’S LIKE MATH FUNCTION

46. Example : GET should not change data on server
RESPECT HTTP

47. data will be lost
CODE
WILL
FAIL

48. CAREFUL USE OF
DARK MAGIC

49. DON’T BE THAT GUY

50. DO NOT USE A
TECHNOLOGY BECAUSE
YOU <3 IT OR BECAUSE
IT’S HYPE : USE IT
BECAUSE IT FITS YOUR
NEEDS
BALANCE YOUR LEARNING CURVE WITH
THE TIME SAVED

51. DO NOT CREATE MONSTERS

52. Monitoring & Bug manager (Sentry)
TRACK BUG & GET METRICS

53. MAKE HARD
COMPUTATION ASYNC

54. SPLIT THE CODE :
MODULES
• Smallest code
base
• Deploy as
service for
each other
• Focus on best
technology for
a problem

55. SMALLEST CODE BASE POSSIBLE
FOR EACH PROGRAM

56. EACH MODULE
IS VIEWED AS
A SERVICE BY
OTHERS
HTTP OR AMQP COMUNICATION
OR AS A CLIENT

57. GET THE BEST TOOL TO
SOLVE YOUR PROBLEM

58. SCALE YOUR TEAM
MODULARIZE YOUR TEAM

59. THE POWER OF
REWRITE EVERYTHING

60. SMALL CODE BASE + MULTIPLE
TECHNOLOGIES =
LEGACY KILLER

61. REWRITE IS QUICK BECAUSE
YOU KNOW ALL THE PROBLEMS
BEFORE IT HAPPENS

62. HAPPY DEVELOPER WORKS BETTER :
ARE YOU HAPPY WHEN YOU START
YOUR IDE?

63. DO NOT BUILD “THE
SERVER” WITH NO DOC

64. USE PROCESS DEPLOYMENT

65. THE GOOD WAY OF DEPLOY AN
APP :
git push

66. AUTOMATE ALL THE
THINGS

67. ALWAYS USE A
REVERSE PROXY
Y U NO USE ONE ?

68. INNOVATE & WRITE KICK ASS APPS

69. I’m @waxzce on twitter
THX FOR LISTENING
& QUESTIONS TIME
There always be special deal
for Atlassian partners