The Death of Microservice Madness in 2018 • Hacker News Board

Re: The Death of Microservice Madness in 2018

#451

Post by eadmund » Wed, Jan 24, 2018, 1:45 AM UTC

crescentfresh wrote: post #392

eadmund wrote: post #155

Earlier quoted context omitted.

> They developed 12 seperate applications, all in the same repo, deployed independently it's own JVM. I've dealt with an even worse system, with a dozen separate applications, each in its own repo, then with various repos containing shared code. But the whole thing was really one interconnected system, such that a change to one component often required changes to the shared code, which required updates to all the oth…

> then with various repos containing shared code What source control system? Also, from the article: > even though theoretically services can be deployed in isolation, you find that due to the inter-dependencies between services, you have to deploy sets of services as a group This is the situation we are in, like you were.

> What source control system?

Git in our case. And our direction was not to use submodules or anything like that to make life manageable. It was pretty unpleasant.

Re: The Death of Microservice Madness in 2018

#452

Post by ec109685 » Wed, Jan 24, 2018, 7:55 AM UTC

philwelch wrote: post #426

ec109685 wrote: post #247

Earlier quoted context omitted.

Right, but the complexity the author complains about is then not on the individual services’ developer teams.

That's the point, yes?

Right, if you have a strong team supporting orchestration (or outsource to a cloud), the need for every developer to be an operations specialist goes down, yet the team can still support a larger number of services efficiently.

Re: The Death of Microservice Madness in 2018

#453

Post by outworlder » Wed, Jan 24, 2018, 6:33 PM UTC

hibikir wrote: post #79

outworlder wrote: post #57

Earlier quoted context omitted.

I do have a case of monoliths-in-disguise-itis. I just wish someone with "street cred" (or with a famous, recognizable name I could use for appeal to authority) could create a simple post saying "Hey, if you have a shared data store that all services depend on and are accessing directly, you are not doing microservices". "And you also don't have microservices if you have to update everything in one go as part of a "r…

Microservices with a share datasource are just a Service Oriented Architecture, circa 2005. You might have a variety of middle tier services, deployed in their own boxes, or at the very least Java service containers, but ultimately talking to some giant Oracle DB behind it. Microservices that share a database are not deployed into a container running JBoss, and instead use something more language-agnostic, but it's u…

Thanks for the imagery, I love that. Would have to be toned down a bit for a meeting but I can see it working :)

Re: The Death of Microservice Madness in 2018

#454

Post by Nomentatus » Thu, Jan 25, 2018, 10:04 PM UTC

danieltillett wrote: post #430

ska wrote: post #370

Earlier quoted context omitted.

I think there are two things at work here. 1 - there are very good professionals, but they aren't cheap and have all the work they need 2 - an amateur can always decide to take economically irrational amounts of time on a project; a professional can't. So the result is that as a careful amateur you can end up with a job you probably wouldn't be able to convince yourself to pay for. We can probably all agree that the…

Here where I live (Australia) it is near impossible to find good professional tradesmen. While it might be irrational on a financial level to spend my time painting or other trades, I get the quality I want by doing it myself. Even on the financial level tradesmen here in Australia are so overpaid (compared to everyone else) that it makes sense even for me to do it myself. My house was painted by "professionals" just…

Next time two (or at most three) coats - the first coverup coat should be black, since the purple (or red or whatever) won't show through black.

Re: The Death of Microservice Madness in 2018

#455

Post by Double_a_92 » Fri, Jan 26, 2018, 11:44 AM UTC

bonesss wrote: post #334

Double_a_92 wrote: post #280

Earlier quoted context omitted.

How would services such as "sign up", "login", "edit profile", and others that need auth be split?

Just like all the other authenticated APIs in the world: you get a token when you log on, and use that token to authenticate yourself on future calls to the services. That's a lot of what OAuth and its ilk handle. This management of API boundaries is likely handled for you by an app, though, so from a user perspective the story is still "open netflix, enter password, watch movie".

But how is the data shared? E.g. when you sign up you store your data. But to edit it, or to just display it you need to access it again, but that data only belongs to the sign-up microservice...?

Re: The Death of Microservice Madness in 2018

#456

Post by ChicagoDave » Fri, Jan 26, 2018, 7:24 PM UTC

ChicagoDave wrote: post #394

corpMaverick wrote: post #387

Earlier quoted context omitted.

How big or small are your micro-services ? how many do you have ? How do you draw the boundaries ?

I can only refer you to Eric Evans book ( https://www.amazon.com/Domain-Driven-Design-Tackling-Complex... ) and other domain driven design material. Boundaries are by domain, and yes that's not a simple thing to define. Sometimes, domains have varying interfaces, which makes building micro-services more complex, especially when trying to adhere to REST/Swagger standards (something I'm not overly find of). But keeping…

I wanted to add that building micro-services requires a bullet-proof security strategy, usually something like OAuth2.

Using authentication, users of an API can have "claims" that will help a micro-service delineate access and provide a way to design for varying interfaces.

This still leaves the Swagger standards in direct opposition to building a set of variant end points since it _requires_ that end points be singular (you can't have a GET api/foo/{id} and a GET api/bar/{id} on the same API without a lot of fudging. This is a distraction from building enterprise-level API's and leans far too much toward single-purpose API's.

Re: The Death of Microservice Madness in 2018

#457

Post by warrenm » Fri, Jan 26, 2018, 8:39 PM UTC

shitloadofbooks wrote: post #54

I think "microservices" is so appealing because so many Developers love the idea of tearing down the "old" (written >12 months ago), "crusty" (using a language they don't like/isn't in vogue) and "bloated" (using a pattern/model they don't agree with) "monolith" and turning it into a swarm of microservices. As an Infrastructure guy, the pattern I've seen time and time again is Developers thinking the previous generat…

You need to be keeping a ledger on technical debt, the same way any and all other "debt" is tracked - http://www.hydrick.net/?p=2394

"Here’s the thing, most of the time we do something that incurs technical debt, we know it then. It’d be nice if there’s a way for us to log the decisions we made, and the debt we incurred so we can factor it into planning and regular development work, instead of trying to pay it off when there’s no other alternative."

Re: The Death of Microservice Madness in 2018

#458

Post by warrenm » Fri, Jan 26, 2018, 8:40 PM UTC

marcosdumay wrote: post #383

cortesoft wrote: post #205

Earlier quoted context omitted.

So you are saying edge and corner cases are the most difficult?

Keep the stuff from spilling all over the place is also between the most difficult things.

Keeping your buckets sorted is definitely important

Re: The Death of Microservice Madness in 2018

#459

Post by warrenm » Fri, Jan 26, 2018, 8:43 PM UTC

philipodonnell wrote: post #419

SOLAR_FIELDS wrote: post #354

Earlier quoted context omitted.

In that case it was a jobs program (to help construct roads) and the rationale against it was that they were extending beyond their purview of what the commission was meant to do.

Isn't that sort of rational then?

Definitely rational

I think (at least, I hope) what OP was trying to get at was the relative irrationality of something 1/8000th the cost of the very expensive item taking a very long time to debate through (especially when $100,000 is most probably far less than many of those board members earn as a salary every year)

Re: The Death of Microservice Madness in 2018

#460

Post by warrenm » Fri, Jan 26, 2018, 8:44 PM UTC

kuschku wrote: post #267

misio wrote: post #264

Earlier quoted context omitted.

Analogies don't always have to apply to your parents.

My argument is that painting is a much smaller skill difference between a hobbyist and a mediocre professional. Actually good software engineering is a much larger skill difference.

>much smaller skill difference between a hobbyist and a mediocre professional. >Actually good software engineering is a much larger skill difference.

Based on my years across various companies, the difference between "hobbyist" and "mediocre professional" developer/programmer is close to nil