Hacker News Reader

> It’s interesting that there are folks who think there must be only one architecture to be the best in all cases.

> To know this enough experience (both good and bad) is needed with both microservices and monoliths.

Over the years I have worked with a huge number of people who are looking for Silver Bullets and Best Practices, generally for one (or both) of these reasons:

- To be blameless if the architecture doesn't work out (building with microservices is a Best Practice, it's not my fault it got very expensive)

- To cut down on the number of deep-thinking decisions they have to make

And to be fair on the second point, I don't necessarily disagree with the premise; if these kinds of decisions allow you to get going quicker, it's not necessarily the wrong choice at the moment. What everyone needs to keep in mind, though, is that if you don't do deep architectural thinking and planning at the start of a project (or even if you do sometimes...), you'll have to revisit it later. Often the same forces and pressures that led to taking shortcuts at the early architectural stages of a project will continue to be present down the road, and it'll be more work to fix it later than to do it right the first time.

It's a tough balance. If there's a high risk that the project won't be alive in 6 months it probably doesn't matter. If it's a prototype that's very likely to get into and stay in production, then it really does matter.

Totally agree on the tough balance. At best it's a trade off of different forms of technical, process, and business debt.

Doing deep enough architectural thinking and planning at the start to focus on maintaining flexibility (which can be achieved in many ways) without premature optimization or engineering can go a long way. Basically, don't work yourself into a corner or concrete too quickly by trying to do too much, or too little is an approach I try to keep in mind. Technical and architectural debt comes with interest as well.

One way to reduce the architectural risk is to make the first version a throwaway. It can burn through assumptions. Similar to design thinking, going broad and converging twice can help get a better sense of vector,

There are fundamental reasons why microservices have become a bit less popular though. If you see a good, elegant microservice architecture, it looks very appealing: independently scalable parts, greater redundancy, etc.

The problem comes when you try to start a new project and begin to realize that except in simple cases, it's exceptionally hard to know ahead of time how you would best be served to split an application up into services. Once there's a network boundary between two pieces of code, there's now an API that needs to be managed carefully: deployments of the two pieces of code may not be in lockstep, rolling one back may be necessary, etc. If you got the split wrong, the refactoring to fix that could be extremely hard.

By comparison, splitting logical services out of a monolith isn't always a cakewalk, but it's usually more straightforward, especially since as you mentioned, it's totally possible to just share the same codebase between services. It could even be the same binary invoked differently.

My feeling is that it's easier to split a monolith than to join microservices that were developed separately together; they might have different codebases and possibly even be written in different programming languages. Therefore, it's probably better to start with a monolith even if you're pretty damn sure you will need some services split off later to scale.

Serverless on the other hand I am more skeptical of. I like certain products that provide generic-ish abstractions as a service: Cloud Run for example seems like a good idea, at least on paper, and Amazon Aurora seems relatively reasonable, too. But I think that they are often too expensive and do not provide enough value to justify it, especially since a lot of serverless tools don't provide terribly generic APIs or services, leading to substantial lock-in.

Both microservices and serverless APIs were sold as near-panaceas to the woes of traditional monoliths, but it's a lot more complicated than that.

edit: When I typed this response, the message I was replying to was different/much shorter.

Apologies, I hit submit accidentally sooner than intended.

Splitting a monolith, in a monorepo, can be conspired to break into microservices a bit easier than going the other way. There's a lot more tooling becoming available.

The committment to cloud, serverless, devops has occured when the complexity of administering servers was high. Banking on progress, the administering servers has become exponentially simpler. The recent project from the basecamp guys (mrsk?) is an example of this.

You could almost roll your own "serverless" with enough postgres exposing itself as a queue and/api. Once you outgrow it, so be it. Tools like Hasura are quite interesting.

Even monorepos are not perfect for evolving to microservices. It’s incredibly hard to refactor generally. We still lack good monorepo tooling. Tests take huge amounts of time to run. Multiple languages becomes painful especially ones with slow compile speed like Rust.

Someone needs to make a programming language that encourages you to write code that can be easily split and recombined. Something that can do remoting well.

I do wish there was more out there about the different ways to design a monorepo and the pros and cons of each.

It took me a while to compile a structure I thought was good to start with but also (hopefully) flexible.

> Monolithic apps can have a service based architecture internally

Not only that, but if you absolutely must (for example different scaling requirements), forking out a service from a monolith and deploying it as microservice is relatively straightforward. Provided source code interdependencies have been maintained cleanly before, which can be done with support from tools.

I definitely agree. More than once I've taken a monolith and sliced out a small piece of it to run as a separate service. That's been a significantly less painful task than trying to aggregate multiple microservices into a less expensive monolith, especially when multiple microservices use the same underlying packages but different conflicting versions or different global configuration.

The interesting thing about doing this is how things kind of end back at n-tier architecture, where one can have abstractions between each layers of the cake to more easily swap in/out technologies as well.

Yeah, definitely. In my experience, the trick is that without doing analysis up front, you don't know exactly what the n-tiers are going to look like. Jumping right to microservices right off the bat is putting a lot of extra overhead at the start of the project (defining HTTP or gRPC or whatever APIs, working out the boilerplate for each project, etc.) without knowing whether the boundaries are appropriate or whether a given component is likely to end up being a hotspot that will need independent scaling.

When you start with a monolith that isn't just a ball of spaghetti (e.g. clear module boundaries), you don't have to put as much work into the whole big picture and it's easier to evolve the internal architecture of one larger service than N smaller services. And if you do discover that one piece of it is appropriate to split off (hotspot, reasonably transactional instead of interactive calling, etc), then you just replace the guts of that module with whatever RPC mechanism you're using and the rest of the application doesn't really need to care about it.

Analysis is important, if we don't know what the problem is, or how to solve it, finding the problem is the first undertaking, and the architecture for it often expands greatly to me.

I often end up viewing the start of apps without a problem to solve might benefit from being a dynamically generated interface set by from a combination of feature flags from subscription to a plan.

That degree of flexibility can seem extreme, but until the patterns from the chaos don't emerge, it can be pretty tough.

As a total aside - Is there/why isn't there a discourse forum for architecture folks to chat about things like this?

This has been one of the most enjoyable threads I've been a part of in HN in recent memory.

> As a total aside - Is there/why isn't there a discourse forum for architecture folks to chat about things like this?

Occasionally I see good discussions on Twitter. I just tried to find a couple of names of people and sadly I can't seem to remember any of them. Sorry.

Otherwise... the discourse generally seems to be "this is The One True Way of doing things and if you're not you should feel bad". And that's not helpful :)

How do you work around DB transactions? For example, in many Spring apps the transaction is common across all DB calls for an HTTP request. Would you put @RequiresNew? Many data sources don’t support this for a singular DB.