Prime Video Swaps Microservices for Monolith: 90% Cost Reduction

Рет қаралды 157,060

Күн бұрын

Prime video engineering team has posted a blog detailing how they moved their live stream monitoring service from microservices to a monolith reducing their cost by 90%, let us discuss this
0:00 Intro
2:00 Overview
10:35 Distributed System Overhead
21:30 From Microservices to Monolith
29:00 Scaling the Monolith
32:30 Takeaways
www.primevideotech.com/video-...
Fundamentals of Backend Engineering Design patterns udemy course (link redirects to udemy with coupon)
backend.husseinnasser.com
Fundamentals of Networking for Effective Backends udemy course (link redirects to udemy with coupon)
network.husseinnasser.com
Fundamentals of Database Engineering udemy course (link redirects to udemy with coupon)
database.husseinnasser.com
Follow me on Medium
/ membership
Introduction to NGINX (link redirects to udemy with coupon)
nginx.husseinnasser.com
Python on the Backend (link redirects to udemy with coupon)
python.husseinnasser.com
Become a Member on KZfaq
/ @hnasr
Buy me a coffee if you liked this
www.buymeacoffee.com/hnasr
Arabic Software Engineering Channel
/ @husseinnasser
🔥 Members Only Content
• Members-only videos
🏭 Backend Engineering Videos in Order
backend.husseinnasser.com
💾 Database Engineering Videos
• Database Engineering
🎙️Listen to the Backend Engineering Podcast
husseinnasser.com/podcast
Gears and tools used on the Channel (affiliates)
🖼️ Slides and Thumbnail Design
Canva
partner.canva.com/c/2766475/6...
Stay Awesome,
Hussein

Пікірлер: 182

@mahdikarimi6467 Жыл бұрын

Timeless concept in software engineering: there's always a tradeoff. there's no silver bullet.

@aymanpatel5862 Жыл бұрын

Fred Brooks came up with this term in the 60s and it holds true to this day

@bytesizedfeed Жыл бұрын

A beautiful concept that serves to maintain the artistry in software development

@heroe1486 Жыл бұрын

@UC0FVA9DdusgF7y2gwveSsng This, and it's not really different from life, most things have tradeoffs, some almost don't and some barely have any advantages

@barebears289 Жыл бұрын

Shut Up

@walidklai2417 Жыл бұрын

this applies to any scientific field, there is always a tradeoff in almost anything, nice one.

@joshuaifara2736 Жыл бұрын

They refer to AWS as another product because Prime video and AWS are actually two different companies, although they are bought owned by Amazon. I believe Prime video still pays AWS for using its cloud services, which makes Prime Video an AWS user as was stated in some parts of the text

@pieter5466 Жыл бұрын

Exactly this, and add the fact that long ago Bezos told all of AWS they were to become a platform, and could only communicate/use each other through APIs and be each other's "customer".

@Dust2n Жыл бұрын

Each product and service team is billed for their aws usage, and a good chunk of amazon teams use aws the same as any other customer.

@Sanglierification Жыл бұрын

why do they make Prime pay for AWS?

@joshuaifara2736 Жыл бұрын

@@Sanglierification Cos they are two different companies, has to do with their business model I think....so Prime video is just like any other AWS customer

@Sanglierification Жыл бұрын

@@joshuaifara2736 but they are both Amazon companies no? They wouldn't pay any VAT, i don't understand

@sevurueva5138 Жыл бұрын

This wasnt a microservice vs monolith issue at all. Read the Amazon article. The issue was more with choosing a serverless functions approach in a computationally heavy image processing task. Not much to do with it being a microservice. Their two main issue was: 1. Having to pass large image files between functions. Higher S3 cost 2. Hitting serverless platform limits due to frequent statechanges. Most of this issue could have gone away with properly partitioning the service and deploying in a platform that could handle intensive loads. Both their issues made it clear it was a mistake for going with a serverless approach for a production workload. Might have been fine for a testing or smaller need.

@NathanHedglin Жыл бұрын

THIS. Everyone is misrepresenting the issue. More like they had stupidly made one microservice into many.

@bumbleblo Жыл бұрын

For sure, another thing that bothers me is the fact that they analyze images files. I know that codecs are hard to handle, but if I'm a billion dollar company for sure I'll take my time to handle this using codec information instead of rgb images.

@neal321 Жыл бұрын

I think a more accurate description would be they moved from serverless distributed asynchronous nanoservices to monitor streaming data, to a synchronous microservice which is obviously more performant for real time video and data analytics. This doesn't really have anything to do with a "monolith", just seems like they broke up the service too fine grained and saw the problems of that. This video streaming quality monitoring service is just one service in the bigger prime video system. ECS tasks are designed for microservices, same idea as a pod in Kubernetes, can be scaled up based on rules. Seems like a lot of people are caught up in the definitions of terms rather than choosing the right technologies and patterns to solve a particular problem.

@astronemir Жыл бұрын

I think you hit the nail on the head Neal. The smaller scale corollary is splitting up your code into async functions that live in separate packages, deploying each one with some sort of auto-scaling containarization env, then having each one constantly trigger the other ones and eat load balacing, sping up, and other associated costs, while calling each function a microservice.

@rjarora Жыл бұрын

Exactly. So much ado about almost nothing

@minominomino6024 Жыл бұрын

I keep repeating this everywhere; you're absolutely right. Chances are it's still a microservices. Just not minaly built on top of Sereverless

@nithishkarthik1454 Жыл бұрын

Exactly !!!

@nin3se Жыл бұрын

using S3 bucket as an intermediate step sounds like something suitable for a prototype. But if I'd want to move the project to production, I'd consider using a message broker like Kafka instead of s3. What do you think?

@franciscokloganb Жыл бұрын

Having worked with both there are definitely pros and cons. However, doing microservices correctly is very very difficult and most people tend to prefer microservice and serverless because it’s cool and fresh. At the end of the day monoliths should be a great default until there are proofs that your business requires something else.

@patrikplecho3717 Жыл бұрын

the payment part. Amazon is internally a customer of aws and each department in amazon is billed by aws separetely. Thats why they write about user paying

@vikaspathak2411 Жыл бұрын

Wondefully explained. Really liked how you broke down the blog piece by piece and how you were attentive towards the small missing details.

@amr3162 Жыл бұрын

17:15 AWS Step function is actually different from the AWS lambda. it's like a workflow orchestration tool / state machine. I only know this because I was also initially confused by step function and thought it was the same as a normal lambda

@SushritPasupuleti Жыл бұрын

Serverless was always solid performance and cost wise when you had not so constant loads. A video streaming platform will almost always see traffic, and almost every out going stream is significant (not short lived connection/load) so it made sense for them to switch. Excited to check out the video now, because when I read the blog post last month, it left out a lot of details. Thanks for the great content as always :D

@noobgam6331 Жыл бұрын

It is literally not the case. Video streaming platform will never have consistent traffic, it will vary very hard hour by hour. Serverless grants you significant advantages in up/downscaling that, albeit arguably not really necessary ones considering the cost

@kyawzazaw18 Жыл бұрын

Won't video streaming be greatly impacted by the content (content release schedule specifically)? Example, the Lord of The Rings series being released would definitely bring a different load.

@bumbleblo Жыл бұрын

That is the most strange thing to me. I think that is fairly obviously that serverless have more cost when handling loads 100% of the time, have more price per minute than EC2 but with the advantage that you pay just what you use. I believe that for sure we have a cost advantage between monolith and microservices architecture but 90% of cost reduction don't seems to be the number. Another thing is: they keep using a microservice architecture (maybe you can convince me that is a SOA), just have change the boundaries that they system have. Big title but the technical aspect it's a mess

@dmitrikonnov922 Жыл бұрын

@@noobgam6331 Would you explain, please, why streaming platform never has consistent traffic? My naive opinion would be, there're multiple time zones as well as multiple shifts people work in, hence, we could expect a certain pattern of traffic.

@LimitedWard Жыл бұрын

Maybe I'm getting lost in the terminology, but IMO "serverless" != "microservices". This is still a microservice in the sense that it completes a singular task within a larger ecosystem of services. I'm not sure where the rule came in that microservices needed to be serverless by definition.

@RaZziaN1 Жыл бұрын

You are right, it's youtube gurus who never written microservices/monolith, they just treat microservices and serverless as a bible because its trendy.

@boot-strapper Жыл бұрын

this might blow your mind, but serverless uses a server

@mannycalavera121 Жыл бұрын

@@boot-strapper so how does it differ from micro?

@boot-strapper Жыл бұрын

@@mannycalavera121 more network latency and less testable

@sevurueva5138 Жыл бұрын

@@mannycalavera121 those terms describe different things. Serverless means you as a developer dont need to worry about setting up the environment. Most also autoscale and shutdown if there is no pending requests. Microservice describe how a large application is split into smaller, managable pieces that are much easier to develop and maintain. It also has added benefits of fine tuning the number of active instances based on their load. Commonly microservices are deployed on serverless platforms given both their benefits align with lightweight usecases. But this isnt always the case. Microservices can be deployed on variety of production environments mostly as containerized deployments. They can be programmed to run nonstop on a platform you set up and maintain. Likewise a large monolith "can" be run on serverless. Theres wont be much benefit given slow start-up times and increased costs brsed on how the platform charges.

@michaelmihov1651 Жыл бұрын

Thanks for enlightening us on this topic. You made a lot of educated guesses and I think your interpretation is very logical despite the fact that so much data is missing.

@LuisPaolini Жыл бұрын

I think that there are 2 things here that were not mentioned: 1) they seem to have realized that they didn't need to make this async (in the microservice approach they were using S3 + step functions as a queue 2) they seem to have realized that everything could fit into RAM, and they didn't need S3

@rakeshsarangi5161 Жыл бұрын

Yes, good insights

@MartinezVM Жыл бұрын

I don't understand why people call this a monolith. Thing is still decoupled to containers that are also fault tolerant, but just because the s#i7 is running in a solely EC2 instance per AZ or region (which is not specified but is has to) they dare to call it "monolith". Sometimes I believe this kind of articles are just marketing drived.

@AshutoshKumar-ue3dr Жыл бұрын

Was waiting eagerly for this!

@RajYadav-fy4lm Жыл бұрын

I love you nasser❤ I was just going to search on youtube and saw your video uploaded before.

@pemessh Жыл бұрын

"There is a lot of missing information" - Every AWS doc ever and Hussein.

@Vivek_____ Жыл бұрын

IMO, the monolith system should follow a Producer/consumer model with in-memory message queue (for now) in between. Media converter can be the producer, and starts converting and pushing work in the queue, and Detectors could be the consumer threads pulling from the queue. Not sure why there is a need for an orchestrator. In future, the in memory message queue could be replaced by some thing like a Redis based message queue to scale media converters and predictors separately.

@ianokay Жыл бұрын

I agree that the diagrams do seem like something a random developer at a small company would develop to fulfill the ask of a "architecture diagram" with the product, and are rather rough around the edges/quickly made.

@mannycalavera121 Жыл бұрын

Cant you have a hybrid system that runs as a monolith under normal loads and spins up instances as required? If you keep the code modular i dont really understand the problem? Dunning Krueger effect i guess

@boot-strapper Жыл бұрын

its almost like putting a network call between every function call is a bad idea. SHOCKER.

@kwinzman Жыл бұрын

If this wasn't on some fancy Amazon blogpost nobody would bat an eye. I feel like I just watched a video of captain obvious stuff.

@rjarora Жыл бұрын

@@kwinzman yup, actually this new approach would be the default approach for most of the companies, lol

@deangelo732 Жыл бұрын

From limited info, keeping related things together is better option to minimize communication overhead. Not sure if vertical scaling would ever be an issue , since the media conversion and detectors run in the same box. If there are x detectors running on the box, would there be a need for 2^^x detectors in future, such that media conversion and all the detectors cant fit on the box?

@allinvanguard Жыл бұрын

I really wonder whether this whole system initially started as a monolith and is now coming back, or whether it was built in a microservices architecture from the ground up.

@joshuaifara2736 Жыл бұрын

I believe the SNS notification is for the client application, so it knows that monitoring is actually going on and it's not just sending data into a dead service

@jayantchhillar4227 Жыл бұрын

I would suggest do read the article. Really well explained.

@vitorhugodecastrosil Жыл бұрын

The usage of s3 are so odd in the first service. The article is not well written, is so confused. Your explanation as always, very good.

@skwtf Жыл бұрын

Thank you for the video! I'm working on a personal project, I hope to turn into a business. I'm starting with a monolith, because I believe it's the right choice. In the last 10 years I've exclusively worked on microservices or breaking a monolith into a microservices. I've never seen a well engineered monolith. It's very hard to find such content, in order to learn about best practices, as well. It'll be great if you can make a video/Udemy course on building a proper monolith in modern times. Best architecture practices, best way to deploy and monitor it, etc. I know how to do that for microservices, but not for a monolith... The irony...

@stevenhe3462 Жыл бұрын

Elixir?

@skwtf Жыл бұрын

@@stevenhe3462 I can check Elixir out, but I'd expect a technology agnostic approach of a proper monolith architecture along with a good way of deploying, scaling, monitoring it.

@stevenhe3462 Жыл бұрын

@@skwtf I recommend the book "Functional Web Development with Elixir, OTP, and Phoenix." In a nut shell, separate the logic and communication, put them into separate light processes, and send messages around. Of course, there are other ways, but this is a way that is easy to manage and scales "infinitely."

@jofla Жыл бұрын

I don't know if would call that a monolith

@vignansphone6693 Жыл бұрын

My 2 cents. AWS step functions is their orchestration tool (lambda is serverless product) . We use orchestration when we need a central party controlling the order to execute a flow like A-B-C-D( called as workflow in orchestration) where A,B,C,D are different network components (called as tasks/activities in orchestration). Every transfer from A to B and B to C is a state transitions and orchestration systems like step functions and temporal charge the customer(prime video team here) by state transitions - usually for any business flow they will quickly go up.

@AlexKorotkov Жыл бұрын

to add another type of detector they will add it to monolith and spin another instance of that monolith with preconfigured access to only proper decoders. insteresting, why they didn't start with "monolith first"?

@ianokay Жыл бұрын

To your point about the 2nd diagram, in the original diagram they showed the S3 content being consumed by the frame checking service. They don't have a solid black line pointing at the frame checking (step) functions, but it can be intuited that any time a new frame hits the bucket an S3 event triggers a step function consuming it (the dotted line pointing at S3). I don't think however that the media conversion service triggered by the lambda answers to that lambda at all, as you seem to allude to with your mouse gestures when you say "I called it".

@daydreamed Жыл бұрын

If we think of prime as a different company and a customer of AWS, then the AWS SNS customer's notification and the state transitions charge makes sense

@aayush5474 Жыл бұрын

Aws step function charges the cloud customer for state transitions in AWS stepnfunctions not the client who is using the app

@debashisdeb472 Жыл бұрын

+1. this blog was very high level. When I read it, I was not understanding a lot of user flows, which I think is missing in the doc. The diagrams could have been better. Came to this video after reading the blog :)

@omardiaa1180 Жыл бұрын

When you say that the asynchonous operation runs in the background and calls a callback function when it finishes so that the main event loop can execute it, isn't that "background" a different thread which makes javascript not a single-threaded?! 🤔

@iloveworkflowprocessautomation Жыл бұрын

where is the monolith? I dont see it. "single" process != monolith. there is even an orchestrator included (for whatever its good to use)

@tuapuikia Жыл бұрын

Microservices means code that performs a single function and you have lots of it in services. A monolith could be an application that handles all kinds of requests and usually deals with consistency very well because it doesn't have to wait for other services in the network. Maybe Amazon Prime realized they don't need to break down all the functions and a single container can handle all the client's requests. My company pay $0 every month for ecs + ec2 as we have the cost saving plan on the ec2 instant type.

@chris-pee Жыл бұрын

Small correction, around 29th minute, what you call load-balancing actually isn't. Both ECS services are called every time, because all detectors need to run. They're just in different clusters to distribute the resource usage.

@mohamedabdelmaksod660 Жыл бұрын

Hussein i believe the customer they pointed to in their article is not the content viewer but it is the customer who streams live events like sports games and can benefit from the monitoring tool provided by prime video to enhance their streaming process that changes a lot IMO with respect to reading the article from this point of view.

@mishikookropiridze Жыл бұрын

This would make a lot sense

@rjarora Жыл бұрын

Yup. Also amazon can't afford to monitor live stream for millions of end users

@mishikookropiridze Жыл бұрын

@@rjarora They don't have to monitor all but random users. But language in article still remains very ambiguous.

@viswesuwaranathan Жыл бұрын

The prime video symbol shows like arrow of moving from Microservice to Monolithic. Companies need to analyze the design and costing before deciding which one to go. Prime video coming with blog on this is really superve! and I understand it has business impact to AWS.

@neel6 Жыл бұрын

I think user refers to the Amazon AWS user? In some parts this makes more sense

@obibullett 5 ай бұрын

I highly doubt they are reuploading the enitre stream and analyze it on the server side, costs associated with that would be astronomical

@deadcat6085 Жыл бұрын

for how huge amazon in, i don't expect the separate divisions to consider they all belong together. to prime video, aws is just another cloud provider.

@studiousguy8138 Жыл бұрын

*From the Amazon perspective, here are the missing links if anyone cares:* 1) AWS is a different company which has the rest of Amazon as a customer. Hence, they use the term "AWS user" in some places in the beginning. Prime Video is an AWS user and pays AWS for it, even though both have the same parent company. 2) AWS Step Function is a serverless workflow orchestration service. What's shown here are different lambdas which are probably the states of one Step Function workflow. State transition is the flow of control from one state to another. AWS doesn't charge users for writing a workflow with states, only charges them when actual state transitions happen in the workflow. "State transition" discussed at 16:45. 3) Entry point lambda sends start conversion request to media conversion service (discussed at 14:15) but doesn't get a response because it is not important. AWS Step Functions manage workflows behind the scenes and workflow requests/responses are not important in all transitions. 4) They show conversion service storing data to s3 (in the same diagram) and lambda doesn't call lambda directly probably because (I think) it is a known "serverless anti-pattern" if you call a lambda from another lambda. Google it. Discussed at 20:08. Also you can't call a lambda function with a media file as input, you have to upload to S3 and pass the bucket key (s3 url) to the lambda function.

@reginaldo8597 Жыл бұрын

I believe the users and costumer topic is just to mention the aws account serving the infrastructure, user is the aws user account and customer is just an sns topic exclusive to receive the user data.

@vicpdx Жыл бұрын

Catchy headline! With a proprietary player why retransmit the whole frame. Clearly exposed initial design flaws : Monitoring ≠ Reserve of Encoding

@akhiltomar4288 Жыл бұрын

Loved it

@LuisDiaz-qg3eg Жыл бұрын

Insightful, as far as the blog allowed

@abdelrahmandwedar Жыл бұрын

Man I couldn't stop launching at this moment 26:56 🤣🤣🤣

@harogaston Жыл бұрын

I think you find it weird because you might be looking at it wrong. The "customer" is not the viewer but who is doing the streaming (uploading) so he wants to know how well the stream is being received by Prime video.

@__nitinkumar__ Жыл бұрын

@19:52, its actually not odd. This is how it happens in Corporates even if it's "our" service we pay for it.

@IvanRandomDude Жыл бұрын

Serverless? More like servermore, meaning you pay more for the servers when you "don't have servers"

@vacc1001 Жыл бұрын

LMAO. You're awfully misinformed.

@bossgd100 Жыл бұрын

😂

@sea0920 Жыл бұрын

We keep going back and forth. SWE's survival strategy.

@imrank7 Жыл бұрын

The team used an OLTP architectural style (microservices) on a OLAP problem (analytical). This mismatch in problem space to solution space leads to suboptimal outcomes. There are tools, techniques and architectural processing styles specifically for real time big data analytical use cases. Data engineering is an entire discipline dedicated to this problem space. Apache spark is an example of technology optimized for this type of processing. AWS has managed Services like EMR that allow you to run these workloads easily. Not everything is a nail 🙂

@Mohamedrasvi Жыл бұрын

Writing to s3 is often good. It needs to be asynchronous and also if the analysis failed, it can be retried later so data will not be lost. In this case I believe it is solely used for triggering the serverles states function. S3 traffic is free within the region. Their problem is the number of requests hitting as they are charged for each of them Instance memory is non network disk unlike ebs volume. They dont persist data over reboot I guess. But still it is ssd. I think they are still in micro service or as you said macro service. They just moved away from serverless stack.

@abogaziah Жыл бұрын

I guess the notification service is meant for the client app, not the user to adjust settings, maybe 🤷‍♂🤷‍♂

@sercantor1 Жыл бұрын

the clickbait for the twitter tech space was too precious to miss.

@KaushikChavali Жыл бұрын

LMAO. Now what switch from Agile to Waterfall?

@owlmostdead9492 Жыл бұрын

Torrenting is still the most elegant way to handle bandwidth related systems, change my mind.

@rydmerlin Жыл бұрын

I assumed it was just what they encoded for the device. But I’m pretty sure they won’t just be uploading things from the client again at least not without the consent of the user. Anything back from the customer would not necessarily reflect what the customer saw.

@andyvandenberghe6364 Жыл бұрын

if the orchestration workflow is too expensive then their initial segregation into microservices was probably too fine grained. So they now found a better bounded context. it does not mean the concept of microservices was flawed.

@abhinavadarsh7150 Жыл бұрын

Nice. ❤

@KevinArellano Жыл бұрын

In later news: everyone moving from tier 1 programming languages to assembly

@supernova82 Жыл бұрын

The more I read about microservices, the more I am convinced, it creates more problems than solve.

@shaulf Жыл бұрын

I think you got it backwards here, the "customer" is the person live streaming, not the client watching the content

@SheeceGardazi Жыл бұрын

i dont think step function get trigger like lambda .... you need lambda to start a step function and you need s3 to point the newly started step function to s3 ... i dont think you can use lambda for data transfer to step function becuase of 15 and payload limitations!

@omaraljarrah5089 Жыл бұрын

I think, maybe why the went with the monolithic approach in this case is for one reason… Their main goal was cost reduction, and so the solution they picked was the one that reduced cost the most, with respect to other factors & standards. I believe Amazons culture is a business centralized culture, not an engineering centralized culture (cough cough Google), which is why they did not go with engineering perfection but rather with business perfection.

@jaydevnath142 Жыл бұрын

If you hired best engineers, you gotta trust them too take best decisions as well.

@wawashra Жыл бұрын

The next trend will be "Hey let us move on from Microservice and back to Monolith." ?

@boot-strapper Жыл бұрын

I hope so.

@RedShift5 Жыл бұрын

It's already happening

@heroe1486 Жыл бұрын

Full loop like SPA to SSR back to PHP like in webdev, but the goal is to understand use cases and not blindly follow trends

@mishikookropiridze Жыл бұрын

Now its all putting runtime and database on edge.

@redrum4486 Жыл бұрын

I'm sure theres consultancies our there that will use the diagram AWS provided for every solution xD

@rejophilipjose7763 Жыл бұрын

It's pretty cool that people who caused the widspread(AWS/amazon) usage of microservice is going back to monolitic for one of their products

@heroe1486 Жыл бұрын

Which isn't cool are the ones from being Amazon who follow them blindly

@NathanHedglin Жыл бұрын

FALSE. Actually read the paper. Everyone is misrepresenting what happened. They basically had a single microservice broken into many that had high S3 bucket transfer costs.

@Sanglierification Жыл бұрын

why AWS make Prime pay for their services? O.o

@brandonklbowen Жыл бұрын

It decouples the orgs and boosts revenue for AWS (flagship of Amazon)

@algorithm1313 Жыл бұрын

Just looking at the diagram i say initially and my experience from step functions and lamda(ill delete this comment if my opinion changes) Both step functions and lamdas aren't great for a highly used production system at least with respect to cost. They can scale really well but they'll cost alot.

@dashmeetsingh9679 Жыл бұрын

Umm why develop monitoring service this way. 1. Spawn random test prime apps on different regions, stream the required live event as is. 2. Do any analytics operation on same machine ( where test prime app is running ). 3. Send results to one source. 4. Setup alerts on the source with regards to analytics received. Benefits : 1. Highly scalable 2. Doesnot utilize actual customer’s bandwidth ( which is critical, suppose a customer experiencing buffering coz uploading of performance metrics is taking time ) 3. Even if one test app crashes, still data would sent by other apps. Higher reliability in case of actual performance issue.

@david007x Жыл бұрын

Its stream monitoring, so the events will be coming from user.

@abhinavadarsh7150 Жыл бұрын

What a thumbnail! 😁

@VinodMoorkoth Жыл бұрын

When the article says "AWS charges user", in this case it means AWS charges Prime Video. Basically Prime video is customer of AWS. I think its also a cultural thing in AWS / Amazon , even if an internal team is using your service , its just customer. Treated alomost like an external customer. Even they are charged just like an external customer.

@vicpdx Жыл бұрын

Yes, to manage cost most large businesses internally charge sub business units to reduce overall cost.

@pocket5s1 Жыл бұрын

serverless is not the same as microservices. most of their cost was in using s3 and not really the use of lambdas.

@Yorgarazgreece Жыл бұрын

If a microservice talks regularly to another microservice, it's probably a bad microservice. Microservices should avoid "talking" to each other as much as possible. This is one of the reasons behind the concept of event driven microservices and event sourcing

@soumyaranjantripathy Жыл бұрын

In this diagram, the customer might be the stream/content provider, not the actual end user watching the content.

@VoyivodaFTW1 Жыл бұрын

Nature is healing,

@animesdaily1018 Жыл бұрын

who the hell is in profile picture

@squirrel1620 Жыл бұрын

This is exactly why one of my company's products failed. The wanted a full severless backend. Worked __okay__ during development, despite issues like latency, which can be solved, but once it went into production they quickly realized the amount of data transfer between microservices would trump any benefit provided by the architecture. In my opinion, microservices are great for asynchronous functions, but not great for building complex systems that pass data back and forth. Also, step functions i feel are just a marketing gimmick to get you to have greater transfer costs and you get charged for each step. Why do I need step functions, when i can just code the steps into a single lambda? Yes there are use cases, and we do use them... Just not for everything

@classicwannabe7710 Жыл бұрын

We had a third-party API which did not notify us after triggering some process that we can consume their data. So polling was the only choice but polling every minute or so would be expensive. BTW it might take up to 20 min for the data to be ready for consumption and only users can trigger that process. Eventually, we decided to use step functions with their timers to run the same lambda multiple times but with some delays in between to have better user experience. I don't know if there is a better design but at least it works 😅.

@classicwannabe7710 Жыл бұрын

Also there are 4000 free state transitions per month by AWS. If I'm not mistaken, it is per region too

@davidmcken Жыл бұрын

I don't know whether to laugh or cry at the initial architecture. Tools like ffmpeg work better on chips with large amounts of cache because pulling in data from RAM can be too slow! Of course network access is going to cause slow downs. At the very least the I-frame needs to be available to render all the deltas from it, they literally have a data localization problem, they would have seen similar issues just going to multi-socket systems. The "monolithic" approach they are taking is just doing everything they need in one place. It would be stuff like is the feed frozen, is the audio out of sync, is it breaking up is the quality really different from the reference feed, etc. The approach is no different than having you get dealt with by one person if you say go to the bank vs being sent to one department for part 1 then another department for part 2 but then the first department needs to send over your file (the context) or more applicably department 2 asks almost everything all over again (in this case only the media conversion is shared). Now thinking about it, for threaded programming it is said that if your code is computationally intensive threading it might actually make it slower, the reason is the context switches are not free and constantly tearing down and rebuilding that context every time a switch between threads occurs hurts performance.

@NeoChromer Жыл бұрын

Sometimes I meed a 3x option for the vids :D no offense love them

@rich5592 Жыл бұрын

This is a by-product of designing by trends vs designing to address a particular solution. There are basic concepts that over the years has been lost. For instance, in such a design, co-locating the data and processing. Distributed computing comes at a cost; in various ways. We the Cloud, Docker, terraform etc, its easy to design something poorly that words, but comes at hidden costs; stability and money.

@Ami7166 Жыл бұрын

Microservices are only required if the solution demands it. Sometimes architects overthinking while designing on scalability.

@ianokay Жыл бұрын

"AWS Step Functions charges users per state transition". This is totally clear, right? 😑 OBVIOUSLY the user of these step functions is Amazon themselves (the title also makes this fairly clear). They're simply outlining how step functions are charged to companies/developers utilizing them; how is the word "user" here confusing? It's how all the documentation for services reads too.

@hdjwkrbrnflfnfbrjrmd Жыл бұрын

All hail the monolith.

@TawfekDaghistani Жыл бұрын

I like Ya rabbi!, Ya rabbi! :D I totally understand your furstration

@Kc-nn8mn Жыл бұрын

CV-driven design :)

@kubre Жыл бұрын

Oh, catched early

@airman122469 Жыл бұрын

Gosh. You don’t say? Imagine if you will, that a simpler architecture with simpler deployment is substantially simpler to maintain. Man. Who would have ever thought? Oh, yeah, literally any developer that’s actually thought about it for more than 30 seconds.

@Luxcium Жыл бұрын

They where getting screwed up by Amazon for not being a monolithic company…

@magic0x0 Жыл бұрын

❤❤❤

@Jkauppa Жыл бұрын

throw to trash, save all

@kwinzman Жыл бұрын

Okay so they gave like an intern some AWS tools and they hacked something together. Threads with shared memory can more efficiently communicate than writing everything in an object/file store first. No suprise. If this wasn't Amazon nobody would would find this notable. I feel like the whole thing is a waste of time.

@laughingvampire7555 Жыл бұрын

they can run the defect detectors in the browser of the user using a webworker, they don't need all this mess, it doesn't matter if its microservices or monolith, to me this tells me they don't even understand the problem, they don't even understand distributed systems.

@labhamjain3915 Жыл бұрын

120$/yr for prime? Here it's less than 10$/yr for students and 20$/yr as regular fee

@stefannich353 Жыл бұрын

Really poor content from Amazon Engineering as expected. It's their weird Leadership Principles who tells them to label every end-device/user as "customers". Not enough details were provided, diagrams are poorly done and it looks like this blog hasn't been through QA. They do not even describe it properly. It's just that they wanted to prove to the world that they achieved cost reduction by converting microservice to monolith. I'd argue that their initial microservice design was sub-optimal. There was already a lot of room for improvements even if it were to remain as a microservice. Looks like a L4 engineer designed this and wrote the blog for their promo.