So what I learned is that the more servers you add the more serverless it is.
@filiformis
Жыл бұрын
Brilliant.
@umutsalihbayrak
Жыл бұрын
They became serverless, but you became servermore.
@benjaminwagner1772
Жыл бұрын
On Point 👌
@Dev-Siri
Жыл бұрын
more, less = less, more
@gouravojha1353
Жыл бұрын
Heavy driver..... Bro
@John_Fx
Жыл бұрын
been in IT for 30 years. it is an endless cycle of flipping back and forth on architecture decisions. can’t remember anymore if we are centralizing or decentralizing now.
@obsidianjane4413
Жыл бұрын
Its an established marketeering pattern. Every ten years or so, when a fresh crop of executives have seized the reins of corporations, they get sold on whatever buzzword for "da cloud" is handy because they don't listen to the ol' SYSADMINs who have seen this pattern over and over.
@artiefischel2579
Жыл бұрын
We've been in another "back to the mainframe" period and are moving toward computing at the edge, PC, etc. again. That will last longer than last time because the network is better, containers make deployment easier, and the cloud companies have absolutely shit on their customers' privacy.
@lovell8983
Жыл бұрын
@@artiefischel2579 also I think one of the reason is that the hardware price is getting cheaper and cheaper. So for a small to medium company, the cost for infra will break even in the long run
@darrenloke5486
Жыл бұрын
Well you should know the answer to it by now? It depends…
@chrislambe400
Жыл бұрын
That does my head in. Just like the new marketing manager that comes with a new logo every 4 years.
@bkucenski
Жыл бұрын
Who could have guessed that initiating classes and calling functions is faster than API calls over HTTP
@grigoriismirnov-pinchukov3406
Жыл бұрын
🤔
@sevdalink6676
Жыл бұрын
Sad history of humanity :D
@NuncNuncNuncNunc
Жыл бұрын
As Attorney Tom says, it depends. If the monolith has a part that is a resource hog, the whole system needs to be scaled for that part. HTTP is also not the the only protocol out there, but sure on board is faster than network communication.
@bkucenski
Жыл бұрын
@@NuncNuncNuncNunc If there's specialized physical resources and processing that need to be optimized, then sure, you will probably build an appliance specific app and server. I/O limitations have to be considered. Enterprise ethernet is up to 10Gbps. NVMe is up to 32Gbps. The fastest RAM is now 69Gbps. Nice.
@elhoward7440
Жыл бұрын
More importantly, shared memory is several orders of magnitude faster than network communication. Every microserver adds significant latency. Not really a problem for streaming services like Netflix, but big problem for something like a game server or stock trading app where you want to minimize latency.
@ceco987
Жыл бұрын
"When it comes to cloud architecture, there are no solutions, only tradeoffs." What a great way to wrap the video up! Keep up the great content
@larrywest42
Жыл бұрын
It is great. Though I'd reword it slightly: "When it comes to software architecture, there are always multiple solutions, with an array of trade-offs that are often hard to measure in advance." (The trade-off here being that over-engineering the pithy slogan makes it cumbersome.)
@guitar300k
Жыл бұрын
so how do I approach this problem, kind of annoy when there's no solutions
@wesleymouch7498
Жыл бұрын
Software systems are like piles of dirt. You can hide it under this carpet or that carpet. Or divide it among multiple carpets. There is no way to completely get rid of the dirt.
@jenskmigselv
6 ай бұрын
That was my take away too
@johnwu8916
Жыл бұрын
This is a lesson I learned at AOL over 2 decades ago. Monoliths are great for efficiency (going fast), microservices are great for flexibility (Change fast). It’s a question of what you want or need to optimize for. There is rarely one single approach for everything, it’s always a trade-off.
@AJ-le3yh
Жыл бұрын
Exactly this, for this reason my biggest shock was to learn that prime video ran on serverless 🤯 it’s not just about performance though but the high demand and predictable traffic, which I guess they were unsure about when first setting off
@johnwu8916
Жыл бұрын
@@AJ-le3yh That's the thing... you can't optimize for speed until you have some predictable pattern that you can optimize against. But all solutions are a two edge sword. When you optimize for speed (as we did at AOL), it's hard to pivot when the pattern changes and you need a more flexible solution to deal with the increased rate of change and a higher level of uncertainty. But when a new pattern emerges, you then are losing efficiency until you can retool your system for efficiency and speed. As they say, there is no free lunch. Personally, I prefer a flexible system that's highly modular. So as new patterns emerge, you can optimize specific key processes (including consolidating multiple modules into a single monolithic system) while keeping the old flexible modules on deck. Then you have a 'conductor' to help determine which solution to use and when. Yes, you lose some performance by doing this, and you could increase the cost slightly, but long term, you are better off, as you are better able to adjust to new, unexpected changes.
@thewhitefalcon8539
Жыл бұрын
@@AJ-le3yh You know what would make sense would be if you could provision a certain amount of serverless capacity for only slightly more than the cost of the same servers
@solderbuff
Жыл бұрын
@@AJ-le3yh , Prime Video is still running on serverless. They are talking only about one microservice here which changed its architecture to be more performant. Prime Video consists of *a lot* of microservices.
@darrennew8211
Жыл бұрын
The same thing happens in software. You build the code in one giant lump, then that's hard to maintain so the next time you build it in lots of little classes, and that's hard to understand so you go back to building it in giant lumps again. Eventually you get "object oriented" were each class is a singleton with 300 instance variables pointing to other singletons.
@name-os8kl
Жыл бұрын
As a lot of things in Computer Science: it depends. There's a tradeoff for using monoliths or microservices. The key is to understand your needs and be aware of the tradeoffs while choosing an approach.
@jordixboy
Жыл бұрын
This is exists in every question of life, it not something only happening in CS lol
@johannbauer2863
Жыл бұрын
@@jordixboy what is life, if not CS?
@sfulibarri
Жыл бұрын
Wow such insight, how did you come across this rare wisdom? Surely it couldn't be an asinine summary of the video we all just watched on this very page?
@kibiz0r
Жыл бұрын
Yep. And it's not just technical trade-offs, either. There are UX constraints to going distributed, cuz now you have to deal with the CAP theorem. If your UX demands that changes be atomic, you're entering a world of pain. But there are also implications to running steps 1-13 of a task within the same process, without any persistent storage mediating the hand-off from step to step. If the process dies, you can't easily resume at step #5. If your UX demands that the task be resumable, you're entering a world of pain.
@notjin2109
Жыл бұрын
@@sfulibarri a lot of ppl summarize videos in their own words in comment sections i think that’s normal
@Denominus
Жыл бұрын
TLDR; They were doing a lot of IO from lambda/step functions/state transitions/S3 for EACH FRAME in movies. Obviously slow. They decided to change that to process a movie's frames all at once in a worker per movie architecture avoiding 90%+ of the IO and slowness. They can still scale horizontally by adding more workers.
@Th3MoL3
Жыл бұрын
that is what i thought i read the article before coming here and seeing Jeff made a video. When he said only horizontal scaling only i was like.....wait a minute.....as you said there was too much overhead communicating to different lambda/step functions so grouped the highly commincating parts on one server to make processing one video way cheaper. Doesnt mean every video has to go through that one container.......
@nnnik3595
Жыл бұрын
Couldn't they even run this single container as a serverless function?
@azufendusgarendum6583
Жыл бұрын
Yeah, I don't understand how they decided that their original architecture would even work at all on paper. The whole article just screams "we created problems and then we solved them. Give us a promotion"
@SahilP2648
Жыл бұрын
Yup seems like Amazon hires all the dumb folks, regardless if they get paid well or not
@nayaleezy
Жыл бұрын
exactly, and this is where microservice purists aka naive newbs lose their minds and we all justly ignore them.
@SkamanSamTyler
Жыл бұрын
Whenever we discuss anything about anything in my programming team, i start by asking "what are the tradeoffs?" The devs know what they are doing, but want a team approach to make a decision. 95% of the time it doesn't really matter, but saving money for the startup usually takes slight priority. There very often are no real hard and fast solutions, only tradeoffs.
@nero4581
Жыл бұрын
Indeed, they went with serverless to test the idea and deploy it fast to the market and then figured out the optimal architecture, reusing algorithms and code from the serverless when switching to monoliths while also lowering the costs and increasing the data analyzed It's only tradeoffs and nothing is perfect or terribly bad
@glenospace
Жыл бұрын
Yeah, but money for startups is 99% dev hours cost, and 1% arch cost. I’ve once been to a meeting where 20 devs were discussing a giant CI/CD bill for an hour. And that meeting time alone was worth 2x the monthly bill from CircleCI.
@MartinezVM
Жыл бұрын
Whenever someone says that their solution has no disadvantages, I always tell them that their solution does have them, it's only that they haven't discovered them yet. Life and software is all about trade-offs.
@chrisme5440
Жыл бұрын
Non tech members of my company take the piss out of me for saying this. e.g. what would you like for lunch? “there are no solutions only trade offs”
@MaryamMaqdisi
Жыл бұрын
Agreed
@dal2452
Жыл бұрын
I once visited a small biotech company that had its own server. I was confused, and they explained that due to the massive amounts of data their machines produce, it costs less for them in the long run to just buy a server than relying on the cloud. If your price for electricity is less than what AWS would bill you, and you can manage the upfront cost, having your own infrastructure actually makes sense.
@braindawg
Жыл бұрын
Depends on the application, of course. I've been in offices with home-built server closets, and I've felt the wrath of customers when someone kicks a plug or pulls the wrong network cable or cuts the DS3 line to the building while they're doing utility work down the street (or when a fan dies, or when a NIC starts dropping packets). If service uptime is important, you're probably paying for rack space in a tier 3 datacenter. If it's critical, you're probably paying for space in multiple geographically distributed datacenters, with multiple ISP connections to each one. This complicates your network infrastructure, so you need network engineers capable of architecting and managing interconnectivity across multiple datacenters, and you need sysadmins to select and maintain the server hardware & software your application is running on. The cost of managing your own servers can be massively more than just electricity + the up-front hardware cost.
@dal2452
Жыл бұрын
@@braindawg True, those data centers have specialized setups to deal with blackouts. I think this particular company was using their server for R&D, not for anything their clients were relying on. Actually another place I worked was a hospital, and they had an entire server room. Hospitals are mandated to have backup generators, so setting up a server might be easier for them.
@jondoty
Жыл бұрын
Your price for electricity is insignificant compared to the cost of installation, initial configuration, and maintenance. And good luck with uptime.
@alexus267
Жыл бұрын
Renting servers that are already in a data center is likely to be cheaper and the cost is fixed. Scaling is a bit slower and you have to deal with hardware failures, but you likely have more software-related outages at early stages. We contemplated migrating services to cloud at a small startup and at that point nobody could come up with any slightest idea how much it's going to cost (few thousand a month were big deal for us back then). So we just kept paying some $100 per month for a physical machine in a DC.
@davidthacher1397
Жыл бұрын
You need the cost to be exclusively electricity actually. If you ever idle more than a certain percentage you are better off renting the server. If the cost of staff is high you are better of renting. When you buy a server you are looking at a 5-10 year investment in most economics. Lot of people hate this actually because it hurts sales in hardware and job security. Some even moan about the power savings. More than likely they were interested in a offline server. If you have workstation that does a lot of computation for multiple people then own a central server may make more sense. The equivalent networking and cyber costs would be on top of hardware, staff, electricity, etc. The idea behind renting is to get away from operating cost and ownership. People that can afford ownership will do so. However for most who cannot will not without renting. The idea here is to allow them to, not take advantage of them.
@Kchandrashekaran
Жыл бұрын
A small business had incomplete webapp which they used for day to day operations. I helped them complete it, the previous dev who worked on it built it as microservice using netflix discovery libraries. It was an overkill as only 10 employees used it, scaling was highly unlikely. The dev lost interest and left, due to overcomplicated architecture he created and lot of time was lost. I rewrote it as monolithic nodejs apis + react app. It worked fine with same performance. I am not against microservice, but sometimes you need to be pragmatic, not idealistic. As always, you teach me something in every video, Thanks fireship!
@wojciechsobiesiak
Жыл бұрын
Improper use of OOP, that's all.
@danitinez85
Жыл бұрын
you need to be pragmatic, not idealistic. I will Tatoo this myself.
@MAVrikrrr
Жыл бұрын
The simpler the better 👍
@Keisuki
Жыл бұрын
Basically every good microservice system begins life as a successful monolith. If you build for microservices right away, the added complexity will ensure that you never reach V1.
@Osys91
Жыл бұрын
@@Keisuki golden words, I can't agree more
@iverson0389
Жыл бұрын
The new approach CAN scale horizontally. Look at the image - it says ECS Task. They just packaged all the steps into one service (this is still a microservice) and they can run multiple instances of this service as containers in ECS Multiple instances will handle multiple different frames in parallel
@LeonHazen
Жыл бұрын
Yeah it sounds like just less micro microservices. They'd broken things down too far, now they're logically grouped into a more reasonable service.
@davidmartensson273
Жыл бұрын
@@LeonHazen That was my understaning also, there is nothing wrong with serverless or microservices, but there is often something wrong in how companies use them. Neither is a magic wand that just solves the problem, first you need to find out IF SL or MS is a viable solution to the problem, and if it is, then you decide the size depending very much on how interconnected the processing is and if there are other requirements. For my use MS is more about domain and process isolation where most services will not need to talk to each other. That way we avoid adding to much communication complexity while we make clear borders between domains, making testing easier. But his also means that we are not going to have hundreds of services but maybe a dozen or two ;)
@sugoruyo
Жыл бұрын
Not quite as simple for video. It's not sufficient to process individual frames. You often need to process the delta between them, particularly as modern compression codecs only encode deltas from one frame to the next instead of the whole frame. You could probably split along keyframes or something but that will require a pre-process step. The trouble with what they did is that it doesn't really scale horizontally for a single input so if they ever need to scale for, say 8K video, they better hope that it works vertically. My guess is they've done their due diligence and expect the available h/w underpinning ECS to be fast enough for heavier video files by the time they start streaming those out. Scaling horizontally for serving out multiple files should be a no-brainer and I'd be willing to bet that their horizontal scaling issues with step functions and S3 became a real problem when trying to do this for multiple files viewed by multiple customers. Seems like they just figured out their bottleneck and cleared it up.
@jofla
Жыл бұрын
They even mentioned in their original post, they do horizontally scale
@ko-Daegu
Жыл бұрын
finally someone said it it's a microservice not a monolith who said monolith is serverless ??? or have to have separate physical servers they still have separate services each is a micro of the entire service they provide
@BoloH.
Жыл бұрын
I've started using the term cloud psychosis for cases where microservices (or some vendor-specific cloud services) are expected to fix any underlying issue with architecture or software design.
@MrFirsito
Жыл бұрын
i like that term... also ive realized am spending 90% of my work time solving unplanned issues related to this shit, send halp
@happyspaceinvader508
Жыл бұрын
Even worse than this is “lift and shift” of traditional infrastructure designs into the cloud, and somehow expecting it to be better and cheaper.
@davidmendizabal7508
Жыл бұрын
Cloud services push micro services trend to benefit themselves. You are just a puppet. I begin to think that software architecture is just full of scam.
@roblreid
Жыл бұрын
Microservices can be built on-prem too. There's nothing cloud-specific about them.
@ComradeOgilvy1984
Жыл бұрын
@@roblreid Putting them on the cloud achieves a higher buzzword compliance score. In the last two companies, I have seen projects burn a lot of engineering resources for "beautiful" microservices architecture that should scale really really well...when there is not possible they will that kind of scaling for >5 years. This is an insane level of premature optimization, and calling it a psychosis seems justified.
@ffxsam
Жыл бұрын
Totally fair that AWS moved this set of services into a traditional container. It really just depends on your use case. We run our SaaS on all serverless, and it works out great for us. Probably our most expensive parts are just outgoing bandwidth due to streaming audio/video (which can't be helped), and using MediaConvert for video uploads. We've been partly serverless since 2016, and fully serverless since 2022.
@hyper_channel
Жыл бұрын
Exactly, all this is so case specific... There are a lot things to be considered... hell if it's a small team things like personal taste might triumph over a 10% more efficient architecture...I would happily trade some on paper performance if it means a happier dev team any day
@saisensei96
Жыл бұрын
Man I agree, this is case-specific as hell. And the video is misleading, one can't judge an architecture just based on it's faulty for one use case. Plus monolith or serverless either of them are not a silver bullet for all the problem. We need to decide based per use case basis rather than thinking like lets do it and think later.
@mikkolukas
Жыл бұрын
"(which can't be helped)" --- yes yes, just lower the video quality for the users, they will *never* notice :P
@ffxsam
Жыл бұрын
@@cheesebusiness One does not simply pick up and move an entire mission critical application to another cloud provider! 😆
@rrmackay
Жыл бұрын
A couple years back we were running route calculations for mapping on lambda, the lifetime was too short so the design was to cache the work and pick it up again on the next start, ran out of contorl one day and spawned 10,000 lambda instances for the same job, CFO was none to happy about that.
@TweakMDS
Жыл бұрын
Good points! My take on this PR debacle: It's always been obvious that the primary scaling (or even use case) for serverless was to have *sparse* workloads. It shouldn't be engineered as a solution for continuous workloads, because the primary benefit is being able to scale to zero. If you scale serverless to be basically continuous use, it's gonna be expensive. There's now some debate on whether or not this is sufficiently documented, but anyone with an AWS/Azure/GCP calculator can quite easily make their own projections and figure this out. Also, serverless and microservices are not interchangeable concepts. I think the best takeaway from this is to consider network overhead when implementing microservices or serverless. It's always baffling to notice that developers have no clue on how much traffic flows between functions (or services). If you run it all on one machine, it doesn't matter, but that's where the key is.
@anandsharma7430
2 ай бұрын
Informative and incisive comment. Thank you!
@paulmcburney6874
5 ай бұрын
Software Engineering Professor here: This video is **really** good for explaining serverless and the serverless/monolith trade-off. Thanks for putting it together!
@sanctuary_inheritor
Жыл бұрын
Just the Thomas Sowell reference at the end already deserves a like.
@LukePighetti
Жыл бұрын
I want to see more people talking about distributed monoliths. That's when you have a single service that communicates over something like Kafka and can be duplicated N times and they all sit behind a random load balancer. The benefits are that you only have a single container type to worry about, but it is horizontally scalable. It doesn't matter if you have N containers and M workers per container, it all works the same.
@LukePighetti
Жыл бұрын
I have seen some AWS bills that just boggle the mind for 100 concurrent user products. Stuff that could totally run on a decent monolith plus a video streaming BaaS product
@unity001
Жыл бұрын
It's already out there named as 'Azure cloud service'. But Microsoft is gonna scrap it soon..
@Prometeo59
Жыл бұрын
@@unity001 Can you explain more what you mean?
@petercai3493
Жыл бұрын
AWS Beanstalk Docker platform is working like this.
@LukePighetti
Жыл бұрын
@@petercai3493 Thank you
@boomeroo
Жыл бұрын
+10 points for working Thomas Sowell into this Code Report. +100 for doing it appropriately. 👍
@futuregootecks
Жыл бұрын
Amen 🌟
@deadohiosky1701
Жыл бұрын
I came here to say exactly this lol
@migueld8970
Жыл бұрын
facts
@muizzy
Жыл бұрын
Prime still uses microservices, it's just the VQA (Video Quality Analysis) product that moved their product from multiple microservices to a larger microservice. They still maintain horizontal scalability, as there's a load balancer in front of the service (this scale cannot be achieved without horizontal scalability). I don't know why they decided to use the term monolith, probably to get more impressions.
@briankarcher8338
Жыл бұрын
I don't think the writer knows what a monolith application actually is.
@QuarktaschemitSenf
Жыл бұрын
ty for being one of the few "no clickbait, no bs , a lot of info" channels on yt. Sadly there are not many channels like this, but props mate
@odytrice
Жыл бұрын
I love that you referenced Thomas Sowell 😁 at 3:40
@citywitt3202
Жыл бұрын
And this is why I run my Linode ops as if we owned our own racks. One server, one job. And if you need more power, you scale the bit that needs more power. If you’re relying on code to provision resources, you’re assuming it must be bug free in financial calculations. Whereas I can tell you to the minute how much we’re spending per user, and exactly how much the next step up will cost us. It only gets cheaper as you grow, and whilst we’re small, the initial costs are absorbable if not free.
@zmirc
5 ай бұрын
Respect. +1
@manm5302
Жыл бұрын
The Thomas Sowell 'there are no solutions' ending was spot on
@JohnDoe-my5ip
Жыл бұрын
When lambda et al works well for your use case, it’s absolutely brilliant. But I’m also pretty sure 80% of lambda apps are a victim of resume-driven development and just end up creating a Flying Spaghetti Monster in the cloud.
@chpsilva
Жыл бұрын
Resume-driven development... I am stealing this acronym 😂
@jdahern
11 ай бұрын
😂
@bb5242
7 ай бұрын
@@chpsilvaUh, how old are you? That term appeared sometime in the late 90s.
@chpsilva
7 ай бұрын
@@bb5242 well I am old enough to be working on software development by the nineties but since I'm also not a native English speaker it's not exactly surprising either.
@nikluz3807
Жыл бұрын
I’m a simple man. I see Fireship, I click.
@Rud331
Жыл бұрын
That's why you are not simple
@akar_excel
Жыл бұрын
Same here, we are men of culture😅
@Ayo_jayo
Жыл бұрын
I click I sits & learn more tips.
@AbdulRehmanKhan.
Жыл бұрын
Good sir
@AndroidChileDemos
Жыл бұрын
same here, this is the only youtube alert that I have.
@tHekrack23
Жыл бұрын
This is just like that bell curve meme, both very beguiners and super advanced users use Monoliths, and all the startups with 50 active users are all about "yeah lets MICROSERVICE EVERYTHING"... I was one of those, still are some times, and I need to remind myself that Monolith never went anyway, and that the dashboard that I'm building for this company that at best is going to be used by 1000 people at the same time is not ever going to have the same problems as the youtube servers
@83hjf
Жыл бұрын
microservices can be good depending on what you do. examples can be random connections to weird external systems, to transform into a common interface. it doesn't really need to be a full-fledged MiCrOseRViCE ArCHITeCturRE
@gadget00
Жыл бұрын
1000 times this; people want the "rush" of handling 100+ microservices and "feel" like a "great engineer/hax0r" for keeping it running, instead of just thinking a bit more and build something sustainable instead
@spitfire7170
Жыл бұрын
shilling microservices nonstop is a great way to pretend you're smarter than you are to people that don't understand tech not that microservices are always bad but they should be implemented sparingly and only for things where it actually makes sense
@brightrrs1740
Жыл бұрын
Not really. Microservices come in handy in sales, because you can sell just specific parts instead of a monolith. But your second point is true, as it is true that probably no one ever actually replaced a microservice with a new microservice, which adheres to the old one's endpoints.
@SahilP2648
Жыл бұрын
Yup you got it. And there are ways to make serverless monolith architectures. You just need to think out of the box. Now if it makes sense economically is a different question entirely but it can be done.
@surrealchemist
Жыл бұрын
I think the use cases of serverless vs not isn't the same as microservices vs monolith. The diagram they showed was a monolithic group of tasks in ECS. That doesn't exactly mean its not running in Fargate, it depends on your workload and if it is memory/cpu constrained, required extra computing like GPU, how long the tasks run for, how long it would take to spin up replacement tasks to scale out etc.
@jocke8277
Жыл бұрын
Fargate is still considered to be serverless right? But with containers
@timmeehan2365
Жыл бұрын
Exactly, people seem to confuse microservices for serverless. You could very well have one monolith application running serverless on a lambda function or a non-serverless microservices architecture
@rumfordc
Жыл бұрын
@@timmeehan2365 what is an example of a monolithic application running on a lamdba?
@CabbageYe
Жыл бұрын
I don't think he understands these concepts very well because he kept implying microservices and serverless are bound to each other and that monoliths can't be deployed on serverless architecture.
@timmeehan2365
Жыл бұрын
@@rumfordc A lot of them actually ! Any monolith application that doesn't need to keep some state (Sockets, sessions) or work with the filesystem. All basic CRUD apps could be deployed in a serverless fashion.
@Grahfx
Жыл бұрын
serverless is perfect for my use case. If my project don't work, it will stay on the free tier, if it sky rocket, it can scale.
@holly_hacker
Жыл бұрын
Serversless is mostly useful if you have workloads that aren't heavy on the cpu, from what I can tell. It's great if you have spiky workloads where most of the time it's sitting idle, and/or where the autoscaling is saving you money.
@T33K3SS3LCH3N
Жыл бұрын
The main claim is still true: AWS makes it easy to scale. It is once you know your scale (and it's big) that it becomes sensible to build a monolith that's optimised for it.
@prashanthb6521
Жыл бұрын
The most correct answer of all !!!
@SioxerNikita
2 ай бұрын
Might be a year ago, yes, this. This is especially why game servers are rarely hosted on their own hardware anymore, because how much infrastructure you need is often changing a lot. Especially on release. You'll need FAR more server than you'll need ever again.
@velo1337
Жыл бұрын
There are no solutions only tradeoffs. i really felt that :)
@FourOf92000
Жыл бұрын
Thomas Sowell (quote source; the guy the gif is of) is full of gems like that
@tobb10001
Жыл бұрын
I feel like this is a sentence about programming in general, not only cloud.
@dennycrane2938
Жыл бұрын
The language is iffy. Anything we do to implement is a solution. IMO Would be better as something more like "There are no 'correct' solutions, only tradeoffs"
@sofianikiforova7790
Жыл бұрын
Based Thomas Sowell
@50PullUps
Жыл бұрын
Nice, a shoutout to Thomas Sowell! Reading his ‘Basic Economics’ was a gut punch. Easily the best non-fiction book you could pick up.
@donparkison4617
Жыл бұрын
Scaling only matters if the demand is bigger than you planned for. The vast majority of applications do not suffer from this, either because they are big enough that they planned for it or they are tiny and will remain so. Small things that unexpectedly turn into big things are extremely rare.
@RebelCoderX
4 ай бұрын
I think in a lot of cases it's fear of missing out, lack of professionalism among developers, and micromanagement. Also, don't forget the influence of technical entropy and misconceptions about architecture such as network topology for microservices, but also architecture inside the code of one piece of that topology. I mean as you start on a new infrastructure, things are simple.. You don't have any existing code to deal with. So everything you make is new. There is nothing to refactor and life is peachy.. But as the weeks and months and years progress, stuff becomes more and more difficult to add and change. You get more and more crashes and eventually management who forbid developers from touching a certain part of the framework for fear of breaking it.. Or forcing developers to put something new live right now because of promises made to stakeholders.. So now you have many parts of the infrastructure that are so fragile that you have to work around them, duplicating functionality, and by so doing introducing ambiguity about what is implemented where.. Developers getting fed up with micromanagement and the mess they are unwilling to admit they created themselves (somehow always claiming it was their colleagues fault).. So then you need to hire more developers to replace the staff that left while it was already difficult to attract the staff capable of understanding the huge mess that the infrastructure has turned into with years and years of outdated, missing, confusing, or plain wrong documentation and dead code. And finally, ten, fifteen, twenty years later you find yourself in a massive pool of code that no one can figure out anymore. But wait! What's this new tech we've been hearing so much about? Google uses it, Amazon uses it, Microsoft uses it, so it must be good.. It's called Servers-in-Space (SiS) and it's the next best thing.. The solution to all our problems! "We need that" says 80% of the companies that don't need it.. "We're not big enough like microsoft or google or amazon to need to think about our architecture", says 80% of the managers who only have written 1 or 2 excel scripts in the last 30 years. And so many companies rewrite their entire product, spending millions or billions of dollars, making essentially the same product on their "server in space".. But of course it's the same developers who created the original product in the first place.. Misunderstanding things like MVC, Security, SOLID principles, microservices, technology stacks, at the same time treating all their knowledge like golden hammers because that's what they were hired to do (after all one of the first questions on a job interview for a developer is "how many years of experience does he/she have with [insert language name]?") So, surprise, surprise.. Ten, twenty years later, you find that overhead is killing your product. After all it can never be unprofessional attitude of the people who built it, the hireing staff, the management, C-level execs, customers with ever changing demands, other stakeholders and rigid, inflexible infrastructure design in an ever changing world, right? So you think this is going to change by moving back to the big monolith? Sure it will! For the first ten years or so..
@apreviousseagle836
Жыл бұрын
This channel makes me proud to be an IT nerd.
@GSBarlev
Жыл бұрын
I'm fairly convinced I'd be happier if I'd gone a different route in my career and knew what none of these words meant...
@apreviousseagle836
Жыл бұрын
@@GSBarlev To really get ahead, you have to be autistic. The field is just too damn big. Just to be an expert in "Windows Server" would be a career on its own *if* you actually did know everything about it inside out. But nobody does. And we're expected to know: Virtualization, Containerization, Storage, Security, Authentication, Databases, and all the tools in those fields (vSphere, Azure, AWS, EMC, Hitachi, K8s, Linux. The 100 or so different SQL's, etc.). Hell just knowing AWS on its own is impossible for one single person. Just *that* is literally hundreds of services. I haven't even touched coding yet: C++, Python, Go, Ruby, JavaScript, C#, blah blah Even the most seasoned Senior Engineer know maybe 2 or 3 of these at an intermediate level, and another 10-15 at a foundational level. The rest is Google-flu and StackOverFlow, lol. Which is why I'm not worried about ChatGPT yet. It will simply weed out the L1, and provide nuclear pistols to the Senior types............................if they leverage and embrace it now.
@turolretar
Жыл бұрын
@@GSBarlev nah it’s all shit, unless you’re talking about being a priest, this is something I can get behind
@daviidon
Жыл бұрын
My respect for this man after seeing the Sowell cameo 📈📈📈📈📈
@liquidsnakex
Жыл бұрын
Jeff is always dropping hints that he’s based, he knows the average lefty is too stupid to notice.
@demetriusjohnson5358
4 ай бұрын
TRUTH!!!
@JonathanTheZombie
Жыл бұрын
I kind of wish Thomas Sowell was also a computer scientist. Closest we have rn is Knuth.
@ЕвгенийАндронов-ш4к
Жыл бұрын
David Parnas? Fred Brooks? Michael Jackson?
@JonathanTheZombie
Жыл бұрын
@@ЕвгенийАндронов-ш4к tell me more
@tcarisland
Жыл бұрын
well his son happens to be one, he's worked as a developer since the 1990s.
@joshbarghest7058
Жыл бұрын
A total charlatan who couldn't hack it in academia and so became a think tank shill? Doesn't sound an anything like Knuth.
@KD-rh2cr
Жыл бұрын
Dijkstra
@elhoward7440
Жыл бұрын
That has always been my response to microserver architecture, that sharing memory between processes on the same bus is always going to be a lot faster that serializing data between microservers. Granted, the objection that the monolith gives you a single point of failure is valid, but having a hot standby constantly being synched from the monolith might actually be cheaper than keeping all those microservers running. So we're left with microservers just being easier to dynamically scale and experiment with, as opposed to maybe rebooting your whole monolith resulting in a few minutes of downtime every day.
@studiouswadoo5027
Жыл бұрын
I love that reference to Thomas Sowell at the end because a lot of people are disillusioned to think there's a one size fit all solution to things. Depending on the service you're trying to run whether it's responding to web requests or doing video processing, you'll have to make architectural decisions. Sure there's ways improve the compute efficiency or do cost optimization but often times there's tradeoffs. You could abdicate the responsibility of managing your infrastructure by going to the cloud but you lose control. I think this applies to a lot of things in life like Tor for example. You're more anonymized in some respects but get higher latency
@ОлександрЗатулєєв
Жыл бұрын
This is partially because lambdas are expensive af. Lookup the prices on AWS - 1 hour of running a 1 GB lambda is 6 cent, 1 hour of running an on-demand t2.micro is 1.16 cent. So, you need to prefer lambdas over EC2 if your code is running less than 10-15 minutes per hour. And we are not even counting reserved instances or savings plans! IMO, in the last 5 years we have had a number of "toy" technologies (won't specify which ones other than lambdas to not generate drama): they look like kid's toolbox - red wooden saw, yellow plastic hammer - all colorful, attractive and completely useless EDIT: I admit that lambdas are not completely useless, but their usability is limited, and mostly it's not of the business domain, but some maintenance - CI/CD pipelines, taking actions if the app is not healthy etc
@Fanaz10
Жыл бұрын
aws is good for companies with too much money, solves the money overflow problem
@allinvanguard
Жыл бұрын
Honestly, the initial version of this architecture was quite sus. Putting a CPU intensive, non-bursty state machine which inherently works together and constantly has to talk to each other, passing artifacts along, onto a durable serverless system? This just screams "single process" to me. I would take the article with a grain of salt, since it sounds a lot like it was not on the right tool for the job all along, so this does not spell doom for serverless or microservices in general.
@jofla
Жыл бұрын
Yeah, but sometimes when we are in the heat of the moment we are not able to see the right design. And only after some time, we are able to see our designs with other lenses and the correct answer becomes evident
@briankarcher8338
Жыл бұрын
@@jofla Calling a step function for every frame of every video watched should have been caught day 1 of the architecture discussions. No excuse for that one.
@zakygerman9897
Жыл бұрын
+1. Also, they could have kept using Lambda, but have it process more data per invocation. Sounds like somebody in the Prime Video team really wanted to use microservices to they jumped on the opportunity and never really had a good discussion about it. Good discussion should have also caught the misuse of step functions in the first place.
@hki6mq
Жыл бұрын
I love the easter eggs you leave lying around in your videos, which elude to your ideas about things beyond tech.
@cougar2013
Жыл бұрын
Thomas Sowell is the goat
@jonnysongs
Жыл бұрын
allude*
@quilnux
Жыл бұрын
What I learned as an early adopter for cloud is that there is a finite point where cloud makes sense and does not make sense. For startups and small businesses with little existing architecture and low traffic needs, cloud will probably make sense (including microservices/serverless) but once you get big, cloud ends up costing more. My business was all-in on cloud services for 4 years before switching to on-prem solutions. The costs go up as your traffic goes up but the increase in cost is not in line with the revenue-per-traffic-volume in most cases. So cloud does not make sense at scale from the perspective of ROI.
@masamune__x86
Жыл бұрын
It's the always satisfying answer of "It depends". I think monoliths are more performance and efficient when they don't do a lot of work, or not at the same time. Overall you should code in a way you can extract a component from a monolith easily into a micro service when needed and only a few things deserve to be relegated to that spot
@jeanchindeko5477
Жыл бұрын
Microservice architecture bring a whole set of complexity and for each new tools to mitigate the risk. Now you need more monitoring, logging, tracing and tools to store and handle all that stuff
@wavesnowaves
Жыл бұрын
One of the main points here, is that moving packets around AWS network is expensive, especially if there is cross AZ movement as well. For use cases that involve a lot of data processing, the less hops the better. And scaling fewer components up instead of out - can save a ton of money.
@AI-xi4jk
Жыл бұрын
Moving video frames is expensive on any network or process.
@steveb7600
Жыл бұрын
I think the bigger issue was long running Lambdas under heavy compute from those payloads but perhaps the data consumption was super costly as well
@steveb7600
Жыл бұрын
@@AI-xi4jk True, I am not sure that would have been cheaper by moving it to a virtual instance
@GeorgeFrick
Жыл бұрын
Thank you for mentioning the trade-offs at the end. You could talk about the four quadrants: Monolith, Modular Monolith, Microservices, Distributed Monolith. Never make a distributed monolith, and decide on the trade offs between Monolith, Modular Monolith and Microservices. I generally recommend a Modular Monolith and you can break off Microservices as needed.
@GeoffreyHale
Жыл бұрын
+
@hanshima_
Жыл бұрын
Thanks for sharing, I'm gonna look into it.
@tomwallen7271
Жыл бұрын
I had this problem whenever I would talk to Pivotal engineers about PFS. It made sense in the abstract use case where compute was only ever needed very rarely in some event driven architecture. But it only ever made sense economically to me for CPS's like Amazon to sell to customers because they had the scale to absorb the infrequency of those workloads and balance it out across their data centers. But on-prem, I was like... "are we just trying to save power on servers? Cause you still need to keep those servers provisioned for this to provide some kind of SLA... Where are the savings!?"
@JuriyBura
Жыл бұрын
I would add my two cents here. First: distributed architecture shine with scalability when some parts are scaling more than the others. In *this specific case* the architecture was not benefitting from this kind of "asymmetrical" scalability. Second: this is an example of system that transfers very significant volumes of data between components, hence they could save the cost by eliminating the need to transfer. Third: analytics is not a business critical function and failing a job is not an issue. Combining all three, monolith makes sense. For majority of the cases out there, the three properties above are simply not present and move to the monolith won't give anything close to 90% of cost savings (but *will* increase build time, team interdependencies, etc, etc). Alas, now everybody will start quoting this article with an interpretation that "Amazon says monoliths are great".
@asdf8asdf8asdf8asdf
Жыл бұрын
Very timely and good catch… More cloud realism will be appreciated on this channel! Basecamp and Dropbox saved a lot of money because they were very VERY storage dependent (S3) Companies that are database dependent are less likely to transfer off…
@jonafll3986
Жыл бұрын
As always it depends on your usecase.
@morgantrevino4881
Жыл бұрын
"There are no solutions, only trade offs," truer words have never been spoken.
@netify6582
4 ай бұрын
After 30 years in IT, this is what I call a vicious circle.
@farqueueman
Жыл бұрын
Once again, Thomas Sowell is right in all dimensions, realities, universes and professions... his wisdom even the test of tech.
@allesdurchprobiert
Жыл бұрын
I'm curious now. What are you referring to?
@farqueueman
Жыл бұрын
@@allesdurchprobiert the last clip used by fireship (or a clip of Sowell near the last portion of the video).
@allesdurchprobiert
Жыл бұрын
@@farqueueman Thanks! I missed it because I was reading comments while the video still played. A bad habit.
@iandrake4683
Жыл бұрын
Is Thomas Sowell a big monolith fan?
@ronjobs2359
Жыл бұрын
They have switched back to monolith for audio/video monitoring service only and not other services
@prashants5071
Жыл бұрын
They actually supposedly transitioned from serverless lambda to microservices. It is, still, multiple different services separated by network calls being aggregated into a single service, but not really going from microservices to monolith. You need to take the decision on the granularity at which you separate the service based on your use case
@abhijithk1397
10 ай бұрын
Exactly people just want to hype things😅
@spuriousGeek
Жыл бұрын
World class content as always - Thank you sir!
@eko100200
Жыл бұрын
The overhead of constantly sending data back and forth (eventually even via REST and strings) is actually pretty high. What a surprise.
@khayalethu.mtshali
10 ай бұрын
The Thomas Sowell quote at the end "...no solutions, only tradeoffs"
@kuti1643
Жыл бұрын
Kudos on using Dr Thomas Sowell for the final conclusion! One of the greatest public intellectuals of our time, a true voice of sanity!
@cocoastarrion4563
Жыл бұрын
When I read this news, I didn't expect these statements blaming serverless architecture. Our service uses step function to manage ephemeral EC2 instances for each job. It works great for us. In the case of the article, it simply means their original design was not efficient/scalable from the beginning. And it was okay for a while. But later the business grew. I still remember our team had an intern when I just became a full-time SDE. The intern designed 6 lambda functions. One of the lambda functions will invoke the other 5. The design was dumb enough, but none of my colleagues pointed it out. I commented: "Why don't u make them Java methods instead?". Then he rewrote the design. In this prime video case, probably something similar happened.
@itsnahombereket
Жыл бұрын
The Thomas Sowell Gif killed me 😂😂😂
@hussienhamza3542
Жыл бұрын
my aws account got charged today 29$ for using support 🗿 , more ironically i didn't use support 🗿🗿 i think this is how they will restore the loses
@Davidlavieri
Жыл бұрын
when you signup you choose a support tier, either free, standard (30$) then other highers up to enterprice
@hussienhamza3542
Жыл бұрын
@@Davidlavieri now i feel dumb 💀
@k1zmt
Жыл бұрын
Amazon just realized that they were loosing a lot of money because many of those lambdas were falling under free-tier. And warming up those are very expensive. Now they are going to force developers to buy instances again which is more money for Amazon. Example with video-processing is a terrifying precedent of poor architecture. You want to process video as a stream, on the computers that have hardware codecs. The closest option is Kubernetes with autoscaler that spins new instances as the load increases. Hybrid architecture is more complicated and requires some balancing but it can be fined-tuned into a reliable and performant solution.
@mr_russbrown
4 ай бұрын
The number of consulting customers I see abusing serverless infrastructure is so heartbreaking. So many people in architecture positions making horrible choices, it's so cringe.
@Someone-tn8ur
Жыл бұрын
Yup, went through this at a prior engagement where I was the lead architect. We started out using serverless on Azure, had scaling issues, ended up going with physical servers and not only dramatically improved performance but reduced costs 80%.
@oxcafeoxbabe
Жыл бұрын
Your mistake here was thinking you can compare azure serverless and aws serverless.
@Someone-tn8ur
Жыл бұрын
@@oxcafeoxbabe No, but thanks for playing.
@eg4933
Жыл бұрын
its always going to be: 1) its always going to be centralize 2) de-centralize 3) go to step 1 forever.
@lakewobegonesbest8725
4 ай бұрын
Cloud computing removes barriers to entry, enabling smaller ops to compete. Orgs with the resources to replicate AWS can of course achieve better cost/performance via highly customized solutions.
@tehArgento
Жыл бұрын
Based Thomas Sowell ending.
@rogdex24
Жыл бұрын
"there are no solutions, only tradeoffs" - this calmed the shit out of my never ending questions.
@123batina
6 ай бұрын
I work on a system with huge amount of data processing 24/7. Its a lie that you cant have horizontal scaling on monolith systems. If you can make your process run in discrete chunks you can have a controller machine distributing parameters. And a bunch of headless monoliths that all communicate around with controller and each other through controller disseminated data. That way you can run all services you need (proc, DB, disk) on proper bare metal or cheap instance, within the instance. If you make it completely headless you can even have it autoscale with load. Anyways - 90% is about the number we saved when I redesigned the arch from saas to scalable monolith farm I described. Oh yeah, we have several sysadmin gig ppl on call to do setup and monitoring / troubleshooting who costs another ~10% of that number. So actual savings are 75 - 80%. Still massive number.
@macienrique
Жыл бұрын
Hey fireship thanks for the videos! It would be amazing to see one about the performance tab in your browser and how to debug performance issues correctly ❤
@JellySword8
Жыл бұрын
Pretty sure he already talked about this
@mikemjlove4988
Жыл бұрын
I've been one of those people who stayed with monolith Architecture when everyone was jumping on serverless infrastructure. Now coming to realistic point of view, If you are working for a multi-million dollar business that requires critical availability or such services where you've got like a 10 million DAU then surely you should put your hands on microservices. But for my apps that can host 25-100k user, my $5 VPS works just fine.
@sharkpyro93
Жыл бұрын
i wanted to do the same with a simple DO droplet as a PoC, how do you manage the deployement and managment of everything? just curious on how you handle everything inside the vps
@yagomizuma2275
Жыл бұрын
@@sharkpyro93why is Race important here?
@sharkpyro93
Жыл бұрын
@@yagomizuma2275 what?
@ARCANEmateCLAN
6 ай бұрын
My company's US branch reecently dropped AWS for their own server infrastructure and saved millions.
@PaulMisner
Жыл бұрын
Read the original article. Prime realized the same thing that a number of AWS customers realize, that the cost of networking apps in a distributed environment often are greater than the benefits of a serverless architecture. Glad you pointed out this is a YMMV situation.
@Xeonerable
Жыл бұрын
As someone who works in the IT space and has to deal with the company wanting to "go to the cloud" I completely feel this video's message in my soul.
@HarmonicaMustang
Жыл бұрын
I worked for a company that wanted to "move to the cloud" without justification for why that would be beneficial to the company goal. Two years later, the entire IT support team (including myself) left within the span of two months. Before, we had a solid network that was stable and reliable. This forced migration was a nightmare to process and maintain, with maybe a single benefit out of a hundred downsides. Some things belong in the cloud, some should stay on-prem where they belong.
@willrandship
Жыл бұрын
When used appropriately, I have personally seen lambda save hundred of dollars per month and hundreds of man-hours of time (a much bigger savings) in a small business context. I don't understand why, when you have a single entry point, or even a set of entry points, the entire service set is not loaded onto a single AWS instance. Even if it remains network-based, loopback communication is basically just DMA with a few extra steps. This would be doable with the current infrastructure if, instead of the lambda being configured as a pile of microservices interconnecting, you made a single "macro-microservice" that can perform the required task. (Having a single entry point implies that a single task is being performed). That does mean avoiding that tidy "service graph" interface they're using, though. Bonus points if you can write it entirely as a single lambda function, with libraries instead of other services. That gets you as many instances as are required to handle request throughput, but with low inter-service latency per request. This would still scale horizontally so long as the initial vertical service was sufficient to perform the task within the time constraints imposed by lambda. As long as the task is truly parallelizable, moving to a totally monolithic architecture seems like too much movement in the other direction unless you are continually processing mountains of data. Granted, that's what amazon video was doing here, so monolithic probably is the sensible option in their case. Microservices are great when you have sparse requests that each need low latency, but terrible if you have a near-continuous stream of requests, even if the latency requirements are still tight.
@owenneilb
Жыл бұрын
I really appreciate that this was a balanced covering of the topic with some depth, rather than a blatant panic piece or reactionary nonsense.
@NewsBytesOnYouTube
Жыл бұрын
Two things. First, the new architecture is still horizontally scalable if they simply distribute the workload on a per-video basis, allowing each instance of the service to analyse an entire video. The old model appears to have worked by distributing an individual video to many services. Now they can still have multiple services but must give a whole video to each one. Secondly, the premis, that serverless is a mistake because of the high costs of data transfers, is only true in the case where you have a lot of data to transfer. There are plenty of systems where the data transfer happens in any model and so serverless wouldn't necessarily be any more expensive than any other model. And, there are plenty of apps where each item of data must be processed in parallel in multiple different ways, asynchronously, and again serverless may still be ideal for that. Finally, there are apps that simply won't fit in an architecture that isn't fully distributed -- won't fit in a monolith. I've worked in systems where the data and CPU requirements are so high that the only approach is to distribute the work to a large number of processing nodes. Having said all that, I'm still not a fan of serverless. I much prefer kubernetes based architectures, due to the standardisation and flexibility of the platform, and the way it guides you towards true platform thinking.
@Abdega
Жыл бұрын
1:40 “What Are you doing Step Function?”
@robertmortimer4837
Жыл бұрын
This is a misrepresentation of the article. The cost was that they were putting large files in S3 between the Lambdas. The movement and storage of large files between operations was the issue
@shivsticker9680
2 ай бұрын
All serverless is is who is responsible for the operating system part of the server. In serverless, you manage your code and it gets run as a job by a server managed by AWS in the backend. Sounds like Amazon found a use-case where a distributed micro-service design, added too much cost for the inter-microservice communication. Their redesign makes complete sense, no need to store the temp files. This will also speed up the service processing because the files are closer. That doesn't mean that Amazon is saying Serverless or microservices are bad ideas in general. Microservice design is less cost efficient and is probably slower than a monolith service, but the main benefit comes from manageability of the code and components. The parts of the service are decoupled and can be replaced/changed easily without affecting the rest of the system, so long as the input/output into the microservice doesn't need to change. There are a lot of factors that drive the micro-service vs. monolith decision. There isn't a one size fits all here imo.
@username7763
5 ай бұрын
I've seen a lot of large systems where the majority of what it did was communication. This resulted in creating new services to address performance issues which also increased communication. Sometimes you need distributed systems so this communication overhead is required. But the problem is all the projects where they embrace making it as distributed as possible. So the software balloons where all it does is communication and there just a tiny bit of logic in a few places that actually does things. Understand the performance needs of your application. What kind of CPU overhead does it actually need? Once you understand that, you have a chance at figuring out scalability.
@EricLS
7 ай бұрын
I’m over here looking at my little baby MECM implementation that was essentially brought to its knees by millions of 2-3KB files because there is a 75ms latency in our design, causing each file to take seconds to transfer, while big files transfer lightning fast. The whole “do everything in little boxes” idea causing shitloads of overhead just makes intuitive sense.
@pif5023
Жыл бұрын
So we are back to PHP and Apache but with JS and Node. I can’t imagine a JS monolith. It makes me shiver.
@bandito241
6 ай бұрын
“There are no solutions only tradeoffs.” Talk about something I learned the hard way lol.
@acasualviewer5861
Жыл бұрын
A basic thing you learn in Parallel and Distributed programming is that network latency is often that LARGEST factor in performance lag. So breaking up your services too much means that you will have to pay more network penalty, and often you'll find your system is more expensive to scale. Also, it's far more expensive to manage while spread all over all those servers.
@aaandrade5
Жыл бұрын
I thought it was the Database
@acasualviewer5861
9 ай бұрын
@@MikeDonaldson-eh2ru If you think "sub-millisecond" is fast then you don't understand what is involved in high performance computing. It takes nanoseconds to call a function in-proc. Why would I wait 1000x longer to call a remote procedure? Note that beyond that latency you have to add marshalling/unmarshalling time. This is parallel programming 101.
@DanielTabuenca
Жыл бұрын
What's funny about the whole thing, is that they didn't have microservices before, and they didn't create a monolith afterwards. This is like me saying "I will create a microservice by starting a step function for every html tag I need to render on my e-commerce site, then render each tag separately into an s3 bucket, then use another step function to combine all the tags and use a web socket to push the results to the browser". Then I'm going to write a blog about how serverless sucks and we didn't expect this to cost this much? The rest of us are saying to ourselves "what the hell were they thinking?". This whole situation is really embarrasing for AWS.
@vintprox
Жыл бұрын
I had a nagging suspicion that there'll be serialization/deserealization bloat in production.
@damnoish
Жыл бұрын
How out of context do you want the cover image to be? Fireship: YES
@nixonkutz3018
Жыл бұрын
Love the lightning pace of the narrative and hilarious graphic content! It's like being part of an elaborate inside joke but it's pure legit tech talk
@ivanharjehausen7231
Ай бұрын
For someone just getting into JavaScript coding, this was so helpful. Thank you!
@wcuribe
Жыл бұрын
Even Amazon engineers don't understand the convoluted pricing model of AWS. Costs problems of the first implementation: 1) AWS Step Functions charges users per state transition. 2) The high number of Tier-1 calls to the S3 bucket was expensive.
@sujaympurayil
4 ай бұрын
"Microservices and serverless components are tools that do work at high scale, but whether to use them over monolith has to be made on a case-by-case basis." - Marcin Kolny, Senior SDE - Prime Video
@vikram_saha7
Жыл бұрын
What a beautiful way to demostrate or explain the whole serverless thing which is going on in linkedin for weeks.
@TrevmiceterZ
Жыл бұрын
Love the Thomas Sowell reference!
@teekay_1
Жыл бұрын
Actually what the finding was that for streaming video (which has unique requirements) serverless turned out to be more expensive. To expand that to every use case is just silly. Serverless for many (if not most) architectures is better, faster, and has less administrative overhead. Now I will say that Lambdas are almost always misused by programmers who aren't smart enough to understand that when you use more than one Lambdas in an architecture you must ensure that the architecture is deterministic, and you need to model it correctly to ensure you understand the implications of these design choices. For example, one anti-pattern that I see with Lambdas all the time is programmers using a Lambda to kick off another process blissfully unaware that the process works in the context of the Lambda, not in a separate context, often with failures that they don't understand and can be hard to debug unless you know that little fact.
@appsky7982
Жыл бұрын
Batch processing will be always more computer efficient than stream processing. But the latter one will be closer to real-time. It's also posible to design a batch processing flow using microservices, but it depends on the problem.
@radiok2ua
Жыл бұрын
So in other words, there's an optimal architecture for each workload. Shocking.
Пікірлер: 2 М.