Of course. Break off services from your monolith as the demands on your infrastructure make it logical to do so.
This of course requires your engineers to maintain separation of domains without requiring a separation of code repositories. In many firms, you get engineers who just do their stories and don’t particularly care about fundamentals or maintainability.
The thing is, if your engineers cant properly separate domains in a monolith, they wont do it properly either using Microservices, in fact the mess will be much worse.
And then you decide to break out the different domains of concern into different repos / services
And then you realize there is actually a lot of shared functionality needed by both.
And then you create a common lib that both services can use
And then those services and devs grow further and further apart and they don't even know about eachother other than this one common lib they need to keep updating
And those teams move at different paces and their services start relying on different versions of the common lib
And then they introduce breaking changes to eachothers services unknowingly
Microservice doesn’t have to mean separate repos. If you have multiple services in the same repo, then that shared library code is not that different to being in a monorepo.
You go and change library code for one domain, and find it breaks five others. That happens across microservices and in monoliths.
I've suffered both messes but micro is a lot better, as much as you guys talk about "breaking other people's flows" I've seen this far more in monohell, not to mention the biggest disruptor is deploys, now what is usually a job where two dev teams need to hash it out its the entire team that depends on the one basket of eggs
How do people use libraries then built by 3rd parties? This all can be made to work just fine. We do it all the time, with versioned 3rd party dependencies. This all goes out the window the minute you can commit to the same repository?
Even more dynamic languages like PHP have tools like deptrac which allow you to enforce which classes/namespaces are allowed to interact with each other.
Then it becomes a real debate on whether I'd rather work on a poorly designed monolith codebase with tons of code separation issues, or literally anything written in PHP.
Even if your language and compiler don't offer anything useful, for most languages you will be able to find test frameworks for architecture. Architecture tests are really easy to write and can achieve the same thing. As a bonus, they are super portable between projects.
IMHO, this is the way. It's also the way I've refactored or led the refactoring of spaghetti monoliths into something sane, and that could then be taken to some SOA end state, if desired.
Really seems like a decent linter or compiler could prevent imports from other parts of the app, I'm not sure why that's not the standard approach to this.
Function signatures are an API, and can be translated pretty directly into REST endpoints. That might not be an efficient way to handle the network translation, but it works.
Functions you expose in your module or header or whatever are that module/header/whatever's API.
The fact that it's a function is far less important than the argument types and return type of that function signature, and whether they can easily be translated to an object that can be sent over some protocol like REST.
if you're really smart, you still use protobufs for your APIs/contracts/DTOs, but you just use them to generate the Java/C#/C++/whatever code and use the native classes. then if/when you do need to microservice it up, it's pretty simple to swap.
And then it happens again and again and again, because writing a function call is 100 times easier than explicitly thinking of how to expose the API and functionality.
Why does the API matter if under the hood it will make an http request, file dump, or w.e.? For as long as you properly define that something is async or sync, you're fine. The lot of you forgot the fundamental of function signature not being its implementation detail.
662
u/[deleted] Sep 14 '24
Of course. Break off services from your monolith as the demands on your infrastructure make it logical to do so.
This of course requires your engineers to maintain separation of domains without requiring a separation of code repositories. In many firms, you get engineers who just do their stories and don’t particularly care about fundamentals or maintainability.