Are you jumping on the microservices bandwagon? When and when not to adopt micro services architecture? If you must, what are the considerations? This slidedeck will help answer a few of those questions...

2. Patterns, Practices that work!
Architecting applications for the cloud
Pros and Cons of Micro
Services
• Ashwini Kuntamukkala
• Sr. Enterprise Solutions Architect, Vizient, Inc
• Twitter @akuntamukkala

3. Business
Technology
Processes

5. Why do we end up here time and again?
• Act first, think later
• Ill conceived scope
• Hastened delivery
timelines
• Short sightedness
• Shipping code pretending
to be agile
• Improper tooling
• Cutting corners
• Early success bolts on
more functionality
• Technical debt goes into
backlog forever
• Improper domain analysis
• Accidental Architecture
• Design Patterns turn into
anti-patterns
• Not paying attention to
non-functional
requirements
Are we doing things right or doing the right things?

6. Common smells
• Large and growing code
repositories
• No separation of
concerns
• Tight coupling and less
cohesion
• Circular dependencies
• Big bang releases
• Painful regression tests
• Buggy and painful
troubleshooting
experience
• Missing and minimal
automation
• Complex deployment
pipelines with manual
steps
• Difficult training and on-
boarding process
• …
Ok…we have a problem. What’s the solution?

7. Micro services...but is it really?
• Buzz word?
• Fad?
• COTS?
• Library?
• Framework?
• Platform?
• Architecture Pattern?

8. Building applications as suite of services. As well as the
fact that services are independently deployable and
scalable, each service also provides a firm module
boundary, even allowing different services to be written
in different programming languages. They can also be
managed by different teams.
Micro Services
- Martin Fowler

9. Don’t get caught up in the buzz. Are you solving the correct problem?
Micro Services
Gone Wild!

10. Small autonomous services
that work together
modeled around a business domain
- Sam Newman

11. UI
Services
DB
UI
Service-A
DB-A
Service-B
DB-B
Service-C
DB-C
Monolith - Single App
Multiple Services
Sharing same database
Composite App
Multiple Micro-Services
Database per Micro-Service

12. Monoliths
• Natural starting point as it is
easier to get started and deliver
value
• Simpler build and deployment
• Simpler scalability
• Simpler security
• Low latency due to intra-
process communication
• Simpler testing
• Simpler logging and monitoring
• Simpler data and database
management
• Simpler transaction
management
• Large code base
• Simple change requires whole
app to be redeployed
• Increased complexity as
functionality is coupled together
• Single type of database doesn’t
meet all requirements
• Tend to get difficult to work with
over time
• Huge resource requirements
• Reduced agility over time
• Coarse-grain transactions
Pros Cons

13. Source:
http://samnewman.io/talks/principles-of-microservices/
http://samnewman.io/index.html

14. Micro Services - Pros
• Smaller manageable
functional units
• Multiple smaller code bases
• Single service provides
single functionality
• Single responsibility per
service
• Clearer separation of
concerns
• Independently scalable
services
• Polyglot persistence as
applicable
• Polyglot programming
language as applicable
• Independently deployable
• Easier on-boarding process
• Frequent functionality
releases
• Decentralized ownership
• Team that develops it,
manages it

15. Micro Services - Cons
• Distributed System Architecture
– Design
– Development
– Deployment
– CAP theorem
• Handle Increased orchestration
• Handle Increased surface area
– Attacks
– Failure
• System and App Observability
• Troubleshooting challenges
• Call Traceability
• Data consistency issues
– Eventual consistency
– Compensatory & reconciliatory
procedures
• Log aggregation
• Rigorous test suite
• Increased latency due to remote
calls
• Strict Service Versioning
• Distributed Configuration
Management
• Organizational Maturity
– Company Culture
– Engineering practices
– IT Operations
– Software defined networks
– On-demand infrastructure
provisioning
• Architectural complexity

16. Source: https://martinfowler.com/bliki/MicroservicePrerequisites.html
• On demand IT provisioning
• System and App Monitoring
• Mature CI/CD pipelines
• DevOps culture

17. Qualifications for micro services
- Application
- Organization

18. Application Qualification Criteria
• What need does this application
solve?
• Is this a business sensitive
application?
• Who is the audience?
• What are the non functional
requirements?
• What type of application is it?
– OLTP
– OLAP
– BI
– Integration
– Batch
– Mash up …
• Is it a data or compute intensive?
• What is the domain model?
• Does domain model decompose
into smaller functional units?
• What data source type fits the
need?
– Traditional RDBMS
– NoSQL
• Graph
• Key Value
• Document
• Column
• Is eventual consistency
acceptable?
• Future scope

19. Organizational Qualification Criteria
• Engineering
– Design and Implement Cloud-Native
applications
• 12 Factor Apps
• Operations
– Continuous Integration
– Continuous Deployment
– On-demand Infrastructure provisioning
– Software Defined Networking
• Data
– Partitioning
– Replication
– Warehousing
– Marts
– Governance
– Virtualization
• Caching Infrastructure
– In memory data grid
– Session storage
• Messaging Infrastructure
– Asynchronous
– Durability
• Security
– SSL
– OAuth, JWT
– Credential Relay
– Service to Service
• Culture
– Cooperation
– Collaboration
– Communication
– Embrace change
– Cutting edge
– Open Source
• PaaS Adoption

20. Common mistakes
• RDD
– Resume driven development
• RDA
– Resume driven architecture
• Not using PaaS
• Let’s build micro-services architecture because
it is cooler

21. Building Cloud-Native
Applications
So you think you are ready to embark on this journey…

22. 12 Factor Applications – Heroku (https://12factor.net)
Criteria Explanation
Codebase One codebase tracked in revision control, many deploys
Dependencies Explicitly declare and isolate dependencies
Configuration Store configuration in the environment
Backing Services Treat backing services as attached resources
Build, release, run Strictly separate build and run stages
Processes Execute the app as one or more stateless processes
Port binding Export services via port binding
Concurrency Scale out via the process model
Disposability Maximize robustness with fast startup and graceful shutdown
Dev/Prod parity Keep development, staging and production as similar as
possible
Logs Treat logs as event streams
Admin processes Run admin/management tasks as one-off processes

23. API Gateway
+
Micro Proxy
Client/UI
Service
Registry
Service
DB
Service
DB
Service
DB
Monitoring
Dashboard
Configuratio
n Server
Auth Z/N
Server
Log
Aggregation
Sample
Microservices Architecture
Cache
Message
Broker

24. Highly recommended reads

25. Domain Driven Design – Eric Evans
• Focus on core domain
• Collaboration between domain
experts and software experts
• Unambiguous language
• Explicit context boundaries
• Exploration and
experimentation

26. Popular Building blocks for Cloud Native Applications
• Service Registry
– Eureka
– Consul
– etcd
• Micro Proxy
– Zuul
• Client side load balancing
– Ribbon
• API Gateway
• Circuit Breakers
– Hysterix + Turbine
• Traceability
– Zipkin
• Configuration Server
• Spring Boot & Spring Cloud
– https://start.spring.io/
• Dropwizard
– http://www.dropwizard.io/

27. Micro services : PaaS
::
Cars : roads

28. PaaS Choices

29. Hands-on lab exercises
• We will use
complimentary tier
offered by Pivotal at
Pivotal Web Services
• Enterprise support for
Cloudfoundry, running
on AWS
• We will use Openshift
Origin VM on our
laptops for hands-on
exercises

30. Questions?

31. Further Reading Material
• https://martinfowler.com/articles/microservices.html
• https://www.safaribooksonline.com/library/view/building-
microservices-with/9780134192468/
• Principles of microservices architecture – Sam Newman
• http://samnewman.io/books/building_microservices/
• https://dzone.com/articles/microservice-architecture-with-
spring-cloud-and-do