Hacker News Reader

Comment by dpix | Hacker News Reader

I see a lot of places that seem to either think that:

1. Microservices will let them ship things faster or

2. It's microservices everywhere or nothing

Microservices might let you ship faster if you are really good at deciding where to draw the lines between services and really good at managing multiple deployment pipelines and all the infra - that's a pretty tough ask.

Also, if you have a monolith it's perfectly fine to pull out one or two parts that need to scale much more efficiently and leave most of your codebase in the monolith, but a lot of times I see companies think once you have created one microservice the monolith is now the worst thing possible and it needs to be broken up entirely.

My general rules for this are to always start in a monolith and break things out as they start to fail or break other parts of the codebase, and don't go all in just because you now have one microservice that works well by itself

View on HN

This, this, this! It's been said elsewhere in these comments, but the term "micro"-services really do them a disservice, like it's expected that you need to break your application up into little pieces, to eliminate complexity. But many applications are inherently complex, and splitting them up isn't going to get you anywhere.

I've been trying to advocate for a "solar system model of services", where you have a big core application in the middle (the sun), surrounded by helper services of various kinds. Your important business logic can be left alone, but the database, other data stores, functions, timers, queues, integrations with third-party systems, one-off jobs, and other things can all stay in orbit.

There are benefits that you get from multiple services that you don't get from a monolith: having to rely on service discovery instead of hard-coding addresses or passwords, being unable to assume that the server your code is running on will live forever, and requiring a concrete CI-CD pipeline to get your code up-and-running are all good things to have, no matter your model, so it's important to have a clearly-defined process for them. A service-oriented architecture can give you that — put down the pickaxe, you don't need to split the monolith in two.

Another aspect no one seems to talk about is whether your deployment is monolithic or fragmented. It seems like a lot of the pain of managing microservices comes from designing a coherent CI/CD pipeline, how to share libraries between various microservices, etc. If you have a monorepo, good build tooling, and a good infrastructure as code tool, I think much of that pain goes away, but none of those things are easy and the precise selection and combination of tools depends a lot on your organization (I wouldn't recommend Bazel or Nix--build tools--to a small or medium-sized organization, for example).

>> If you have a monorepo, good build tooling, and a good infrastructure as code tool,

Yep, and so many organisations ignore these. Especially after a less successful transition to micro-services.

"you mean you want to spend more time doing non-customer visible development? You just did that micro services thing a while ago!"

"Yes, but to take proper advantage of that we need to invest in the right infrastructure and tooling"

"how can I sell that?"

Honestly, that sounds like the devops team didn't communicate well with the business when they pitched them microservices. The business can't reasonably know that moving to microservices entails a change in infrastructure and tooling--you have to build that into your high level estimates.

Often, they didn’t. How many stories have we all heard about “wow.. transitioning to microservices was way harder than we expected” followed by a move back to monolith instead of fixing the issues.

That doesn’t mean a micro service architecture is wrong... just that you have to either learn from your mistakes or hire an amazingly talented team... that have learned from mistakes somewhere else.

I’ve been pushing for a similar model for years as well but called but used rings to model it. Might have to try your solar system model and see if I have better luck.

I've found it most helpful to think in terms of deployments: Each (micro)service effectively gets deployed independently.

One implication of this is you need to ensure your APIs are backwards compatible with any other services - even if it's only one service that your team also manages. This also includes databases, if shared by multiple services (which I won't get into, suffice to say congrats, your database schema is now also a crappy API).

As soon as you start having concurrent deployment dependencies -- that is, the updates for service a + b both have to be deployed at the same time or things are broken -- you've effectively built a monolith anyway, just with an annoying code layout (eg, spread across multiple repositories).

You can use orchestration to tie these deployments together, but this means you're effectively building a monolith with a microservice architecture. Is that really what you want?

Sharing databases across services (micro or not) is generally a pretty bad idea exactly for reasons around versioning.

Versioning APIs is a pretty standard way to get around this.

If your deployment relies on synchronized service deployments you really dont have independent services at all.

"Sharing databases across services (micro or not) is generally a pretty bad idea"

I don't think such a blanket statement is justified. There are plenty of situations where it may make sense to pull out some functionality into its own service--so it can be written in a different language, scaled independently, isolated from failures, or whatever--but where giving that service its own separate database would be serious overkill, complicating ops and introducing potential data integrity issues for no real benefit.

"If your deployment relies on synchronized service deployments you really dont have independent services at all."

So what? That's really the point: blindly following the Microservices (TM) doctrine is often a mistake. It's better to just solve whatever problem you're facing in the simplest possible way. While that may mean by-the-book microservices with independent databases, in many cases something in between is a better choice.

I didn't mean it as a completely blanket statement, hence why I said "generally". In my experience it's a lot harder to manage a contract between a db schema and multiple codebases over managing versioned contracts between APIs.

"It's better to just solve whatever problem you're facing in the simplest possible way."

I completely agree with this, but I dont beleive that syncronizing deployments across multiple services is ever simple - have been in this situation at a past company where it would take an entire week every 3 months to do a deployment

Fair enough, but I think even "generally" is too strong. There's a huge cost to splitting into multiple dbs, and I'd say it should be avoided by default unless the benefits clearly outweigh the complexity costs. Just to give one example, authentication gets way more difficult with separate dbs, and you get a whole new class of potential security bugs.

Your concerns about versioning and deployments are certainly valid, but I don't think they outweigh the costs of turning your data layer into a distributed system until a project gets very large or those issues are actively causing you headaches.

Writable views or stored procedures are a pretty standard way to versioning database access from clients.

> this means you're effectively building a monolith with a microservice architecture. Is that really what you want?

I actually kinda do want that, although maybe it's a niche thing.

It would be nice to be able to deploy a monolith that's already cut at seams where there's an obvious API boundary. At one extreme, you could imagine a single binary where processes communicate via RPC.

What that would give you is an easy way to split off microservices as they're needed.

I'm sure somebody has done work along these lines.

This is actually a similar approach to how next.js deployed to vercel (previously zeit) works by default. Each page or api endpoint is served by an individual lambda function so they can scale up or down independently

https://nextjs.org/docs/deployment#optimized-for-nextjs

Awesome thank you

At my current place of work we have

1 monolith and 2 "Micro-Serivces"

Working in the monolith is fine, but running tests is slow because it is a giant rails app that is 7+ years old.

There is 1 "microservice" that does its thing and the few people who need to interact with it like it.

the second microservice was created, deployed and abandoned. Now people want to move it into the core monolith. It is a distinct unit of functionality that doesn't really have any overlap with the core app. I'm going through and adding all of the tooling to this project because it enables us to solve a certain class of problem (Report generation) that the monolith can't do very well for a couple of reasons. Articles like this have fueled the fire to re-combine it but the pain points have nothing to do with this particular service being separate.

If it's working well why change it?

If your co-workers argument is just "microservices bad" then obviously they are making a mistake. But in the general I've seen far more frequent inappropriate splitting of monoliths than inappropriate combining of microservices. (this is honestly the first time I've heard of it.)

I mean you admit it yourself, far too often the splitting off is inappropriate. Normally an inappropriate microsservices is a net negative over all that costs you money in the long run. Just because its working doesn't mean it is efficient.

My last two "assimilations" where because one microservice was written in Java. The original guy left and no one (around the company) likes to touch Java (or pretend they don't know/do it) which means it was alaways me who had to update it. It was a very small service, likely why he thought small = micro! but it was about 3 hours of work in the monolith. Now anyone can update/contribute to it and not bug me every time

The other was a microservice that only served the monolith. New features required the monolith to be updated in order to realize the new features.

Makes total sense.

Honestly it doesn't work well now as a developer. It is about a week worth of work away from being a great developer experience. They'll come around. Honestly every time I have split out a separate service it is because the current state of affairs is bad and there is a distinct need. Those handful of things have been rock solid and needed very little attention, but it has been a last resort.

The thing that jumps out to me: there are WAY more page-loading indicators now than there has ever been before. Lots more jumping content, lots more laggy content population, many more elements sliding around...I know "worse is better" is a truism of sorts in technology, but this is ridiculous.

What good do any of these architecture decisions make when the experience for the user, the customer, is measurably worse? I mean, aside from not being able to interact with elements of a page before a chain of JavaScript finally gives the all-clear, sites clearly look worse with grayed placeholders and whatnot. There should be a Conway's Corrollary for revenue-oriented choices.

As Matt Easton says: "Context!"

I think "5 Whys" might be a useful exercise here.

Why was building X as a microservice faster? [reason]? Well, why was that?

I like this. A key tactic is to always do things, such that one can change one's mind!

That advice of starting with a Monolith has consistently been given by those involved in Microservices since the start. I remember a Fowler article in particular. Unfortunately the "if you only have a hammer everything is a nail" analogy holds true when people start looking at where microservices may fit into an overall system architecture. Their answer is invariably - everywhere!

Really small, reusable/shareable and stable domains are the sweet spot for microservices. As you say that is most likely to come from decomposing from a monolith. Microservices can really help with building rich domain components in an overall architecture and removing complexity from other components through delegation to the microservice is my experience. They just don't need to be everywhere.

The same problem of over-eagerness is becoming apparent with some of the movement to event-based architectures. People become obsessed acolytes and there is no other way. When in fact they may well be ideal for a portion of your overall system architecture but are unlikely to serve it all well.

I'm yet to do micro-services at all at work or outside. I count myself lucky :-).

Starting with a monolith could lead to really difficult refactorings unless you structure the code in a way that it can be easily decoupled.

The same argument can be made for building separate services too. Could become very difficult to merge data between two services after you had redundant information being saved across the two because of a bad design up-front.

I once worked in a monolith that was structured in a way that it could have been easily decoupled. It never was because the codebase was so modular and well-tested that the only time we ever felt the need was when trying to assign ownership to runtime exceptions.

https://gocardless.com/blog/getting-started-with-coach/ was the framework.

Exception triage often requires examining the stack regardless— even if you have multiple processes, you're still going to have errors bubbling up from your pool of shared library code.

Law of Demeter!

That idea had a lot of influence from Smalltalk, where the natural way of developing was in a monolith. So tactics like that which are about decoupling by default were a good idea in that context.

https://wiki.c2.com/?LawOfDemeter

Monolith -> microservices : difficult refactoring

Microservices -> monolith : difficult refactoring

Microservices with poorly chosen context boundaries -> microservices with well chosen context boundaries: very difficult refactoring.

"Monolith -> microservices : difficult refactoring" I guess my point is that it doesn't have to be complicated if you architect the monolith carefully. That usually doesn't happen though because frameworks don't necessarily promote the practice and projects are short sighted.

It's also really hard. Trying to determine how to split up any code base into logical divisions such that you when adding the next 5 years of functionality you'll have the fewest number of cross division processes is hard.

This is why Martin Fowler recommends starting with a monolith and refactoring into microservices unless you have extensive experience building out very similar applications in the same domain.

Reply on news.ycombinator.com