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

11–20 of 152 posts

Re: Microservices

#11

Post by teen »

seibelj wrote: post #2

I swear, the HN front page algorithm is easily gamed, this gets a few points quickly and it rises straight to the front page. I don't know if HN is accounting for vote rings but some penalizing should be implemented.

agreed, most of the points this article makes are invalid as well. google has been running the microservices pattern forever and seems to scale fine. for example he mentions that costs are ndoe based but no where in a microservice pattern does it say each service has to run on its on vm

Re: Microservices

#12

Post by jedberg »

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 monitoring, altering, and scaling.

But those things are hard to do and hard to get right.

Re: Microservices

#13

Post by exabrial »

jsmith0295 wrote: post #9
gjolund wrote: post #6

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

I think a lot of people don't implement them properly. And if you're an individual or a small team trying to build something it's usually overkill.

Agree 100% with both of these statements. A general rule seems is to divide them on transactional boundaries and business concerns.

Re: Microservices

#14

Post by 0xfaded »

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…

At work I built and maintain a large codebase that deploys to multiple servers to perform multiple tasks. We also license software.

The answer to your question is simply libraries and build targets. My monolith is mostly shared code, with unique functionality at the fringes, but it all builds into a single deployable jar, minus the licensed libraries which are special cased.

I'm a huge fan of SBT, despite its dwarf fortress like learning curve.

Re: Microservices

#15

Post by throwaway13337 »

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 using these tools. There are exceptions, of course, where the problem does call for huge-company solutions, but they're rarer than most people expect.

Re: Microservices

#16

Post by fapjacks »

reacharavindh wrote: post #10

I for one, feel the same way when someone tells me they are building "microservices" for a small application that they don't ever plan to scale to that levels. IMO, amongst us, there is a wide-spread issue of "Here's the new cool thing - My application/system has to do it". The other day, a friend was talking on and on about setting up a Hadoop cluster for what I saw as a one-time use batch script.

And? Did you try to talk your friend out of it?

Re: Microservices

#17

Post by lgunsch »

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…

Why would you not be able to scale a monolith? You can apply the same principles to it: "[Stick] a load balancer in front of a micro service and scaling based on measured load"?

A microservices allows you to scale up very particular components of an architecture, but there is nothing stopping a monolith from being horizontally scaled in just the same way. In AWS, I would make the monolith deployed with an AMI in an auto-scaling group with a load balancer in front.

Re: Microservices

#18

Post by [deleted] »

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…

[deleted]

Re: Microservices

#19

Post by lgunsch »

gjolund wrote: post #6

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

I'm curious what makes you think that. At the end his bio says he has 12 years of experience, and from his blog seems to know a thing or two.

Re: Microservices

#20

Post by blackoil »

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.
Post reply on HN