Hacker News Reader

Comment by je42 | Hacker News Reader

it depends on your reasons.

- if you need to scale the number of teams working on the same product you need to introduce microservices to make the teams work independently from each other.

- if you need to scale the (monolith) service and it is too expensive to just scale it n times. microservices can help because you can scale each microservice independently.

- that's said the overhead is real. There have been quite a few publications and advocates (like Randy Shoup) that staying monolith is fine until you have pain that a microservice architecture can ease.

View on HN

Exactly! I think we completely agree.

All those reasons are very fine ones - but it's still a dangerous move to go microservice style. You have to know what you are doing, and in our buzzword driven industry that's not the case usually.

Little insidious time wasters will creep into your work flow and they will lurk there eat away dollars and you won't even notice.

I constantly switch back and forth between working on monolithic and microservice apps and for the majority of companies sticking to a monolith until the pain points you mentioned become unbearable is the good call.

Even then, just break down your apps to bigger sized services, and stop when the pain goes away. Microservices is a catchy name but if anything micro is the poison there.

yeah good to point to make it explicit. splitting to smaller (but not micro) is a very good transition, that might already help.

Given that I have been part of a team that independently invented micro-services, and that since knowing that, I’ve met several other people who have done similarly, it can’t imagine that it’s all that hard. To me, it was just a natural evolution.

What do you consider as the most important things that people are do wrong?

Also, could you enumerate the time-wasters? Off hand, besides occasionally having to re-consolidate the architecture, I can’t think of many. It would be good to know how much the time-wasters cost in contrast to the alternatives.

> if you need to scale the number of teams working on the same product

You can do that by several different ways. Overall, if one wants a "one size fits all" answer to how to break code into teams, it is by breaking the code into libraries, not services. Services are a niche tech here, to be considered when the others won't suffice.

> if you need to scale the (monolith) service and it is too expensive to just scale it n times.

Again, nearly every time this happens, the correct answer is to refactor the monolith so replicating it scales. Services are only for those cases where this won't suffice.

I don't think I disagree with how you think. But I do think your comment is easily misunderstood and harmful without those qualifiers.

1) Agreed, the split into libraries can be fine. At some point, you want teams to deploy independently of other teams.

2) agreed ! thanks for adding the qualifiers !

A service can be deployed independently from other services.

If you release a new version 1.1.0 of a library you have to update and redeploy all applications that use this library.

I’ve seen the library approach in practice. It is works to a certain point, but it isn’t too long until having a single deployable[1] artifact becomes as much of a bottleneck as having a single codebase, if not more. Taking this approach makes it harder to do other things that are just as important, such as continuous delivery, empowering development teams to take ownership of operational excellence, or even ship updates in a reliable and timely fashion.

Most of the hatred towards microservices is probably better directed at REST, which is a good paradigm for serving documents to web browsers but is overcomplicated for microservices. RPC is a good alternative, and gRPC is a good implementation of it.

[1] My phone autocorrected this to “deplorable”, which is also a good adjective for a monolithic web application that contains lots of libraries and is only deployable as one artifact.

To my siblings: you don't know how libraries work.

If you understand binary compatibility you can deploy a library without deploying its client applications/libraries (they would need to be restarted, however).

In fact, this is one of the very reasons people invented shared libraries! It's why, for example, Linux distros are based on shared libraries: one can update large swaths of the system by updating a single package.

If your languages don't support this then it would be very unfortunate indeed.

Yeah, I've not seen much in the way of definitions about what the bounds of a "micro" service are or how much scope each one includes.

It sounds like you're saying that a single micro service maps to a team. Do you think each team should manage many micro services and how many do you think each team should manage?

I'm generally interested but having been the guy on dev teams to handle most of the configuration management stuff I've not really been willing to listen to micro service advocates.

Depending on runtime environments/architectures the CM costs sound prohibitive at best.

One per team sounds about right, unless there are some components that don't fit together in the same runtime (e.g. a data lookup with a little business logic might not fit with a module sending out emails). That said libraries go a long way to reduce the dependency graph and prevent developers from creating unnecessary edges by randomly autocompleting code.

IME we had multiple services for each team. But we were in the process of carving several mutually incompatible whales into common, shared services, YMMV. So we had one team maintaining each whale, and our senior engineers would collaborate to identify pieces that could be cut from each and replaced with a common service. If the innards of one whale matched our service better than the others, that whale's team got to write the service. Eventually all the teams would port their products to the new, resulting service.

This meant, for example, that my team, had our whale, an audio transcoding service, an automated transcription service, a post-phone-call messaging service, and several data integrations.

If you need a whole team to do nothing but maintain a service, it seems to me like you built it to do too much.

So you would hard couple your architecture to your current org structure?

Software architecture always mirrors org structure anyway. That’s Conway’s law.

and boy if it doesn't mirror org structure. you get pain :)

multiple services per team are trickier. also depends on their complexity. sometimes you can't get around it.

it also depends on your infrastructure to manage services. if setting up, managing, deploying and monitoring a service is cheap it can make sense.

Or microservices are strongly indicated if you are in a SaaS industry as we are (HR software), where individual customers want choice over the components making up their own stack.

This is perhaps off-topic but why would you let your SaaS customers dictate the composition of the stack? This seems to obviate one of the major benefits for customers, namely that they don't sweat the details.

Very relevant.

The nature of software for managing humans is that it's very fuzzy, fashion/tend driven, diverse.

E.g a recent trend is for companies to try and reduce the number of undesirable applicants they get for jobs (since in a big e.g retailer, saying no to a candidate is likely also saying no to a customer).

So customer now needs to inject an e.g culture fit quiz into the candidate experience, which only unlocks the apply button once the candidate has "passed".

This kind of tweaking and evolvement is not possible within a monolith, so good APIs allowing vendors of the customer's choice to inject functionality are essential.

That functionality can then be injected in the form of a small app that does one thing and does it well, has it's own database, i.e has many of the characteristics of what people think of as microservices.

I don't think it's helpful to conflate "microservices" with "dynamically-loaded code". Many, many programs have a plugin system that can completely alter their behavior while having all the characteristics of a monolith - single process, function calls rather than a message bus, central control of flow rather than decentralized, etc.

Well, this can be a fruitless discussion without a shared understanding of what a microservice is.

To Martin Fowler:

> In short, the microservice architectural style [1] is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

Assembling HR ecosystems from separate apps certainly meets all of the points above.

Ah, this is more what I might call 'macroservices' - API-centric full applications which can be used standalone with their own client interfaces or API-assembled into bigger solutions. I think this should be the default architectural approach and was what Yegge wrote about Bezos mandating at Amazon.

From what I'm seeing, the microservices style is commonly being used for much smaller services a la Unix, typically for reuse across an org. Introduces too many issues around SPOF, orchestration and queuing, versioning, discoverability. I think Lambda is the correct evolution for making that work (if nothing else let AWS figure out stuff like failover, deployment, and the standards for fabric between functions).

Really?! A quiz in HR software needs a microservice with a separate database? Are you reinventing modular design and feature flags?

You talk as if the customer already has the quiz content in their mind, and just needs a few web pages to present it.

That's not the way the industry works.

Some exciting, specialised startup develops some kind of cool UI blended with some psych validated content, and manages to get it installed at a couple of large reference clients, and then finally manages to draw a link between the quiz results that candidates achieve, and their ultimate chances of successful employment (maybe just getting hired - maybe their on the job performance after X months).

The customer is buying into this package of leading edge stuff. They don't want their existing vendor to have some junior developer hack something up and put it behind a feature flag. They want the new shiny stuff, and they want it from the new shiny vendor.

It depends on your market. If you are "SaaS for the masses" (i.e. you've got 50,000+ customers) then you're right - any customization is limited to "pick a color from our predefined palette". But if your customers are Fortune 500 -- they can and will demand special consideration.

Doesn't that indicate a modular architecture or just feature flags rather than microservices?

Yes, if the customer was happy to buy everything from a single vendor that would work perfectly fine. But as per sibling comments, that's not the way that the enterprise HR software market works. There are many, many very specialised vendors that do just one thing.

We did that without microservices, just dynamically-loaded modules on a monolith base. A custom configuration for each client selected which modules to load at runtime.

Typically in the enterprise HR software space, the customer does not want to buy all their components from a single vendor. If they want a culture fit quiz, they do not go to their ATS (applicant tracking system) vendor for it. They go to an organization that has specific skills in this particular area, and has onboard psychologist(s) who can demonstrate the validity of said quiz.

The code behind such a quiz is usually trivial - the intellectual property not so much.

> quite a few publications

"Monolith First", Martin Fowler

also this: https://www.slideshare.net/RandyShoup/goto-aarhus2014-enterp...

Reply on news.ycombinator.com