The document discusses architectural patterns in software, particularly focusing on microservices. It outlines the benefits and challenges of adopting microservices, such as improved scalability and deployment but also highlights potential complexities and costs involved. The content emphasizes that organizations should only transition to microservices if their systems have become too complex to manage effectively as monoliths.

2. An architectural pattern is a general, reusable solution to a
commonly occurring problem in software architecture within a
given context
- Wikipedia

3. COMMON ARCHITECTURAL PATTERNS
• Event-driven
• Peer-to-peer
• Service-oriented
• Monolithic
• Micro-services
• Etc.
ARCHITECTURAL PATTERNS

4. A critical analysis on when and how to embrace
Microservices
Asiri Liyanage
Senior Software Architect – Sysco
LABS
Are You Ready for Microservices?

5. Are You Ready for Microservices?
• Inception and growth of an application
• How to identify a MS
• Things to be considered when moving to MS
• Things to be careful of
AGENDA

6. Growth of an Application
• MVP
• Add components one by one
• All the logical components are
bundled together
SYSTEM GROWTH
Source: Reactive-ms-architecture by Jonas Bonér

7. Feel the pain?
• Have to have large infra, just to cater a
small to medium app
• Hard to maintain
• Release cycle is too lengthy, have to build-
deploy entire app
• Too much of testing
↳ Unit testing? integration, performance, load
↳ Small code changes, huge test cycle
↳ No automation!!!
↳ No-trust on the codebase or application as a whole
(fear of code changes)
• Tied to a single language
• That technology suits better than the current
technology for the new task!
MONOLITH
source: http://bits.citrusbyte.com/microservices/

8. PROPERTIES OF MICROSERVICES
• Enables Smaller Code Bases
• Small/focused services
with meaningful functionality, using
the best technology for the job
• Encapsulated Data
↳ Own Datasource
• Can have different technology stacks
• Many small teams
MICROSERVICES
https://dzone.com/articles/what-are-
microservices-actually

9. PROPERTIES OF MICROSERVICES
• Can be scaled independently.
• Independently Deployable
↳ Service Instance per VM
↳ Service Instance per container
↳ Serverless deployment
MICROSERVICES
Source: http://danielcoding.net/wp-content/uploads/2016/08/load-balancer.png

10. Deployment
Instance per VM
Instance per Container
source: https://dzone.com/articles/why-container-based-deployment-is-preferred-for-mi

11. As application complexity rises, start breaking the
system
• Identify areas where you could break the application into smaller components
source: https://cdn.thinglink.me/api/image/936871655911718915/1240/10/scaletowidth
STEP INTO THE GAME

12. How to start?
• Start breaking the system into small
components
• has its own data source
↳ Small code base
• Can be written in the correct language
of choice
• Remember properties of MS?
STEP INTO THE GAME
source: http://bits.citrusbyte.com/microservices/

13. DIFFICULTIES ON STARTING AT THE
INCEPTION!
• Trial and error period with lot of uncertainty
• Many integration points
• Development and Debugging issues,
↳ Testing challenges
↳ Might lead to redundant implementations
↳ Versioning nightmare!
• No domain specialty
• Application (at least UI) consistency, data
and txn consistency, security, performance
• Many instances (or containers) have to be maintained
• For a startup, this may be an overkill
WHY NOT AT THE START OF THE APPLICATION DEVELOPMENT?

14. FOR A MATURED ORGANIZATION
• Integration points are handled through
different means (e.g.: API Gateways,
ESBs, etc)
• Domain specialty is there
↳ There is a matured team who understands the
technology as well the domain
• Controlled by processes
• Development, Deployment practices (CI / CD)
• Dev Ops culture etc.
↳ Engineering process
• Specialty in technology
ARE YOU READY?
source: https://martinfowler.com/bliki/images/microservice-
verdict/productivity.png

15. FOR A MATURED ORGANIZATION
• Central logging frameworks like graylog, logstash etc
↳ Helpful in Debugging and monitoring
• Proper versioning practices
↳ Can use semantic versioning x.x.x
↳ or duals
• Controlled through governance
↳ Maintain contracts
↳ Easy to fix bugs in the component
• For new features and enhancements, micro-services may
sound perfect for a matured organization
ARE YOU READY?

16. WHAT OTHER THINGS TO CONSIDER?
• API Gateway – fault-tolerant APIs
↳ Circuit-breaker pattern
• Design for auto-scaling
↳ Local status should not be
maintained
↳ Co-relation IDs
• Containerization
• Asynchronous message passing
ADDITIONAL THINGS THAT GO HAND IN HAND WITH
MICROSERVICES
Source: http://bit.ly/2xoUmzG

17. Don't even consider microservices unless you have a
system that's too complex to manage as a monolith.
- Martin Fowler

18. Be Careful
• Distributed systems are prone to
failures
• Eventual consistency - may be suitable
for FB but not for a payment app!
• Complexity in dependency
management, testing and debugging
• Complexity in release management
• Cost - if not properly designed, might
lead to higher costs
THINGS TO REMEMBER
Source: http://bit.ly/2h6m4rj

19. Be Careful
• Serialization between microservices
• Additional complexity in testing a
distributed system
• Increased complexity in deployment
• Increased network communication
• Skill of the team matters
• Microservices is NOT the only choice!
THINGS TO REMEMBER
Source: http://bit.ly/2wZYhn0

20. Thank you