Live data from Hacker News

Microservices Are Something You Grow Into, Not Begin With

nickjanetakis.com

141–150 of 159 posts

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

#141

Earlier quoted context omitted.

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

As GP said the network is inherently flakier and slower and yes, we are very close to the physical limit.

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

#142
post #33

Earlier quoted context omitted.

> Definitely agree you shouldn't start with a ton of services, but I think you should definitely start with more than one. The jump from monolith to service-oriented thinking is a huge one. I can't get my head around this. Why should you start with more than one? What is so different about "breaking your application into services" and "breaking your your application into appropriate modules / classes"? If those need…

What is different about breaking an application into services is that because services run as different processes: * you have an immediate natural failure domain (the process) as well as resource isolation between services, * services can be updated independently (something that is done many thousands of times every day at companies like Amazon or Google), * a corollary of independent updates is that services can be…

I'll give you that you can deploy services separately, but the other advantages that you give could be accomplished with automated testing - that's kind of the point in unit testing to test components independently.

The vast majority of people aren't working at Amazon or Google's scale despite developers seeming to think that they need to work the same way.

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

#143

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.

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

#144
I mostly agree with the article except the part where the author plays down the architectural considerations during project inception.

> Right now it’s just me working on the project, and you can be sure I just cracked open my code editor and started writing code on day 1.

It's definitely fun to start with writing code, but in my view it may be more efficient to pause for a moment, understand the problem and find the right solution for it. Then start writing PoC code, which can be refactored at a later stage. That's just pragmatism - lots of code will go to the bin anyway, but at least we give ourselves a chance to have a longer and happier run with it before that happens.

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

#145

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?

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

#146
post #18

Earlier quoted context omitted.

Indeed. It just replaces internal calls between services of your monolith with flaky and slower network calls.

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?

As people already said, there is little point on talking about hypotheticals, since those properties are inherent...

But there are tools that can distribute a program over a network, and let your functions run at any node with the right capabilities "just like" (the network allowing) if it was local.

This is another point that the microservices pushers miss. It's a solved problem, and can be done in a much better way than what they push around.

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

#147
post #82

Microservices, test driven development, Agile, 4GL and so on. It's all the same thing: a technique that is applicable some of the time but not all of the time that ends up getting a bad rap because the people promoting them tend to come from the theoretical side of the street, and they see the subject matter as their new revenue stream. They will then promote it to be used even when it isn't applicable. A web based s…

>It's all the same thing: a technique that is applicable some of the time but not all of the time that ends up getting a bad rap because the people promoting them tend to come from the theoretical side of the street, and they see the subject matter as their new revenue stream. Also because we've created an industry where everyone must stay up-to-date, so if anything gets traction, suddenly people start getting worrie…

Which leads to Resume Driven Development driving choices rather than logical debates where merits and trade-offs are considered.

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

#148

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…

Yeah, I definitely agree with these points. And I think quite a few of them come down to one simple thing:

There's a huge disconnect between what many developers wish they were doing and what many developers are doing. They wish they were at Google/Facebook/Amazon/whatever working on some complex greenfield project that'll change the world, they're instead working on CRUD apps for corporate clients, agencies and businesses with far less technical needs.

So their obsession with using microservices and modern JavaScript frameworks and complicated build processes and what not for everything comes down to them trying to turn B into A, even if the actual solutions they need don't actually require any of that complexity.

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

#149

Earlier quoted context omitted.

This sounds sanctimonious and rife with the exact same inexperience and overly brittle purist attitudes you are criticizing. It really is true that huge monolith legacy systems might prevent dev teams focused on product growth from even being capable of doing their jobs, let alone meeting aggressive deadlines. It doesn’t always mean microservices or heavy re-architecture is the right choice, but sometimes it absolute…

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.

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

#150

We are finishing up a 2 year migration out of a data center to Aws and a complete rewrite of a Frankenstein Soa (of sorts) to a couple of monoliths .I was basically in charge of choosing the tech selection (we wanted to minimize tech stacks until we could get a handle on it) and the “how.” A monolith made perfect sense as there was nothing salvageable, and I mean nothing. And the traffic requirements were definable,…

I'm dying to read the whole thing. Please.
Post reply on HN