Stack Overflow vindication

In my last post I talked about how, while the code base for Stack Overflow is monolithic, the architecture actually is not.

I'm sure this statement pisses off someone, somewhere. But when do we cross the line? I would argue that SO isn't a particularly large domain of business logic to begin with. Or, put another way, if SO were a bigger solution and that solution were designed as a series of microservices, it isn't unreasonable to think that most of what SO is today would end up inside of a single microservice anyway.

In fact, imagine a world where there is an open source, industry accepted service for localization and another one for authentication both on the level of acceptance as ElasticSearch. Then, it becomes very easy to imagine that SO would have been architected with those included as well instead of using in-house solutions. 

And then you end up with an architecture where the core of SO is even more focused on one small thing.

Also, since I know that there ARE solutions out there for auth and localization, I have little doubt that if you look around for it, you will find sites or applications which are exactly that; applications which leverage a ton of existing services and then all that is left over is a small core service which IS a microservice. Furthermore, you're bound to find some doing this and claiming to be monoliths.

Monorepo does not equal Monolith. Nor is an architecture not Microservices based simply because there is but a single service 1st party service (or even if there is a single service in totality). Some times the sum total of what needs to be done can be done in a single service without violating any Microservices concerns.

But! The second you start delegating anything beyond database and simple hosting to external services your architecture is no longer purely monolithic.

That being said, I do like the Stack Overflow approach. It is a simplification of my proposal for how to write a new application. Where I had suggested looking for obvious fault lines to split out into microservices. This ensures that you have some proficiency in the area should you need to pivot later and that you aren't just going hog-wild converting everything into microservices or serverless functions. 

What SO has done is sought out pre-existing solutions along those fault lines. And where they found solutions they could host, they took that path over writing their own logic. Smart. 

And, by self-hosting and running 3rd party solutions in-house they face many of the same challenges a Microservices architecture faces. Which in turn means that they DO have some knowledge and proficiency in that area should a need arise.

Basically, I want to clear the air. I don't have any intrinsic issues with the way they designed SO. I only have issues with the claim that the architecture is monolithic and the assumption that because a big successful company has done something this way that it is inherently "correct".

As I stated previously, I think that the specs on their SQL server really speak to a solution which could be more hardware efficient. True, making it more hardware efficient COULD impact performance. And true, hardware costs are easier to control because they are self hosting so they may not care.

I honestly don't think that they NEED to care. Clearly it is working for them. And that is all that matters to them. I'm also grateful for a counter opinion to the "microservices everywhere" and the "cloud everything" non-sense I hear regularly. 

What I hate is the people reading too much into it and trying to draw conclusions like "monoliths everywhere" and "self-host everything".