Microservices Are Something You Grow Into, Not Begin With • Hacker News Board

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

#151

Post by i_made_a_booboo » Sat, Oct 20, 2018, 11:19 AM UTC

netcan wrote: post #93

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…

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…

Best comment ever.

Especially as I'm sitting here learning ASP.NET Core Identity on Pluralsight for hours and thinking about all the "identity architecture coordination meetings" I'm anticipating having on this next project.

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

#152

Post by ex_amazon_sde » Sat, Oct 20, 2018, 11:52 AM UTC

ex-aws-now-goog wrote: post #67

ex_amazon_sde wrote: post #59

Earlier quoted context omitted.

Microservices are a cult, but SOA is Amazon's conerstone. Most services are the right size to fit a team (so, not micro) and implement separation of concerns. Random link: https://www.zdnet.com/article/soa-done-right-the-amazon-stra...

Some Amazon teams have multiple services of varying sizes. What Amazon and similar companies get right is by (generally) insisting on good engineering/business/regulatory reasons for splitting out services.

> Some Amazon teams have multiple services of varying sizes

Yes. I'm not saying that is 1 team runs only 1 service, but with "microservices" people tend to refer to much smaller daemons.

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

#153

Post by madeuptempacct » Sat, Oct 20, 2018, 3:34 PM UTC

spdionis wrote: post #143

madeuptempacct wrote: post #99

My problems with microservices irl: 1. Sharing models - the models can be moved out to another repository or a NuGet package, but guess what happens when you have to modify them? Inevitably, devs duplicate models. 2. Debugging across five different code bases - have fun changing all the environment variables to point to your local every time, or running five different applications at the same time for local developme…

Is duplicating models that big of a problem? Just an honest question, hoping to get more answers/opinions besides parent's.

It's a good question. Going to let others answers. My tldr opinion is "Not really, but code duplication any time, but especially across repos can lead to hard-to-troubleshoot errors".

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

#154

Post by blablabla123 » Sat, Oct 20, 2018, 5:05 PM UTC

closeparen wrote: post #136

blablabla123 wrote: post #130

Earlier quoted context omitted.

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.

I guess it depends on the company. But most of the time it seems bloated bureaucracy is a symptom of dysfunctional work relationships. When people know what to expect from each other and stuff "just works", then there is no need for any such thing and indeed you probably won't find it I think

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

#155

Post by JamesBarney » Sat, Oct 20, 2018, 5:51 PM UTC

mlthoughts2018 wrote: post #149

JamesBarney wrote: post #116

Earlier quoted context omitted.

Isn't the argument that is being made that you did things exactly right. That microservices are a great architecture to migrate to when you feel the need. But aren't a great to start a project.

I don’t see how you get that at all. The comment starts out expressly criticizing when organizations consider migrating to microservices from existing monolith projects.

The comment was arguing the use of microservices is far more common than the need for microservices. And based on your description it sounds like you guys were one of the few that had a need for microservices.

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

#156

Post by karandwivedi42 » Sat, Oct 20, 2018, 6:04 PM UTC

spdionis wrote: post #145

karandwivedi42 wrote: post #135

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.

Is that a joke website or serious?

Serious. It is a concept by the creators of Netlify.

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

#157

Post by mlthoughts2018 » Sat, Oct 20, 2018, 9:35 PM UTC

JamesBarney wrote: post #155

mlthoughts2018 wrote: post #149

Earlier quoted context omitted.

I don’t see how you get that at all. The comment starts out expressly criticizing when organizations consider migrating to microservices from existing monolith projects.

The comment was arguing the use of microservices is far more common than the need for microservices. And based on your description it sounds like you guys were one of the few that had a need for microservices.

> " The comment was arguing the use of microservices is far more common than the need for microservices."

In re-reading the parent comment several times now and taking some time to reflect on it, I find that I am not able to agree with this interpretation of it.

As I understand it, the parent comment is taking issue with any type of reaction to a monolith in the direction of switching to microservices as a tactic to get rid of the blockage and tech debt. The comment does allow that some cases may support the use of microservices, but this secondary comment is so at odds with the sanctimonious tone sardonically criticizing people who want to migrate to SOA from a monolith, that I just do not find that phrasing to contribute much to my understanding of the comment. It seems clear to me that the comment means to harshly denigrate the idea of wanting to switch to SOA as a solution strategy in those cases, and the "concession" that sometimes it might be the right thing to do is tacked on, not really related to everything else.

I accept that we might just agree to disagree on the interpretation, but I still feel comfortable that my original interpretation is the most consistent with the available text of the comment and the context of it.

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

#158

Post by harel » Sun, Oct 21, 2018, 7:35 PM UTC

eropple wrote: post #81

harel wrote: post #37

Bottom line is that it's all a case by case basis. However I'll always warn against slicing microservices too thin. Each slice is a moving part outside of the machine and therefore brings in additional risk. I recently refactored/rewrote a monolithic project into a few fairly chunky services. Each one is sliced by a broad context. The only reason I did it was because the monolithic app required separate physical depl…

The term used before "microservices" got trendy was "service-oriented architecture," or SOA. So this isn't exactly a new idea. ;)

Nope. Nothing new here. I remember SOA very well as the buzz word du jour back then. It sounds less cool than micro services though. At least we got our buzz words through the PR & Marketing departments in this decade.

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

#159

Post by koffiezet » Mon, Oct 22, 2018, 4:20 PM UTC

madeuptempacct wrote: post #99

My problems with microservices irl: 1. Sharing models - the models can be moved out to another repository or a NuGet package, but guess what happens when you have to modify them? Inevitably, devs duplicate models. 2. Debugging across five different code bases - have fun changing all the environment variables to point to your local every time, or running five different applications at the same time for local developme…

> 3. Docker and Kubernetes add a LOT of overhead.

That depends on the application.

But docker adding overhead? Everywhere I introduced docker to devs, productivity went up, not down once a good way of working was presented to them. No 10 devs using some different versions of the same database engine, no more rogue gmail accounts for 'testing purposes' by showing them mailhog, updating the backend service became as much as a 'git pull' and 'docker-compose up' for the frontend devs instead of in the best scenario killing their vagrant vm and reinstalling it, or worst case, a 3-page installation/configuration document to follow on a fresh VM, and the list goes on... Sure there is some overhead involved, people need to learn a new tool - and have a bit more feeling with how software is deployed, but from an infra pov, that's a good thing.

Kubernetes? Yes that adds a ton of overhead, certainly initially. Few really need it, but if you move from a monolithic app into a more micro-service based architecture for scalability issues, something like k8s is a godsend. What I do notice however is that once teams are accustomed to a workflow involving it after building a large application, they actually enjoy it and also start using it for smaller-ones. Architecture-wise it's easy to go overboard with the microservices, splitting things up simply because they're 'cleaner' - but that's something you should resist.

But as you say, for smaller web apps, microservices make no sense...