Hacker News Reader

Comment by cddotdotslash | Hacker News Reader

While microservices are certainly the buzzwordy trend of the month, developers really need to take a step back and ask if designing or refactoring a project into microservices is really helpful. I've talked to developers who have taken a single app that worked perfectly fine and split it into five or six services just because "microservices!" Now they're stuck maintaining five apps, five APIs, etc. and have yet to actually benefit from the split. My rule of thumb is: can I see parts of this project being used in another project? If the answer is yes, it gets considered. If no, it stays the working app that it is.

View on HN

>I've talked to developers who have taken a single app that worked perfectly fine and split it into five or six services just because "microservices!" Now they're stuck maintaining five apps, five APIs, etc

And then when they need help fixing the mess they can call in a consultant wielding Fowlers latest book, or go to a bunch of new monolithichitecture conferences where people put up slides full of memes mocking microservices.

Truly we are blessed to live in an era of such efficient job creation.

wonder if they did it to increase their job security. "If I make something that only I can understand, my job is guaranteed, and if it's complicated the longer I can stay employed"

plenty of bad code out there built with more popular tools and patterns that only few people understand =)

"so I wrote our backend using brainfuck and we've been using it for a year now, you really think you can fire me?"

hahaha, love it. and you wrote the readme in zalgo, right?

But you realize that before they mock it, they first have to build a data lake for it.

IMO, microservices are successful when the issue is scaling people (you can split into loosely coupled teams, one per service), or scaling data (different read / write patterns allow different data stores). I don't consider reuse as a criteria, unless as a project you mean a new feature within the existing app. It's not like Spotify, for example, is starting many new projects but they will benefit from the above.

Yes. A friend is at a company that went from a monolith to a microservices approach. (The service-to-engineer ratio is something like 1:2.) He says it's radically better because somebody after a new feature can mainly just compose existing services. But they had hundreds of employees before they made the switch.

Personally, I would start sooner than that. I think new technologies make service creation easier. But the right moment for me depends a lot on product, team, and tech.

Most of the 'problems' with microservices are in the operations phase, not typically in the development phase.

Do serious shops have phases for these things anymore? In my view a modern shop should be developing and releasing frequently, and that engineers should experience operational consequences of development choices.

So I guess I would say that any place not working like that might not be ready for a microservices approach.

Another good use is operational conditions. Like certain parts of the app have different consmption/scalability needs, or certain services doesn't ever change, if at all. We currently have parts of our monolith that change ALL THE TIME, other parts haven't been updated in years. I'd personally like to partition out the stable code.

Totally this.

I think Containers are somewhat pushing Microservices a bit too early for some organizations because of Docker's focus on single entry point (sans supervisor, etc). They are useful for other reasons, but containers solve people problems, containers solve technical deployment problems.

You don't want N kinds of things if you can have 2 kinds of things (say, web tier, job workers for long running stuff, db layer), until you start having problems working out of the same codebases/repos/etc.

Microservices make things harder to debug and most likely there is still coordination that needs to happen, and it's likely going to be less efficient versus developing libraries -- so if you're a small company, you can probably ignore these for a while.

> can I see parts of this project being used in another project?

If yes, please, create a library.

Microservices share data, if you'll need part of the data in other projects, yes, they are the way to go. If you just need behavior, or need to decentralize CPU usage, there are plenty of easier ways to achieve those.

>If yes, please, create a library.

Assuming you want to force everyone to use the same technology stack. And redeploy every application every time the internals of the library change.

That may well be OK for what you are doing. Or not.

The possibility to not redeploy instantly when the library changes may be the biggest win one get from not using services.

Also, a library does not force people into the same technology stack. It makes it easier to work with the same programing language, but it's still possible to not do so. Microservices also often have complex data structures that only work well when created and parsed by the same set of tools. There is some difference, but much less than you are claiming.

If a library dictates a "technology stack", then maybe it's more of a "framework" than a "library"? I think we're supposed to deprecate those now.

A library dictates a stack since it's hard to use a Python library in an Haskell application.

Many libraries have functional equivalents in other languages. Is there some python library that's so awesome it would have no equivalent in Haskell? (If you say "NumPy" I think you're veering into framework territory.)

Interestingly I found these for using python libraries in Haskell:

https://github.com/Russell91/pyfi

> I've talked to developers who have taken a single app that worked perfectly fine and split it into five or six services just because "microservices!"

We've also all met that developer that decided that Foo (library, framework, pattern, language - pick your poison) is SO MUCH BETTER than Bar (which is what you use now), and frantically sets out to replace all things Bar with Foo (and gives up halfway, so now you've got the maintain both Foo and Bar bit of your code, all intertwined).

The problem isn't with Foo and it's merits, it's actually very useful, the problem is that that developer is, frankly, shit.

Microservices is a perfectly useful pattern to achieve a number of ends, but it's not the answer to all questions. Know what you're trying to achieve, evaluate options on their actual merits (not what's buzzwordy this month) and make decisions consciously.

EDIT to add:

> can I see parts of this project being used in another project?

That's not the only benefit from microservices. Smaller units are easier to reason about (and test!), and they allow you to experiment: A monolithical app needs to maintain some sort of consistency. Most of the time it will be written in the same language, using the same general patterns and libraries supporting these patterns (eg. dependency injection using Guice or Spring). Most of the time, none of this will be cutting edge, some of the time it will be decidedly out of date, but changing it is hard and risky, and, well, it works.

With microservices your can use the languages, patterns and libraries that suit your isolated use case best. Need to support complex web forms? You might want to run Node.js so you can use the same JS code for validation on the front end and back end. Need lots of boring CRUD in your admin app? Ruby on Rails is your friend. Number-crunching? You might want to use Clojure or F#. Interfacing with some proprietary system (e.g. Sharepoint)? Use the best supported library you can find (.NET webservices client), and build a service up around that, on the platform that best supports that library (ASP.NET on IIS on Windows).

In other words, the more integration you have to do anyway, the better a microservices architecture looks.

Launching a feature that maps across multiple microservices is also fun.

First, you need to issue pull requests for multiple projects and keep mental track of the status of those pull requests.

Second, [in a large organization] you might find out that changing the microservice on the server side breaks some client down the road because of new/unexpected parameters introduced, and the client handling it poorly.

Third, if the services [in a large organization] are distributed across multiple teams, you need to work around their schedules and their deploy calendars to orchestrate those changes.

For some reason I had never thought about that possibility. Now that I have, it sounds absolutely hellish.

Sounds like you haven't correctly drawn the boundaries of your microservices or you're not versioning them or both.

And if you're having a tough time deploying changes, it sounds like you're not practicing continuous delivery, which as Fowler said is a prerequisite.

Yeah I think this goes into the category of:

  Patient: "Doctor, when I bend my arm backward, it hurts!"

  Doctor: "Stop doing that."

Doesn't mean that using your arm is a bad idea.

So:

- don't issue pull requests for multiple projects

- don't keep mental track of the status of those pull requests.

- don't worry about breaking clients

- don't worry about the logistical/scheduling issues of multiple teams

Which is kind of the point behind his earlier article 'Monolith First' [1]

[1] http://martinfowler.com/bliki/MonolithFirst.html

Microservices help make your projects smaller and force developers to adhear to your interface. If you ever work with batshit insane devs tripping over each other, you respect the idea of those unbreakable interfaces.

That said, I heard a dev want to break up a low traffic app that had to take in a message, encrypt it, then put it on a queue want to break that into microservices. My first reaction is "what the fuck?". My second reaction is that an encryption service might not be a terrible idea, though I doubt ensuring folks don't roll broken encryption is why the dev proposed it.

SoA is nothing new and there are definitely times to use it much like there are times to use MVC and times not. However, it's a "buzz" right now because of the nature of many of the apps we have out there right now. Big data is also a buzz and fits well with SoA / microservices. Docker fits in here as well. The entire way the hosting landscape is shifting nurtures an SoA and the notion of running apps as VMs sans operating system is yet another support for SoA.

No, it's not appropriate for your blog. But it IS appropriate for many applications out there and it's an incredibly beneficial way to scale a set of services and build a complex application in a cost effective manner.

I don't quite agree with the notion of being "stuck maintaining five apps, five APIs, etc." because it's not. It's really one app. You're doing something wrong if you feel that you have five different apps and APIs. In fact, your testing and debugging should become easier under such an architecture. Maintenance should be much better if done properly. Of course regardless of your software architecture, you can end up in "maintenance hell" so that's really an invalid argument against SoA. I certainly wouldn't let the fear of bad programming prevent me from using a specific design pattern or architecture.

I would add in workers... is there something that should be run on a different system.. the typical example is image resizing. Even if a service will only be used in one place, if it's compute heavy, I'd lean towards putting it behind a work queue, on an independent service.

There's also the question about project complexity.. does the marketing website really need to be part of the application's project?

It's a matter of separating things out where it makes the most sense.

There definitely seems to be more of a tradeoff than people either want to admit, or realize upfront. My teammates were just talking yesterday about a small change that would touch 5 different repos and take some number of deployments to actually be realized. Of course there are ways to justify that sort of downside, but it's not a free lunch.

Apps that follow the microservice pattern will not consist entirely of independent services, as there is still a need for a central component that can do request handler for responding to user events or routing and initiating individual service processes.

To reduce complexity and centralize common functionalities API Gateways such as KONG (https://github.com/mashape/kong) are the base of microservice architectures.

>I've talked to developers who have taken a single app that worked perfectly fine and split it into five or six services just because "microservices!"

I think the idea is to use microservices when they will be owned by separate teams. If your application is small enough that a single team can meaningfully work on it, then you probably don't need to break it up.

Could you explain that to my manager please? He wants our one team to maintain 6+ microservices, each in their own git repo. Its going to be such a cluster-schtuppe, I just know it, and no one cares to listen to reason...

Splitting your code becomes a pain when branches touch more than one program.

>Who have taken a single app that worked perfectly fine

If it worked "perfectly fine", and the team is productive, then they should have spent their time on more important things :).

This is what happens when you hire bunch of fresh grads or inexperienced engineers who blow their load whenever there's a chance to reinvent the wheel and hoping it will catch on.

Experienced engineers know that technology that has stood the test of time is boring. But we are not in the business of designing "fun" ways of working constantly, we are here to ship software on schedule and produce something that is easily understood and maintanable by next generation of engineers, instead of getting bamboozled by a new buzzwords invented by empty suits (agile, tdd, xp, microservice, mvc up your browshizzle), regardless, if not an engineer, than some "manager" who can't code reads some article on HN, and decides that's the way to do it.

Reply on news.ycombinator.com