In this weeks podcast, I wanted to talk about how the size and complexity of a deployable piece of software matters to the ability to deliver value to the customer - and thus ROI on our Software Development.
Or listen at:
Published: Wed, 13 Nov 2019 17:02:38 GMT
Transcript
At some point, hopefully sooner rather than later, our software is deployed for use.
This maybe a website, a mobile app, or the controller for a fridge.
And commonly, once that software has been deployed, we will want to change it and re-deploy it.
In this podcast I want to talk about how the size and the complexity of that software can affect our ability to re-deploy quickly and safely.
Two terms that try to describe the extremes are monolith and microservices.
Wikipedia describes as monolith as:
"... software application which is designed without modularity. Modularity is desirable, in general, as it supports reuse of parts of the application logic and also facilitates maintenance by allowing repair or replacement of parts of the application without requiring wholesale replacement."
Whereas it describes a microservices as:
"a collection of loosely coupled services. In a microservices architecture, services are fine-grained and the protocols are lightweight. The benefit of decomposing an application into different smaller services is that it improves modularity. This makes the application easier to understand, develop, test, and become more resilient to architecture erosion. It parallelizes development by enabling small autonomous teams to develop, deploy and scale their respective services independently"
Both the monolith and microservices can be described in their modularity and suitability for fast change.
Let me explain with an analogy;
Imagine you run a small convenience store - stocking groceries for example.
Due to the size of that store, its perfectly acceptable to have a single person (probably yourself) responsible for everything. You handle the till, you stock the shelves, you order new stock, you handle customer complaints and you manage the books.
That's perfectly acceptable right?
Now image you scale your store up to a superstore.
You certainly cannot manage to operate it all by yourself - you need to scale out ... You need more people.
So you employ 100 people to staff the store.
So day 1, how do you train them?
Do you train all 100 to do everything?
Do you teach all 100 to handle the till, stock the shelves, order new stock, handle customer complaints AND manage the books?
Of course not.
You segregate their duties.
One group will be on the tills - you teach them to handle the tills.
One group will stocking the shelves - you team them to stock the shelves.
And so on.
Now image that you have a new till system and you need to train the team on how to use it.
You only have to train the group that operate the tills.
This specialised group is akin to the microservices - they are modular and specialised. You can train them without having to train the everyone else. And with a microservice, you can change and deploy it with affecting the wider ecosystem.
But image if you'd decided day 1 to train every member of the team to be multi-disciplined - every single one of them could handle the till, stock the shelves, order new stock, etc.
This is akin to the monolith where you'd need to train the entire team.
A much more disruptive and expensive event.
Getting back to software systems;
The key takeaway from this podcast is that by keeping the deployable software focused and relevant to the task in had, it makes it more modular and easier to adapt.
If your team is describing your existing system as a monolith and it is provide hard to change, then they may propose breaking it up into more modular pieces (such as microservices).
By breaking software down into smaller, more modular pieces you achieve a number of things:
Greater understanding of the system by the developer. The human brain can only handle so much at one time - by breaking into small local pieces, it makes it much more practical for a developer to hold a full mental model. It is rarely possible to hold a complete mental modal for large systems - making development both slower and more likely to produce unexpected outcomes.
Testing is quicker as there is a smaller amount of functionality to test.
Deployment will be easier and with lower risk
It can also be cheaper to scale. Because we have smaller more concise pieces we can scale the relevant pieces. For example, on Black Friday we can scale the parts that support the sales increase - without having to needlessly scale other parts.
So, should the monolith always be avoided?
Not always,
In the DevOps Handbook; while the overriding advice is to decouple and become more modular, there is as acknowledgment that monoliths can be easier and possibly more resource efficient at small scale.
And that lines up with my shop keeper analogy. If its a small shop, it will be more effective to be a "jack-of-all-trades" than employ a number of specialised staff.
And sometimes it can be the right thing to do for long term RIO to go monolith first - at least whilel the overall shape and size of the software supports it. And even then you should be considering the technical debt that you will be acquiring while doing it.
At some point, assuming you are successful enough, that monolith will need to be broken up or the repayments on its technical debt will bring your organisation to its knees.
The DevOps Handbook lists eBay, Amazon, Twitter and LinkedIn as case studies of organisations that achieved considerable product & market fit from their monoliths - only to faced considerable risk of failure due to those same monoliths.
In each case, they had to re-architect to just survive. Following their moved from monoliths to microservices they where able thrive and win in the marketplace.
In this episode I've introduced two architectural patterns used to describe software development today.
I've briefly described the pros and cons of both patterns - and more importantly why your development may be talking to you about them.