Downloaded 27 times
![“If you can't build a [well-structured]
monolith, what makes you think
microservices are the answer?”
http://www.codingthearchitecture.com/2014/07/06/distributed_big_balls_of_mud.html](https://image.slidesharecdn.com/indicthreads-keynote-150303063013-conversion-gate01/85/Changing-application-demands-What-developers-need-to-know-74-320.jpg)
Uploaded byIndicThreads
Changing application demands: What developers need to know
The document discusses the evolving demands on developers from monolith to microservices architectures. It outlines the advantages and disadvantages of both approaches, including ease of development and deployment complexity, while also examining the principles of DevOps and the importance of collaboration, consistency, and automation in modern software development practices. The piece emphasizes that despite the benefits of microservices, they introduce added complexities that require careful management and design considerations.
More Related Content
Similar to Changing application demands: What developers need to know
![Lect 1 Number systems and base conversions. [Autosaved].pptx](https://cdn.slidesharecdn.com/ss_thumbnails/lect1numbersystemsandbaseconversions-260111134109-67c2d865-thumbnail.jpg?width=640&height=640&fit=bounds)
Changing application demands: What developers need to know
- 1. Changing application demands What developers needto know Arun Gupta, @arungupta Red Hat
- 2. Arun Gupta Director, DeveloperAdvocacy @arungupta blog.arungupta.me arungupta@redhat.com
- 3.
- 4. Monolith Application UI Database BusinessLogic HTMLHTMLHTML CSSCSS HTMLHTMLCDI HTMLHTMLREST HTMLHTMLJSF HTMLHTMLJPA Cache DB
- 5. Monolith Application UI Database BusinessLogic HTMLHTMLHTML CSSCSS HTMLHTMLCDI HTMLHTMLREST HTMLHTMLJSF HTMLHTMLJPA Cache DB
- 6. Monolith Application UI Database BusinessLogic HTMLHTMLHTML CSSCSS HTMLHTMLCDI HTMLHTMLREST HTMLHTMLJSF HTMLHTMLJPA Load Balancer Cache DB
- 7.
- 8.
- 9. Advantages of MonolithApplication
- 10. Advantages of MonolithApplication • Typically packaged in a single .ear
- 11. Advantages of MonolithApplication • Typically packaged in a single .ear • Easy to test (all required services are up)
- 12. Advantages of MonolithApplication • Typically packaged in a single .ear • Easy to test (all required services are up) • Simple to develop
- 13. Monolith Application UI Database BusinessLogic HTMLHTML HTMLHTML HTMLHTML HTMLHTML HTMLHTML Version 1
- 14. Monolith Application UI Database BusinessLogic HTMLHTML HTMLHTML HTMLHTML HTMLHTML HTMLHTML Version 1 UI Database Business Logic HTMLHTML HTMLHTML HTMLHTML HTMLHTML HTMLHTML Version 2
- 15. Monolith Application UI Database BusinessLogic HTMLHTML HTMLHTML HTMLHTML HTMLHTML HTMLHTML Version 1 UI Database Business Logic HTMLHTML HTMLHTML HTMLHTML HTMLHTML HTMLHTML Version 2 UI Database Business Logic HTMLHTML HTMLHTML HTMLHTML HTMLHTML HTMLHTML Version 3
- 16. Monolith Application UI Database BusinessLogic HTMLHTML HTMLHTML HTMLHTML HTMLHTML HTMLHTML Version 1 UI Database Business Logic HTMLHTML HTMLHTML HTMLHTML HTMLHTML HTMLHTML Version 2 UI Database Business Logic HTMLHTML HTMLHTML HTMLHTML HTMLHTML HTMLHTML Version 3 UI Database Business Logic HTMLHTML HTMLHTML HTMLHTML HTMLHTML HTMLHTML Version 4
- 17. Disadvantages of MonolithApplication
- 18. Disadvantages of MonolithApplication • Difficult to deploy and maintain
- 19. Disadvantages of MonolithApplication • Difficult to deploy and maintain • Obstacle to frequent deployments
- 20. Disadvantages of MonolithApplication • Difficult to deploy and maintain • Obstacle to frequent deployments • Makes it difficult to try out new technologies/ framework
- 21.
- 22. –Martin Fowler “building applicationsas suites of services. As well as the fact that services are independently deployable and scalable, each service also provides a firm module boundary, even allowing for different services to be written in different programming languages. They can also be managed by different teams” http://martinfowler.com/articles/microservices.html
- 23. UI Business Logic Persistence Characteristics ofmicroservices 👱 🙍 🙍👱 👱 👱 🙍 🙍👱 👱 👱 🙍 🙍👱 👱
- 24. UI Business Logic Persistence Orders Shipping Catalog Characteristics ofmicroservices 👱 🙍 🙍👱 👱 👱 🙍 🙍👱 👱 👱 🙍 🙍👱 👱
- 25. UI Business Logic Persistence Orders Shipping Catalog Characteristics ofmicroservices 👱 🙍 🙍👱 👱 👱 🙍 🙍👱 👱 👱 🙍 🙍👱 👱
- 26. UI Business Logic Persistence Orders Shipping Catalog Characteristics ofmicroservices 👱 🙍 🙍👱 👱 👱 🙍 🙍👱 👱 👱 🙍 🙍👱 👱
- 27. UI Business Logic Persistence Orders Shipping Catalog Characteristics ofmicroservices 👱 🙍 🙍👱 👱 👱 🙍 🙍👱 👱 👱 🙍 🙍👱 👱
- 28. –Melvin Conway “Any organizationthat designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization's communication structure.” http://www.melconway.com/Home/Committees_Paper.html
- 29. Teams around business capability Orders 👱🙍 🙍👱 👱 Shipping 👱 🙍 🙍👱 👱 Catalog 👱 🙍 🙍👱 👱 Characteristics
- 30.
- 31.
- 32.
- 33. “you build it,you run it!” With great power, comes great responsibility Characteristics
- 34. Designed for failure Faulttolerance is a requirement, not a feature http://techblog.netflix.com/2012/02/fault-tolerance-in-high-volume.html Characteristics
- 36.
- 37.
- 38. Sync or AsyncMessaging Characteristics
- 39.
- 40.
- 41.
- 42. Strategies for decomposing •Verb or usecase - e.g. Checkout UI
- 43. Strategies for decomposing •Verb or usecase - e.g. Checkout UI • Noun - e.g. Catalog product service
- 44. Strategies for decomposing •Verb or usecase - e.g. Checkout UI • Noun - e.g. Catalog product service • Single Responsible Principle - e.g. Unix utilities
- 45.
- 46. Service A Towards microservices EAR WARDBWAR WAR JAR JAR JAR JAR DBCache
- 47. Service A Towards microservices EAR WARDBWAR WAR JAR JAR JAR JAR DBCache
- 48. Service A Towards microservices EAR WARDB Load Balancer WAR WAR JAR JAR JAR JAR DBCache
- 49. Service C WAR Service B WAR AggregatorPattern #1 Service A WAR
- 50. Service C WAR Service B WAR AggregatorPattern #1 DBCache Service A WAR DBCache DBCache
- 51. Service C WAR Service B WAR AggregatorPattern #1 DBCache Service A WAR DBCache DBCache Aggregator Load Balancer
- 52. Service C WAR Service B WAR AggregatorPattern #1 DBCache Service A WAR DBCache DBCache Aggregator Load Balancer
- 53. Service C WAR Service B WAR AggregatorPattern #1 DBCache Service A WAR DBCache DBCache Aggregator Load Balancer
- 54. Aggregator Service C WAR Service B WAR AggregatorPattern #1 DBCache Service A WAR DBCache DBCache Aggregator Load Balancer
- 55. Service C WAR Service B WAR ProxyPattern #1.5 DBCache Service A WAR DBCache DBCache Proxy Load Balancer
- 56. Service C WAR Service B WAR ProxyPattern #1.5 DBCache Service A WAR DBCache DBCache Proxy Load Balancer
- 57. Service C WAR Service B WAR ProxyPattern #1.5 DBCache Service A WAR DBCache DBCache Proxy Load Balancer
- 58. Chained Pattern #2 ServiceA WAR DBCache Load Balancer
- 59. Chained Pattern #2 ServiceA WAR DBCache Load Balancer Service B WAR DBCache
- 60. Chained Pattern #2 ServiceA WAR DBCache Load Balancer Service B WAR DBCache Service C WAR DBCache
- 61. Branch Pattern #3 ServiceA WAR DBCache Load Balancer
- 62. Branch Pattern #3 ServiceA WAR DBCache Load Balancer Service B WAR DBCache
- 63. Branch Pattern #3 ServiceA WAR DBCache Load Balancer Service B WAR DBCache Service D WAR DBCache Service C WAR DBCache
- 64. Shared Resources #4 ServiceB WAR DBCache Service C WAR Service D WAR DBCache Service A WAR DBCache Load Balancer
- 65. Async Messaging #5 ServiceB WAR DBCache Service C WAR Service D WAR DBCache Queue DBCache Service A WAR DBCache Load Balancer
- 66.
- 67. Advantages of microservices • Easierto develop, understand, maintain
- 68. Advantages of microservices • Easierto develop, understand, maintain • Starts faster than a monolith, speeds up deployments
- 69. Advantages of microservices • Easierto develop, understand, maintain • Starts faster than a monolith, speeds up deployments • Local change can be easily deployed, great enabler of CD
- 70. Advantages of microservices • Easierto develop, understand, maintain • Starts faster than a monolith, speeds up deployments • Local change can be easily deployed, great enabler of CD • Each service can scale on X- and Y-axis
- 71. Advantages of microservices • Easierto develop, understand, maintain • Starts faster than a monolith, speeds up deployments • Local change can be easily deployed, great enabler of CD • Each service can scale on X- and Y-axis • Improves fault isolation
- 72. Advantages of microservices • Easierto develop, understand, maintain • Starts faster than a monolith, speeds up deployments • Local change can be easily deployed, great enabler of CD • Each service can scale on X- and Y-axis • Improves fault isolation • Eliminates any long-term commitment to a technology stack
- 73. Advantages of microservices • Easierto develop, understand, maintain • Starts faster than a monolith, speeds up deployments • Local change can be easily deployed, great enabler of CD • Each service can scale on X- and Y-axis • Improves fault isolation • Eliminates any long-term commitment to a technology stack • Freedom of choice of technology, tools, frameworks
- 74. “If you can'tbuild a [well-structured] monolith, what makes you think microservices are the answer?” http://www.codingthearchitecture.com/2014/07/06/distributed_big_balls_of_mud.html
- 75.
- 76. Drawbacks of microservices •Additional complexity of distributed systems
- 77. Drawbacks of microservices •Additional complexity of distributed systems • Significant operational complexity, need high-level of automation
- 78. Drawbacks of microservices •Additional complexity of distributed systems • Significant operational complexity, need high-level of automation • Rollout plan to coordinate deployments
- 79. Drawbacks of microservices •Additional complexity of distributed systems • Significant operational complexity, need high-level of automation • Rollout plan to coordinate deployments • Slower ROI, to begin with
- 81. “Devs” job isto add new features “Ops” job is to keep the site stable and fast 35
- 82. “Ops” job isNOT to keep the site stable and fast 36
- 83. “Ops” job isNOT to keep the site stable and fast “Ops” job is to enable business 36
- 84. “Ops” job isNOT to keep the site stable and fast “Ops” job is to enable business And so is “devs” 36
- 85.
- 86. What is DevOps? It’s DevOps! It’s DevOps! It’s DevOps! It’s DevOps! It’s DevOps! It’s DevOps!
- 87.
- 88.
- 89.
- 90.
- 91.
- 92.
- 93. Is DevOps foryou? https://puppetlabs.com/wp-content/uploads/2013/03/2013-state-of-devops-report.pdf
- 94. Five “C”s ofDevOps
- 95. Five “C”s ofDevOps • Collaboration between “dev” and “ops”
- 96. Five “C”s ofDevOps • Collaboration between “dev” and “ops” • Culture
- 97. Five “C”s ofDevOps • Collaboration between “dev” and “ops” • Culture • Code everything - application and configuration
- 98. Five “C”s ofDevOps • Collaboration between “dev” and “ops” • Culture • Code everything - application and configuration • Consistency - automation over documentation
- 99. Five “C”s ofDevOps • Collaboration between “dev” and “ops” • Culture • Code everything - application and configuration • Consistency - automation over documentation • Continuous delivery
- 100. Collaboration • “Dev” • Engineering •Test • Product management • “Ops” • System administrators • Operations staff • DBAs • Network engineers • Security professionals
- 101. Collaboration • “Dev” • Engineering •Test • Product management • “Ops” • System administrators • Operations staff • DBAs • Network engineers • Security professionals
- 102.
- 103. Culture • Respect other’sexpertise, opinions, responsibilities
- 104. Culture • Respect other’sexpertise, opinions, responsibilities • Trust: Ops to think like devs, devs to think like ops
- 105. Culture • Respect other’sexpertise, opinions, responsibilities • Trust: Ops to think like devs, devs to think like ops • Leads to transparency
- 106. Culture • Respect other’sexpertise, opinions, responsibilities • Trust: Ops to think like devs, devs to think like ops • Leads to transparency • Don’t ignore failure, build joint recovery plans
- 107. Culture • Respect other’sexpertise, opinions, responsibilities • Trust: Ops to think like devs, devs to think like ops • Leads to transparency • Don’t ignore failure, build joint recovery plans • Amplify feedback loops
- 108.
- 109.
- 110.
- 111. Code everything • Applicationcode • Build scripts • Database schema • Configuration files • IDE configurations • Infrastructure • Deployment scripts • Test code and scripts • Provisioning scripts • Monitoring • Logging • …
- 112. “Never send ahuman to do a machine’s job”
- 113.
- 114. Consistency • Automation overdocumentation
- 115. Consistency • Automation overdocumentation • Repeatability Dev Test Prod
- 116. Consistency • Automation overdocumentation • Repeatability • Push-button deployments Dev Test Prod
- 117. Consistency • Automation overdocumentation • Repeatability • Push-button deployments • Managing environments Dev Test Prod
- 118. Consistency • Automation overdocumentation • Repeatability • Push-button deployments • Managing environments Dev Test Prod
- 119. Manage environments • Cloudcomputing: PaaS, OpenShift, … • Virtualization: Virtual Box, Vagrant, … • Containers: Docker, Rocket, … • App server: JBoss EAP, Tomcat, … • Configuration tools: Puppet, Chef, Ansible, Salt, ... • Orchestration: Kubernetes, Swarm, …
- 120.
- 121. Continuous Delivery • AgileManifesto
- 122. Continuous Delivery • AgileManifesto • Continuous Integration
- 123. Continuous Delivery • AgileManifesto • Continuous Integration • Fail fast and recover
- 124. Continuous Delivery • AgileManifesto • Continuous Integration • Fail fast and recover • Self service
- 125. Continuous Delivery • AgileManifesto • Continuous Integration • Fail fast and recover • Self service • 100% Automation
- 126. Continuous Delivery • AgileManifesto • Continuous Integration • Fail fast and recover • Self service • 100% Automation • Proactive monitoring and metrics
- 127.
- 128.
- 129.
- 130. Initial Managed Defined Quantitatively Managed Optimizing Culture& Organization • Teams organized based on platform/ technology • Defined and documented processes • One backlog per team • Adopt agile methodologies • Remove team boundaries • Extended team collaboration • Remove boundary dev/ ops • Common process for all changes • Cross-team continuous improvement • Teams responsible all the way to production • Cross functional teams Build & Deploy • Centralized version control • Automated build scripts • No management of artifacts • Manual deployment • Environments are manually provisioned • Polling CI builds • Any build can be re-created from source control • Management of build artifacts • Automated deployment scripts • Automated provisioning of environments • Commit hook CI builds • Build fails if quality is not met (code analysis, performance, etc.) • Push button deployment and release of any releasable artifact to any environment • Standard deployment process for all environments • Team priorities keeping codebase deployable over doing new work • Builds are not left broken • Orchestrated deployments • Blue Green Deployments • Zero touch Continuous Deployments Release • Infrequent and unreliable releases • Manual process • Painful infrequent but reliable releases • Infrequent but fully automated and reliable releases in any environment • Frequent fully automated releases • Deployment disconnected from release • Canary releases • No rollbacks, always roll forward Data Management • Data migrations are performed manually, no scripts • Data migrations using versioned scripts, performed manually • Automated and versioned changes to datastores • Changes to datastores automatically performed as part of the deployment process • Automatic datastore changes and rollbacks tested with every deployment Test & Verification • Automated unit tests • Separate test environment • Automatic Integration Tests • Static code analysis • Test coverage analysis • Automatic functional tests • Manual performance/ security tests • Fully automatic acceptance tests • Automatic performance/security tests • Manual exploratory testing based on risk based testing analysis • Verify expected business value • Defects found and fixed immediately (roll forward) Information & Reporting • Baseline process metrics • Manual reporting • Visible to report runner • Measure the process • Automatic reporting • Visible to team • Automatic generation of release notes • Pipeline traceability • Reporting history • Visible to cross-silo • Report trend analysis • Real time graphs on deployment pipeline metrics • Dynamic self-service of information • Customizable dashboards • Cross-reference across organizational boundaries
- 131. Deployment Pipeline “End-to-end automation of build,deploy, test, and release process”
- 133.