Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Microservices Are Something You Grow Into, Not Begin With

nickjanetakis.com

Post reply on HN
Print view View original

21–30 of 159 posts

Re: Microservices Are Something You Grow Into, Not Begin With

#21

Post by adamdrake »

Most of the time, I've found a push to microservices within an organization to be due to some combination of:

1) Business is pressuring tech teams to deliver faster, and they cannot, so they blame current system (derogatory name: monolith) and present microservices as solution. Note, this is the same tired argument from years ago when people would refer to legacy systems/legacy code as the reason for not being able to deliver.

2) Inexperienced developers proposing microservices because they think it sounds much more fun than working on the system as it is currently designed.

3) Technical people trying to avoid addressing the lack of communication and leadership in the organization by implementing technical solutions. This is common in the case where tech teams end up trying to "do microservices" as a way to reduce merge conflicts or other such difficulties that are ultimately a problem of human interaction and lack of leadership. Technology does not solve these problems.

4) Inexperienced developers not understanding the immense costs of coordination/operations/administration that come along with a microservices architecture.

5) Some people read about microservices on the engineering blog of one of the major tech companies, and those people are unaware that such blogs are a recruiting tool of said company. Many (most?) of those posts are specifically designed to be interesting and present the company as doing groundbreaking stuff in order to increase inbound applicant demand and fill seats. Those posts should not be construed as architectural advice or _best practices_.

In the end, it's absolutely the case that a movement to microservices is something that should be evolutionary, and in direct need to technical requirements. For nearly every company out there, a horizontally-scaled monolith will be much simpler to maintain and extend than some web of services, each of which can be horizontally scaled on their own.

I also wrote https://adamdrake.com/enough-with-the-microservices.html as a way to communicate some of this, including some thoughts on when and how to structure a codebase (monolith) and when it might make sense to start moving towards microservices, etc. There are cases where it's reasonable (even advisable) to move towards microservices, but they are rare.

Re: Microservices Are Something You Grow Into, Not Begin With

#22

Post by BillinghamJ »

I think you can selective. We started with ~5 services all built fairly ad-hoc, splitting on sensible boundaries with the goal of never having a "mega" service.

This means it has been reasonably easy over time to fully replace them on an individual basis with more mature systems without changing the API design.

Now we're 3 years in with ~40 services and the approach has served us very well.

Definitely agree you shouldn't start with a ton of services, but I think you should definitely start with more than one. The jump from monolith to service-oriented thinking is a huge one. But the jump from a few services to more is much easier.

Re: Microservices Are Something You Grow Into, Not Begin With

#23

Post by kabes »

js4ever wrote: post #3

What I love about microservices is isolation and forcing you to do thing well from the beginning. Monoliths tend to become horrible to maintain after few years. On the opposite change one small 50 lines microservice is a lot less risky!

You can just as easily create an unmaintainable spaghetti mess of microservices. Isolation is defined by good architecture, microservice or monolith is just how it gets executed.

Re: Microservices Are Something You Grow Into, Not Begin With

#24

Post by jacquesm »

Microservices, test driven development, Agile, 4GL and so on. It's all the same thing: a technique that is applicable some of the time but not all of the time that ends up getting a bad rap because the people promoting them tend to come from the theoretical side of the street, and they see the subject matter as their new revenue stream. They will then promote it to be used even when it isn't applicable.

A web based service can be as messy or as clean as you want no matter whether the underlying architecture is a monolith or a bunch of microservices. I don't like the 'micro' in microservices to begin with, to break up a large and complex problem into multiple smaller problems that are each simple to solve is a core principle of programming. If you take that to an extreme you end up with services that do almost nothing and then you have a communications problem (or at least, you will have one in most environments you are likely to encounter). If you glue everything together in on giant hairball you don't have the comms overhead but you have a cognitive overhead in trying to understand it all.

Like with everything else: there is a happy medium: services that are easy to understand because they do not have horizontal ties to other parts of larger whole, enough isolation to help you with debugging, not so much isolation that you end up doing remote requests for data that should have been nearby.

Everything in moderation.

As an illustration of 'microservices' done well: I worked - the last time I had an honest job+ - as a programmer on a message switch for KVSA, a company that brokers shipping capacity. Super interesting job, even more interesting architecture. Right from day one (contrary to the article title!) it was decided the system was too complex to tackle as a monolith. The reliability demands and the latency requirements led to the base system being built on top of QnX, a soft real time Unix like operating system with a micro kernel. Since in a microkernel environment message passing and service oriented architectures go hand-in-hand the technique percolated through to the application level, which ended up being a series of queues and 'admins' (QnX parlance for a daemon or a service) handling the inputs from these queues and effecting transformations on those inputs resulting in new outputs or side effects (such as a fax or a telex being sent). The system worked flawlessly, had a very high degree of redundancy built in and it most likely would have never made it to production if it weren't designed like this from day #1. For that particular use case it was ideal.

+ in 1993, if you're wondering whether microservices are something new you have your answer.

Re: Microservices Are Something You Grow Into, Not Begin With

#25

Post by asknthrow »

majidazimi wrote: post #12
microwhat wrote: post #8

Earlier quoted context omitted.

Sounds like resume-driven-development. I worked at a company with this disease before. The system was an abomination of vastly different technologies over the years stitched together loosely. Development was slowed substantially by having such a mess and the company couldn't move fast enough to compete so the startup died. Usually tech isn't the reason for a startup's death. In this case, it was.

> Sounds like resume-driven-development. Sure. That's one of the responsibilities of a team lead: to help team members to work and gradually build up their CVs. I want my team to experiment new stuff and learn while working. But I also want to limit the risk boundary. The whole reason why younger people are leaving dinosaur companies is that no one in management layer lets juniors experiment and fail. End of the day…

Nah, your job is to lead the team in the most effective direction in order to fulfil business objectives, not build resumes.

Re: Microservices Are Something You Grow Into, Not Begin With

#26

Post by crdoconnor »

kabes wrote: post #18
lbriner wrote: post #11

I agree that microservices is the new "must have" technology but actually it isn't a great deal different from a monolith. The monolith can have separation between services and still requires interfaces to work between them. As others have said, microservices bring a lot of baggage that you might never have seen before (i.e. big learning curve) and the myth of isolated changes is just that, a myth. Unless it is some…

Indeed. It just replaces internal calls between services of your monolith with flaky and slower network calls.

This can sometimes be worthwhile in a corporate environment even if technically it makes things harder, because it solves a major political / communication problem.

However, for the expense of dealing with the complications of an additional network boundary to worthwhile, some of the following must hold:

* You need architect who has an overview of the whole system creates abstractions that make sense and puts the API boundaries in the correct place, avoiding the "tightly coupled microservices" antipattern.

* You need good devops people who can track problems that span service boundaries. This is the one area where the company can't skimp (i.e. no outsourcing of this position). Without these people you get an epic political clusterfuck where everybody ends up blaming "the other" team for their problems.

* The two services need to be built by two teams which, for whatever reason, cannot be relied upon to communicate or work effectively with one another (different orgs, different country, different company maybe).

* The two teams possibly use different programming languages.

I believe these reasons are probably the reason why it worked wonders for Martin Fowler. Then startups read his blog and decided that every team needed to build 15 microservices and the whole world went crazy (thanks Martin).

Re: Microservices Are Something You Grow Into, Not Begin With

#27

Post by kcsomisetty »

Having worked in a payments company, where SLAs can be very demanding,

We broke our monolith server into microservices, and realized that we broke in to too many pieces as our SLAs broke. (every microservice you add to your usecase adds a small but fixed cost)

and finally decided to convert some microservices into libraries to save milliseconds and bring down our 95th percentile, I completely agree with the premise of the article.

never start with microservice, start with monolith with enough flexibility and inbuilt abstractions which can allow you to replace an abstraction with a monolith.

Re: Microservices Are Something You Grow Into, Not Begin With

#28

Post by CogitoCogito »

kabes wrote: post #18
lbriner wrote: post #11

I agree that microservices is the new "must have" technology but actually it isn't a great deal different from a monolith. The monolith can have separation between services and still requires interfaces to work between them. As others have said, microservices bring a lot of baggage that you might never have seen before (i.e. big learning curve) and the myth of isolated changes is just that, a myth. Unless it is some…

Indeed. It just replaces internal calls between services of your monolith with flaky and slower network calls.

It occurred to me a couple years ago when designing my deployment architecture that the majority of the complexity was just this. Instead of letting linkers/module systems do the work, I was doing all that stuff first by hand and then basically writing my own form of linking logic to solve a problem we created ourselves. Reminded me of when I read about the old ways people used to link code by hand...

And yes we were definitely cargo-culting...microservices were totally unnecessary for us. The only positive result is that it forced clean boundaries, but those could just as well have been forced by thoughtful architectural design anyway.

Re: Microservices Are Something You Grow Into, Not Begin With

#29

Post by vectorEQ »

people jump into this because of shit processes like agile which push for incremental and iterative development processes instead of thinking things through properly. usully just to be able to have easy deliverables and easy reporting to upper management about the epic progress that is made. all the while product quality usually is degraded to a point where customers will start to feel it badly. always the same dumb excuse is used that tech is changing so fast. but really, it's only changing so fast because people invent retarded processes which move too fast. you don't need to keep up with every innovation if you have a good quality product. you only need to keep up with this if you require all the latest buzzwords in your product because without them you are unable to sell your piece of junk. /endrant

Re: Microservices Are Something You Grow Into, Not Begin With

#30

Post by Aissen »

IMHO, the monoliths vs microservices debate is akin to monorepos vs multi-repos: they are both strategies used to share work when your organization grows. Both can work well, depending on your tooling and organization.

But do not forget that those abstractions layers you add, while very useful (say, for release velocity), might also be a direct application of Conway's Law: https://en.wikipedia.org/wiki/Conway%27s_law

Which means that refactoring some code, might sometime require refactoring your organization, so if you lack the ability to do that incrementally, you might converge to an ossified system that stops evolving.

Post reply on HN