71–80 of 139 posts
I have a theory that auto-wired Dependency Injection in a single DI container is partly to blame for monolith spaghetti. Once an app reaches a certain size and anything can depend on anything else, reasoning about the whole can become difficult. I think there is value in wiring a monolith together in such a way that each course grained subcomponent exposes a constrained interface into the rest of the system (payments…
I have a theory that auto-wired Dependency Injection in a single DI container is partly to blame for monolith spaghetti. Once an app reaches a certain size and anything can depend on anything else, reasoning about the whole can become difficult. I think there is value in wiring a monolith together in such a way that each course grained subcomponent exposes a constrained interface into the rest of the system (payments…
You can run a single copy of the resulting binary (eg. for testing) that spins up all sub-components, or copy it to multiple machines and start individual parts. The ones which happen to run together can use in-process communication as well, others will have to dial in via remoting.
I have done the full theme park ride on monolith->microservices->monolith. Both have ups and downs. The most important thing I learned is that "microservices" in absolutely no way necessitates "bullshit spread across multiple cloud vendors and other scenarios involving more than 1 computer". What part of microservices says things must be separated by way of an arbitrary wire protocol? We now have a "monolith" (proces…
While we do Microservices at work ( distrubited team and Conway's law does make sense: https://ardalis.com/conways-law-ddd-and-microservices/ )
It doesn't make sense for me personally. So I applied all DDD logic and implemented it in my app.
In dotnet there is a useful feature where functionality from referenced projects is included in your main WebApp. Which makes everything pretty clean.
I use application logic over 2 "gateways". Where a gateway is a dummy solution that contains Swagger, global things for that project ( eg. auth verification) and uses the controllers/logic from the referenced projects.
- SPA - Angular that contains a Ocelot gateway on the same domain ( = no cors issues)
- ApiGateway - Contains all the backend api logic and custom integrations with partners.
- ShopGateway - Is included in the Frontend.
- Frontend - the shop itselve. Currently in the process of making this db-less ( everything over API / messages or using the gateway. The gateway is currently a referenced project ( see up), so everything is pretty fast)
In the meantime, i can make "reasonable" quick adjustments and the logic is really flexible.
Overview of the solution: https://ibb.co/k5wn07x
Note: Db migration from "1 project" to this is not complete yet :( . But it's one of the bigger shifts and i'm already 90% finished before i can start the actual shift to MartenDb from EF / Dapper )
If you want a quick summary on the logic behind, DDD would be the answer.
Architecture astronauts love microservices. I'm watching a government customer take simple, cohesive systems developed by a small team (4-5 people) and split it up into tiny little pieces scattered across different hosting platforms and even clouds. Why? Because it's "fun" for the architects and pads out their resume. Just now, I'm watching a "digital interactions" project that will have dozens of components across t…
I'm involved in a (greenfield) project right now where the lead insists on gluing a bunch of Google Sheets/Forms/Docs/whatnot together with triggers and custom APIs (roadmap TBD) instead of just building a simple website in $framework. Fingers crossed he doesn't discover k8s...
I have done the full theme park ride on monolith->microservices->monolith. Both have ups and downs. The most important thing I learned is that "microservices" in absolutely no way necessitates "bullshit spread across multiple cloud vendors and other scenarios involving more than 1 computer". What part of microservices says things must be separated by way of an arbitrary wire protocol? We now have a "monolith" (proces…
Pretty clearly the pros and cons come down to the application and necessary stability. Need ultra stable? More and smaller microservices usually better. Need fairly stable? Bigger services is fine. Need it to work generally? Build it however you can.
I have done the full theme park ride on monolith->microservices->monolith. Both have ups and downs. The most important thing I learned is that "microservices" in absolutely no way necessitates "bullshit spread across multiple cloud vendors and other scenarios involving more than 1 computer". What part of microservices says things must be separated by way of an arbitrary wire protocol? We now have a "monolith" (proces…
Pretty sure microservices will be remembered as a horribly convoluted stop gap once we have better language modularization. They encourage modular patterns which is usually good, but all that plumbing will eventually become unnecessary. I can’t help but remember building 6 versions of each class in the old ejb days whenever I hear microservices hype.
Microservices and monoliths are opposing extremes on a scale. There is a range somewhere in the middle which is entirely sensible.
I feel like I've found my greatest success with my service abstractions by separating things out based on resource and availability needs of the functionality.
I have done the full theme park ride on monolith->microservices->monolith. Both have ups and downs. The most important thing I learned is that "microservices" in absolutely no way necessitates "bullshit spread across multiple cloud vendors and other scenarios involving more than 1 computer". What part of microservices says things must be separated by way of an arbitrary wire protocol? We now have a "monolith" (proces…
Currently at my day job, we have a monolithic code base with multiple entry points. If you update a library, you have to update the client or keep the changes backwards compatible. I really prefer this over multiple micro services.
Earlier quoted context omitted.
I'm involved in a (greenfield) project right now where the lead insists on gluing a bunch of Google Sheets/Forms/Docs/whatnot together with triggers and custom APIs (roadmap TBD) instead of just building a simple website in $framework. Fingers crossed he doesn't discover k8s...
Do you feel those hosted solutions are worse than rolling your own website? Why stand up your own website and architecture if you can use off the shelf solutions? I am genuinely curious.
One definite disadvantage is testability (which drives stability and ease of refactoring). I can write an automated end-to-end test that will enter some text into a CMS on my site, hit submit, then verify that a post was published. If the CMS is google sheets, I'm going to violate some terms of service and possibly get a blacklisted IP if I do that. Instead I'm going to mock out a response according to the API contract sheets gives me. If they change the API in a subtle way, it may break.
An advantage is that google sheets is probably more robust than my CMS and I'll never be able to look at (or have to fix) their code.
Flexibility cuts both ways: I can't add features to sheets. So if there's a field I really need to validate on the client, I'm out of luck. But also nobody is going to ask for that feature because I obviously can't add it, so that may be good assuming there's a workaround.
I have done the full theme park ride on monolith->microservices->monolith. Both have ups and downs. The most important thing I learned is that "microservices" in absolutely no way necessitates "bullshit spread across multiple cloud vendors and other scenarios involving more than 1 computer". What part of microservices says things must be separated by way of an arbitrary wire protocol? We now have a "monolith" (proces…
That's not a requirement, cf. Erlang/OTP.
But to qualify as a microservice, you need it decoupled enough that you can independently deploy and/or restart individual services. Pretty sure that's a minimum to call yourself microservice-based, and hard to do by just using classes in C++ or something.
Arguably you should also have quite a bit of control over dependencies and their versions. If your service isn't ready for python3, it can keep using python2, or whatever. Taking this to the extreme would generally mean a black box that serializes everything over a network, so that any service can be implemented on any stack. I'm not sure that's fundamental to the idea of microservices, though.
Earlier quoted context omitted.
Pretty sure microservices will be remembered as a horribly convoluted stop gap once we have better language modularization. They encourage modular patterns which is usually good, but all that plumbing will eventually become unnecessary. I can’t help but remember building 6 versions of each class in the old ejb days whenever I hear microservices hype.
Example of better language modularization? Who is working on this?
I wish more languages/compilers/runtimes had a similar capability.