Same-process modularization should solve that problem. Splitting the architecture into separate processes means a crash in one module doesn't propagate to other modules, but the whole system still breaks down if the process is essential.
What same-process modularization does _not_ solve is independent lifecycle management. In a monolithic system your change rate often becomes tied to your slowest, most bug prone module or team. If you've some integration test that bakes some piece of important code for 48 hours, you can only make a change _everywhere_ else every 48 hours.
Now sometimes folks (the Windows team famously did this) build systems which identify which tests to run based on changes that occur in the codebase, but that's _not_ easy.
Yes. With the microservice as the unit of deployment, the design is about team structure as much as it is anything else. The team of 4-12 people owns and deploys a service at their own pace, without needing to be part of a larger and slower batch.
If you're interested in iterative development and continuous deployment, which of course I am, it is a natural fit. It is productive in that case.
A system can break without crashing. Incorrectly processing financial transactions due to a bug in price calculations would be a good example of a serious breakage that may well be worse than crashing.
Yes. And the little-understood reason why microservices became the answer is that the tools for defining clear ownership boundaries in a single service were (and to an extent still are) lacking.
Defining a clear public contract in most existing programming languages that cannot be violated by a lazy programmer is tricky. Java's package-private should be the answer but is too blunt and ends up requiring a team to make things public so they can use them. C# has a bit more control that might make clear contracts possible (I haven't tried), but not everyone wants to use it because Microsoft. And most of the popular languages at the time of the rise of microservices had basically no mechanism for defining public versus private interfaces.
Microservices allow you to do that in any language— your HTTP API is your public interface. Anything inside of that is physically impossible to access without adding an explicit build-time dependency, which would be trivial to catch in code review.
Yes, code review could theoretically solve the same problems, but in practice no organization is that disciplined. You need tooling, and those tools didn't exist yet when microservices came to be. We're seeing them develop now (Rust's visibility modifiers are very powerful, and monorepo tools are starting to develop lints that can impose module boundaries on languages that lack them natively), and it's not a coincidence that around the same time we're seeing a lot of people moving back to monoliths.
> With microservices, each team becomes responsible for one part, and (as long as they keep their SLAs) they can't break each other's code.
Well, they still can and do break someone else's code. It is just breaking someones code with more steps in between. And who is at fault isn't necessarily as clear cut.
Yes and no. Would you rather ask for deployment of a microservice owned by a team of 10 people, or a monolith that has changes from a department of 100 people. Which deployment do you think has "extra bureaucracy"? Which one do you think can be done this week?
There are co-ordination costs to microservices. But there are also independence benefits.
> With microservices, each team becomes responsible for one part, and (as long as they keep their SLAs) they can't break each other's code.
When done well, microservices work as a unit of deployment. The team that owns the service code deploys it on their own pace. Sure there is process to follow, but it involves 10 people in that microservice team not 100 people for the monolithic app. This allow for smaller batches and independence of development.
Having micro services doesn’t protect against affecting another team’s code/service. Think of a service changing some behavior or contract on either side of your service. Are you thinking of a person changing the actual code of another team? That can be solved without micro services.
The whole post feels like it came from a parallel universe. People adopted microservices because stack traces are too long! Exposing the implementation details of a function in its type signature is good! The most meaningful way to specify a function is by how it can fail (this one is fun, though)!
No doubt it’s harder to write structured code and assertions against a string stacktrace, but as a human reading it, the information is immensely valuable.
Depends on how your app is structured, but it very well can be.
badvalue = dobadthing();
dostuffwith(badvalue);
Depending on the indirection between dobadthing() and the place that chokes on badvalue the stack trace can be completely worthless. It is one of the reasons people hated the original Spring. Claimed it decoupled stuff but all it really did was obfuscate.
I have seen similar claims made about Clojure. Bad data coming from somewhere, but no way to trace it through the system. Sure you can filter bad data in to the garbage can, but that just masks the issue not fix it.
So… if I ever decide I want to change the call stack of a lower level function… I’m going to break types that all my callers and callers’ callers and callers’ callers’ callers’ are depending on? Like, my call stack is enshrined in a type so that to change it means a refactor all the way up to main()?
It seems a step on the path to learning both the Either Monad and the Validation Monad, especially for someone coming from golang which desperately needs a proper Either Monad and essentially has baked in the worst of both imperative and FP worlds in the way everything returns as if there were an Either Monad but not enough useful combinators nor a semblance of do-notation/Computation Expressions exist.
Which is fun to see, really, because it is interesting watching someone rediscover FP principles from first practice.
I got to this part of the article and concluded it wasn’t worth my time, nor probably anyone else’s
1. Absurd claim that file names aren’t important in a stack trace
2. Claims they’re sharing a feature of F# that is never used, then later reveals they’ve been studying F# for 3 months
3. Then this statement about tagged unions
Just having sum types is not enough: you need some level of type safety and exhaustivity checking in match/switch statements to truly benefit from them.
Go does not. Java did not (maybe now with sealed types and exhausitvity checks on switch statement, but not sure if they've already landed).
Java does have exhaustiveness checking on switch expressions over sealed types in the release JDK, but not switch statements (due to the requirement for backwards compatibility). I'll often find myself writing var _ = <some switch>; to get around this, a very Java idiom if ever there was one, heh
Java does have exhaustiveness checking on switch statements for sealed types, but not enums (for backward compatibility), which is probably what you're using.
Try this:
sealed interface Shape permits Circle, Rectangle { }
record Circle(double radius) implements Shape { }
record Rectangle(double length, double width) implements Shape { }
void test() {
Shape shape = new Circle(5);
switch (shape) {
case Circle _ -> System.out.println("Circle");
case Rectangle _ -> System.out.println("Rectangle"); // Comment out this line to get an error.
}
}
I looked it up and apparently it actually comes from Algol, but I digress. Point being sum types and their equivalents are found all over the place. I wouldn't be surprised to find out modern prologs have them.
God I remember having to deal with F# when I was an intern, what a nightmare. It's like the worst parts of Java and C# smashed into one esoteric language.
C# has a much awaited and active proposal to add DUs to C# so I suspect C# will also support this once live (and continue its legacy of plucking great features from F#).
Another reason why companies moved to microservices is because it is easier to manage smaller projects. Services have stronger boundaries, they can be swapped with newer and alternative implementations, it is possible to combine the power of different technologies.
I came from the other side: I own a huge monolithic web behemoth which is almost unbearable to maintain now. It was built using a now outdated technology, but: it serves customers, it runs the business, it brings profits. Nevertheless, it is a huge pain to even try to change something in it. The project is at its dead end now, it is a one-trick pony who has become too old.
Nowadays I build newer parts using separate well-defined services. It is not textbook microservices, I would call it just services. Imagine building a mini-product that is not publicly available and only used internally. This kind of productized services work well enough to never look back at the fragile monolithic approach.
I dont think so, TST and stacktraces are different.
Stacktraces show me call-stack to the point the error happened. Something TST does not always show: different call-stacks can result in the same (or very similar) TST-stacks.
It is possible to return the stacktrace as part of the TST error (not just an error message but also a stacktrace).
ORMs are a bad idea, even when using OO langs: they make the simple queries slightly simpler (`Users.getById(id: Long)`), they do not help you for hard queries (ORM-using codebases of size usually have hard-SQL-queries "in strings").
Most users of FP langs know this and hence will not even try to implement ORMs.
Look into jOOQ, LINQ-method-syntax (or whatever it is called, without the funny SQLish syntactic sugar), SQLDelight or sqlx for non-ORM options that improve embedding SQL in general purpose langs.
I like the idea of F# type providers but last time I tried (two years ago) they were pretty shit compared to any mainstream ORM/alternative - has that improved ?
Also ORM for simple row selects is a straw-man - their use case is deserializing, updating relationship graphs where they hide away a bunch of code. Should that code be hidden is a different question - but pretending it's there to save you from typing SELECT * FROM foo is kind of disingenuous. Editing graph data structures in most FP languages is just not compatible with OOP approach hence no ORM.
I like TST. We use it in our code (FP'ish Kotlin).
But I also like stack traces, as they show me call-stack to the point the error happened. Something TST does not always show: different call-stacks can result in the same (or very similar) TST-stack.
I must say this take seems a bit... grandiose... to me.
People have been banging on with type systems and similarly "better" capabilities for at least 2 decades [0] and Enterprise continues with a stark preference for language "practicality" and low barrier of entry.
IMO it's because it's best to keep engineers superficially interchangeable rather than having a highly stable system (perhaps stable over spec) and a costly workforce with lots of negotiation leverage. But I digress.
One of the main reasons why companies move from monoliths to microservices is to promote ownership and accountability in large codebases.
In a monolith where everyone owns the code, developers can break each other's code.
With microservices, each team becomes responsible for one part, and (as long as they keep their SLAs) they can't break each other's code.
When something fails it's easier to identify who needs to fix what.
Microservices don't make much sense for small teams if they don't need or don't have the headcount to split responsibilities.