10

For the love of GOD, if you're an architect or someone in the position where you can make drastic changes to the overarching design of a software system, if you're so keen on enforcing something "cool" just because you've read about it in a blog post/seen it on a youtube video, READ ABOUT IT THOROUGHLY, as in, pick up a fucking book or do actual research. An architect overseas just informed us that a whole legacy PHP application (a fucking monolith with a dysfunctional database, yes, I think someone demented designed it) should be rewritten to a microservice architecture (without a messaging broker, just plain API interaction through HTTP) AND WE'RE KEEPING THE DATABASE WHICH BEGS TO BE PUT DOWN FOR GOOD. So now we're gonna have a clusterfuck of tons of PHP microservices (Q_Q) which interact through plain HTTP APIs (swagger's gonna be put to a test) and all have a single broken database in the center. Talk about a microlithic design. Jesus Christ.

Comments
  • 2
    "Microlithic" it is
  • 1
    Just try to do service-oriented architecture. A lot of people sees soa as msoa... And if you have less than 20 rest API with an API GATEWAY (kong, consul, ...). It's doable and not so horrendous.
    Then show him papers about responsibility segregation on msoa... And DO NOT IMPLEMENT EVENT SOURCING!!! Just do normal command sourcing with segregation/isolation for each service.

    Good luck
  • 0
    @asgs lets do a nanolith hic, cuz the neolitictac is allready taken1/taken2/taken3/taken4...etc.
  • 0
    @jotamontecino yeah!, lets be hAPI!
  • 3
    I wonder how he justified this retarded idea.

    I mean, nowadays, everyone understands that if you have a shared databe and synchronous calls, you are not doing microservices, you’re just adding more network hops, so more things can fail.
  • 0
    @matste I don't know but from what I've seen, people undertake building microservice-oriented architectures waaay too easily. Those same people have probably never heard of the CAP theorem, Amdahl's law, coherency delay etc. And of course I agree that microservices are a great way of building complex systems but if, and only if, the person orchestrating all of that is competent and the crew(devs) actually have some understanding of best practices and patterns when it comes to building them.
  • 1
    There are only 3 real reasons to split something into microservices:
    - to have independent scaling
    - to have independent teams
    - to rewrite a part in completely different technology

    There are other reasons, but they are usually derived from these 3.
  • 1
    @matste It seems like these days everyone just automatically thinks everything needs to be microservices and monoliths are the devil. Everything has it's place, and in many instances monoliths are just fine/preferred. If something requires scaling, move it. Programmers are too susceptible to fads...
  • 1
Add Comment