Many of the learnings here are immediately applicable for designing large-scale, interactive desktop applications. Instead of services we have components inside a single process, communicating with each other, instead of huge, distributed database there's persistent/volatile/ui program state owned and shared by multiple components. But the principles presented in this talk work equally well.
even I do think the given direction in the talk is the way to go, I do not think it has anything simple, for any non trivial use case. For example, implementing idempotency is not simple and implementations can be quite fragile. another example is the transaction context: a simple concept as the set of local variables (normally managed by the compiler or runtime automatically) are now messages handled by the developer and if consistency is required by the problem... event driven solutions can become nightmares thanks for the talk
I really like the description of the tech progression for ebay and amazon. I do miss some context, though. Next time, can you add data like: - company revenue at the time of refactor - developer team size at the time of refactor - client volume at the time of refactor - world reach at the time of refactor
Unfortunately, I don't feel the content of this talk addresses 'simplicity' very well. Basically, it's a quick overview of a greater number of architectural ideas. However, if you do not know them, you will not understand them from this talk. If you do already know them, there is not much to learn for you either.
Thanks for the presentation. However, things like Idempotency and Undo Saga are not exactly simple things, IMO. Would love to hear you, elaborating on these aspects in one of your future presentations/articles!
23:45 - 5% on writing you say, and 75% on reading* - no way! I don't believe you! It can't be true! Writing takes 99% of the time so let's improve it. Let's invent new languages, with even more compact, non-self-explanatory and non-intuitive syntaxes or skip writing a valuable comment...writing speed is what matters, nobody needs to understand the code fast... Sarcasm :) *reading - I prefer "understanding" word here
Interestingly, Amazon Prime Video migrated from microservice architecture to monolithic architecture. The issue was that passing video data between microservices generated too much I/O. The monolithic architecture would hold the video data in memory. They can still scale by running multiple instances of the monolithic application.
This is such a frustrating fable to see repeated. The team migrated from step functions to containers, but they still had exactly the same microservices architecture. They _said_ this was a monolith, only because they apparently had absolutely no idea what that word means.
@@andsnpl Sure, that's true from a coding and development perspective. However, from a server perspective, you're working with a monolithic application. Your deployments are whole-application, your scaling is not hyper-granular, and your ability to use serverless is weakened. At that point, half of the purported benefits of microservices are gone. Mind you, half of the downsides are gone, too.
That was a really bad microservice architecture if it was multiple processing huge streams of data. Can't blame the microservice architecture, part of it should have been a macroservice.
Here you are talking about wrong design ruclips.net/video/oejXFgvAwTA/видео.html , because with decoupling also exist cohesion , distributed transaction between a different databases -owned by different teams or organizations . Difficulty of distributed transactions coming just wrong design of the system
Many of the learnings here are immediately applicable for designing large-scale, interactive desktop applications. Instead of services we have components inside a single process, communicating with each other, instead of huge, distributed database there's persistent/volatile/ui program state owned and shared by multiple components. But the principles presented in this talk work equally well.
WOW!! Software artitecture for large scale simplified.
Fantastic talk, thank you
Great talk!
even I do think the given direction in the talk is the way to go, I do not think it has anything simple, for any non trivial use case.
For example, implementing idempotency is not simple and implementations can be quite fragile.
another example is the transaction context: a simple concept as the set of local variables (normally managed by the compiler or runtime automatically) are now messages handled by the developer
and if consistency is required by the problem... event driven solutions can become nightmares
thanks for the talk
I really like the description of the tech progression for ebay and amazon.
I do miss some context, though.
Next time, can you add data like:
- company revenue at the time of refactor
- developer team size at the time of refactor
- client volume at the time of refactor
- world reach at the time of refactor
Unfortunately, I don't feel the content of this talk addresses 'simplicity' very well.
Basically, it's a quick overview of a greater number of architectural ideas.
However, if you do not know them, you will not understand them from this talk. If you do already know them, there is not much to learn for you either.
Thanks for the presentation. However, things like Idempotency and Undo Saga are not exactly simple things, IMO. Would love to hear you, elaborating on these aspects in one of your future presentations/articles!
22:00
Quite abstract and not applicable in real life. Just some more or less interesting anecdotes from speaker's jobs.
23:45 - 5% on writing you say, and 75% on reading* - no way! I don't believe you! It can't be true!
Writing takes 99% of the time so let's improve it.
Let's invent new languages, with even more compact, non-self-explanatory and non-intuitive syntaxes or skip writing a valuable comment...writing speed is what matters, nobody needs to understand the code fast...
Sarcasm :)
*reading - I prefer "understanding" word here
Interestingly, Amazon Prime Video migrated from microservice architecture to monolithic architecture. The issue was that passing video data between microservices generated too much I/O. The monolithic architecture would hold the video data in memory. They can still scale by running multiple instances of the monolithic application.
This is such a frustrating fable to see repeated. The team migrated from step functions to containers, but they still had exactly the same microservices architecture. They _said_ this was a monolith, only because they apparently had absolutely no idea what that word means.
@@andsnpl Sure, that's true from a coding and development perspective. However, from a server perspective, you're working with a monolithic application. Your deployments are whole-application, your scaling is not hyper-granular, and your ability to use serverless is weakened. At that point, half of the purported benefits of microservices are gone. Mind you, half of the downsides are gone, too.
That was a really bad microservice architecture if it was multiple processing huge streams of data.
Can't blame the microservice architecture, part of it should have been a macroservice.
@@andsnpl Press X to doubt. No way that an entire department doesn't know the proper terminology when referring to a monolith.
@@andsnpl it 's a spectrum not binary I guess
Here you are talking about wrong design ruclips.net/video/oejXFgvAwTA/видео.html , because with decoupling also exist cohesion , distributed transaction between a different databases -owned by different teams or organizations . Difficulty of distributed transactions coming just wrong design of the system
It's NOT unreasonable to expect simplicity to be effective...
It's rather unreasonable not to expect that.
Where have we as an industry gotten :DD
Indeed. Good old KISS engineering principle
❌ The Unreasonable (Effectiveness of Simplicity)
✔ The (Unreasonable Effectiveness) of Simplicity
Pity that the last question obviously wasn't properly understood by the speaker.
@coninuousdelivery has recently released great video addressing the 2nd question ruclips.net/video/Fh8CqZtghQw/видео.html
What was missed? It kinda answer the question for me. Or I might miss understood the question as well...
@@cinoss5 She asked about cross-system testing (very good question), while his answer was repeating that it's easy to test those pieces in isolation.
@@elixirfunintegration testing is difficult
@@KManAbout Would it have beeen the answer then? :) Yeah, sure it is.
Great talk ❤