| > Great, now do multiple versions of typescript. and jest. and ts-jest. Why would I do that? There is absolutely no reason a single application should be using two versions of Typescript at the same time. What you're talking about is a combinatorial explosion of packages and versions - it's bad, bad, bad for software quality. Upgrade paths can be done gradually. I've done and seen it done more times than I can count. > For how long? Until it gets to what size? That depends a great deal on the type of software and how it was engineered. If you inherit a mess and your engineering team is incapable of not creating a mess then, sure, drawing heavy handed microservice boundaries might make sense. But in that case you're solving an organizational problem not a technical problem. All of the technical benefits you've been claiming are moot. > So generating multiple executables from one repo? That is a monorepo, if you have a bunch of processes that communicate with each other through some channel, be it pipes or sockets or whatever, then I'm going to argue you have microservices. They may be running on one machine, but again, you have multiple processing talking to each other. You could generate multiple executables. Or you can generate a single executable that's able to run in different "modes" (so to speak). What you've shown throughout your writing is you don't quite understand what microservice architecture is. Multiple applications communicating over the network (or whatever) is NOT a "microservice". Why wouldn't you just call that a "service"? A microservice is a very small application that encapsulates some "unit" of your larger application. Where that boundary is drawn is obviously up for debate. I don't wanna digress but I can assure that two applications on the same server talking over a network is NOT a microservice. That's just... like... software, lol. > Now I'll also argue that such code bases are more likely to have strong coupling between components. It doesn't have to be that way, but it becomes harder to resist (or to just stop junior devs from inadvertently doing). Creating a network boundary (a HUGE performance cost) just to prevent people from doing stupid stuff is not good software architecture. > So one executable with multiple network endpoints exposed? Sure. But you have lost some security boundaries in the process. If the only system that can ever have customer PII lives inside a firewall with no public IP address, you've gained security VS PII floating around in the same process memory address as your public endpoints. Your PII lives in a database. Restrict read access to that database (or subset of that database) to applications running on the internal network. The most straightforward way to do that would be through configuration management. Applications accessible to the outside world will never even have read access. With microservices, there is nothing stopping some tiny internal service from exposing data to a public service. Maybe the internal service wrote their ACLs wrong and the data leaked out. What you're describing, again, has nothing to do with microservices and is a problem you need to deal with either way. PII is a data problem not a code problem. Microservice/monolith is a code problem not a data problem. > Also, the Unix philosophy is small dedicated programs that do one thing really well. Kind of like... microservices. So now all programs that communicate over the network are microservices. Do you not see how silly that sounds? > Vs a monolith where you have everything running on one machine under one process. That's not how anyone deploys monolithic applications. You're now trying to claim that monolithic applications only run one server. Confusing. > Different problem domains are best solved with different programming paradigms. That's why we create multiple applications that do different things. Microservices are something totally different. > If you have well defined interfaces you don't need atomic builds. That is kind of the entire point! Unless there are some legal requirements which mandate "blessed builds". The benefit of atomic builds is it's very easy to reproduce the behavior of your application at any given moment. So, for example, a user reports a difficult to find bug and you're only investigating it 2 weeks later. You'll need to rewind your application's "code state" to whatever it was at the time that the user was using your application. For a monolithic application this is as easy as pointing the monolithic repo to some commit SHA. With microservices this is much harder to do without tooling. This can be for many reasons. Sometimes every microservice is a separate repo. Sometimes your development environment isn't running every microservice. > Pure functional peeps say no state at all, and arguably the functional paradigm often works, but the performance hit is insane at times. I'm not even that into FP and this is painful to read. Such a gross misrepresentation of what FP is about. > Microservices say you need to decouple components and that components can only talk through preestablished and agreed upon messages. You mean like function calls? > It enforces this decoupling by isolating different bits of code on the other sides of boundaries You mean like... visibility? As in public/private interfaces? > so that network connections of some type have to be used to communicate between modules Enforcing correctness by placing a network boundary is too heavy handed. There are other ways to achieve the same thing that doesn't involve adding orders of magnitude latency for no reason. > You get some benefits with this, I still maintain it is easier to update to new breaking changes of dependencies on smaller chunks of code rather than adopt a breaking change to a global dependency across possibly hundreds of thousands of lines of code. You do realize that large software existed before microservices became a thing right? And it was maintainable, right? There are so many ways to solve this problem without affecting thousands of lines of code blindly. There's also just as much risk in having 10 services that are running slightly different versions of the same dependency. In fact that's a freaking nightmare. > Because you only need to maintain the API contract, microservices can be deployed in a true CI/CD fashion, with teams constantly releasing changes to their services throughout the day, every workday. Sir, I'm afraid of you have a bad case of buzzworditis. |