Reactive programming is an approach to building software applications that emphasizes building applications that are responsive, resilient, and elastic. Microservices are an architectural style that structures an application as a collection of loosely coupled services, with each service focused on doing a small, well-defined job. The document discusses various benefits and challenges of adopting microservices, including how to determine service boundaries, standardization needs, testing challenges, avoiding coupling between services, importance of monitoring, and designing services for failure. It emphasizes that while microservices provide advantages, teams must be prepared for increased operational and resilience overhead.

1. Mite Mitreski
Voxxed Days Istanbul - 9 May 2015
@mitemitreski
Reactive and microservice pitfalls

2. What is reactive programming?

3. Reactive programming is _______
a) Hype
b) Awesome
c) Different
d) Just the observer pattern
e) Microsoft Excel
f) Manifesto
g) All of above

4. http://www.reactivemanifesto.org/
Responsive
Message Driven
ResilientElastic

5. Microservices
The monolith Microservices

6. Monolithic Architecture

7. The monolith
● Componentization is via Services
● Often organized around Tech abilities
○ UI Expert teams
○ Backend or middleware developers
○ DBA’s

8. … organizations which design systems
... are constrained to produce designs
which are copies of the communication
structures of these organizations...
—Melvin Conway

9. The microservices
● Organized around Business Capabilities
● Products not Projects
○ development team takes full responsibility for the
software in production
○ "you build, you run it" - aka the Amazon way
● SOA done right?

10. Decentralized Governance
Java EE
Clojure
Ruby
C# app
Spring
based
Spring
with tab
indentati
on

11. Decentralized Governance
Java EE
Clojure
Ruby
NodeJS
Spring
based
Spring
with tab
indentati
on
V2
replaced
C# with
NodeJS

12. Other microservice benefits
● Decentralized Data Management
● Evolutionary Design

13. Microservices are the unix way
This is the Unix philosophy: Write programs that
do one thing and do it well. Write programs to
work together. Write programs to handle text
streams, because that is a universal interface.
Doug McIlroy, head of the Bell Labs CSRC (Computing Sciences
Research Center), and inventor of the Unix pipe

14. Mike Gancarz: The UNIX Philosophy
1. Small is beautiful.
2. Make each program do one thing well.
3. Build a prototype as soon as possible.
4. Choose portability over efficiency.
5. Store data in flat text files.
6. Use software leverage to your advantage.
7. Use shell scripts to increase leverage and portability.
8. Avoid captive user interfaces.
9. Make every program a filter.

15. With all the frameworks out there
what do I pick?

16. Reactive Microservices?

17. How NOT to FAIL @ Microservices?

18. #1 How big is too big?

19. As big as a piece of Baklava?

20. #2 Each service on it’s own repo
● Each service should be on a separate VCS
root
○ Physical code separation
● Various dependencies temptations not
possible

21. #3 What to standardize
Java EE
Clojure
Ruby
NodeJS
Spring
based
Spring
with tab
indentati
on
Standardize interface
Free for all

22. #4 How do test all of this?
Nod
eJS
S2App
S1
Nod
eJSMock
App
Mock
End 2 end

23. #5 Coupling avoidance
● Function coupling
● Data structure coupling
● Temporal coupling
● URI coupling

24. #5 Coupling avoidance
● RPC (RMI)
● CORBA
● Shared Serialization
● SOAP
● Resources (REST)

25. #6 Avoid distributed transactions
Space B
Space B
JINI/Gigaspaces example
Space A
SOME
APP

26. #7 Monitoring is essential
Java EE
Clojure
Ruby
NodeJS
Spring
based
Spring
with tab
indentati
on

27. #7 Monitoring is essential
Spring Boot - Actuator
JMX
Custom HTTP monitoring
Gigaspaces UI

28. #8 Use tracking ID
Clojure
Spring
App
NodeJS
ID : 223-305

29. #8 Use tracking ID
Clojure
Spring
App
NodeJS
ID : 223-305
ID : 223-305

30. #8 Use tracking ID
Clojure
Spring
App
NodeJS
ID : 223-305
ID : 223-305
ID : 223-305

31. #12 Design for failure

32. #14 Move to production individually
PROD
S2
1.0.0
S1
1.0.0
App
1.0.0
TEST
S1
1.0.0
App
1.0.0
S2
1.0.0

33. #14 Move to production individually
PROD
S2
1.0.0
S1
1.0.0
App
1.0.0
TEST
S1
1.0.1
App
1.0.0
S2
1.0.0

34. #14 Move to production individually
PROD
S2
1.0.0
S1
1.0.1
App
1.0.0
TEST
S1
1.0.1
App
1.0.0
S2
1.0.0

35. #15 Stability ?
● Timeouts
● Circuit breakers
● Bulkheads
● Handshakes

36. #16 Make batch calls if possible
ServiceClient

37. #16 Make batch calls if possible
ServiceClient

38. Are Microservices the Future?

39. Who uses microservices ?

40. Trends

41. Amazon’s SOA way

42. Standing in the shoulders of giants

43. Summary
Microservices are awesome but be
aware of the challenges and make sure
you use best practices.
Operation and resilience are the
biggest overheads.

44. Summary
Ensure your team is up to the task
and you really need it !
Ensure you have DevOps experties.
Start small and make adjustments
as needed.

45. Summary

46. Questions

47. Microservices resources
● http://martinfowler.com/articles/microservices.html
● Microservices not a free Lunch
● Adventures in a cloudy future