Distributed isn't Microservices, In-Process isn't a Monolith

[@ninocavalo]

Finally some reasonable and thoughtful perspective about the topic.

[@viktorshinkevich3169]

This is the best overview of trending article, great job Derek! I was confused people not seeing this as distributed VS in process and logical VS physical boundary and rather talking about microservices and monoliths. The moment I read the article I got a memory of past years when people were trying to shrink their monoliths and ended up with distributed monoliths instead of microservices and suffered from it. And you did not disappoint, highlighting the same “problem” Amazon solved here by changing the physical boundaries. You even noticed, just like myself when reading, that Amazon reused many of their components and refactoring thus went quite smoothly for them. Ofc it did, because responsibilities did not change, it’s still the same service (micro service, whatever). Thank you for you job!

[@StrandedKnight84]

Yes! I was waiting for someone to point this out. Serverless can be much cheaper or much more expensive than reserved instances, depending on the use case. Like you say, context is king.

[@ianokay]

Wasn't the refactor akin to decomposing the product from one logical boundary with multiple independently scalable (different physical) micro-services, to one logical boundary with tightly coupled (physically) services on one machine (which could be considering composing them into a less independently scalable... monolith)? Bringing multiple physically independent services together into one major, coupled, structure? I think that's a fitting description of monolith

[@pradeepsahoo7243]

Depends on where you draw the line for a service. Generally, if you would consider a solution to a business usecase as a service and the refactoring they did to come up with a service that's faster, more scalable, less expensive is the right solution. Monolith is multiple services tightly coupled together and usually sharing the same stateful data store.

[@vlakarados]

As usual, it's a great hype-blowing video. One comment though - 5:30 - the service is everything, but the Customer, Audio/video stream and SNS notification, with the latter 2 being the contract.

[@TransparentWorld1275]

Great video! It clarified some of the questions and confusions in my head that I got from reading the blog post vs reading LinkedIn influencers' takes on it.

[@joshualetcher4743]

Thank you!!!! I've been seeing all these posts and videos and rolling my eyes, these creators either are using clickbait to get views or just don't know what they're talking about.

[@neal321]

Yes, 100% agree! This has nothing to do with microservice vs monolith. This is just one service in the prime video system to monitor video streams, people are too worried about definitions of terms rather than the actual use case

[@roeiohayon4501]

I had the same thought after reading the article. Many people mistakenly believed that Amazon consolidated all their microservices into one massive monolith, based solely on clickbait videos and the article's title. Nevertheless, I found the article informative and would have appreciated additional numerical stats and a detailed explanation of how they calculated the cost-effectiveness of their new architecture.

[@CodeOpinion]

Agree. I enjoy when teams post articles like this to give some insights as to things they discovered along the way.

[@allinvanguard]

Great opinion! This emphasises the point that cutting domains does not require you to include infrastructure into the decision. You can have a pluggable modular structure in a monolith and just lift and shift it to a microservice based infrastructure when the domains are sliced properly, as well as vice versa.

[@CodeOpinion]

Yes, but the difficult part generally is how you communicate and/or compose data between boundaries.

[@MrDomenic123]

Great video, Derek! I hope this will be seen by many to avoid any further confusion and misunderstanding.

[@drewkillion2812]

Fireship definitely wrote that video tongue and cheek. The other articles are likely clickbait

[@mackie1001]

I encounter this confusion quite a lot. People think in the physical and get confused where a given autonomous service is made up of multiple distributed processes (be they containers or server less function or whatever). Much better to think in terms of boundaries and responsibilities like you say 👍🏻

[@80-two]

Finally, someone realised the "really" hidden cost of scalable cloud services.. All the cloud services made sense as individual products, but when you combine them all and use them as intended, be prepared to get your wallet out

[@marna_li]

Yes. A big disservice to themselves for not knowing what a microservice is. From the perspective of AWS as a system, this "monolith" is still considered a microservice. Just because you re-organize code that was previously spread out to multiple processes into one unit doesn't make it less of a microservice (by any definition) from an architectural perspective. They can still individually deploy and scale just that service without hurting the rest of AWS. What this really shows is that serverless functions have their drawbacks. I know from experience.

[@TransparentWorld1275]

One of the few videos that didn't claim that "Amazon moved their infrastructure to monolithic architecture" and specified that it's a piece of the video streaming system

[@ghoul4375]

Thanks for the insight! If you feel like it would be a good fit for a new video, I would find a review of Microsoft Orleans and where it fits in the micro services and/or monolith space very valuable. It seems like an under appreciated framework that should be leveraged for often. Thanks again for all of the informative content!

[@CodeOpinion]

I have talked about Orleans before (kzbin.info/www/bejne/n3ablJypi8yioJo), however I'll revisit the (virtual) actor space again soon.

[@maddalab]

First the good stuff in the video Very quickly, accurate and succinctly describes the before and after solution. Call out the key point in the new architecture (a) there is no orchestration involved with S3 that involves lambda function A good explanation of how to think about a service - logical separation rather than physical (memory) boundaries. Then the bad - A lot of semantic gymnastics in this video. Couple of examples Says - In this particular context the cost of the lambda architecture didn't make sense. With the new architecture we are all in memory because we are the same task - without citing an example where lambda functions with orchestration (required for any non trivial "service") would work. The catch - they don't work - if only for cost reasons. But also for the over head introduced in orchestration, monitoring, error handing and all the essential orthogonal requirements for any "service" Says - A service is the authority of a set of business capabilities - any one is free to draw a line on what a business capability is - it is logical after all as the video states, using reductio ad absurdum a service can provide the entire businesses capabilities and would be a monolith, no wait that is a service. Now on the AWS post itself - no one in their right mind would think a lambda architecture for detection and aggregation is the right solution to experiment with on application design, it is way more easier to start with the solution they ended up with, and then move to the first if it provide to be the right solution. The final architecture is how we've built services and monoliths for over 2 decades - the only lesson one has to take away to scale is - be stateless. You can do that with PHP's process per request model or lambda or with some discipline in whatever tools you choose. Lets end with with some lighthearted fun at AWS - Principal Architect at AWS (soon to be distinguished engineer) - We rewrote all AWS services in PHP

[@kardeskalap2165]

Finally some reasonable perspective, well done!

[@ZadakLeader]

The lightning has definitely been much better in the past 2 videos :) But i don't know why the clarity is still a bit low, might just be the limitation of the camera. Anyway, good content!

[@CodeOpinion]

Still working on it!

[@frattaro8556]

The biggest cost issue for this service would (should) be bandwidth anyway.

[@Mikenight120]

Finally a rational point of view, a real champ

[@soycabanillas]

Have you seen the code report video from fireship until the end? I think that the conclusion is on point.

[@CodeOpinion]

A thumbnail that says Serverless sucks? It still missed the point as this has nothing to do with microservices or monoliths.

[@TristanOnGoogle]

Is "In-Process" the right expression to oppose to "distributed" though ? Because there are multiple parallel processes in a non distributed system. What about "[physically] grouped services" to oppose to "[physically] distributed services" ?

[@CodeOpinion]

An individual request is processed together fully in-process. It's not distributed workflow as it was previous with lambda/step functions. Them scaling horizontally with ECS doesn't change that.

[@TristanOnGoogle]

@@CodeOpinion What I mean is it's not "in-one-process" as "in-process" suggests (see "parallel execution" in your slide which implies multiple parallel processes) I watch all your videos, and in general, in the case of a modular monolith a request will be processed in a primary domain (in one process), then an event can be emitted to a message broker, and then multiple consumers may continue the request processing, and it's not a physically distributed system, but it's not really "in-process", I was looking for a better general word to described "regrouped" services :)

[@jwbonnett]

They don't need a detector as the client knows the bitrate, you can detect in the client and report back, no extra processing in the cloud. It's just bad design. Prime shouldn't have called the article what they did, creating confusion of microservices vs monolith. Serverless is not microservices either. It's about using the right tool for the job.

[@gravisan]

I think the important thing to call out here is, most distributed architectures are dog shit and people tend to design systems without much thought into what the actual problem being solved is. The point here isn't whether server less is good or not, it's asking the people that use this stuff in their system - do you know wtf you are doing?

[@br3nto]

You said it well. There’s a difference between logical and physical boundaries, and than difference matters. Also the difference between micro service vs monolith isn’t binary, nor is it single dimensional. There are the number of logical vs physical boundaries, and then how the logical boundaries are distributed between the physical boundaries.

[@AntonioRonde]

GOAT of Software Architecture

[@transientwaveform1475]

All the commentary around this blog post was making me go insane. This is the first take that I feel is sane

[@CodeOpinion]

I felt the same way, which is why I had to post a video. I was losing my mind reading/watching some of the commentary on twitter/youtube/etc

[@iham1313]

had the same topic yesterday - if you use something wrong, it‘s not the fault of the thing; it is yours. maybe amazon wants to earn more by renting vm instances instead of lambdas …

[@CodeOpinion]

Context changes. Using a tool correctly in a given context, but then the context changes. Which is what happened to them via volume/scale. So they adapted. That doesn't make the tool wrong or using the tool wrong.

[@ianokay]

Aren't microservices just defined by having combined physical and logical boundaries? And that's what everyone is suggesting is problematic? That "moving to monolith", is the suggestion it may be wise to stop always doing that, and instead to move multiple logical boundaries into one physical boundary. That's the whole point everyone is making now, right?

[@CodeOpinion]

Microservices have implied physical boundaries, which is fine. However, it doesn't need to be an exact 1:1 with a logical boundary. Check out this video, which should help: kzbin.info/www/bejne/eHfGqZqZpLRohNU

[@ianokay]

@@CodeOpinion I've watched that but I'll rewatch since it's dense... but if a "microservice" is not 1:1, and is an EC2 with 2 disparate services (logical boundaries) coupled to its physical scalability, is it really a microservice?

[@konnaf24]

Exactly! We've had disparate services for a long time, such as modular router software in my field, but we never referred to them as microservices because they were restricted within the limits of a single server without communicating over the network. They could have been referred to as a monolith or a modular monolith, but never as microservices.

[@ianokay]

@@CodeOpinion I'm more-so not clear about your response here in this comment; can you clarify further about what I got wrong in my initial line of reason and set of questions in response to this video?

[@frozencanuck3521]

Hi Derek -- Any chance you'll have a Mastodon account? Would love to follow you there

[@CodeOpinion]

Maybe? I haven't thought about it too much

[@m1dway]

Things to note here... API != Service and another thing CONTEXT IS KING!!!!

[@krccmsitp2884]

Absolutely! All of it.

[@frattaro8556]

This is correct.

[@Xmasparol]

Looks like you've roasted Fireship LOL

[@CodeOpinion]

Some peoples takes were way different than mine, some were close but much prefer the clickbait clearly.

[@oursbrun4243]

I mean; I have watched some of those "reviews". Their analysis are correct (same as yours). Those titles were just clickbait...

[@CodeOpinion]

Unfortunately.

[@ifyugwumba8120]

Its trending 😂 How aws abandoned I think aws would have made more explanation. Thank you

[@ray89520]

Totally agree - I didn't get the whole buzz when the article came out. They changed the implementation, so what? A great software architect finds the best matching architecture based on the various requirements. These can be functional, but also all non-functional/quality attributes related (think ISO 25010 as one possible approach) and also in-placed constraints (like certain technology choices or cost budgets) and based on these find the best suited design and architecture for the moment and foreseeable future. That can be described in multiple aspects - logical and physical is the obvious one, but you can also think about process and development view (think about 4+1 architecture view model).

[@bernaridho]

This and explanations in many other videos/websites are NOT scientific. No precise well defined and verifiable terms.

[@beachbum868]

umm ...... monoliths are a service

[@escapepeterpan]

🎉

[@eNtrozx]

Microservices are all about not using the same process for different business needs what are you talking about man

[@CodeOpinion]

In the decomposition of a larger system.

[@JimmyStewpot]

You are using too much logic. It may cause the internet to break...