Recommended
More Related Content
What's hot
What's hot (19)
Similar to The Decomposition Dilemma
Similar to The Decomposition Dilemma (20)
More from JoAnna Cheshire
More from JoAnna Cheshire (20)
Recently uploaded
Recently uploaded (20)
The Decomposition Dilemma
- 1. November 27, 2017 1DXC Proprietary and ConfidentialDXC Proprietary and Confidential November 27, 2017 The Decomposition Dilemma Microservices Days Austin @jpmorgenthal #microservicesdays
- 2. November 27, 2017 2DXC Proprietary and Confidential Why µServices? Application Server Bundle 1 Bundle 2 Bundle 3 Database User Interface Back-end DBA Legacy Apps
- 3. November 27, 2017 3DXC Proprietary and Confidential Conway’s Law Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations Solution Application
- 4. November 27, 2017 4DXC Proprietary and Confidential To decompose or not to decompose, that is the question!
- 5. November 27, 2017 5DXC Proprietary and Confidential Decomposition Strategy 1. Start with bounded contexts 2. Trace dependencies to bottom 3. Address messaging, injection and external configuration impact 4. Extract the data 5. Deploy and test often
- 6. November 27, 2017 6DXC Proprietary and Confidential Think Contextual Boundaries Entertainment Enterprise Customer Network Customer Customer Customer Management
- 7. November 27, 2017 7DXC Proprietary and Confidential Think Contextual Boundaries Subscriber Provider Payment Payment Processor Payment Payment Billing Billing
- 8. November 27, 2017 8DXC Proprietary and Confidential Think Contextual Boundaries Subscriber Provider Payment Payment Processor Payment Payment Billing Billing Prepare
- 9. November 27, 2017 9DXC Proprietary and Confidential Think Contextual Boundaries Subscriber Provider Payment Payment Processor Payment Payment Billing Billing PrepareDeliver
- 10. November 27, 2017 10DXC Proprietary and Confidential Think Contextual Boundaries Subscriber Provider Payment Payment Processor Payment Payment Billing Billing Process Process Receive
- 11. November 27, 2017 11DXC Proprietary and Confidential Think Contextual Boundaries Subscriber Provider Payment Payment Processor Payment Payment Billing Billing Process Process Receive
- 12. November 27, 2017 12DXC Proprietary and Confidential Think Contextual Boundaries Subscriber Provider Payment Payment Processor Payment Payment Billing Billing Process Process Receive
- 13. November 27, 2017 13DXC Proprietary and Confidential Shift from objects to resources TurnLightOff(); { “state”: “off” } https://…/lightswitch/1921
- 14. November 27, 2017 14DXC Proprietary and Confidential Trace dependencies • Monoliths form entanglements around persistence of data • Monoliths expect that various functions data all exist in same repository • Monoliths have code dependencies • Monoliths share data structures to ensure consistency of data representation • Monoliths maintain direct connections with services • Database, messaging, logging, etc. • Carving out a business context often requires these entanglements to be identified and decomposition may require multiple interim states before the microservice can become completely atomic
- 15. November 27, 2017 15DXC Proprietary and Confidential Untangling the data Application Server Bundle 1 Bundle 2 Bundle 3 Database Legacy Apps µService µService
- 16. November 27, 2017 16DXC Proprietary and Confidential Untangling MOM, injection and Aspect-Oriented Programming • Aspects change behavior of the application dynamically for cross-cutting concerns in code whereas microservices introduce cross-cutting concerns through orchestration • Common shared objects often lead to the creation of dependencies that led to the monolith in the first place • Interception of events can help to strangle the original logic and facilitate growth of the new microservice • Monoliths often use injection as a means of configuration often furthering the entanglements • There are no tools to help reverse engineer the necessary injection parameters • Messaging middleware, such XPDL and Camel embed business logic in XML process and mapping files • There are no tools to help reverse engineer the logic trapped in these files and models • You can’t tell if there’s relative aspects of your bounded contexts captured within the XPDL and Camel Models
- 17. November 27, 2017 17DXC Proprietary and Confidential Summary • Decomposition may not always be appropriate for the business • Drivers for microservices are speed, cost, quality and user experience • Bounded contexts may not easily be extracted from the monolith without significant rework • Develop a plan to move from objects/functions to assets • Identify and untangle dependencies • Strangler pattern is just abstraction in action
- 18. November 27, 2017 18DXC Proprietary and ConfidentialDXC Proprietary and Confidential November 27, 2017 Thank you!
Editor's Notes
- This solution has a number of benefits: Simple to develop - the goal of current development tools and IDEs is to support the development of monolithic applications Simple to deploy - you simply need to deploy the WAR file (or directory hierarchy) on the appropriate runtime Simple to scale - you can scale the application by running multiple copies of the application behind a load balancer However, once the application becomes large and the team grows in size, this approach has a number of drawbacks that become increasingly significant: Continuous deployment is difficult - a large monolithic application is also an obstacle to frequent deployments. In order to update one component you have to redeploy the entire application. This will interrupt background tasks (e.g. Quartz jobs in a Java application), regardless of whether they are impacted by the change, and possibly cause problems. There is also the chance that components that haven’t been updated will fail to start correctly. As a result, the risk associated with redeployment increases, which discourages frequent updates. This is especially a problem for user interface developers, since they usually need to iterative rapidly and redeploy frequently. Scaling the application can be difficult - a monolithic architecture is that it can only scale in one dimension. On the one hand, it can scale with an increasing transaction volume by running more copies of the application. Some clouds can even adjust the number of instances dynamically based on load. But on the other hand, this architecture can’t scale with an increasing data volume. Each copy of application instance will access all of the data, which makes caching less effective and increases memory consumption and I/O traffic. Also, different application components have different resource requirements - one might be CPU intensive while another might memory intensive. With a monolithic architecture we cannot scale each component independently Obstacle to scaling development - A monolithic application is also an obstacle to scaling development. Once the application gets to a certain size its useful to divide up the engineering organization into teams that focus on specific functional areas. For example, we might want to have the UI team, accounting team, inventory team, etc. The trouble with a monolithic application is that it prevents the teams from working independently. The teams must coordinate their development efforts and redeployments. It is much more difficult for a team to make a change and update production. Requires a long-term commitment to a technology stack - a monolithic architecture forces you to be married to the technology stack (and in some cases, to a particular version of that technology) you chose at the start of development . With a monolithic application, can be difficult to incrementally adopt a newer technology. For example, let’s imagine that you chose the JVM. You have some language choices since as well as Java you can use other JVM languages that inter-operate nicely with Java such as Groovy and Scala. But components written in non-JVM languages do not have a place within your monolithic architecture. Also, if your application uses a platform framework that subsequently becomes obsolete then it can be challenging to incrementally migrate the application to a newer and better framework. It’s possible that in order to adopt a newer platform framework you have to rewrite the entire application, which is a risky undertaking.