Monoliths aren't bad in all situations, but in larger projects, it is desirable to work in a more modular way. But microservices bring a lot of complexity which is maybe not always desired or needed. Self-contained Systems, which are autonomous web applications, are an ideal way to make your large application manageable by multiple teams. This session will make a comparison between the 3 architectural styles, monoliths, micro-services and Self-Contained Systems highlighting their strengths and their weaknesses.

2. From Monolith To Micro-service and back
The Self Contained System

3. (Joan R)

4. Microservices: The Right Way (Daniel Woods)

5. (Scott Patt studio)

6. • C4J
• Senior Java Web Developer, Java Coach, Architect
• JSR-375
• Java EE Security API Expert group member
• Java EE Believer
@rdebusscher
@Atbash_EE
http://jsfcorner.blogspot.be
http://javaeesquad.blogspot.be
https://www.atbash.be
W H O A M I
RUDY DE BUSSCHER

7. • "Architecture"
• Monolith
• Micro-service
• Self Contained System
• Guidelines
• Deployment
A G E N D A
M O N O L I T H V S M I C R O - S E R V I C E

8. • "Architecture"
• Monolith
Characteristics
Demo
• Micro-service
• Self Contained System
• Guidelines
• Deployment
A G E N D A
M O N O L I T H V S M I C R O S E R V I C E

9. M O N O L I T H
• WHAT?
• Single code base
• Compiled together
• Single artefact

10. M O N O L I T H ( P R O )
• Easy up and running
• Easier integration
• Uniformity (like UI but also code)
• Consistency

11. M O N O L I T H ( C O N T R A )
• Insult like "legacy"
• Team communication issues
• Slow delivery
• Issues block deployment
• Resource consumption cannot be spread.
• Difficult to maintain for larger codebases
• > 50 000 or > 100 000 LOC ?

12. " B E T T E R " A L T E R N A T I V E S
MICRO-SERVICES
• Successful Examples
• Netflix, Amazon, Zalando, Ebay, ...

13. E T S Y
• Online shop for hand-made / vintage products
• 150 engineers, 50 deploys a day
USING A SINGLE MONOLITH

14. There is no such thing as a "silver bullet"

15. W H A T I S B E S T ?
• Monolith
• Micro-service
• Some other thing
• IT DEPENDS

16. • "Architecture"
• Monolith
Characteristics
Demo
• Micro-service
• Self Contained System
• Guidelines
• Deployment
A G E N D A
M O N O L I T H V S M I C R O S E R V I C E

17. ORDER FLOW

18. Demo
CLASSIC MODELS
SHOP

19. • "Architecture"
• Monolith
• Micro-service
Characteristics
Pitfalls
• Self Contained System
• Guidelines
• Deployment
A G E N D A
M O N O L I T H V S M I C R O S E R V I C E

20. M I C R O - S E R V I C E
• WHAT?
• Software applications as a suite of
independently deployable, small, modular
services and communicates through a well-
defined, lightweight mechanism to serve a
business goal.

21. B U S I N E S S G O A L
• SRP
• Each micro-service
• Single responsibility
• Around a business or technical domain
• BAD - DDD
• Boundary Aware Design (BAD) -> Not used
• Domain Driven Design (DDD)

22. S M A L L
• How small is small?
• Pizza team?
• As much as it takes for a Single Responsibility
• If some micro services are too small
• nano-services (anti-pattern) "single method services."
• group them into larger micro-service.

23. I N D E P E N D E N T L Y

24. I N D E P E N D E N T L Y

25. C O M M U N I C A T I O N
• REST style with JSON data over HTTP.
• Independently, means prepare for failure
• What happens when a micro-service is down?
• Fails also => monolith situation!
• Cache! (see further on)

26. • "Architecture"
• Monolith
• Micro-service
Characteristics
Pitfalls
• Self Contained System
• Guidelines
• Deployment
A G E N D A
M O N O L I T H V S M I C R O S E R V I C E

27. F A L L A C I E S O F D I S T R I B U T E D
C O M P U T I N G
1. The network is reliable.
2. Latency is zero.
3. Bandwidth is infinite.
4. The network is secure.
5. Topology doesn't change.
6. There is one administrator.
7. Transport cost is zero.
8. The network is homogeneous.
FAILURES
SLOWER / CACHING
CONVERSIONS
SECURITY

28. T R A N S A C T I O N A L
• What if "unit of work" span Multiple micro-
services?
• Business rollback / Compensating transaction
• Eventual consistency

29. D I S C O V E R Y
• Where is micro-service I need?
• Where is the Central messaging system?
• Hardcoded through config files
• Discovery tools (Consul, Zookeeper, etc, ...)

30. A S Y N C H R O N O U S
• Async servlet
• Not on same thread
• Async "actions"
• UI puts message on central bus.

31. S P A M O N O L I T H

32. • "Architecture"
• Monolith
• Micro-service
• Self Contained System
• Characteristics
• Demo
• Guidelines
• Deployment
A G E N D A
M O N O L I T H V S M I C R O S E R V I C E

33. S E L F C O N T A I N E D S Y S T E M
• Combines Monolith and Micro-service
characteristics.
• More a micro services then a monolith.
• Tackles some pitfalls of other systems.
• No Silver bullet.

34. S C S C H A R A C T E R I S T I C S
• Each SCS is an autonomous web application.
• Each SCS must include UI, Logic and Data
• Optional Service API
• Inter SCS communication, 3th parties
• Asynchronous communication where possible.
• No shared code / logic
• Each SCS is owned by one team.

35. S C S C H A R A C T E R I S T I C S

36. S C S P R O
• Better maintainability.
• SRP - but on all levels (UI, Logic, Data)
• Fewer units
• Avoid SPA monolith

37. S C S B E S T P R A C T I C E S
• No direct communication
• Use of Service bus
• Asynchronous 'Actions'
• JSON data over REST.
• Caching data other SCS locally
• Domain driven design

38. • "Architecture"
• Monolith
• Micro-service
• Self Contained System
• Characteristics
• Demo
• Guidelines
• Deployment
A G E N D A
M O N O L I T H V S M I C R O S E R V I C E

39. • "Architecture"
• Monolith
• Micro-service
• Self Contained System
• Guidelines
• Deployment
A G E N D A
M O N O L I T H V S M I C R O S E R V I C E

40. G U I D E L I N E S ( 1 )
• All applications starts small
• Work in iterative manner
• Small -> monolith is easier
• Package structure! -> easier split up later
• Refactor later

41. G U I D E L I N E S ( 2 )
• Good failure handling essential
• Services keep on running
• Logging / notifications of failure
• Automatic

42. G U I D E L I N E S ( 3 )
• Data ownership
• Only 1 Service owner of certain Data
• Use event to inform changes
• Event sourcing
• or more in general, data cache
• Each Service needs a cache of the data required to
work.

43. G U I D E L I N E S ( 4 )
• Continous Delivery
• A must for Micro-services / SCS
• Too many deployments
• Too many artefacts
• CD -> Automatic testing needed

44. • "Architecture"
• Monolith
• Micro-service
• Self Contained System
• Guidelines
• Deployment
• Thin / fat
• WildFly / WildFly Swarm
A G E N D A
M O N O L I T H V S M I C R O - S E R V I C E

45. H O W T O D E P L O Y ?
• Classic way with application server?
• App servers have, unfairly, a bad name.
• Fat jar?

46. App Code
App Dependencies
App Runtime
SKINNY
THIN
HOLLOW
FAT

47. F A T J A R
• Easier handling (single file)
• Tailored for you app
• A lot a bytes to transfer for a single change
• Slow (especially creation, transfer)
• Difficult to "layer" them in containers for ex
Docker.

48. T H I N / S K I N N Y W A R
• Just your code.
• Faster handling (network, container layers, ...)
• Infrastructure (server) needs be pre configured.
• Difficult to optimise for single app (if multiple)

49. W H I C H O N E ?
• Dependents on your company culture
• Both are equivalent

50. • "Architecture"
• Monolith
• Micro-service
• Self Contained System
• Guidelines
• Deployment
• Thin / fat
• WildFly / WildFly Swarm
A G E N D A
M O N O L I T H V S M I C R O - S E R V I C E

51. W I L D F L Y S W A R M
• FAT jar of WildFly and your WAR
• Only required server modules added
• Smaller
• Independent from your code
• No WildFly swarm import statements.

52. Demo
WILDFLY SWARM

53. A L T E R N A T I V E S
• Payara micro
• TomEE embedded
• WebSphere Liberty

54. Q & A