An analysis on whether you are ready to embark on embracing Microservices. Discussing about applicability of Microservices for startups as well as for matured organizations.

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