The first step to building antifragile software is often to 'break apart the monolith’. A monolithic piece of software constrains your choice of technologies, languages and speed of change to the lowest common denominator, and also represents a system to make robust (at best) or to accept is fragile (at worst).
Antifragile software systems aim to thrive on change, and any such system if it is robust or fragile in its entirely will resist or fear change respectively. Therefore the monolith is often identified as the main problem.
But how to go breaking apart the monolith? This is why I invented the simple Life Preserver design tool that I’ve now used successfully with hundreds of clients across dozens of domains. A couple of examples of the Life Preserver in action are used by the new Spring.io site and linked to below:
In a nutshell, the Life Preserver tool looks to answer the following questions:
Simple to use but sometimes tricky in nuance, my book “Antifragile Software” goes into more detail on how to use the Life Preserver (or at least it will by the end of this week!) with the aim to prepare your architecture to gain the advantages in the right places of separating out antifragile, reactive microservices.
Antifragile software systems aim to thrive on change, and any such system if it is robust or fragile in its entirely will resist or fear change respectively. Therefore the monolith is often identified as the main problem.
But how to go breaking apart the monolith? This is why I invented the simple Life Preserver design tool that I’ve now used successfully with hundreds of clients across dozens of domains. A couple of examples of the Life Preserver in action are used by the new Spring.io site and linked to below:
- Designing and Implementing RESTful Web Services with Spring
- Data Access with Spring
- Designing and Implementing a Web Application with Spring
In a nutshell, the Life Preserver tool looks to answer the following questions:
- Where does my component go? - The Life Preserver tool helps you group together components into areas where they evolve at the same rate as other components.
- What should my component do? - Components can be analysed and migrated towards single-purpose and ensure that they do no accidentally cross-boundaries between evolutionary rates of areas of your application.
- What should be the coupling between my components/areas of my architecture? - Various components and techniques can be assessed for the level of de-coupling they provide between evolutionary areas of your application, allowing you to choose the right level of complexity of approach for the right level of de-coupling. This is the jumping off point to begin to break out some of those single-purpose components as services in their own right, as and when the advantages of microservices become attractive.
Simple to use but sometimes tricky in nuance, my book “Antifragile Software” goes into more detail on how to use the Life Preserver (or at least it will by the end of this week!) with the aim to prepare your architecture to gain the advantages in the right places of separating out antifragile, reactive microservices.
RSS Feed
