Changing application demands: What developers need to know
•
2 j'aime•1,533 vues
Due to the demands of our hyper-connected, Internet-driven economy, users expect speedy delivery of new features, highly engaging personalized user experiences, and smooth, streamlined performance. The result is that best practices for application development and architecture are rapidly changing. Traditional approaches to development are no longer competitive, with the new focus on simplicity, usability, and large-scale DevOps agility. In order to thrive, development teams must adjust to deliver high-quality applications fast. This keynote will discuss: The traditional monolith application vs. the modern application. Architectural considerations for the modern application. How trends such as DevOps and microservices affect application design. Tools, technologies, and techniques for building modern applications. Session at the IndicThreads.com Confence held in Pune, India on 27-28 Feb 2015 http://www.indicthreads.com http://pune15.indicthreads.com
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (20)
Similaire à Changing application demands: What developers need to know
Similaire à Changing application demands: What developers need to know (20)
Plus de IndicThreads
Plus de IndicThreads (20)
Dernier
Dernier (20)
Changing application demands: What developers need to know
- 1. Changing application demands What developers need to know Arun Gupta, @arungupta Red Hat
- 2. Arun Gupta Director, Developer Advocacy @arungupta blog.arungupta.me arungupta@redhat.com
- 4. Monolith Application UI Database Business Logic HTMLHTMLHTML CSSCSS HTMLHTMLCDI HTMLHTMLREST HTMLHTMLJSF HTMLHTMLJPA Cache DB
- 5. Monolith Application UI Database Business Logic HTMLHTMLHTML CSSCSS HTMLHTMLCDI HTMLHTMLREST HTMLHTMLJSF HTMLHTMLJPA Cache DB
- 6. Monolith Application UI Database Business Logic HTMLHTMLHTML CSSCSS HTMLHTMLCDI HTMLHTMLREST HTMLHTMLJSF HTMLHTMLJPA Load Balancer Cache DB
- 9. Advantages of Monolith Application
- 10. Advantages of Monolith Application • Typically packaged in a single .ear
- 11. Advantages of Monolith Application • Typically packaged in a single .ear • Easy to test (all required services are up)
- 12. Advantages of Monolith Application • Typically packaged in a single .ear • Easy to test (all required services are up) • Simple to develop
- 13. Monolith Application UI Database Business Logic HTMLHTML HTMLHTML HTMLHTML HTMLHTML HTMLHTML Version 1
- 14. Monolith Application UI Database Business Logic HTMLHTML HTMLHTML HTMLHTML HTMLHTML HTMLHTML Version 1 UI Database Business Logic HTMLHTML HTMLHTML HTMLHTML HTMLHTML HTMLHTML Version 2
- 15. Monolith Application UI Database Business Logic 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 Business Logic 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 Monolith Application
- 18. Disadvantages of Monolith Application • Difficult to deploy and maintain
- 19. Disadvantages of Monolith Application • Difficult to deploy and maintain • Obstacle to frequent deployments
- 20. Disadvantages of Monolith Application • Difficult to deploy and maintain • Obstacle to frequent deployments • Makes it difficult to try out new technologies/ framework
- 22. –Martin Fowler “building applications as 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 of microservices 👱 🙍 🙍👱 👱 👱 🙍 🙍👱 👱 👱 🙍 🙍👱 👱
- 24. UI Business Logic Persistence Orders Shipping Catalog Characteristics of microservices 👱 🙍 🙍👱 👱 👱 🙍 🙍👱 👱 👱 🙍 🙍👱 👱
- 25. UI Business Logic Persistence Orders Shipping Catalog Characteristics of microservices 👱 🙍 🙍👱 👱 👱 🙍 🙍👱 👱 👱 🙍 🙍👱 👱
- 26. UI Business Logic Persistence Orders Shipping Catalog Characteristics of microservices 👱 🙍 🙍👱 👱 👱 🙍 🙍👱 👱 👱 🙍 🙍👱 👱
- 27. UI Business Logic Persistence Orders Shipping Catalog Characteristics of microservices 👱 🙍 🙍👱 👱 👱 🙍 🙍👱 👱 👱 🙍 🙍👱 👱
- 28. –Melvin Conway “Any organization that 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
- 32. Characteristics
- 33. “you build it, you run it!” With great power, comes great responsibility Characteristics
- 34. Designed for failure Fault tolerance is a requirement, not a feature http://techblog.netflix.com/2012/02/fault-tolerance-in-high-volume.html Characteristics
- 36. Characteristics
- 38. Sync or Async Messaging Characteristics
- 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
- 46. Service A Towards microservices EAR WAR DBWAR WAR JAR JAR JAR JAR DBCache
- 47. Service A Towards microservices EAR WAR DBWAR WAR JAR JAR JAR JAR DBCache
- 48. Service A Towards microservices EAR WAR DB Load Balancer WAR WAR JAR JAR JAR JAR DBCache
- 49. Service C WAR Service B WAR Aggregator Pattern #1 Service A WAR
- 50. Service C WAR Service B WAR Aggregator Pattern #1 DBCache Service A WAR DBCache DBCache
- 51. Service C WAR Service B WAR Aggregator Pattern #1 DBCache Service A WAR DBCache DBCache Aggregator Load Balancer
- 52. Service C WAR Service B WAR Aggregator Pattern #1 DBCache Service A WAR DBCache DBCache Aggregator Load Balancer
- 53. Service C WAR Service B WAR Aggregator Pattern #1 DBCache Service A WAR DBCache DBCache Aggregator Load Balancer
- 54. Aggregator Service C WAR Service B WAR Aggregator Pattern #1 DBCache Service A WAR DBCache DBCache Aggregator Load Balancer
- 55. Service C WAR Service B WAR Proxy Pattern #1.5 DBCache Service A WAR DBCache DBCache Proxy Load Balancer
- 56. Service C WAR Service B WAR Proxy Pattern #1.5 DBCache Service A WAR DBCache DBCache Proxy Load Balancer
- 57. Service C WAR Service B WAR Proxy Pattern #1.5 DBCache Service A WAR DBCache DBCache Proxy Load Balancer
- 58. Chained Pattern #2 Service A WAR DBCache Load Balancer
- 59. Chained Pattern #2 Service A WAR DBCache Load Balancer Service B WAR DBCache
- 60. Chained Pattern #2 Service A WAR DBCache Load Balancer Service B WAR DBCache Service C WAR DBCache
- 61. Branch Pattern #3 Service A WAR DBCache Load Balancer
- 62. Branch Pattern #3 Service A WAR DBCache Load Balancer Service B WAR DBCache
- 63. Branch Pattern #3 Service A WAR DBCache Load Balancer Service B WAR DBCache Service D WAR DBCache Service C WAR DBCache
- 64. Shared Resources #4 Service B WAR DBCache Service C WAR Service D WAR DBCache Service A WAR DBCache Load Balancer
- 65. Async Messaging #5 Service B WAR DBCache Service C WAR Service D WAR DBCache Queue DBCache Service A WAR DBCache Load Balancer
- 67. Advantages of microservices • Easier to develop, understand, maintain
- 68. Advantages of microservices • Easier to develop, understand, maintain • Starts faster than a monolith, speeds up deployments
- 69. Advantages of microservices • Easier to 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 • Easier to 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 • Easier to 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 • Easier to 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 • Easier to 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'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
- 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 is to add new features “Ops” job is to keep the site stable and fast 35
- 82. “Ops” job is NOT to keep the site stable and fast 36
- 83. “Ops” job is NOT to keep the site stable and fast “Ops” job is to enable business 36
- 84. “Ops” job is NOT to keep the site stable and fast “Ops” job is to enable business And so is “devs” 36
- 85. “Dev” “Ops” 37
- 86. What is DevOps? It’s DevOps! It’s DevOps! It’s DevOps! It’s DevOps! It’s DevOps! It’s DevOps!
- 93. Is DevOps for you? https://puppetlabs.com/wp-content/uploads/2013/03/2013-state-of-devops-report.pdf
- 94. Five “C”s of DevOps
- 95. Five “C”s of DevOps • Collaboration between “dev” and “ops”
- 96. Five “C”s of DevOps • Collaboration between “dev” and “ops” • Culture
- 97. Five “C”s of DevOps • Collaboration between “dev” and “ops” • Culture • Code everything - application and configuration
- 98. Five “C”s of DevOps • Collaboration between “dev” and “ops” • Culture • Code everything - application and configuration • Consistency - automation over documentation
- 99. Five “C”s of DevOps • 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. Culture
- 103. Culture • Respect other’s expertise, opinions, responsibilities
- 104. Culture • Respect other’s expertise, opinions, responsibilities • Trust: Ops to think like devs, devs to think like ops
- 105. Culture • Respect other’s expertise, opinions, responsibilities • Trust: Ops to think like devs, devs to think like ops • Leads to transparency
- 106. Culture • Respect other’s expertise, 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’s expertise, 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
- 111. Code everything • Application code • Build scripts • Database schema • Configuration files • IDE configurations • Infrastructure • Deployment scripts • Test code and scripts • Provisioning scripts • Monitoring • Logging • …
- 112. “Never send a human to do a machine’s job”
- 113. Consistency
- 114. Consistency • Automation over documentation
- 115. Consistency • Automation over documentation • Repeatability Dev Test Prod
- 116. Consistency • Automation over documentation • Repeatability • Push-button deployments Dev Test Prod
- 117. Consistency • Automation over documentation • Repeatability • Push-button deployments • Managing environments Dev Test Prod
- 118. Consistency • Automation over documentation • Repeatability • Push-button deployments • Managing environments Dev Test Prod
- 119. Manage environments • Cloud computing: PaaS, OpenShift, … • Virtualization: Virtual Box, Vagrant, … • Containers: Docker, Rocket, … • App server: JBoss EAP, Tomcat, … • Configuration tools: Puppet, Chef, Ansible, Salt, ... • Orchestration: Kubernetes, Swarm, …
- 120. Continuous Delivery
- 121. Continuous Delivery • Agile Manifesto
- 122. Continuous Delivery • Agile Manifesto • Continuous Integration
- 123. Continuous Delivery • Agile Manifesto • Continuous Integration • Fail fast and recover
- 124. Continuous Delivery • Agile Manifesto • Continuous Integration • Fail fast and recover • Self service
- 125. Continuous Delivery • Agile Manifesto • Continuous Integration • Fail fast and recover • Self service • 100% Automation
- 126. Continuous Delivery • Agile Manifesto • Continuous Integration • Fail fast and recover • Self service • 100% Automation • Proactive monitoring and metrics
- 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. jboss.org