Project management is essentially a hard topic, a definition of actual project management is not consisted of one skill like Code design or code quality (vague concept btw) but multiple skills that one should have.
Most outages in the global world we live in comes out of years of malpractices eventually to come to fruition as typical bugs, but dealing with technical debt is the most serious issue there is.
Patterns were always around since before Object Oriented programming as an example we can check a few examples given to me by God, Google, and StackOverflow, despite that, our needs evolve, and hence our code has to change too.
The latest craze with Microservices (Serverless, edge or not) gave us some good and some bad examples out of it, on their credit Amazon fixed a few of their mistakes with Amazon Prime Video, startups that claimed to need Microservices wasn’t so lucky and closed shop in tears.
But what is the solution if not to copy the greats? Fear not, for Pelorio Architecture project is here for you.
Technically i’m promoting it because i truly believe there’s no other way to stay sane in todays world if you don’t think things through instead of jumpting to Agile Chaos maneuvers which is what happens if you don’t take Fragile Manifesto seriously enough.
What it really is a Modular monolith Pattern in the making, and maybe along the line also a style guide, for small projects that will potentially be big enough to actually split them into difference services, but until then… until then you keep your hands out of microservices, you vile beast indie hacker with a one man company.
The only way to stay sane, is to stay humble with a monolith, but your code should be modular, for when the need arise for you to grow, then it will also become a technical debt to refactor, so… the only way to cheaply refactor this in the future, is never mess it up in the first place, with pelorio architecture, a modular monolith for the small projects.
When the discussion comes for actually splitting the monolith we should go back to the definition.
What is Microservices?
A microservices architecture is a way to build applications by developing them as a collection of services. This approach allows you to create, deploy, and manage each service and its architecture diagrams independently.
With this definition we understand that independence is the major benefit from using this, also a seperation of concerns should be an obvious benefit aswell, but that’s not a given if you don’t explicitly design it in your code and database aswell.
If you do it will create an expected technical overhead that only grows as long as your microservices grow, for that reason seperation should not be a small task and grow along with your team, for it will be their life-long burden.
I’d expect seperation to be a Technical but also a team building issue, for the needs of the system can be a task for many, 10 senior people can hold a company, but 9 cannot, for that reason splitting Microservices should be carefully considered while the needs and the company grows at the same time or seperately.
Pelorio Architecture is a work in progress, the idea is to keep it as neutral as possible from actual projects, but keep very generic modules that everyone need like Authorization, Logging, Cronjobs, Limiters, Analytics and so on.
The structure is based on the idea that the project is small, but in a few weeks notice, you might be able to split it and get it prepared for a service split, without significant overhead.
Do you have an opinion on this?
Let me know.
