Do micro apps improve maintainability?
This page is published under the terms of the licence summarized in the footnote.
The principles and characteristics of micro apps are not drivers or goals in themselves.
Division of one macro app into many may make it less efficient, less robust, harder to secure, and harder to manage.
So what is the overarching goal? Flexibility and agility, or simply maintainability?
People can and do modularise the code of a macro app, to make it easier to maintain.
A 3-layer software architecture appeared as long ago as 1979.
Division of one macro app into several micro apps implies:
· Dividing the code into deployables deployed at separate times.
· Distributing the code to separate devices.
· Assigning maintenance responsibilities to multiple teams.
· Allowing different user interfaces to reuse one server-side micro app.
It is easy to see how division into micro apps could turn out to be an anti-maintainability pattern.
Martin says:
“If you need to change the allocation of responsibilities between components, such movements of behaviour, are harder to do when you're crossing process boundaries.
There are always trade-offs; and a lot depends on how integrated the micro apps are required to be.
Many have
presented modularisation into small subsystems as a
pattern for maintainability.
Fred George makes a case for it in this presentation --> http://youtu.be/2rKEveL55TY
Trouble is, the presentation is thin on facts and evidence.
Fred seems to contradict himself in two places
He seems eager to promote a pub-sub solution everywhere
But above all, he seems to be talking only about the easy parts of a system – the enquiries.
The presentations says nothing about modularisation of database structures, and appears to say nothing about update code or business rules.
The “Stonehenge” he complains of appears to be what OO designers of the 1990s produced.
“Inside a large (1million lines of code) system is a small or tiny system trying to get out”
Sure – OOPers have been massively over-engineering systems for the last 20 years.
“Carve up systems into tiny pieces”
What Fred calls Microservices are (of course) small encapsulated modules
He says small de-coupled services (100 lines of code) are good, and reduce the impact of change.
OK.
But he seems to contradict himself on replacement of old services.
He recommends “Allow old service versions to continue alongside new ones”.
First, you surely can’t do that with services that update the same data in different ways.
Second, he also says 6-month old services are rare in his example system and replacing them fast helps to reduce technical debt build up.
“Events are more important than entities”
Sure - I have been telling OOpers that for 20 years.
“Use pub sub style to decouple services and publish events
“A service should publish every interesting conclusion it can.”
Even if there is no subscriber for the event?
Using one central publisher? If not only one publisher, then which publisher(s) to tell of the event?
Example 1 – small enquiry services pin ball each other
New services encapsulate all enquiries on each join table in an existing database.
Hard to believe anybody thinks that is a new idea
If services are focused on join tables (link entities) then what about the kernel entities?
No change to existing database structures or update processes?
Services “pin ball” each other to gather all data required
Interesting idea, but doesn’t sound key to micro services.
Example 2 – pub sub
500 loosely-coupled services all publish their knowledge as events.
He appears to contradict himself.
He says the services are disposable
Yet he also says there are sequential dependencies between them
He replaced unit tests by messages saying “I am broke”.
And surely, you can’t do that with update services?
Footnote: Creative Commons Attribution-No Derivative Works Licence
2.0 23/12/2014 14:35
Attribution: You may copy, distribute and display this copyrighted work
only if you clearly credit “Avancier Limited: http://avancier.co.uk” before the start and
include this footnote at the end.
No Derivative Works: You may copy, distribute, display only complete and verbatim
copies of this page, not derivative works based upon it.
For more information about the
licence, see http://creativecommons.org