Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Changing application demands: What developers need to know

1,061 views

Published on

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

Published in: Software
  • Be the first to comment

Changing application demands: What developers need to know

  1. 1. Changing application
 demands
 
 What developers need to know Arun Gupta, @arungupta Red Hat
  2. 2. Arun Gupta Director, Developer Advocacy @arungupta blog.arungupta.me arungupta@redhat.com
  3. 3. Monolith Application UI Database Business Logic
  4. 4. Monolith Application UI Database Business Logic HTMLHTMLHTML CSSCSS HTMLHTMLCDI HTMLHTMLREST HTMLHTMLJSF HTMLHTMLJPA Cache DB
  5. 5. Monolith Application UI Database Business Logic HTMLHTMLHTML CSSCSS HTMLHTMLCDI HTMLHTMLREST HTMLHTMLJSF HTMLHTMLJPA Cache DB
  6. 6. Monolith Application UI Database Business Logic HTMLHTMLHTML CSSCSS HTMLHTMLCDI HTMLHTMLREST HTMLHTMLJSF HTMLHTMLJPA Load Balancer Cache DB
  7. 7. Monolith Application EAR WAR Load Balancer WAR WAR JAR JAR JAR JAR
  8. 8. Monolith Application EAR WAR Load Balancer WAR WAR JAR JAR JAR JAR Cache DB
  9. 9. Advantages of 
 Monolith Application
  10. 10. Advantages of 
 Monolith Application • Typically packaged in a single .ear
  11. 11. Advantages of 
 Monolith Application • Typically packaged in a single .ear • Easy to test (all required services are up)
  12. 12. Advantages of 
 Monolith Application • Typically packaged in a single .ear • Easy to test (all required services are up) • Simple to develop
  13. 13. Monolith Application UI Database Business Logic HTMLHTML HTMLHTML HTMLHTML HTMLHTML HTMLHTML Version 1
  14. 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. 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. 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. 17. Disadvantages of 
 Monolith Application
  18. 18. Disadvantages of 
 Monolith Application • Difficult to deploy and maintain
  19. 19. Disadvantages of 
 Monolith Application • Difficult to deploy and maintain • Obstacle to frequent deployments
  20. 20. Disadvantages of 
 Monolith Application • Difficult to deploy and maintain • Obstacle to frequent deployments • Makes it difficult to try out new technologies/ framework
  21. 21. http://akfpartners.com/techblog/2008/05/08/splitting-applications-or-services-for-scale/
  22. 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. 23. UI Business Logic Persistence Characteristics of microservices 👱 🙍 🙍👱 👱 👱 🙍 🙍👱 👱 👱 🙍 🙍👱 👱
  24. 24. UI Business Logic Persistence Orders Shipping Catalog Characteristics of microservices 👱 🙍 🙍👱 👱 👱 🙍 🙍👱 👱 👱 🙍 🙍👱 👱
  25. 25. UI Business Logic Persistence Orders Shipping Catalog Characteristics of microservices 👱 🙍 🙍👱 👱 👱 🙍 🙍👱 👱 👱 🙍 🙍👱 👱
  26. 26. UI Business Logic Persistence Orders Shipping Catalog Characteristics of microservices 👱 🙍 🙍👱 👱 👱 🙍 🙍👱 👱 👱 🙍 🙍👱 👱
  27. 27. UI Business Logic Persistence Orders Shipping Catalog Characteristics of microservices 👱 🙍 🙍👱 👱 👱 🙍 🙍👱 👱 👱 🙍 🙍👱 👱
  28. 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. 29. Teams around business capability Orders 👱 🙍 🙍👱 👱 Shipping 👱 🙍 🙍👱 👱 Catalog 👱 🙍 🙍👱 👱 Characteristics
  30. 30. Explicitly Published interface Characteristics
  31. 31. Independently replaceable and upgradeable Characteristics
  32. 32. Characteristics
  33. 33. “you build it, you run it!” With great power, comes great responsibility Characteristics
  34. 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
  35. 35. Characteristics
  36. 36. 100% automated Characteristics
  37. 37. Sync or Async Messaging Characteristics
  38. 38. REST vs Pub/Sub Queue P1 P2 P3 P4 C1 C2 C3 GET PUT POST DELETE Characteristics
  39. 39. “Smart endpoints
 Dumb pipes” Characteristics
  40. 40. Strategies for decomposing
  41. 41. Strategies for decomposing • Verb or usecase - e.g. Checkout UI
  42. 42. Strategies for decomposing • Verb or usecase - e.g. Checkout UI • Noun - e.g. Catalog product service
  43. 43. Strategies for decomposing • Verb or usecase - e.g. Checkout UI • Noun - e.g. Catalog product service • Single Responsible Principle - e.g. Unix utilities
  44. 44. Service A Towards microservices EAR WAR WAR WAR JAR JAR JAR JAR
  45. 45. Service A Towards microservices EAR WAR DBWAR WAR JAR JAR JAR JAR DBCache
  46. 46. Service A Towards microservices EAR WAR DBWAR WAR JAR JAR JAR JAR DBCache
  47. 47. Service A Towards microservices EAR WAR DB Load Balancer WAR WAR JAR JAR JAR JAR DBCache
  48. 48. Service C WAR Service B WAR Aggregator Pattern #1 Service A WAR
  49. 49. Service C WAR Service B WAR Aggregator Pattern #1 DBCache Service A WAR DBCache DBCache
  50. 50. Service C WAR Service B WAR Aggregator Pattern #1 DBCache Service A WAR DBCache DBCache Aggregator Load Balancer
  51. 51. Service C WAR Service B WAR Aggregator Pattern #1 DBCache Service A WAR DBCache DBCache Aggregator Load Balancer
  52. 52. Service C WAR Service B WAR Aggregator Pattern #1 DBCache Service A WAR DBCache DBCache Aggregator Load Balancer
  53. 53. Aggregator Service C WAR Service B WAR Aggregator Pattern #1 DBCache Service A WAR DBCache DBCache Aggregator Load Balancer
  54. 54. Service C WAR Service B WAR Proxy Pattern #1.5 DBCache Service A WAR DBCache DBCache Proxy Load Balancer
  55. 55. Service C WAR Service B WAR Proxy Pattern #1.5 DBCache Service A WAR DBCache DBCache Proxy Load Balancer
  56. 56. Service C WAR Service B WAR Proxy Pattern #1.5 DBCache Service A WAR DBCache DBCache Proxy Load Balancer
  57. 57. Chained Pattern #2 Service A WAR DBCache Load Balancer
  58. 58. Chained Pattern #2 Service A WAR DBCache Load Balancer Service B WAR DBCache
  59. 59. Chained Pattern #2 Service A WAR DBCache Load Balancer Service B WAR DBCache Service C WAR DBCache
  60. 60. Branch Pattern #3 Service A WAR DBCache Load Balancer
  61. 61. Branch Pattern #3 Service A WAR DBCache Load Balancer Service B WAR DBCache
  62. 62. Branch Pattern #3 Service A WAR DBCache Load Balancer Service B WAR DBCache Service D WAR DBCache Service C WAR DBCache
  63. 63. Shared Resources #4 Service B WAR DBCache Service C WAR Service D WAR DBCache Service A WAR DBCache Load Balancer
  64. 64. Async Messaging #5 Service B WAR DBCache Service C WAR Service D WAR DBCache Queue DBCache Service A WAR DBCache Load Balancer
  65. 65. Advantages of microservices
  66. 66. Advantages of microservices • Easier to develop, understand, maintain
  67. 67. Advantages of microservices • Easier to develop, understand, maintain • Starts faster than a monolith, speeds up deployments
  68. 68. 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
  69. 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 • Each service can scale on X- and Y-axis
  70. 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 • Improves fault isolation
  71. 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 • Eliminates any long-term commitment to a technology stack
  72. 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 • Freedom of choice of technology, tools, frameworks
  73. 73. “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
  74. 74. Drawbacks of microservices
  75. 75. Drawbacks of microservices • Additional complexity of distributed systems
  76. 76. Drawbacks of microservices • Additional complexity of distributed systems • Significant operational complexity, need high-level of automation
  77. 77. Drawbacks of microservices • Additional complexity of distributed systems • Significant operational complexity, need high-level of automation • Rollout plan to coordinate deployments
  78. 78. 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
  79. 79. “Devs” job is to add new features “Ops” job is to keep the site stable and fast 35
  80. 80. “Ops” job is NOT to keep the site stable and fast 36
  81. 81. “Ops” job is NOT to keep the site stable and fast “Ops” job is to enable business 36
  82. 82. “Ops” job is NOT to keep the site stable and fast “Ops” job is to enable business And so is “devs” 36
  83. 83. “Dev” “Ops” 37
  84. 84. What is DevOps? It’s 
 DevOps! It’s 
 DevOps! It’s 
 DevOps! It’s 
 DevOps! It’s 
 DevOps! It’s 
 DevOps!
  85. 85. https://sites.google.com/a/jezhumble.net/devops-manifesto/
  86. 86. https://sites.google.com/a/jezhumble.net/devops-manifesto/
  87. 87. https://sites.google.com/a/jezhumble.net/devops-manifesto/
  88. 88. https://sites.google.com/a/jezhumble.net/devops-manifesto/
  89. 89. https://sites.google.com/a/jezhumble.net/devops-manifesto/
  90. 90. https://sites.google.com/a/jezhumble.net/devops-manifesto/
  91. 91. Is DevOps for you? https://puppetlabs.com/wp-content/uploads/2013/03/2013-state-of-devops-report.pdf
  92. 92. Five “C”s of DevOps
  93. 93. Five “C”s of DevOps • Collaboration between “dev” and “ops”
  94. 94. Five “C”s of DevOps • Collaboration between “dev” and “ops” • Culture
  95. 95. Five “C”s of DevOps • Collaboration between “dev” and “ops” • Culture • Code everything - application and configuration
  96. 96. Five “C”s of DevOps • Collaboration between “dev” and “ops” • Culture • Code everything - application and configuration • Consistency - automation over documentation
  97. 97. Five “C”s of DevOps • Collaboration between “dev” and “ops” • Culture • Code everything - application and configuration • Consistency - automation over documentation • Continuous delivery
  98. 98. Collaboration • “Dev” • Engineering • Test • Product management • “Ops” • System administrators • Operations staff • DBAs • Network engineers • Security professionals
  99. 99. Collaboration • “Dev” • Engineering • Test • Product management • “Ops” • System administrators • Operations staff • DBAs • Network engineers • Security professionals
  100. 100. Culture
  101. 101. Culture • Respect other’s expertise, opinions, responsibilities
  102. 102. Culture • Respect other’s expertise, opinions, responsibilities • Trust: Ops to think like devs, devs to think like ops
  103. 103. Culture • Respect other’s expertise, opinions, responsibilities • Trust: Ops to think like devs, devs to think like ops • Leads to transparency
  104. 104. 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
  105. 105. 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
  106. 106. http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr
  107. 107. http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr
  108. 108. http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr “Treat people warmly, issues coldly!”
  109. 109. Code everything • Application code • Build scripts • Database schema • Configuration files • IDE configurations • Infrastructure • Deployment scripts • Test code and scripts • Provisioning scripts • Monitoring • Logging • …
  110. 110. “Never send a human to do a machine’s job”
  111. 111. Consistency
  112. 112. Consistency • Automation over documentation
  113. 113. Consistency • Automation over documentation • Repeatability Dev Test Prod
  114. 114. Consistency • Automation over documentation • Repeatability • Push-button deployments Dev Test Prod
  115. 115. Consistency • Automation over documentation • Repeatability • Push-button deployments • Managing environments Dev Test Prod
  116. 116. Consistency • Automation over documentation • Repeatability • Push-button deployments • Managing environments Dev Test Prod
  117. 117. 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, …
  118. 118. Continuous Delivery
  119. 119. Continuous Delivery • Agile Manifesto
  120. 120. Continuous Delivery • Agile Manifesto • Continuous Integration
  121. 121. Continuous Delivery • Agile Manifesto • Continuous Integration • Fail fast and recover
  122. 122. Continuous Delivery • Agile Manifesto • Continuous Integration • Fail fast and recover • Self service
  123. 123. Continuous Delivery • Agile Manifesto • Continuous Integration • Fail fast and recover • Self service • 100% Automation
  124. 124. Continuous Delivery • Agile Manifesto • Continuous Integration • Fail fast and recover • Self service • 100% Automation • Proactive monitoring and metrics
  125. 125. Build Test Deploy Continuous
 Integration
  126. 126. Build Test Deploy Continuous
 Integration Release Build Test Deploy Manual Acceptance Continuous
 Delivery
  127. 127. Build Test Deploy Continuous
 Integration Release Build Test Deploy Manual Acceptance Continuous
 Delivery Release Build Test Deploy Continuous
 Deployment
  128. 128. 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
  129. 129. Deployment Pipeline “End-to-end automation of build, deploy, test, and release process”
  130. 130. jboss.org

×