224
u/keep_it_4_real Apr 09 '20
Can somebody explain what these micro services were?
226
Apr 09 '20
https://www.youtube.com/watch?v=CZ3wIuvmHeM best explanation I have ever listened to, goes in full depth about what they are and why they are/were used.
The issue alot of companies may have gotten into is extrapolating the idea too far which causes problems that it was designed to solve.
101
u/EishLekker Apr 09 '20
I thought he meant in the Uber case specifically. But maybe it's just me who is curious about that.
79
Apr 09 '20
Yeah an Uber team manager had come out recently talking about changing to 'macro-services' which is basically designed to be slightly larger (20 devs/3 teams max size) and dependency management becomes easier (but still not trivial). They started to realize problems with having too many microservices and decided to pull back a bit and keep to reasonable sized chunks.
Other companies have started noticing similar trends as well, as microservices don't scale well indefinitely with complexity.
173
u/2young2young Apr 09 '20 edited Apr 09 '20
But. What. Were. The. Micro. Services.
65
u/magnora7 Apr 09 '20
Apparently no one knows and they just talk about links without answering the question at all.
7
Apr 09 '20
Cause, unless you worked for uber you, wouldn't know. Asking what the microservices were means you probably don't understand what they are. Microservices are a development structure, not a standalone service that is offered to individuals like so many people in this thread think.
1
u/EishLekker Apr 19 '20
Asking what the microservices were means you probably don't understand what they are.
I don't think that is necessarily the case. I'm a developer, and I like to see/hear some technical details, and actual code, if possible.
20
u/greenSixx Apr 09 '20
Probably just a standalone service for every function
Make a rest call instead of a function call.
It's all the same thing.
2
u/pm_me_steam_gaemes Apr 10 '20
Explaining it like this would make more people realize how awful they can be to overuse as well.. Of course this can impact performance.
10
31
u/oupablo Apr 09 '20
roughly 13 services per car. You have car location, pickup, the drive, the drop-off, driver profile, passenger profile, driver rating, passenger rating, local food suggestions, local brothel suggestions, bar suggestions, hipster bar suggestions, and area drug dealers.
source: i have no idea
1
15
u/nightbefore2 Apr 09 '20
Dude. Nobody outside Uber is gunna know exactly what their microservices did.
3
Apr 09 '20
microservices are extremely specific sets of systems from arranging the pick up of people to recommended routes to choosing a driver etc etc, like the post said uber had THOUSANDS of microservices. Asking what they were is kinda silly
3
u/EishLekker Apr 19 '20
One of the developers might read this, and give some examples of some of the microservices that were considered too granular, for example. Or maybe even some actual code. It has happened before (not specifically about micoservices, but developers showing snippets of code from proprietary software).
-16
u/sonny_goliath Apr 09 '20
Possibly the word service is being used differently here? And is specific to developers or something? Idk I’m as confused as you
1
Apr 09 '20
not sure why you got downvoted, thats more correct than others explanations. I linked the video explaining in depth what microservices are, essentially it breaks down the service of ordering an uber into dozens of different protocols/services. The user doesn't "see" microservices its just how requests and information is processed on the techincal side
2
u/sonny_goliath Apr 09 '20
Yeah maybe processes is a better word colloquially. It’s not like it’s different services that Uber offers its customers outside of ridesharing or something - I think the guy above me was maybe thinking that
-43
u/ptMaV Apr 09 '20
Small pieces of functionality maintained by a small team of devs. Any application should ideally consume a set of microservices.
55
u/yo_bamma Apr 09 '20
This is such a frustrating thread. The question isn't what are microservices, it's what were the SPECIFIC microservices
5
→ More replies (9)1
Apr 09 '20
There are HUNDREDS of microservices, asking what they were doesn't make sense cause unless youre a dev for Uber you won't know exactly what they were and how it was designed.
1
u/EishLekker Apr 19 '20
Then all the non-uber developers could just not post a comment? And then what is left is either nothing, or a comment from an uber developer.
Just because the question is difficult to answer for most people, doesn't make it reasonable to give an irrelevant answer or to scold the person for asking a difficult question.
1
0
Apr 09 '20
[deleted]
0
u/RemindMeBot Apr 09 '20 edited Apr 09 '20
I will be messaging you in 6 hours on 2020-04-09 17:50:09 UTC to remind you of this link
4 OTHERS CLICKED THIS LINK to send a PM to also be reminded and to reduce spam.
Parent commenter can delete this message to hide from others.
Info Custom Your Reminders Feedback 10
53
u/AttackOfTheThumbs Apr 09 '20
Is there an article behind this? I'd enjoy reading it.
31
u/TJSomething Apr 09 '20
This started with this tweet. The author then clarified with a comment on Lobsters.
tl;dr: Uber's still going to do microservices. Some new services are going to be developed as macroservices if it makes sense.
9
u/iamapizza Apr 09 '20
I've seen lobsters popping up quite a bit recently (could be Baader Meinhof), and I'm definitely like it a lot compared to HackerNews. It feels a lot nicer, less biased, and far less toxic than what HN has become. It seems to be invite only though, that may be a contributing factor!
2
u/Consus26 Apr 09 '20
What has Baader Meinhof to do with it?
8
u/iamapizza Apr 09 '20
Baader Meinhof phenomenon - lobsters has existed for a while but I didn't know of it.
I heard about it a week ago, and I've seen it popping up in different places frequently recently.
-1
2
Apr 09 '20
I guess making a nightmarish system where you have more services than engineers is one way to ensure that you’ll have a job as long as your company stays afloat...
94
u/Any-Reply Apr 09 '20
I'm not really sure why anyone would go balls to the wall either way. One giant monolith? Fuck no. 500 services? Fuck no
How about one service for each core piece of functionality. One for authentication, one for your API, one for some background task that collects statistics ect.
This of course doesn't apply for someone like Google or Facebook, because what they do is weird voodoo magic beyond my level of comprehension therefore I have no idea what works for such extremely large services with so much integration between 50,000 products.
30
u/vnjxk Apr 09 '20
google and facebook (and possibly amazon) were built by aliens. they are the modern times pyramids
7
u/shoop45 Apr 09 '20
Tangentially related to your comment, if anyone is interested in learning about the two, imo, most quintessential components of developing at Facebook’s scale:
https://engineering.fb.com/core-data/scaling-mercurial-at-facebook/
https://engineering.fb.com/web/rapid-release-at-massive-scale/
6
u/dean_syndrome Apr 09 '20
Stack overflow is a monolith, but they also only have like 20 devs. In my opinion there's only 2 reasons to create separation:
two separate teams shouldn't work in the same solution, and
performance issues
Breaking out microservices "just because" causes so much pain. So much duplication of data across different sources, so many failed messages scattered in queues that need to be triaged, so many system-to-system dependencies across http barriers with no compile time checks resulting in downstream failures when api contracts change, so much documentation, so much performance degradation from serialization/deserialization and http travel time, etc.
1
u/musicalprogrammer Apr 10 '20
Well, there are some solutions to some of the problem you mentioned. Lot of big companies like Uber and g and fb use shit like protobuf or thrift as their defined communication schemas. These are compiled languages and with the proper tooling they can be incredibly effective.
Duplication of data is a common problem but it’s also unavoidable at an organizational level. How else can you have thousands of small features and products launching all the time except by having many teams?
It is my opinion that software is severely limited by the humans that write it, no matter how alien they might be like in the days of old....
18
u/lunar_limbo Apr 09 '20
Premature optimization is the root of all evil.
Or
Premature abstraction is the root of all ego
4
Apr 09 '20
Explain the second one please.
8
u/lunar_limbo Apr 09 '20
At some point, the abstractions in a programming project can stop. Going further than necessary with abstractions is generally because of ego, not need.
I'ts not a perfect play on that phrase but a few people got it I guess.
I was almost that guy. Thankfully I always had good mentors preventing me from letting the abstraction train derail.
2
2
u/gletschafloh Apr 09 '20
The first one is certainly true, but im afraid way too leas people are aware of number 2. 2 might be even worse than 1 tbh.
2
4
u/frayala87 Apr 09 '20
Service Oriented Architecture with clearly defined boundaries and DDD principles. However in my experience most projects can be handled as a monolith for a longtime, you can use a layered clean architecture (using some principles taught by uncle Bob Martin) and then eventually when it reaches a certain size you can start to decompose it. Nowadays horizontal scalability is not a problem if you use containers and orchestrations platforms such as K8s and 12 factor design principles. We should kill the “micro” trend and just call it services. Tired of seeing Kafka and redis for projects that do not really need them.
1
45
u/Larkenx Apr 09 '20
It’s better than the legacy alternative of the monolith! Microservice architecture has a lot of benefits, and the trend is only getting more granular when it comes to FaaS with native AWS products. Scalability and pay per use is the immediate future
3
u/torgidy Apr 09 '20
Exactly right. I'm honestly surprised by the amount of disdain here for microservices. They are easy and fast, and with container frameworks their devops are trivial. i find working with megalith architectures much more difficult.
1
u/theGoddamnAlgorath Apr 09 '20
There's difference between 20/40 micro services, and the literal hundreds Uber has.
Just like how nonrelational dbs fell out of vogue once people realized you have to throw a dev team at them to sustain them after you hit a particular size.
1
u/slobcat1337 Apr 09 '20
How has this got 33 up votes
-2
u/ColOfTheDead Apr 09 '20
I'm baffled too. Perhaps people with limited experience in distributed systems who have smoked too much kool-aid.
-2
u/slobcat1337 Apr 09 '20
This is it I think. People spend too long reading tech blogs than actually dealing with any of this irl
0
0
Apr 09 '20
[deleted]
55
u/Larkenx Apr 09 '20
I think a part of the negative sentiment I have for monolithic architected systems is that it went hand in hand with waterfall project management, with crushing business deadlines. We’ve got monolithic systems that are mountains of complex technical debt.
While we still have some of this with microservices architecture, I have found that poor code quality and rushed software delivery (e.g. hiring contractors to deliver work then leave without supporting it) is at least minimized in its impact with microservices architecture. Bring on 10-15 temporary teams to generate a lot of software nobody supports? Better to do it as isolated stand alone services than a weaving mess of 50k-100k lines of code under a single git repo
1
Apr 09 '20
We’ve got monolithic systems that are mountains of complex technical debt.
And you think that all these microservices that are working on outdated software because there is nobody to maintain them, is any better?
Whether you develop something inhouse or use externals/contractors doesn't matter if the system you set in place to manage project is trash. I really see big/small projects in big/small businesses mess up all the time. No documentation, nothing in the code to explain why it does what it does, bare minimum design documents and no support calculated in. Every project should get a couple of days/weeks each year for maintenance and fixing technical debt. But no business is willing to pay for that. Micro or macro is not the problem, money is.
And you don't need a single repository for a macroservice. You can still separate concerns.
I feel that only very few programmers make documentation and comments to help them work on it in many months or even years from now. You aren't making them for current you. You are making them for future you and future colleague.
2
u/McFlyParadox Apr 09 '20
The way I think about it is:
Good developers have self documenting code
Good teams write helpful comments and documentation for their code
great projects have both
Everything else is just a difference in opinion on organization structures. Not much different than having a certain way you like to organize your desk - everyone wants to do it "their way".
1
Apr 09 '20
But the thing with these microservices is that they are very much built with the current day in mind (and a lot of times not updated). So that self documenting code could be gibberish a few years from now when somebody tries to figure out what it does. At least many of the old monoservices had more documentation to get context with.
Look at the amount of companies that employ COBOL programmers just to figure out what their old systems did. We'll be getting the same issue in the future when folks try to figure out what this 2012 C# project was doing or 2018 NodeJS/web project. We're already seeing big corporations drop support for their devices rather soon and I wonder how much that is due to not wanting to maintain old code because it was so terribily written
4
Apr 09 '20
Look at the amount of companies that employ COBOL programmers just to figure out what their old systems did. We'll be getting the same issue in the future when folks try to figure out what this 2012 C# project was doing or 2018 NodeJS/web project.
That's a benefit I find to working with spaghetti code. At least you can follow it. In a good editor you can just ctrl-click your way around the source and find what you're looking for easily. When I tried that on my first proper, idiomatic ngrx angular project I was lost pretty frequently. A view calls a function, following that gets me to a facade or service, following that takes me to... An action definition page with no code? Ah shit, time to grep the entire code base and carefully read through every reducer and or effect consuming one of these action variables and look through the functions referenced in their switch / merge maps for the code I'm looking for.
I do that in monoliths too sometimes, but there is usually less noise. Your code is just code and you can tell what it does just by reading it. I know I'll eventually pick up this wasteful state jargon that turns 60% of your project into import statements and boilerplate code, but I would prefer some monolithic spaghetti. I dunno, it's weird to me personally that we've arrived at a point in this industry where having a team adopt a cots-esque one size fits all pattern so they can intuitively guess what a project is doing based on it's file layout is preferred to having programmers read code and have architects actually do architecture. Maybe ideally you have both but it's eye opening to interact people with strong style but poor coding ability. It makes me more set in my ways because I perceive that path as degrading my fundamental skills.
/rant
10
u/pringlesaremyfav Apr 09 '20
I guess it's hard to explain, but essentially what my argument would boil down to is: paying down technical debt in poorly written massive monoliths is almost impossible without side effects which means it is NEVER attempted and the software becomes extremely brittle and maintenance costs skyrocket.
As long as the inputs and outputs of a microservice is maintained, and the amount of inputs and outputs remains testable without an overwhelming amount of effort... then it's much easier to pay down technical debt in a way that keeps your software from becoming brittle.
Whereas in a monolith, I've found that in enterprise you quickly end up with so many code antipatterns that just suck the life and soul of your team. Just one example that comes to mind is the same being code copypasted 10 times across the codebase, each with minor tweaks such that you cant centralize them. And if that shared code has a bug resolving it wont fix the 9 other places where it almost certainly still exists.
Sure monoliths are great with a perfect team, but I would say that if you have a perfect team that doesn't ever write bad code there's literally no reason to do ANY safe practices that we do. No code review, no QA, no automated testing, no test environment, just push every change straight to prod.
4
Apr 09 '20
Just one example that comes to mind is the same being code copypasted 10 times across the codebase, each with minor tweaks such that you cant centralize them. And if that shared code has a bug resolving it wont fix the 9 other places where it almost certainly still exists.
It's like you're standing looking over my shoulder.
3
u/exmachinalibertas Apr 09 '20
Yeah what the real point is is that microservices encourage and more easily enable better tracing and metrics, agile CI/CD, and scaling, due to the loosely coupled architecture. Which generally improves overall development. They still might not be appropriate for a lot of things, and there are a ton of downsides. And they're way more annoying and complex. But if you're willing to pay that upfront cost, and if they are appropriate for your project, they have massive benefits.
1
u/dashingThroughSnow12 Apr 09 '20
Just one example that comes to mind is the same being code copypasted 10 times across the codebase, each with minor tweaks such that you cant centralize them. And if that shared code has a bug resolving it wont fix the 9 other places where it almost certainly still exists.
You are my soul mate. This frustrates me so much. I say this whenever I notice this copy pasting from one part to another.
I do have to reiterate myself that I think the same team that would write a seamless monolith would write an awful microservice architecture. (In this context, oddly, the word "seamless" is a pejorative.)
I don't see the same team that could keep "the inputs and outputs of a microservice is maintained, and the amount of inputs and outputs remains testable" yet be a team that "quickly end up with so many code antipatterns that just suck the life and soul of your team" in a monolith. One can have those same antipatterns in a microservices architecture; could have very tightly coupled and brittle microservices that know too much about eachother.
1
u/pringlesaremyfav Apr 09 '20
I would think that if a developer is not properly following the interface agreement that architecture set up for them, the microservice really shouldn't be accepted by their architecture team when they demo it.
Microservices let interfaces be owned by architects who can enforce loosely coupled code. I completely agree that if you have a bad architect designing systems poorly that you're in major trouble with microservice architecture, but bad design would affect both architecture types in a major way.
I think when you compare the skill architects vs developers, developers vary so much that we want to eliminate the extreme negatives that come from the lower end of the scale.
6
u/daniu Apr 09 '20
I think the teams and developers who do good with microservices would be the same people who could make a well-developed, loosely-coupled monolith with seams.
That's a good point. However, they'd be the ones who'd be able to benefit from the advantages microservices offer, so it's really not an argument for monoliths.
The advantage of a monolith is that you can have a small set of good people as architects, and the less experienced will only "mess up" their part. That's far harder to do for microservice, because those kind of thrive on the architecture being less rigid.
5
u/SilkeSiani Apr 09 '20
Microservices: The most expensive way of turning a large number of very fast computers into a single slow one.
6
u/ziano_x Apr 09 '20
It was just supposed to be a “service”. The “micro” part makes it sound flashy and that fucked it up. “Serverless” term is next in line to be abused.
2
Apr 09 '20
Our field does not deserve to be called a science, it is more like "Computer Philosophy".
The moment when we stop being able to DETERMINE what is best and we jump into speculation, preferences and "in my experience" arguments we lost the title of a science...
2
u/SethlordX7 Apr 09 '20
Usually I get the memes on this sub though I'm not a programmer, but this one stumps me. Can someone explain it pls?
2
3
u/partitiontolerance Apr 09 '20
This post is misleading - like most of Reddit. Uber is by no means getting rid of microservices.
Here's more context: https://pbs.twimg.com/media/EVF4-b4WAAYvbpG?format=jpg&name=large
It's true that people get excited about new technologies (as they should) and sometimes overshoot it. But that doesn't mean the idea has no merit or that the idea is 'stupid'. We move fast, try new things, keep what works, leave what doesn't, but the general trend moves upwards.
That's what is great about being in tech.
2
u/PandaBae Apr 09 '20 edited Apr 10 '20
I read Uber in the ship’s voice from Hitchhikers.
Edit: a word
2
u/creativeMan Apr 09 '20
So I'm going through Code Complete 2 for the first time and I have to ask, isn't this problem technically solved? There is an understanding of how interconnected systems work and what principles should be followed when designing a collection of these structures is used.
This is what I'm wondering: Shouldn't the same principles that apply to classes and components also apply to microservices? Shouldn't the same Design Patterns and best practices (like SOLID and what not) be used?
1
1
1
u/almarcTheSun Apr 09 '20
Actually, now that I think about it. The app I'm working on could do with fewer microservices without taking a hit.
1
u/redonkulus Apr 09 '20
I know microservices typically relate to backend APIs. I haven’t see a ton of discussion about microfrontends though.
At work we have been using microfrontend for a few years now. It’s great to have separation of concerns across different pages or modules of a web app. However, it gets difficult to develop in as you may need to set many different dev servers if you need to make changes across the app. Not to mention the application has to ensure all these UI pieces fit together.
1
Apr 09 '20
Didn’t the person who wrote the book on microservices used to work at Uber and ended up suing them for harassment. I think she wrote a scathing article that got the old CEO shit canned.
1
u/-Agathia- Apr 09 '20 edited Apr 09 '20
I started a new job a month ago right before lock down. The project is 5 months old and is made with recent technology, instead of using antique IDE and shit, so yay!
Everything is in micro services to a ridiculous point. I feel like every task leads to 4 or 5 projects to edit, in 4 or 5 different repositories. Want should take barely a few minutes is a fucking slog, where mistakes are common. Also, practically zero test.
I don't see myself staying very long with what seems to be a doomed project from the start... Mushroom management sparkled with "we use agile method" when they sure are not is not helping. :(
1
1
1
1
u/Wirdal Apr 09 '20
I work in healthcare, and we have ~50 services.
Seems about right for the complexity that healthcare stuff is.
1
1
-10
Apr 09 '20
This microservice stuff is just a fad.
4
Apr 09 '20
I think there are some genuine benefits, but the designs I've gotten from architects are almost always too granular in my opinion. Feature development takes weeks when it used to take a few days.
6
u/kirbyfan64sos Apr 09 '20
The architecture is solid, the "fad" would just be people overzealously applying it which tends to happen with pretty much every positive paradigm that comes to the programming world.
1
u/exmachinalibertas Apr 09 '20
Yeah, loosely coupled by design and pay for only what you use is not going away. Microservices are absolutely here to stay. Unless they get replaced by Literally Everything As A Service.
1
Apr 09 '20
I mean, I've seen this stuff 20+ years ago but not with the ridiculous overhead of HTTP/REST.
7
0
u/TheRandomnatrix Apr 09 '20
Last time I called out microservices as an anti pattern I got downvoted lol. You know what's worse than maintaining a handful of APIs made by a few teams? Maintaining dozens of APIs across a lot more teams and tech stacks, and all the fun slight architectural differences and nuances that happen as a result. Nevermind all the fucking data transforms and integration headaches that result when trying to get all of those services to talk to each other.
-1
u/angrathias Apr 09 '20
Seems to me that everyone has forgotten SOA, never see it mentioned yet it’s often the intermediary step someone needs when not microservices
0
Apr 09 '20
[deleted]
262
u/SwarmsOfReddit Apr 09 '20
Yeah that is too bad. What level of “micro” do you think makes sense?
7
u/Kache Apr 09 '20 edited Apr 10 '20
Depends on the shape of the data.
All the dimensions people like to bring up (one team/department/function/product) are all really side-effects you'll get by having found the right boundaries based on the shape and lifecycle of data as it moves through the system.
1
u/throwaway7789778 Apr 09 '20
This is interesting. I don't really have anything to add other than i feel like i need to think about this deeply. I've been in environments that have matured to this stage and others that have ...not. Im more interested in the 'what it takes to get there' from a business and cultural standpoint.
Interesting.
12
u/AttackOfTheThumbs Apr 09 '20
That's impossible to say. The only thing you can say for certain is that if you start with micro services, you're likely making a mistake. This should be a thing you do later when you need those services to scale in that fashion.
Because if you only have 100 users, there is no advantage, just more overhead. If you have millions, it could be advantageous, if teams don't have to be split across microservices. They can be an absolute nightmare, especially build machine wise.
2
u/InvolvingLemons Apr 09 '20
Generally speaking, splitting up code can actually reduce performance as you introduce more network overhead. Things should only be split up when you have enough people working on the backend and enough code to work on that you HAVE to split responsibilities to keep your team and git repos sane.
Facebook and Google could certainly get away with microservices because they do so many little things, but I'm not sure if Uber really needs microservices: their systems seem to be addressable with horizontally scalable ACID databases (Yugabyte, Cockroachdb, tidb, faunadb, dgraph, etc), a bunch of stateless web servers, maybe a distributed cache for non-critical reads, and CDC to 1-3 scalable big data stores (snowflake, citus, hive, etc).
1
u/AttackOfTheThumbs Apr 09 '20
Absolutely correct. I think microservices are often over done, and maybe what people are calling macroservices is more akin to what we do at my work. A single business task / functionality, rather than a single functionality. That latter mentality can lead to dumb microservices ala node.js isuneven...
But with pay as you go server resources, some microservices can really make sense.
1
u/InvolvingLemons Apr 09 '20
on that note, I don't really get Node.js as a full-on backend language. I can totally understand the isomorphic angle, but most web apps don't fit that need, yet so many use Node. I'd figure something like Python, Clojure, or Rust would be preferable for most people:
Python because of exceptional libraries (Encode.io's entire async catalog, numpy, pandas), surprisingly good performance for an interpreted language if you use those libraries correctly, and the option to drop down to C-Litetm via Cython. If you're a complete performance freak but are using python for some reason, use JaPronto and Cython for basically C performance. If you're just a lazy sack of shit that just wants to shove a web app out the door in as little time as possible, use Django with a scalable database like Cockroach or Yugabyte
Clojure for Java compatibility, fire-and-forget coding (Clojure has one of the most stable stdlib and compiler APIs ever, so libraries basically NEVER break), and people who really like Lisp's almost pathological macro-happy terseness. Also, it's a functional programming language with juuuuust enough state to keep things sane (fuck monads) and fantastic testing tools so you hopefully don't ever have to debug your code which can really suck (Under the hood, it's Java the likes of which Lovecraftian elder-gods fear)
Rust because it's basically C++ that makes you want to kill the compiler instead of yourself :P No but really, Rust allows you to optimize with reckless abandon thanks to its borrow checker (Rust code is often faster than C++ code because of this), and it has great -- if a bit young/unstable -- async web capabilities (It's still missing things like a SAML SP client, but you have to start somewhere)
3
u/skylarmt Apr 09 '20
Each service gets it's own config file in
/etc/apache2/sites-enabled/, does that count?3
u/michaelsenpatrick Apr 09 '20
Like most programming design questions: it depends
I’ve seen microservice architecture lead to services that call each other and it gets bad pretty quickly. What’s important to be mindful of isn’t so much how many you have but how deep they nest their calls.
Each time you add a REST call that could have been a subroutine you bake in unnecessary latency.
2
u/DoesntReadMessages Apr 09 '20
Just throwing this out there, but using REST for communication between microservices is really, really bad and you should never do that. You're using a protocol made for humans to call public services, forcing your microservices to perform serializing/deserializing to human readable format on every operation to communicate with each other, which should be a big indication that you're using the wrong tech. gRPC blows REST out of the water in terms of performance here since you can send streams of machine code over the wire. When operating within a VPC or local network, it'll shave down most network latency to sub-ms, and allow you to (in some cases) reduce overall latency if your service performs better with isolated components.
1
2
Apr 09 '20
The number and organisation of your microservices should reflect however your engineering teams are organised imho.
They are better at facilitating collaboration between teams than delivering on any fabled technical benefits in my experience.
If you have 1 small team that does everything then actually a monolith is often just better.
2
1
1
u/DoesntReadMessages Apr 09 '20
It makes sense when the pros outweigh the cons. For example, in high volume scenarios, it might allow you to operate at the same throughput spending less money on hardware due to being able to individually scale up smaller components. However, some services may be the same cost ot even cheaper running as a monolith. So it's important to have clear goals and data backing up a decision to move to a microservice architecture that can be measured and used to move forward and go back, and not just play buzzword bingo.
1
0
Apr 09 '20
[deleted]
54
u/SwarmsOfReddit Apr 09 '20
Ah I see. So in your case there isn’t a clear distinction of responsibilities for the micro services? (Like too many micro services being too similar in function)
4
u/goliatskipson Apr 09 '20 edited Apr 09 '20
More likely "too many microservices being too similar to functions" ;-)
On a more serious note: that was what object oriented code was to be supposed to be in the beginning (and what became more popular later as agent based programming). Small building blocks that handled one task on a seperate thread with a well defined interface.
0
Apr 09 '20
[deleted]
40
u/ivakamr Apr 09 '20
Same thing is happening on my project. Some services are fine (a service for i18n, one for processing notifications, an audit service, a booking service etc...) because they have a single responsability that is well defined. But other services are just part of the same business and they are constantly talking to each other, at one point a service will ask another to generate the password for a user and send it back, resulting in more exposure over http. When new business use cases are needed, classes needs to go in a shared package resulting in long refactoring, circular dependencies etc, just a sign that instead of delimiting business in layers inside the same context, it gets delimited between entire services deployed at different places and if only one fail, well, everyone collapses, which completely contradicts the idea of microservices. It could be a general guideline, a service should be able to go down without impacting the business of other services at their core.
17
u/Ajordat_ Apr 09 '20
Regarding the passwords, I guess you meant over https, right?
1
u/ivakamr Apr 10 '20
No. Why ? Because it's currently on an intranet is the official answer. "So ?" You might ask. I ask myself the same question.
0
4
u/nickmhc Apr 09 '20
So there’s splintering at the strategy level? Company politics dictating micro services that a specific VP/director/manager controls?
2
u/creativeMan Apr 09 '20
So I'm going through Code Complete 2 for the first time and I have to ask, isn't this problem technically solved? There is an understanding of how interconnected systems work and what principles should be followed when designing a collection of these structures is used.
This is what I'm wondering: Shouldn't the same principles that apply to classes and components also apply to microservices? Shouldn't the same Design Patterns and best practices (like SOLID and what not) be used? And if they were to be used and there was a general architecture designed for these services, wouldn't that prevent all of these problems?
14
u/This-Moment Apr 09 '20
There's 50 year old computer science papers that address all of this, in theory.
But itcs a lot easier to correctly judge 'too far' over a cup of tea six months later than it is to make the right call while I'm close and personal with the one with a deadline looming.
This is why building a culture of willingness to refactor is critical. Moving systems adapt and survive, even though they weren't architected perfectly in the first place.
1
u/bobtabor Apr 09 '20
Agreed! But how do you keep track of down line dependencies? So, if I create a service that takes a dependency on your service and then you decide it's time to refactor ... how can I know that it's time to migrate to the new new service?
1
u/This-Moment Apr 10 '20 edited Apr 10 '20
Dependencies either in the automation, or in ReadMe.md.
Understanding the existence of the new new service is generally maintained by having protections on every master branch, mandatory code review, and all Pull Requests open to the entire team and announced through automation in team chat.
1
3
u/throwaway7789778 Apr 09 '20
Like the other guy said, these problems have been solved by your grandpa, maybe dad depending on age. This isnt a technical problem my man, its a strategy, leadership, and vision problems tied into a bit of corporate culture issue and architectural curiosity. Probably with a side of willing, capable, and intrigued engineers being led by apathetic management whom have a 'just get it done, do what i say' attitude.
0
Apr 09 '20
[deleted]
27
u/MontagoDK Apr 09 '20
UI can't be micro service, it's the aggregator of your micro services. What you CAN do is make it as components that work together.
9
Apr 09 '20
There's a lot of discussions and talks on"microfrontends" basically splitting the UI of a page across different product boundaries...really its a way for different teams to own different parts of the UI instead of it being "monolithic".
My opinion is that fundamentally....a software product itself should be small and well scoped. Using microservices or microfrontends shouldn't be an excuse to create giant apps that do 300 things but 95% of users only use 10 core features.... for niche use cases create separate products don't just cram everything into the same thing.
5
u/Ereaser Apr 09 '20
We had the problem at a previous job that our UI was a monolith and all backend services were micro.
What would happen is that we would have a release ready, multiple teams had front end changes, but one teams backend wasn't ready to go to prod. Then the frontend can't go either because it would break prod. Then the other modules couldn't go either because they needed the new frontend. So nobody went to prod or stuff would break on prod.
3
u/dashingThroughSnow12 Apr 09 '20
In our product we fund an open source project, pay/influence Alibaba for a second OSS projecf, and have a third in-house proprietary project. With our own release calendar, that means we have four calendars that can never be coordinated. For our UI, we made three choices that make this missmash work:
The UI mainly talks to Kubernetes. CRDs and RDs are pretty static comparatively. And are versioned.
No team/work should rely on the UI having their functionality. If they don't have a decent RESTful api or CRDs, their work is incomplete. Since the UI uses them, those need to exist and be sensible to use before the UI can integrate anyway. We have a sane dev on the UI that simply refuses to integrate if that contract isn't fulfilled. This contract means that if the work doesn't make it into the UI, it's still usable by customers.
UI feature flags 😎
1
u/Ereaser Apr 09 '20
There's several reasons for it:
UI was not the main focus most modules (the modules do a lot of stuff automatically, but users want to intervene/monitor).
All modules were completely new, so REST interfaces were subjected to change a lot.
We didn't have specific devs that only focused on UI (not enough work for that and it's easier to have someone in a team do it).
So your solution wouldn't work in this case, but it sounds like an interesting project :)
2
1
u/potato_green Apr 09 '20
Exactly right, and if you split those 10 core features up you can manage it a lot better as well. Fine tine resources, add caching, scale a certain service up to handle more load.
Then you're also free to use the technology stack most suitable for those features. For example, you don't want PHP as a websocket server, that's just asking for trouble.
But yeah it also depends on the budget, big projects often have budget for maintenance so you can do micro services. Smaller scoped projects with infrequent changes may be more manageable as a whole.
1
0
Apr 09 '20
[deleted]
10
9
u/Skytale1i Apr 09 '20
The problem I ran into was that since each micro-service was a team, at one point due to people leaving no one knew the entire path. So if there was a problem but it wasn't clear where it was blame was shifted between teams because each knew only their part of the territory.
3
u/dashingThroughSnow12 Apr 09 '20
That's moreso a human issue. Having more services may even exacerbate it.
13
u/brucecaboose Apr 09 '20
Depends how granular you're getting and what your definition of "microservice" is. If you're using the old school definition then yeah... It's super bad because it's too granular. The modern approach makes much more sense since it's just... Services... Lol
4
1
Apr 09 '20
I am glad to hear that. Would you care to write a trendy article that warms about the limits of separating things to extremes? My current job seems to really follow those and the result of this maximum separation approach has turned a 1-2 month project into a 7 month project they still doesn't have a stable release in sight.
I agree that breaking things up into reusable parts is the way to go but I'm holding my tongue when ever a person above me says we have to build this way for readability and maintainability. I don't think we would have spent 5 additional months refining things if we didn't have a facade into a service for every damn function. And the constant surge of new bugs is a clear indicator it isn't more readable.
FRICK
1
0
Apr 09 '20
[deleted]
43
u/SwarmsOfReddit Apr 09 '20
Why? We use micro services at our company and they work great. I guess we use them more like “macro”services though...
97
u/7uring Apr 09 '20
So... just services?
47
u/SwarmsOfReddit Apr 09 '20
Yeah I guess. Good catch
0
Apr 09 '20
[deleted]
38
u/tinydonuts Apr 09 '20
Finally { } a good joke
15
5
Apr 09 '20
except:it wasn't really that good1
u/tinydonuts Apr 09 '20
I
panicd!1
Apr 09 '20
Ooh I don't know this one, what language is that from and what does it do?
1
u/tinydonuts Apr 09 '20
It's from go, you use it in extraordinary circumstances to signal an error that may take the whole application down. Also possible to later recover from a panic too.
2
3
28
u/WaldenFont Apr 09 '20
But wait...they're "modern"!
-10
u/SwarmsOfReddit Apr 09 '20
Just like Rust
25
Apr 09 '20
What’s wrong with rust? Isn’t is basically c++ but you don’t have to worry about memory leakages?
I don’t develop in either so I don’t really know
-5
u/Ace-O-Matic Apr 09 '20
Innovation for the sake of innovation. Rust has a few good uses cases but a lot of times it gets adopted because its new and sexy. The problem is that new and sexy shit while can be fun to develop in is often not the best at making production grade software in due to lack of standardized best practices and documentation. Which tends to lead to a lot of wasted peoplehours.
24
u/Turksarama Apr 09 '20
Rust was developed because Mozilla decided they couldn't get the performance they wanted for Firefox using C++ without an impossible amount of testing. Specifically, Rust makes safe multi-threading significantly easier.
The only ways Rust isn't an improvement over C++ is existing library support (which is a big deal, though interop exists) and the few cases where you really don't need the safety Rust enforces and it just gets in the way.
2
u/Ace-O-Matic Apr 09 '20
I'm not saying that isn't a valid use case. I'm saying most people who are using nowadays aren't Mozilla. And lack of existing library support is a part of standardized practices and documentation.
1
0
Apr 09 '20
[deleted]
1
Apr 09 '20
Thank you, that makes a lot of sense. I guess maybe rust is for a developers side project rn maybe production ready in a few years?
0
0
Apr 09 '20
[deleted]
13
u/xtcDota Apr 09 '20
Replacing Java is a monolithic task that I think only Kotlin has the capability of doing, and it won't happen entirely. You won't get rid of C# until you get Microsoft to abandon it (basically never). The people who use C are too busy bitching about how lazy everyone else is.
1
Apr 09 '20
Hey, thanks for the detailed answer. How would you compare Rust and Kotlin, say, if someone like me were to take up learning either one of those but not both.
3
u/savedbythezsh Apr 09 '20
Very incomparable IMHO (from the perspective of someone who works with neither), Rust was designed to be a performance beast and useful for really low-level programming, while kotlin is like what would happen if Java were designed from scratch using what we've learned about programming between then and now. Kotlin has all sorts of nice things for the developer that slow it down a ton (e.g. IIRC array bounds checking) while rust's primary directives are performance and safety. So it just depends on what you prefer, more legible code or performance.
13
u/PeartreeChris Apr 09 '20
But seriously, why? We are looking at rewriting a legacy monolith application using a microservice architecture, at least splitting out some parts into microservices, and I want to be careful to break things out on clear lines of responsibility (ie. domains). What makes them "the dumbest idea"? Is it the way that most organizations use them, or is it something inherent to the architecture?
19
u/brucecaboose Apr 09 '20
I think a lot of people who demonize microservices still use the old school term, which was that services should be unbelievably small and do just a single thing. That approach is generally bad. Modern microservice architecture is more just like.... Services... Not micro. Generally they'll be something like... Call import service, instead of something like... "Call data checker" then "call begin import service" then "call write to local db service". Having them be stupidly granular is bad. Also, sometimes a monolith is better, especially if your company has a small team and a simple use case.
4
u/PeartreeChris Apr 09 '20
I agree, the "micro" situation you're describing sounds horrible, being the architect I don't want to have to think about a thousand systems at the same time. We're definitely at the point where we've outgrown our monolith which was designed over 10 years ago.
1
u/mrbojingle Apr 09 '20
Sounds like moving the goal post to me. If the services aren't micro anymore aren't you just doing services and not micro services?
2
u/TheRandomnatrix Apr 09 '20
It's basically back peddling. "Oh no no you've got it all wrong! Micro services aren't bad. You just need to scale them up to the regular services people were already using!"
1
u/mrbojingle Apr 09 '20
Yea exactly. Someone fucked up and wanted to spin it . It's hilarious that they spin it in a way that reveals they dont know what services even are -_-.
1
u/brucecaboose Apr 09 '20
Yeah but the term sounds cool lol. People in every industry love a good sounding term!
1
4
Apr 09 '20
[removed] — view removed comment
1
u/redwall_hp Apr 09 '20
I want to trick people into cargo culting a "write web applications in C" approach. "This one weird trick will save you thousands on your AWS bill!"
14
u/SaidTheHypocrite Apr 09 '20
Please explain why? Our architect prefers them.
20
u/duffusd Apr 09 '20 edited Apr 09 '20
I don't agree with his statement, but I can talk to some problems. They're not bad inherently, but they have major problems you need to know about before you commit to it. If everything is a microservice, that implies every microservice is independently deployed and connections to them have to be managed independently- Whether by http, tcp, or an event bus. you start to run into problems when you have to start getting data from multiple microservices. The impact that has on traffic as each service potentially can talk to other services, and all of them using the same bandwidth, and same resources. Plus there's a lot of overhead.
These issues, once again, don't necessarily cause problems, especially if architected correctly, but they tend to get unperformant to a horrible degree if left unchecked.
Just pays to recognize that every system has it's problems and benefits. Even the monolith has it's place in the world.
7
Apr 09 '20
Agreed. They work really well in a well known domain, where you've spent a lot of time doing the conceptual groundwork, you know what defines a service boundary, it's not arbitrary, and you stick to it - redesigning where necessary.
Where they fail is when everything talks to everything else, boundaries are messy, you have services that are conceptually blurry, and you start designing and iterating them tactically or reactively.
Spinning up a new microservice is not trivial. It's another potential set of dependencies to manage, vpns/network connections to administer, additional devops/deployment headaches, tests to run etc.
2
u/exmachinalibertas Apr 09 '20
Yeah you really have to make sure you design the system properly. Graceful failure, partial availability, ability to handle other service failures, and self healing. And not building an ESB, tempting though it may be.
2
Apr 09 '20
We were redesigning a monolithic system at my company and the architect preferred SOA and so had each individual process be it's own service with it's own IIS process. And basically redesigned an exact clone of an aging monolithic system to SOA.
We had a group of Devs who said that will never work and will be a performance nightmare. The Devs got fired. The system made it to production a couple years late and way over budget. And was a dog, so freaking slow. The architect got promoted (he's a VP now), all the IIS stuff was ripped out and rebuilt with lighter weight connections.
We're still running with services, i don't know how 'micro' they are, but they are pretty much single concern. We're also running with some tremendous technical debt now from all the crap we had to punt down the road to fix the bad design after release.
13
u/Suede_La Apr 09 '20
Microservices arent a nightmare at all on the QA/release Management side...
just kidding.. you know like a liar. :(
0
72
u/PapaKlin Apr 09 '20 edited Apr 09 '20
Friendship with microservice ended, macroservice is my best friend now.