Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Death of Microservice Madness in 2018

dwmkerr.com

Post reply on HN
Print view View original

331–340 of 469 posts

Re: The Death of Microservice Madness in 2018

#331

Post by bonesss »

oblio wrote: post #319
lulmerchant wrote: post #265

Earlier quoted context omitted.

"microservice" is certainly a buzzword, but it's not just service-oriented architecture. Mircoservice architecture is modular design, with all the advantages of effectively infinite scale, incredibly flexible orchestration, and the resilience provided by the public cloud providers. It has it's own set of challenges, and it isn't the right solution for every problem. But it can be fantastic when used properly. I've wr…

And how is that not also service oriented architecture? That's also supposed to be modular and one of the reasons for splitting out service is to scale. You can then place those services in a cloud...

Microservice architectures are a sub-category of SOA.

Many of the same reasons to use them apply to both, but with a finer granularity on what is being hosted where and how it is scaling with microservices. Scaling a service with multiple facets going through it gets tricky, hence a desire for a more appropriate modularity.

"Placing services in the cloud" kinda papers over why microservices and cloud-native apps hang together so tightly... Leveraging cloud-provider capabilities (message queues, streaming services, specialized DBs, etc), often introduces new kinds of scaling, new requirements, and new deployment needs at the component level. Particularly if you're working in multiple clouds or a hybrid environment or with teams in different organizations... Tech stacks might diverge at the component level, developer competencies diverge, maintenance routines and monitoring and the rest of it too.

A thin service wrapper in front of DynamoDB is gonna have a different scalability story than a DoItAll service on a VM that can also write to DynamoDB. Especially if the service is used by multiple apps, or customers in addition to apps. For a SaaS outfit that can be make or break.

Re: The Death of Microservice Madness in 2018

#332

Post by bonesss »

giancarlostoro wrote: post #329
nemothekid wrote: post #33

Earlier quoted context omitted.

Once when starting a new gig I inherited a "microservices" architecture. They were having performance problems and "needed" to migrate to microservices. They developed 12 seperate applications, all in the same repo, deployed independently it's own JVM. Of course if you were using microservices, you needed docker as well, so they had also developed a giant docker container containing all 12 microservices which they de…

Sounds like they don't understand why it's called a microservice to begin with. They're not supposed to be solutions an entire piece of software, just dedicated bits at least that's what I'd figure with a name such as "micro". When we adopted microservices at my job (idk if Azure Functions count or not) we did it because we had 1 task we needed taken out of our main application for performance concerns and because we…

> idk if Azure Functions count or not

Azure Functions are technically a "serverless" product, but using them as y'all intended to is a textbook definition of a "microservice" :)

Re: The Death of Microservice Madness in 2018

#333

Post by stult »

simias wrote: post #268
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…

The #1 thing they should teach in any engineering school (or maybe any school period ) is "you shouldn't remove/replace/change something until you've understood why it was done that way in the first place". Or maybe a somewhat equivalent version: "you're not as clever as you think you are and the people who came before you were not as dumb as you think they were".

>"you shouldn't remove/replace/change something until you've understood why it was done that way in the first place".

That only works until you encounter something for which there was no rational reason in the first place.

Re: The Death of Microservice Madness in 2018

#334

Post by bonesss »

Double_a_92 wrote: post #280
openasocket wrote: post #61

Earlier quoted context omitted.

So, according to your advice, we shouldn't use micro-services that write to a database, ever? That doesn't make any sense to me. Multiple services writing to the same database can be bad, but a single service storing persistent state in a database is perfectly fine. Just because we're micro- doesn't mean we have to cut out 90% of what a service is.

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".

Re: The Death of Microservice Madness in 2018

#335

Post by coldtea »

ivan_gammel wrote: post #290
pjmlp wrote: post #229

Earlier quoted context omitted.

They can manage those teams by writing libraries, no need for microservices.

It's much harder to deploy a library fix to production (producing a new build of integrated app in large team is a big deal), than a microservice.

You'd be surprised. With a microservice you still need to coordinate the release with other consumers of it.

Re: The Death of Microservice Madness in 2018

#336

Post by bonesss »

ozim wrote: post #266
dragonwriter wrote: post #200

Earlier quoted context omitted.

I think that it is accurate to say that in a system composed of microservices, a microservice should not effect the state of other microservices in the system other than by consuming them. Whether it should consume other microservices is less clear, and gets into the choreography vs. orchestration issue; choreography provides lower coupling, but may be less scalable.

Services consuming other services, sounds like recipe for spaghetti. I hope people use layering where you don't call stuff that is in the same layer.

> Services consuming other services, sounds like recipe for spaghetti.

Can we extend that logic to classes or interfaces? Accessing data operations through a well-established API is generally seen as a good thing and is the exact cure for spaghetti...

Service APIs also entail load balancing and decoupled deployments, so they eliminate unclear architecture that arises at the app level when trying to tune the whole for individual components. Particularly when a shared component exist across multiple systems.

For a generalized microservices architecture: layering is a bit of a misnomer as everything is loosely in the same 'service' layer... I'd also point out that in N-tiered applications application services or domain services calling other services at the same layer is seen as the solely approved channel for re-use, not an anti-pattern.

Re: The Death of Microservice Madness in 2018

#337

Post by bonesss »

mathattack wrote: post #80
dvt wrote: post #15

Biggest issue with microservices: "Microservices can be monoliths in disguise" -- I'd omit the can and say 99% of the time are . It's not a microservice if you have API dependencies. It's (probably) not a microservice if you access a global data store. A microservice should generally not have side effects. Microservices are supposed to be great not just because of the ease of deployment, but it's also supposed to mak…

Do you have examples of micro services and good data warehouses working well side by side? Your point makes sense, but I keep hoping for a way to have One Data Source Truth working side by side with the services that across it.

You might want to look into Apache Kafka, with log compaction, which provides a model to accomplish exactly that while also handing message passing/data streaming.

Your data warehouse can suck facts from Kafka (with ETL on either side of the operation, or even integrated into Kafka if you so desire), and you can keep Kafka channels loaded with micro-"Truth"s (current accounts, current employees, etc). That way apps get basically real-time simplified access to the data warehouse while your data warehouse gets a client streaming story that's wicked scalable. And no coupling in between...

It's a different approach than some mainstream solutions, but IMO hits a nice goldilocks zone between application and service communication and making data warehousing in parallel realistic and digestible. YMMV, naturally :)

Re: The Death of Microservice Madness in 2018

#338

Post by chrisweekly »

nurettin wrote: post #203
spraak wrote: post #162

Earlier quoted context omitted.

You really think that the productivity of today's programmers is less? What evidence and data do you have for that?

Warning: all anecdotes. While I don't think that productivity has decreased, what was notepad, a compiler, some dlls and a debugger before turned into a thousand little packages, several configuration files, a bunch of servers you have to run on your dev. computer, which is also 10x more capable, yet everything feels so sluggish. I also feel that ceteris paribus, the meetings got longer, project management tools now…

>"ceteris paribus" Latin for "all things equal".

Re: The Death of Microservice Madness in 2018

#339

Post by bonesss »

ianamartin wrote: post #309
mathattack wrote: post #80

Earlier quoted context omitted.

Do you have examples of micro services and good data warehouses working well side by side? Your point makes sense, but I keep hoping for a way to have One Data Source Truth working side by side with the services that across it.

A data warehouse really should be completely orthogonal to any architecture choices. Good data warehouses are fed by data engineering pipelines that don’t care if you have a single rdbms or multiple document stores or people dropping CSVs in an FTP directory. I hate to burst your bubble, but you shouldn’t and can’t have truth working along side systems that access it. Data is messy and tends toward dishonesty. The on…

> The only way to get usable data ... is by separating your truth from your transactional data.... If you let your transactional systems access and update data directly in your warehouse, you are in for a universe of pain.

I strongly agree with this assessment :)

I have posted a bit more on this nearby, but Apache Kafka is well positioned as a compromise to support both of those truths: an orthogonal data warehouse full of sanitized purity and chatty apps writing crappy data to their hearts content.

By introducing a third system in between the data warehouse and transactional demands, Kafka decouples the communicating systems and introduces a clear separation of concerns for cross-system data communication (be they OLAP, or OLTP).

If your transactional data is crappy (mine is!), and you want your data warehouse pure (I do!), then Kafka can be a 'truthy' middle ground where compromises are made explicit and data digestion/transformation is explicitly mapped, and all clients can feast on data to their hearts content.

Re: The Death of Microservice Madness in 2018

#340

Post by Jaruzel »

moreless wrote: post #328
WalterBright wrote: post #277

Earlier quoted context omitted.

I've tried to hang sheet rock. How hard could it be? It certainly looks easy. A disaster for me, too.

For us non-english speakers - "sheetrock" == drywall. I find I can do most such works better than (average) professionals, but it takes a lot of time to learn, prepare, execute (+ sometimes re-execute) and clean. It all depends on when you are satisfied with the result.

I recently came across 'sheetrock' as a term and had to google it...

For UK natives it's actually three steps:

"sheetrock" == drywall == Plasterboard

Post reply on HN