[HN Gopher] Untangling microservices, or balancing complexity in...
___________________________________________________________________
Untangling microservices, or balancing complexity in distributed
systems
Author : ablekh
Score : 39 points
Date : 2020-04-10 20:10 UTC (2 hours ago)
(HTM) web link (vladikk.com)
(TXT) w3m dump (vladikk.com)
| wdb wrote:
| The backlog example in the article is crazy! Do they really do
| services like that in the big world? Backlog service which
| encapsulates all the services I can follow (partly) but all these
| separate ones
| FpUser wrote:
| I've never bought into this idea of microservices. Always wrote
| high performance native servers and have yet to encounter the
| situation when well designed monolith running on multicore
| monster with gobbles of RAM failed to satisfy client. Granted it
| will not work for Google but what does the world care. Most of
| the businesses (read potential clients) will never come anywhere
| close to those scales.
|
| Long time ago when computers were slow I did design some
| distributed applications myself - reliable IP multicast server,
| business process servers, map reduce type solutions like bill
| generation etc where it did make sense. That was long time ago
| and now most of those at their old scale could run on a single
| reasonable priced server.
| jzoch wrote:
| If you dont have a team large enough or a business big enough
| to need multiple individual services than you aren't the target
| market. Unless you care about high availability (which small
| services can help you achieve) then a single server is fine.
| brodie wrote:
| Microservices can be useful in medium/large companies where you
| have many teams of devs and it becomes cumbersome to have them
| all work on one monolith. As long as there's good communication
| and understanding of needs between teams, each team can develop
| their services how they want, in whatever language/platform,
| with their own review and QA and deploy processes.
|
| For smaller teams or small projects it isn't really super
| useful. Also, my personal experience is that when you start
| making microservices, the monolith doesn't go away. It also
| isn't so cumbersome if each team is in charge of one or a few
| services and you only split things if there's a clear benefit.
|
| I'm probably saying things you already know. My point is that I
| think for multiple cooperating teams, monoliths and
| microservices are complementary.
| snupples wrote:
| You don't need to "buy into" an idea to realize that there are
| advantages and disadvantages to a given approach. Take one
| example: The single server idea is going to suffer outages. You
| could at the very least have two monoliths either load balanced
| or in some kind of failover setup. But what distributing some
| of the components would give you is a graceful failure scenario
| where even if all the instances of a specific component fail,
| the rest of the application still works. Maybe only one
| function stops working temporarily but most work continues on.
| This doesn't mean everything must be microservice koolaid all
| the time all the way but I'm sure you can conceive of that
| being an advantage under certain use cases that would be worth
| other possible trade-offs.
| jennyyang wrote:
| Uber is not reorganizing their microservices into
| "macroservices". The original tweeter refuted it, but it's still
| being propagated as fact. Granted the original tweet was poorly
| written but in the thread itself, he refutes it later on.
| antoncohen wrote:
| Thank you. This is the core of it[1], IMO:
|
| > Back in the day, we'd spin up a microservice that did one,
| small thing just like that. We had a bunch of small services
| built and maintained by one person. This was great for
| autonomy, iteration speed, learning and making devops a no-
| brainer. You could spin up a service anytime: but you'd be
| oncall for it.
|
| > Now, as my area is maturing and it's easier to look ahead, as
| we create new platforms, we're doing far more thoughtful
| planning on new services. These services don't just do one
| thing: they serve one business function. They are built and
| maintained by a team (5-10 engineers). They are more resilient
| and get far more investment development and maintenance-wise
| than some of those early microservceis.
|
| [1] https://lobste.rs/s/mc3k1c/at_uber_we_re_moving_many_our
| 0xDEEPFAC wrote:
| Relevant comedy: https://www.youtube.com/watch?v=y8OnoxKotPQ
| ecnahc515 wrote:
| I knew this would be in the comments before even opening the
| page. This thing has been getting shared a ton lately since it
| was just uploaded 2 weeks ago. I think it kind of goes to show
| how many people empathize with the video.
| Frost1x wrote:
| This made my day, thank you.
| ablekh wrote:
| Hilarious video (and most likely very true). Thank you for
| sharing.
___________________________________________________________________
(page generated 2020-04-10 23:00 UTC)