Hacker News Reader

I've always got the impression that micro-services are a bad idea most of the time, apart from sometimes where they're not. Mainly if you're really big.

There are a lot of advantages to having a monolith, especially in statically typed languages.

Every extra service you add is costly, it involves setup, build steps that can break, extra things to monitor, more complex development environment, less flexibility, harder to redesign, harder to fix flaws in the original architecture, etc.

You need a certain level of maturity in devops practices before microservices are worth it.

Deploying an extra service to a kubernetes cluster, for example, is neither costly nor prone to breaking nor harder to monitor, etc.

I think the best practice nowadays is for a small startup to first write a monolith and then later split it out into microservices when they're ready.

To me it seems guaranteed that it is more expensive, regardless of if you use [insert trendy tool here].

There's always something that can break. More parts, more breakdowns. The services have to communicate, those communication channels are extra points of failure. What happens when one service inadvertently passes along something another one can't decode properly?

Ooops, wasn't expecting unicode! Ooops, wasn't expecting a long int! Oops, the JSON encoder we used in this service spits out stuff the JSON decoder in this one hates! Ooops, we upgraded a package in this service, but not that one! And on, and on.

And when something does inevitably break in the chain, there's the extra cost in debugging of figuring out which bit actually broke.

Agreed on all counts. The only time I recommend multiple services, rather than just load-balancing across monolithic applications, is when part of it's written on a different stack. As an example: I'm writing a gizmo with a Ruby core and a NodeJS ingest endpoint, and yeah, I'll probably run them on separate machines.

But here's the dirty secret: if you have a load balancer in front of your application, you already have a way to send requests for feature X to a separate pool of machines if that feature is a hot spot for you currently--and unless your application hits some really degenerate cases your base RAM load Simply Should Not be that high for your application in the first place, making the marginal cost and machine sizing floor less of an issue.

There are benefits to microservices in some environments, chiefly to reflect your org chart when your human protocols are breaking down. They tend to be marginal, and whether they outstrip the increased overhead of dealing with more moving parts (whether in your code or not; I quite like k8s but I still wouldn't want somebody less comfortable with it than I am running it in production, and plenty of those folks do!) is in many ways up in the air.

It's important to realize the level of abstraction going on here. This is all philosophical discussion of how much Buddha-nature is in a particular company.

If your application is composed of single-purpose modules, which are well documented, which have clean public interfaces, which are instrumented for monitoring, which can be scaled by using a load-balancing message router of some kind... and it works well, who cares whether you call it micro-services, Web Services, SOA, or FactoryFactory-Producer/Consumer Ecosystem?

It's not about what you call it, it's about the overhead having many services entails.

You should have exactly the number of services required.

This may be hard to plan out from the beginning, but if all is basically sound, you may be able to reduce that number later. (E.g. when a module is called only by one other module, and there's no requirement for them to scale independently, maybe they should be one module.)

I feel like you're just saying the same thing a different way.

Most development doesn't happen in a "we know exactly where we're going" way.

This all sounds like some perfect, waterfall development cycle, everything's designed on paper in UML and the code is then written to spec without any changes, no requirements change, no interfaces change.

That model of development simply doesn't exist in the real world.

Your profile and blog say you're a sysadmin, do micro-services keep you in a job ;) It's one thing to make a bunch of micro-services as a sysadmin. It's quite another to base an ever growing and mutating production code base around them that actually has no clear path to success and an only vague understanding of future requirements.

Oh, no, my workplace avoids microservices like the plague. I can only think of one: PDF generation is handled by a network call that hands a webpage to a heavily firewalled (in and out) special container that hands back a PDF. There's no state in the container other than what it's processing, so we can discard and regenerate them.

We keep development and operations staff tied closely together as a team, and have done since well before "devops" was coined.

Even if you're not really big, sometimes it's helpful just to have everything broken up and not have to go to a 750,000 LOC solution and find the 10-line file that you need to edit.

I'm on the architecture side so am bearing the brunt of the complexity but the senior and especially mid level developers who have code open 7.8 hours a day say the few things we do that have real microservices are the easiest to debug and work on. The monolithic apps take longer to get less done.

Agreed though that it certainly adds complexity on the admin/arch/ops side.

Having microservices doesn't really solve this problem, though, because you still have all those lines of code, plus all the extra code to make it all talk to each other. If the problem is one of organization, that can probably also be solved in large codebases without breaking into multiple systems.

Monolith: a->b

Microservice: a->async->serialization->network->serialization->scheduling->b

A monolith is extremely simple to traverse with a debugger, a microservice is not. I can make a dozen jumps over/into/out in less time than it would take me to open Fiddler or man tcpdump.

I have heard that some companies have tooling that makes the microservices debugging situation tolerable or sometimes even better than monolith (e.g. writing tests for you by snooping the network layer), but I have yet to play with any. Do you have recommendations?

Very much this.

It may be worthwhile for really complex and "business vice separated" services to be written as micro services because it gives you clear separation of concerns. But, in reality, to often you see a single logical service getting implemented with a lot of (N/W + serialization + management) costs unnecessarily just because it is cool to say that you did micro services.

My thumb rule is : If you don't foresee different teams of devs working on these different services, then you're better off leaving it as a monolith and scaling it as a whole application instead.

Yes, I've always seen microservices as an organizational win over any type of technical win.

Basically having separate teams work on one code base with one deployment cycle can sometimes be really tough. And sometimes you can get a big win by splitting up this service so multiple teams can each have their own service to focus on.

This whole team of one developer supporting 8 microservices seems ludicrious to me.

I completely agree with you.

I tend to like the idea of the 2 pizzas rule from Jeff Bezos.

Having a small team (let say under 10 people) manage a service end to end (from spec to code to production) can be really efficient.

On large code bases/large products, this can help a lot, offsetting the cost of a more complex architecture.

However in a microservice architecture, the APIs between services is critical. It's a contract between services, and it should be clearly stated, you cannot go berserk every other day and change it. You also need to establish clear rules about versioning, deprecation and end of life of said APIs.

(by the way, it would be nice if we had a standard to negotiate API versions, for example stating that a rest API must always have a /version which lists the available versions, if some versions are deprecated and when they will be EOLed).

That's completely orthogonal to microservices, though. Having your modules communicate to each other via function calls does not make them significantly less modular than having them communicate to each other via network requests, but it removes a lot of complexity in serialization and network protocols.

Technically you're right. Practically, though, putting some code in one process and some in another helps you leverage Conway's Law to make lazy, rushed, or untrained developers respect the intended separations in your designs.

You won't just jam another getter in that Singleton if that Singleton is in another process.

It can work the opposite way just as easily. Code that should go in one microservice ends up in a different one because the developer is rushed and doesn't want to go to the extra work of changing multiple services.

Microservices really shine when your setup requires HA everywhere. If you're running multiple copies of everything and need your overall product to still run while parts fail, then it's a lot easier when the individual parts are small microservices that do one thing with predictable operating conditions.

If you're not running in High Availability, and can tolerate one copy of everything, then monolithic probably makes more sense. Glue it all together and roll out improvements across all the parts at once.

This is not a real distinction, though. You can have N instances of a monolith if it's written smartly (generally speaking, where "smart" equals "is a twelve-factor app").

And frankly, for the 95% and probably the 99% case, running a copy of each monolithic application its own auto-scaling group is probably significantly less work and less hair-pulling than the chasing the microservice dragon.

> I've always got the impression that micro-services are a bad idea most of the time, apart from sometimes where they're not.

I'll argue that if you're building something, you should probably build it as a monolith, with the exception of some well-defined services (like authentication & authorisation). Once you've got version 1 built, then you know enough about the problem that you're ready to consider breaking stuff off into microservices (this is why auth^2 make sense to break off from the get-go: they're pretty well-understood at this point, so we all should know how to handle them).

Premature microservicement is the root of much evil. Trying to break things up into services before you actually understand the problem will only lead to tears & suffering.

You're also making a lot of assumptions. I started working in 2004 and in 2006 I was already doing 'microservices', I was responsible for a few web services (.NET) (with a few endpoints each), other colleagues had others. These web services where part of a bigger system (out of the many that we had). Emphasis here is on few endpoints, the services where split on functionality, some services talked to other services, some directly to the database. One of the reasons for the split was also because we were using Visual Source Safe and multiple people working on the same code was hard. So yes, I think 'Microservices' is a buzzword, it's been driven by the use of containers, deployment automation, and the assumptions that people have done monotliths because they didn't know better is wrong. Every sane engineer who has put too much functionality in a service which at some point caused problems with scaling, agility, etc, would take measures to address it.

Yes, people were doing microservices before the name appeared, but that's true of all design and architectural patterns. A few people/teams implement similar solutions to similar problems, then someone recognizes the similitude and names that general pattern. Then it becomes easier to know in which conditions it might be useful to apply it, especially for people with less experience (assuming they can see through the snake-oil sellers that inevitably pop up).

>> Then it becomes easier to know in which conditions it might be useful to apply it, especially for people with less experience

In my experience it's exactly the opposite that has happened. I see microservices being abused all the time, just because someone read a blog and thought they were cool. The same thing happened with SOA by the way.

It's funny that the main reason you switched was because of the difficulties of VSS. Your tools forced you to make decisions about how you code!

We just switched to SVN. The migration was an easy < one day job, a few weeks of pain with some developers grumbling that it was too complex and then everyone was (mostly) happy that we no longer had to hunt down the consultant who had locked a particularly critical file and was now out of the office the rest of the week.

You’ve been on VSS until just recently? That seems insane. Wasn’t the last update to VSS shipped in 2005?

Also, why SVN? That seems an antiquated choice at this point.

"Just" being "simply", rather than sticking with VSS.

I read that as “recently” rather than “simply”, but could be wrong.

No, this was a decade ago at a company I used to work for.

Although a couple of years ago I did have a job where they used it, but I quit after 2 months. For some reason a couple of the Devs would constantly check in blank commits. Not sure if that was a product of VSS or because the Devs were awful (part of the many reasons I left so quickly).

It's not quite as bad any more, but still terrible when compared to Git or SVN.

Ok. That makes more sense. :)

One of the first things I did at a contract in 2013 was port their RCS wrapper scripts to SVN. I wept hard for those weeks.

That sounds pretty terrible. Why did they need a bunch of wrappers?

I’m a big fan of vanilla tooling. Complex build, version control, etc gets no love and ends up ten years later as a big mess that no one understands or wants to support.

Because their entire workflow had been about these RCS wrappers for 5+ years and they weren't ready to change that for existing projects etc. New projects (such as the one I did after that) were thankfully just plain ol' SVN commands from the start.

One common theme of the tech industry is that excellent ideas get picked up by bullshit artists with time to waste and ink to spill and are then turned into something completely anathema to their original intent. Anecdotally, this seems to happen with more speed and vigor than in other domains.

Yeah pop culture driven programming.

It's worth remembering how painful SOAP was, and what a disaster the early implementations were, and how little agreement there was on anything, for many years. Pete Lacey has written a hilarious satire of the whole thing:

http://harmful.cat-v.org/software/xml/soap/simple

Maybe SOAP wasn't the entirety of SOA, but back then it was a big part of it.

I agree the term "microservices" has been ruined by those who came in with a very specific agenda. When I was at Timeout.com, in 2013, I used the phrase "an architecture of small apps":

http://www.smashcompany.com/technology/an-architecture-of-sm...

It was a few months later, when Martin Fowler wrote his essay about it, that I first heard the term "microservices". When I read his essay, I assumed he was talking about the same thing that I was talking about. But I later found that the people promoting microservices defined it entirely in terms of HTTP, so I've gone back to talking about "an architecture of small apps" when I am talking about small apps that talk to each other with something other than HTTP, such as this kind of architecture:

http://matthiasnehlsen.com/blog/2014/11/07/Building-Systems-...

In that example, Mattias Nehlsen builds a system where the communication is via Redis.

> Maybe SOAP wasn't the entirety of SOA, but back then it was a big part of it.

Well, SOAP and Wiz-Dull.

Many of the robotics platforms in common use (e.g., ROS) consist of independent, single-responsibility services that communicate over a shared message bus using a protocol that's not HTTP.

But for enterprise apps, it's 2018. Other protocols? What other protocols? You should be using HTTP/2. It can MUX multiple streams over the same connection. FINALLY! At long last! We're no longer limited to a single concurrent stream!

Sure, but you could point a generic client at a SOAP endpoint, and have a client for it, since the endpoint told the client what methods were available and what their signatures were.

REST lost that.

I think GraphQL has it back again. Any GraphQL people want to comment?

GraphQL Person. It does. But GraphQL is not a silver bullet. It adds a decent amount of complexity on the front end (assuming web / mobile app) that I don't think is worth it unless you're really making use of GraphQL's feature set.

Thanks. I feel the endpoint redundancy issues in REST APIs for what I'm doing now (and what I've worked on on the past) but there's so many other things that could deliver value I'm holding off on GraphQL till my next big project.

I have spent the last couple of months enduring code generation from Swagger, boy do I miss WSDL tooling.

SOA was just as notable as microservices is for people arguing over its "true meaning" which is how so many arguments got started.

In reality the definition of both was always fairly fuzzy.

Our shop tried microservices, and so far it's a BIG FLOP and time-drain. Conway's Law overpowered it: if the org structure (both dev's and domain org) don't match the microservices partitioning, bleep happens. You cannot force sharing/reuse where the parties don't want it (both dev and domain).

If you share something, you create a dependency; and that dependency needs to be managed both technically and domain-wise. Group X now has to depend on Group Y's decisions if they both use/share service Z. If X and Y don't buy off on a common dependency on Z, they get frustrated and blame devs and the other service users.

Stored procedures and SQL allow data/service sharing with less code anyhow.

>First, the services became monoliths of conflicting responsibilities,

Really depends on how they were written and how they were maintained.

>then the mobile revolution and big data led to scalability challenges that the era of SOA never had to consider.

Can you describe this in more detail?

"By being brutal with decomposing and decoupling your concerns you could scale each intelligently and independently."

Yep. This is the first concept he misses.

"They think of microservices as just another buzzword. "

And this is the second one.

What he's describing as SOA doesn't match what I've seen. Even your 1-5 services example is rare. It was mostly taking a buzzword, loading up on some tooling, and cranking WSDLs. You could end up with dozens of those little rascals right out of the starting gate. (It should have been 1-5, agreed. I just never saw it work like that in shops of any significant size)

Aren't you comparing the historical reality of SOA with the ideal/theoretical implementation of microservices?

(I wasn't around in the SOA era)