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

Microservices

basho.com

Post reply on HN
Print view View original

41–50 of 152 posts

Re: Microservices

#41

Post by pbreit »

throwaway13337 wrote: post #15

Microservices, like nosql databases, and complex deployment systems (docker) are very important solutions to problems a very small percentage of the development community has. It just so happens that the portion of the community is the one most looked up to by the rest of the community so a sort of cargo cult mentality forms around them. A differentiator in your productivity as a non-huge-company could well be in not…

My company built from the ground up with micro-architecture and it is an unmitigated disaster. Totally unnecessary, mind-numbing problems unrelated to end-user features, unpredictability at every step, huge coordination tax, overly-complex deployments, borderline impossible to re-create, >50% energy devoted to "infrastructure", dozens of repos, etc.

The whole thing could be trivially built as a monolith on Rails/Django/Express. But that's not exciting.

Re: Microservices

#42

Post by StabbyCutyou »

gjolund wrote: post #6

The title should be "I've never implemented microservices properly, so you should avoid them."

I appreciate the feedback, but unfortunately I think you've made a bit of a leap in terms of what my point here was.

It isn't that i'm saying "Don't build microservices", but rather "Don't adopt this approach until you understand the tradeoffs involved". I've worked on teams that have done it well, and not done it well. I've worked with large codebases that are well maintained, and poorly maintained. There are tradeoffs that need to be taken into consideration before adopting any major architectural approach.

I will say that upon reflection, the original title could have been reworded a bit to better express this.

Re: Microservices

#43

Post by josh_carterPDX »

My thought is that this comparison between a monolithic code base vs a microservices code base is a bit subjective. If you're starting out chances are your code base hasn't even gotten to the level of being monolithic. So those thinking about how they're going to architect their platform may begin to think that a microservice setup could help for future changes to their code. It really depends on each team, their background, and how they want to think about their platform in the future. To list out the pros and cons of both to draw a conclusion that one is better than the other is certainly setting a bias that I believe to be a bit unfair. Just look at Netflix and their container services. It's a platform adopted by a ton of companies including Nike. So for some a microservices approach makes a lot of sense.

Re: Microservices

#44

Post by gjolund »

eric_h wrote: post #40
gjolund wrote: post #29

Earlier quoted context omitted.

Because scaling a monolith is not a realistic approach. Every single monolith I have worked on has been refactored as domain specific microservices, and in every case it was a resounding success.

In my experience scaling a monolith just costs more (i.e. hosting costs). Our product, when we started, was quite expensive to run at our high traffic times, but we were eventually able to cut our costs drastically by breaking certain pieces out into services.

Depends on the product, but for many startups those additional costs can be crippling.

Also, I have found it much easier to onboard a new engineer, give them the requirements for a service and let them go at it. I've been using AWS Lambdas to great effect in this way.

Re: Microservices

#45

Post by StabbyCutyou »

mey wrote: post #4

From personal experience Microservices enforce a clear interface and isolation pattern. This is achievable many ways, but having discrete deployed code makes it very hard to violate rather than being disciplined. Licensing costs can go drastically up as most modern licensing is node/core based. As can deployment procedures get more complicated. I would love to understand how this article believes that the modules in…

Author here - your ninja edit is one of the core premises of the entire post.

Some other folks have addressed the scalability questions you raised, but i'd add - I am in no way advocating for monoliths as a better approach. Rather, both have tradeoffs you need to think through before adopting.

Thanks for taking the time read.

Re: Microservices

#46

Post by StabbyCutyou »

josh_carterPDX wrote: post #43

My thought is that this comparison between a monolithic code base vs a microservices code base is a bit subjective. If you're starting out chances are your code base hasn't even gotten to the level of being monolithic. So those thinking about how they're going to architect their platform may begin to think that a microservice setup could help for future changes to their code. It really depends on each team, their bac…

You have a good point in that in the early stages, any app is likely not to be a "monolith", but it's less about size/LOC and more about the design ethic of the architecture itself.

If you build your codebase internally with service level abstractions in mind, you can gain a lot of benefit without the cost of the network or the additional errors it can introduce.

Thanks for reading!

Re: Microservices

#47

Post by jedberg »

StabbyCutyou wrote: post #38
jedberg wrote: post #12

This could be titled "If you do things wrong it won't be good". A lot of his examples are of people doing things poorly or incorrectly. I could make the same arguments about object oriented programming my saying it's bad because someone makes every function a public function. For example, microservices are absolutely more scalable if done correctly with bulkheading and proper fallbacks and backoffs, and proper monito…

Hi, author here - thanks for taking the time read it. You're not wrong in that this article is meant to point out the pitfalls of the approach, and to advocate for understanding before diving into a particular architecture. It's meant to give people things to consider before deciding breaking things into "microservices" is the right thing for their engineering org at that time. I attempted to note several times that…

Got it thanks for clarifying. My suggestion would be to make that a bit more explicit -- I didn't get that impression reading the article.

Re: Microservices

#48

Post by rdsubhas »

You need to be this tall to use [micro] services:

* Basic Monitoring, instrumentation, health checks

* Distributed logging, tracing

* Ready to isolate not just code, but whole build+test+package+promote for every service

* Can define upstream/downstream/compile-time/runtime dependencies clearly for each service

* Know how to build, expose and maintain good APIs and contracts

* Ready to honor b/w and f/w compatibility, even if you're the same person consuming this service on the other side

* Good unit testing skills and readiness to do more (as you add more microservices it gets harder to bring everything up, hence more unit/contract/api test driven and lesser e2e driven)

* Aware of [micro] service vs modules vs libraries, distributed monolith, coordinated releases, database-driven integration, etc

* Know infrastructure automation (you'll need more of it)

* Have working CI/CD infrastructure

* Have or ready to invest in development tooling, shared libraries, internal artifact registries, etc

* Have engineering methodologies and process-tools to split down features and develop/track/release them across multiple services (xp, pivotal, scrum, etc)

* A lot more that doesn't come to mind immediately

Thing is - these are all generally good engineering practices.

But with monoliths, you can get away without having to do them. There is the "login to server, clone, run some commands, start a stupid nohup daemon and run ps/top/tail to monitor" way. But with microservices, your average engineering standards have to be really high. Its not enough if you have good developers. You need great engineers.

Re: Microservices

#49

Post by StabbyCutyou »

fishtoaster wrote: post #26

There's some good points here and some I disagree with. One area, though, where I think he misses the point, is: > Additionally, many of these stories about performance gains are actually touting the benefits of a new language or technology stack entirely, and not just the concept of building out code to live in a microservice. Rewriting an old Ruby on Rails, or Django, or NodeJS app into a language like Scala or Go…

One of the downsides of the blog post was that I adapted it from a lightning talk, so it was meant to be a little content-light, but to put ideas in peoples minds around how to think about the tradeoffs.

For example, your point about Go vs Rails is an apt one - I would only add that I made that comparison because...

A: It was originally a golang meetup where I gave the talk B: Go is increasingly becoming popular as a choice people move to off of Rails, for performance sensitive code (Scala being the other popular choice I see), and also for building "microservices" themselves.

I could have, and maybe should have, gone a little more in depth at that part, but the idea wasn't to be fully exhaustive (for better or worse).

But the main takeaway about the performance gains was that the idea of putting the word "micro" in front of something magically made it more performant without appreciating why. It's a response to folks simply parroting information without understanding it.

Thanks for the feedback.

Re: Microservices

#50

Post by StabbyCutyou »

BillinghamJ wrote: post #3

Raises some good points, but I think the title isn't really correct. It's not "don't use microservices" - it's more about making sure you understand the implications of having a microservice architecture, and making sure it's not an excuse for not writing a monolith (or SOA) properly.

I do wish I had titled it better, as most people have (rightfully) dinged me on this one ;)
Post reply on HN