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

131–140 of 159 posts

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

#131

Post by haskellandchill »

fiedzia wrote: post #80
adamdrake wrote: post #21

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 t…

> Business is pressuring tech teams to deliver faster, and they cannot, so they blame current system And are very often right about it. Delivering monoliths can require such amount of bureaucracy and needless coordination that it slows everything down. I've seen it. > Inexperienced developers proposing microservices because they think it sounds much more fun than working on the system as it is currently designed. It…

What’s fun about microservices? I find them annoying, but a necessary evil depending on context.

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

#132

Post by colemorrison »

I agree if you have no idea what you're doing - which seems to be the case for many developers starting new projects stuck in the paradox of choice.

But like anything else, if you understand the toolset, ecosystem, and have the experience, it can take far less time than esoteric documentation and conversation would have you believe.

I always begin with this pattern, but it's because I've acquired so much experience and know-how with it that it's a quick upstart. However, this didn't come with any ease. Most want to just dive into really myopic course work or tutorials that are "just examples" and "shouldn't be used in production." The WORK to understand it is getting each nuance under your belt. It's just like any other skill set - it takes patience and deliberate effort. Documentation spelunking and trial / error experiments.

That being said, under the fire of a manager, timeline of capital, or just the raw impatience inherent to humans we wind up falling back to what's safe, what has plentiful easy-to-learn patterns, and listen to all the other folk who get 50% through, stop, and then just spin up terribly organized monoliths.

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

#133

Post by barbecue_sauce »

I don't like the phrase "microservice" because it now has a certain amount of baggage, similar to "service oriented architecture" which it was meant to be somewhat of a counter-point to. Whereas the issue with SOA was its association with maligned/feared technologies (SOAP, WSDLs, CORBA), the issue with microservices is the implied granularity. SOA was a good idea, but people (particularly in start-ups) don't want to say they're doing SOA because it has old-school, corporate connotations. On the other hand, the granularity of microservices seems too extreme for what most products would actually need but the concept is associated with more modern technologies which are attractive to developers, like gRPC or Avro or Kubernetes (or even something as simple as HTTP). So I would say the most pragmatic approach for a greenfield web product (rather than a corporate IT integration) is have a fairly standard core (probably a REST API, a server-side MVC framework, or a GraphQL backend if you're nasty) and factor out services that make sense to the team (maybe a service that handles push notifications, or a service that does image processing, or a service that is the secret sauce of your product) because they need to scale independently or handle async/computational tasks that should have dedicated resources or they pull from a data source that is orthogonal to the rest of the system. You need to strike a balance between "micro" and "service".

There is this idea that you either have microservices or you have a monolith, while its really more of a gradient. I guess what I'm advocating for is "modern service-oriented architecture" or "chunky services" vs "microservices"; reasonably sized, well-considered services that use modern technologies for inter-service communication.

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

#134

Post by fiedzia »

haskellandchill wrote: post #131
fiedzia wrote: post #80

Earlier quoted context omitted.

> Business is pressuring tech teams to deliver faster, and they cannot, so they blame current system And are very often right about it. Delivering monoliths can require such amount of bureaucracy and needless coordination that it slows everything down. I've seen it. > Inexperienced developers proposing microservices because they think it sounds much more fun than working on the system as it is currently designed. It…

What’s fun about microservices? I find them annoying, but a necessary evil depending on context.

They free you from conforming to monolith conventions, which may be very far away from what would be best practice for given service.

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

#135

Post by karandwivedi42 »

I am just starting to develop web apps. Is [JAMStack](https://jamstack.org) + Lambda functions (AWS Lambda) a good place to start with?

Since Lambda functions are similar to microservices, I am now confused if I should stick to simpler backends or full stack instead of JAMStack.

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

#136

Post by closeparen »

blablabla123 wrote: post #130
netcan wrote: post #93

Earlier quoted context omitted.

Reality is also confusing. People can see that in a one day hackathon, the same bunch of people can produce more stuff than they do in a year otherwise. Why? Are they lazy? Did they use better tools? My niece Shelly added address book integration to her hobby app in an afternoon, while drunk. WhyTF are we 640 man hours deep into "identity architecture coordination" meetings?!! Just do with Shelly did! Those things do…

I guess that's the difference between proper Engineering and hacking something quickly and under self-inflicted pressure together. Your nieces app might work on her setup but not on others and may need almost a complete rewrite on an OS/API update. The properly engineered solution on the other hand might "just work" for years. I think key is to realise how much engineering is needed on what occasion. I find it distur…

No, self-inflicted communication overhead due to a bloated bureaucracy is not what separates engineering from hacking.

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

#137

Post by crdoconnor »

vlkr wrote: post #66
crdoconnor wrote: post #26

Earlier quoted context omitted.

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…

"Although the evidence is sparse, I feel that you shouldn't start with microservices unless you have reasonable experience of building a microservices system in the team." https://martinfowler.com/bliki/MonolithFirst.html

Yeah, he wrote that after he realized that the microservice movement he spawned had gone nuts.

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

#138

Post by sixdimensional »

danmaz74 wrote: post #111
sixdimensional wrote: post #85

Earlier quoted context omitted.

Counterpoint: if network calls weren’t flaky and slow would it make a difference in deciding whether to separate modules via a physical machine boundary?

But network calls ARE inherently flakier and slower. What good does it to imagine they weren't?

It helps demonstrate where additional investment and development might be warranted. If we have hit a physical limit in networking, then that is one thing - but if we are only hitting an artificial limit because our technology and infrastructure is not sufficiently advanced - then this problem is actually showing an opportunity.

As an architect you have to sometimes ignore constraints to understand if the final picture you would assemble makes any sense. If the final picture you assemble makes sense, then working backwards through the limitations, to find out, are these really limitations or are these opportunities to innovate?

That's my thought as to why you would imagine they are not a limitation. To aid in brainstorming, innovation and identify opportunities for improvement, or alternative solutions you would not have seen if you simply accept the bottleneck as a given.

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

#139

Post by sam0x17 »

adamdrake wrote: post #21

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 t…

I find that, ironically, they are great for all of the things that lambda and google cloud functions make difficult, e.g. image processing, open cv, heavy calculation using third party libraries, etc. What we need is a lambda-like service that uses Docker files that run for a max of 540 seconds.

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

#140

Post by i_made_a_booboo »

hderms wrote: post #121
badminton1 wrote: post #106

Earlier quoted context omitted.

You can. But one day, some 10xer will be short on time and will duct tape your module with 10 other modules.

The newish argument for microservices is that they enable compositionality, so wouldn't that same hypothetical apply? I.e. some 10xer is short on time and glues a bunch of microservices together and now you have the same problem but worse because there's no IDE allowing you to trace the code?

You have a problem. You decide to use regular expressions to solve it. Now you have two problems.

You have a problem. You decide to use microservices to solve it. Now you have ten problems.

Post reply on HN