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

121–130 of 152 posts

Re: Microservices

#121

Post by cmdkeen »

aikah wrote: post #71
txutxu wrote: post #39

Earlier quoted context omitted.

I see microservices as responsibility deduplication in a organization-traversal-wide. De-duplication is a very old concept (differentiates good "sysadmins" from bad ones, since the 90's, and good programmers from bad ones). Thinking organization-traversal-wide is what is hard for some persons. Currently working at consulting in a big corp... you get to this problem: Resource: name FooBar, type int (organization view…

> I see microservices as responsibility deduplication in a organization-traversal-wide. AKA SOA. Why call it microservice ?

The Newman book is worth a read - I'm going through it at the moment and a lot is applicable to SOA as well. Microservices is partially a re-branding exercise to take the massive space SOA covers and talk about a more specific definition.

The main thing is the size of the services, the clue being in the name. Also there's a clearer emphasis on the services being more business related concepts, SOA can often described in more techy service splits rather than business concepts.

Re: Microservices

#122

Post by jamesblonde »

jsmith0295 wrote: post #87
xorcist wrote: post #81

Earlier quoted context omitted.

In many ways it's just like micro kernels again. If micro services are the bee's knees, why are you writing them in Eclipse or Emacs? Wouldn't interconnected processes make up a "better" environment? An why are you deploying on something as monolithic as Linux? Shouldn't you out-compete all of these obviously inferior solutions, as there are probably more money in that than whatever web app you are currently building…

That's one thing I've always thought when people claimed microservices followed "the UNIX philosophy". UNIX doesn't even follow that philosophy, it's a monolith! Yet it's also a modular system, which is possible without being either a microkernel or microservices.

Yes. For me, shared state in the Linux kernel is like a shared database between microservices. It makes life way easier, is faster, but you need to be careful you don't introduce subtle bugs.

Re: Microservices

#123

Post by hliyan »

blackoil wrote: post #20

My approach is to design like microservices and develop like a monolith. Thinking about microservices will force you to define module, their boundary and interfaces. A monolith will simplify deployment, refactoring. Once your code matures, you'll know if any microservice has to be taken out and deployed seperately.

My conclusion as well. In my mind, I call them 'air-gapped modules'.

https://www.linkedin.com/pulse/maintainable-software-archite...

Re: Microservices

#124

Post by technion »

pbreit wrote: post #41
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/Djan…

I suppose there's a difference between the "from the ground up micro-architecture" and "using a micro service or two" that should really differentiate the various "should we use microservices?" discussions.

Several sites I'm aware of have an Facebook-style chat service, which is basically an off the shelf node app on its own. This makes far more sense than trying to build such a thing into their legacy app. It also perfectly describes a very useful micro service, in a very different environment to yours.

Re: Microservices

#125

Post by johnnydoebk »

StabbyCutyou wrote: post #50
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 ;)

I'll go against the majority (or vocal minority?) and say: I like your title, it's good because it attracts attention (I wouldn't read the post if it were a "understand the implications of having a microservice architecture" or whatever others recommend).

Re: Microservices

#126

Post by XorNot »

romanovcode wrote: post #115
pbreit wrote: post #41

Earlier quoted context omitted.

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/Djan…

Tell me about it. Exactly same situation here. You forgot the fact that they're paying 1k+ for AWS for all these services where if it was a normal application it would've cost around 100 bucks.

If you're doing this then you don't know what you're doing infrastructure wise anyway.

Re: Microservices

#127

Post by pinouchon »

oelmekki wrote: post #56

Instead of microservices, I split my projects in tons of libraries and think of them as products, enforcing a well thought of and consistent api (usage api, not http one). I call that an atomized monolith. I get the cool things about microservices: properly isolated functionalities, ability to assign a team on it, simplicity of code and considering each feature as important, not just "that thing in the codebase". But…

I think this is a good approach. Many popular libraries put API design as their top priority, sometimes at the cost of clean code. For example, RamdaJS has this principle of "API is king": "We aim for an implementation both clean and elegant, but the API is king. We sacrifice a great deal of implementation elegance for even a slightly cleaner API.". Imo, good "monolith atomization" requires you to do this kind of tradeoffs, and this can be though.

Re: Microservices

#129

Post by oelmekki »

oelmekki wrote: post #56

Instead of microservices, I split my projects in tons of libraries and think of them as products, enforcing a well thought of and consistent api (usage api, not http one). I call that an atomized monolith. I get the cool things about microservices: properly isolated functionalities, ability to assign a team on it, simplicity of code and considering each feature as important, not just "that thing in the codebase". But…

Oh btw, forgot to mention this: for rails projects, mastering rails templates and thor is a must have, too, in atomized monoliths. It allows to quickly build rails engines with all the project setup made instantly. You can even build complexe templates that ask for input to toggle features or provide variable values. Yeah, I love tooling :)

http://guides.rubyonrails.org/rails_application_templates.ht...

Re: Microservices

#130

Post by appelza1 »

tkyjonathan wrote: post #118
rdsubhas wrote: post #48

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…

You can add to your list all the sysadmin, devops complexity to the power of two, new single-point-of-failure issues, SLAs, backups, retention of backups.... Basically, you are multiplying the complexity of the ops people.

Microservices done right won't have a single point of failure, though. Agreed us ops guys have a lot more work cut out for us, at least initially.
Post reply on HN