Synchronous vs Asynchronous Programming

Рет қаралды 25,970

Күн бұрын

We all learn to program by learning synchronous programming first. We call a function, and our code stops and doesn't do the next thing until we receive a response. The trouble is that as soon as our systems get even a little more complex than that, this complexity explodes. In large-scale, high-volume, distributed systems synchronous programming doesn't work very well.
In this episode Dave Farley, author of "Continuous Delivery" and "Modern Software Engineering", explores synchronous vs asynchronous programming. Dave explores the idea that async is the simpler, maybe more fundamental, idea, and looks at a few examples that suggest that at least for distributed systems asynchrony is faster, more reliable, and surprisingly, easier.
-----------------------------------------------------------------------------------
⭐ PATREON:
Join the Continuous Delivery community and access extra perks & content!
JOIN HERE ➡️ bit.ly/Continu...
-------------------------------------------------------------------------------------
🚨 FREE TDD COURSE AVAILABLE NOW! 🚨
Practice your TDD with a FREE hands-on tutorial where you can work along with me using an excellent practice tool. Sign up for your test driven development tutorial HERE ➡ courses.cd.tra...
📧 Get a FREE "TDD Top Tips" guide by Dave Farley when you join our 📧 CD MAIL LIST 📧
The best way to keep in touch with the latest discussions, events and new training courses, get FREE guides and exclusive offers. ➡️ www.subscribep...
-------------------------------------------------------------------------------------
👕 T-SHIRTS:
A fan of the T-shirts I wear in my videos? Grab your own, at reduced prices EXCLUSIVE TO CONTINUOUS DELIVERY FOLLOWERS! Get money off the already reasonably priced t-shirts!
🔗 Check out their collection HERE: bit.ly/3vTkWy3
🚨 DON'T FORGET TO USE THIS DISCOUNT CODE: ContinuousDelivery
-----------------------------------------------------------------------------------
🖇 LINKS:
🔗 The Reactive Manifesto ➡️ www.reactivema...
🔗 Martin Fowler's Article on the LMAX Architecture ➡️ martinfowler.c...
🔗 LMAX Disruptor ➡️ lmax-exchange....
-------------------------------------------------------------------------------------
CHANNEL SPONSORS:
Equal Experts is a product software development consultancy with a network of over 1,000 experienced technology consultants globally. They increase the pace of innovation by using modern software engineering practices that embrace Continuous Delivery, Security, and Operability from the outset ➡️ bit.ly/3ASy8n0
Roost, An Ephemeral DevOps Platform, automates your DevOps pipeline. It creates ephemeral DevOps environments on-demand or based on pull requests. Roost reduces DevOps complexities and shortens release cycles with fewer engineers. ➡️ bit.ly/CD2Roost
Tricentis is an AI-powered platform helping you to deliver digital innovation faster and with less risk by providing a fundamentally better approach to test automation. Discover the power of continuous testing with Tricentis. ➡️ bit.ly/Tricent...
TransFICC provides low-latency connectivity, automated trading workflows and e-trading systems for Fixed Income and Derivatives. TransFICC resolves the issue of market fragmentation by providing banks and asset managers with a unified low-latency, robust and scalable API, which provides connectivity to multiple trading venues while supporting numerous complex workflows across asset classes such as Rates and Credit Bonds, Repos, Mortgage-Backed Securities and Interest Rate Swaps ➡️ transficc.com
LaunchDarkly is a first-of-its-kind scalable feature management platform that allows development teams to innovate faster by transforming how software is delivered to customers. We want to show you what we're all about. Book a demo to see our platform in action! ➡️ tinyurl.com/CD...

Пікірлер: 104

@ContinuousDelivery Жыл бұрын

Set up your team for success. This FREE GUIDE is a great resource for team leads or business leaders managing technical teams and are looking for advice from me in a convenient, short-form handbook. Available to download NOW ➡ www.subscribepage.com/organise-teams-guide

@edgeofsanitysevensix Жыл бұрын

So at work, before I was involved in the project, a team decided they would use SignalR and Service Bus as a async mechanism to do simple CRUD operations between the UI and the back end services. This was designed, they claim, to provide async functionality. Under stress testing it failed miserably and the implementation forced a synchronous wait anyway via the means of waiting for a SignalR hub response before sending the resoponse back to the UI. It was in my opinion nonsense, as it negated many of the benefits of asynchronous systems and also overkill for the situation. The intent was scalability. But to be honest, it was a symptom of pre-optimisation and YAGNI when a simple synchronous REST API would have worked and scaled just as well, especially if it was containerised. Async is an attractive proposition, but so many misunderstand it and come up with crazy implementations. When starting simple, it can be easier to spot where issues lie and where a different approach is required. Thanks for the video. It was interesting.

@dhwang101 Жыл бұрын

🤣 I've been doing async programming since I started working over 20 years ago. It takes learning and practice. What many people don't know or do is non-blocking event handler.

@darshandhabale143 Жыл бұрын

I thought event driven architecture could only be applied for server to server communication, I didn't realise that ui to server could be event driven sounds weird really, because in a usual human computer interface, we make our user wait for the response and give confirmation after the action is resolved

@filker0 Жыл бұрын

I've been designing and developing asynchronous software since the early 1980s, though that may be because I got my start working on asynchronous serial communications in terminal devices. When I design anything that communicates with users or other programs/systems, I always start with an asynchronous model. Even given the concurrency concerns that go into the design of the data structures, the application code is usually far simpler and less prone to performance problems. I have several war-stories about this sort of thing that I'd love to describe, but this is not the time or place for that sort of thing.

@coryserratore5951 Жыл бұрын

Anyone working in the telecommunication domain is likely aware of the concept via the Erlang/OTP platform, based on the actor model. Same concept Dave describes: message-oriented communication between single-threaded actors. Great for high concurrent, high contention scenarios.

@cchinaka Жыл бұрын

This is the best explanation of asynchronous programming ever ❤🎉

@Ownermode Жыл бұрын

Well presented episode. I really felt your enthusiasm about this subject.

@coryserratore5951 Жыл бұрын

This discussion all touches on why the Actor Model (from the early 70s) is making a renaissance in the context of large scale distributed microservice systems. Message and queue-based single-threaded actors within a bounded context. Event-driven choreography between contexts.

@coryserratore5951 Жыл бұрын

Platforms such as Erlang, Akka, VLINGO Xoom are exploiting the advantages of this model.

@georgeFulgeanu Жыл бұрын

Hi Dave, I think you're doing a great job by presenting the concepts but you might be jumping maybe, MAYBE, too fast through them. For example asynchronous vs synchronous programming in a single thread which is a discussion on it's own. Then jumping immediately to asynchronous communication between systems, which is another topic and there is a place for async and there is a place for synchronous communication. And then there came the last important topic event sourcing vs event driven architecture which again wasn't explained as a separate important to understand topic. I really do enjoy you're content and I'm not saying this and I hate myself that I realise that I offered a classic feedback sandwich

@manishm9478 Жыл бұрын

Thanks for pointing this out, i was quite confused by the video but there are some great points in it!

@marcin2x4 Жыл бұрын

Yes! Been waitin' for this topic. Another awsome t-shirt! 😃

@rngesus8057 Жыл бұрын

oh i remember reading about the lmx disruptor many many years ago. before i knew anything about development. i think it was one of the moments you become a little more concious

@coderider3022 Жыл бұрын

Built my latest micro service product using web external calls and async messaging for internal / inter service comms. Performance is very good but you need a good package and clear conventions on commands etc.

@andreaszetterstrom7418 Жыл бұрын

Having such messaging queues it seems like one could even make an app that is expected to work offline for long periods of time. Just have a sufficiently large ring buffer and it'll continue to function offline as if the server doesn't want it to do anything. For an application that for example mostly takes data input from the user that should work fine. Once it gets any type of network access it'll start outputting its new data and possibly receive queued up requests from the server. All of it without the need for any special offline mode logic.

@thiagomiranda3 Жыл бұрын

Do you think async will be useless now that we have project Loom in JVM? We will be able to have the cake and eat it too. Creating multithreaded applications in a imperative style, that is easy to debug and think and also the async qualitities that make it mandatory for current systems. Async for me is just a way we figure out how to solve a hard problem of platform threads. But if this is not a problem anymore, there is no point in making your code harder to reason about and to debug. There is also this awesome article explaining why Go programmers don't have to use this shit trick (async code) to workaround platform threads being heavy weight called "What color is your function". I can't post the like here because KZfaq will delete my comment.

@disgruntledtoons Жыл бұрын

Nine times out of ten (at least), when I make a call to a service, the user can't do anything until the response is received, and if the response comes back with an error the user can't do the next step anyway. The exceptions are when the user can go do something else, in which case the call can simply spawn a background task to run a job.

@ContinuousDelivery Жыл бұрын

You can always design it a different way, and if you use async the vast majority of the time, all the time when the system is actually working, the user will get a faster response.

@DanielPaunescu Жыл бұрын

Hi Dave, great video! I was wondering if you could give your opinion about the Rx family of reactive systems, how do you see them fit into this picture?

@adambickford8720 Жыл бұрын

Most developers aren't nearly as clever as they think they are, but that doesn't stop them from making a mess of even trivial things. However, in an async world they are far less brave as the 'complexity budget' is largely spent. I've found that actually makes things easier as you're tackling essential complexity, which is researchable, vs some wannabe 'architect's layer on top of JPA (or whatever).

@therealjordiano Жыл бұрын

That was extremely informative, fantastic stuff

@andreistirbu2733 Жыл бұрын

I love this philosophy-of-technology channel! I learned a lot from your videos!

@dennislindqvist5461 Жыл бұрын

The sound of your recordings has been distorted lately :/ Could you please check your recording levels?

@draganglumac Жыл бұрын

Love the Erlang comment Dave made me chuckle 😀 Of course, one could always take the gateway drug that is Akka hahahah 😀

@Inkartnee123 Жыл бұрын

You make great content, once everyone finds your way of presenting you will grow so unbelievably fast 🎉🎉

@ContinuousDelivery Жыл бұрын

Thank you for your support!

@erikz1337 Жыл бұрын

What is your opinion on actor model of reactive programming?

@malavoy1 Жыл бұрын

This sounds like the asynchronous communications in hardware I learned in the 80's.

@ContinuousDelivery Жыл бұрын

Yes, comms is comms, HW or SW or even people, it doesn't really change the fundamentals. Async is closer to reality than sync, and so the abstractions around it leak less severely.

@rwri002 Жыл бұрын

Hi Dave, I've worked in an organization that tried (or thought it tried) to do what you describe at the end of your video, break the system down to such a degree that the call stack was all asynchronous (In that case using MQM for the messaging) it did not go well. The reasons why are too involved to fully state here but one clear one was the state of an entity (say a customer record) being changed at one point in some context and a delayed or replayed message in another context then not finding the entity in the expected state (resulting in an unrecoverable situation). Clears this can be avoided with better design. But IMHO this needs to be thought about and designed for. So I don't think it's a good idea to just try to make a sync program async without thinking carefully about this type of issue (and others). BTW could not agree more on async await, having to use it a lot in my current project, not good.

@jimhumelsine9187 Жыл бұрын

I kept thinking of Hexagonal Architecture and Event Sourcing while watching this video.

@ContinuousDelivery Жыл бұрын

Yes, that is certainly how we built the LMAX system. Implemented infrastructure to hide nearly all of the accidental complexity, and it was the async model, and the lossless transmission of data, through async events, that allowed for this. It was the nicest complex system to work on that I have seen so far.

@RicardoSilvaTripcall Жыл бұрын

It's really nice approach, but unfortunately not always feasible, working on finance, specially on loans simulations, we had do call 15 services or more, and almost all of them were dependent on the previous service response to work. Maybe a total revamp of the underlying services and business logic would be needed so they would be able to be called asynchronously ... But it is really hard not to say impossible to a huge company to undertake a massive change in their core business ...

@xybersurfer Жыл бұрын

sequentially making asynchronous calls, could still have the advantage being able to do other things while waiting. but i recognize not being able to take full advantage of asynchronous calls, because of design decision out of my control

@cod3r1337 Жыл бұрын

What makes you say the async-await abstraction is "crazy"? Because in my mind it's really just syntactic sugar to flatten callback chains und thus reduce syntactic noise. And why isn't that a good thing?

@ContinuousDelivery Жыл бұрын

I think it is yet another attempt at trying to hide the reality that the comms is async, and as usual when we try to do that, it starts to leak problems. If I make an async call that looks sync, because it is handled as an "await" callback, I have hidden the failure case. What happens if I never get a response or if the response is delayed? If I write the simple async case, it seems more obvious now to think about the problem. I send an "OrderItem" message, and I am done. So now I have some things, who's state I am, presumably tracking, I have an item that has been "Ordered", but not yet dispatched. In normal circumstances I have another message "ItemDispatched" and when I receive that message, I move my "Item" from being "Ordered" to being "Dispatched". This seems pretty natural to me, but what if I don't receive a reply in a sensible amount of time? If I did all this with async-await I almost certainly won't think of that case, but if I did the equally simple coding that I described, I might, and even if I only thought of it later, what to do is pretty obvious, look at all the "Ordered Items" and any that was ordered more that a day, an hour, or a week ago, I decided what to do - connect the customer and appologise, try and find an alternative source for the item and so on. My point is that this extra stuff seems simpler, and less technical, because it is. Because we are not trying to hide this async series of events as a sync call, the realities of the situation seem clearer and easier to spot to me.

@cod3r1337 Жыл бұрын

@@ContinuousDelivery Mechanically, async-await is absolutely the same thing as continuations on Promises/Futures/Monos or whatever your API calls them. Error handling callbacks become try-catch blocks, that's about it. The only real difference is the shape of the code, if you will. So if I understand you correctly, your criticism should apply to the Promise / Continuation style of asynchronous programming as well?

@markmitchell1290 Жыл бұрын

@@cod3r1337 I agree. It seems much more intuitive to me to have an await call with a try-catch block for any needed error handling / timeouts. It places the "What do we do about it" stuff in direct proximity to the call that was made. And there is no thread-locking, other operations can continue un-impeded. With the traditional async approach I have to create call backs, and then remember to write additional code elsewhere to track the calls and then even more code to check to see if the call back never arrived.

@BosonCollider Жыл бұрын

@@ContinuousDelivery Now I am curious about what you think about stream/CSP like concurrency like with Go's channels or Kafkas streams

@WouterStudioHD Жыл бұрын

Hey Dave, great content, but can you work on the audio quality? It's really dull sounding at the moment. Maybe a different microphone or some processing can fix this. The acoustics seem good, no excessive reverbs.

@matreyes Жыл бұрын

Great video, it remembers me why I choose Elixir. Do you have a link to the conference talk that inspired this video?. Thanks and keep sharing knowledge!

@ContinuousDelivery Жыл бұрын

Reactive systems: kzfaq.info/get/bejne/qJehlrl-0L_Wl3k.html Actor based systems: kzfaq.info/get/bejne/Y6-Kn7KByM-3nGQ.html

@AntonioPetrelli Жыл бұрын

The answer is project Loom.

@slack128 Жыл бұрын

Love that shirt!

@stuartcoyle1626 Жыл бұрын

Old Erlanger here. This is exactly why I use Erlang and Elixir.

@totobol86 Жыл бұрын

¡Gracias!

@lorddidger Жыл бұрын

It is little disappointing that your example is basically how TCP is done. It is hard to see past the trivial solution - just use sync operation over TCP.

@ContinuousDelivery Жыл бұрын

For the reasons explained in the video, this is not about the transport, it is about how the apps interact with it, do they care about the failure cases or not. It you attempt to hide the async nature of the comms, the abstraction leaks in all these complex failure scenarios.

@GnomeEU Жыл бұрын

I'm currently working with an UI framework that is constantly accessing my objects. This is a problem cuz I get constant threading exceptions that are hard to fix. Also error messages like: you can't access objects x because a different thread owns it, are not fun. In the end you have to make sure again that some objects are only accessed from one thread. Not really easier tbh.

@BitsViewer Жыл бұрын

You can try out semaphores and/or monitors , search for it’s implementation in your framework and good luck 🍀

@cod3r1337 Жыл бұрын

Sounds weird. Which UI framework is that? Every UI framework I've ever seen, and I've seen a few in nearly 20 years, is single threaded.

@georgehelyar Жыл бұрын

I don't know what you're using but generally the answer is to marshall back to the UI thread at the point where you need to interact with the UI. Use the UI thread to read anything you need from the UI, use another thread to do work, and then use the UI thread again to write back to the UI for display. This might sound a bit complicated but UI frameworks tend to make it pretty simple, and it tends to be mostly hidden from you.

@HoD999x Жыл бұрын

why has no one invented a language that looks normal but does everything asynchronously? it should be possible to transform "next line of code" into a callback parameter. the problem here isn't that my code is "syncronously written" but that it is executed that way. why doesn't the OS/JVM/whatever say that "int x = calculate()" does NOT block? the semaphore could be hidden, automatic

@sneibarg Жыл бұрын

The implementation of Python's PEP 492 did that.

@new_phone_who_dis Жыл бұрын

Isn't that simply javascript?

@DominiqueBoucher Жыл бұрын

Isn't that language Elixir?

@pwinowski Жыл бұрын

async/await syntax is just that. Introduced first to C#, now available to most modern, popular languages.

@lukeyd2000 Жыл бұрын

Kotlin's coroutines are similar to what you describe.

@luci0rullz Жыл бұрын

Thank you sir!

@orlovskyconsultinggbr2849 Жыл бұрын

This really , really important , i in my experience alway was nervous about all that concurrency nonsense, nobody was able to explain me why real time stock exchange works perfectly nobody.

@StarLord1996 Жыл бұрын

Damn that shirt is awesome!

@dmlled Жыл бұрын

Erlang, Elixir & Pony for the win

@dmlled Жыл бұрын

kzfaq.info/get/bejne/mNVliq9mrrellGQ.html

@neuro5261 Жыл бұрын

Hello. Is it possible for you to record the audio in stereo

@DodaGarcia Жыл бұрын

About async await, I do use it But in my defense, I am very ashamed of it every time

@ContinuousDelivery Жыл бұрын

🤣🤣👍

@davidcalloway9062 Жыл бұрын

So you're saying I should use Node.js?

@mrsvvmrsvv7400 Жыл бұрын

How do you see the development of implicit async programming style in the nearest future? I.e. the program code doesn't have ANY async operations at all (no async/await, send/receive, start thread etc).

@cod3r1337 Жыл бұрын

Are there any real-world examples of this concurrency style? Because it's hard to imagine. The closest thing to that in my mind are Go goroutines, which Java now kind of tries to emulate with Project Loom. But even this style requires at least *some* explicit concurrency.

@mrsvvmrsvv7400 Жыл бұрын

@@cod3r1337 Here are some: 1. Java parallel streams. There's nothing in a code about dealing with threads, gathering thread results and synchronization. Just the word "parallel". 2. Data processing of sharded relational data, e.g. Citus. The code is just plain old SQL. But it starts multiple simultaneous processes that work with data on multiple cluster nodes. 3. Similar example - map/reduce Hadoop data processing. 4. Apache Nifi - a dataflow parallelism model with a simple visual programming language.

@SohailSiadat Жыл бұрын

How do you make the background animations of your videos? They are well made. Are they made by an animator person?

@ContinuousDelivery Жыл бұрын

We have an editor who does most of the animations, and I do the more technical ones, so quite a lot of those in this episode.

@pixelslate9979 Жыл бұрын

Actors! Actors! more Actors!

@dlabor1965 Жыл бұрын

Erlang!

@joseluisvazquez5126 Жыл бұрын

Interesting! Would the send() interface return an error (eg. Can't enqueu / won't send) or would that break pure asynchronicity? Also, how would you manage a distributed data set in which you might want to quickly split or join sets managed by s single thread/ node?

@Yulrag Жыл бұрын

Asynchronous made me nervous until I got used to it.

@kwicklaunch Жыл бұрын

Synchronous - at the same time Asynchronous - at different times Concurrent - at the same time Sequential - execute each instruction in a specified order SEQ SEL ITER ALT PAR have i got that right ?

@pwinowski Жыл бұрын

Synchronous - one thing at a time, in a specific order, and nothing in between. Asynchronous - allowing other things to happen while waiting, and possibly, getting results in the different order, than requested. Concurrent and Sequential, I would agree, there are nuances (like concurrent is not necessarily parallel, and sequential might not refer to execution, but gathering results), but generally you've got those right.

@ioannischristou2362 Жыл бұрын

First of all, after 25 or more years of writing parallel/distributed systems code, I can safely say that i'm not afraid of concurrency or asynchronicity of any kind. Second, I don't think that async makes debugging easier, or that it allows for replaying a program, based on the log of the events. The most important reason is that (assuming independent clocks) you cannot order the events in the various machines, can you? next point, you said you wished software engineers were taught to write asynchronous s/w from day 1 of training. Unless one were trained as a hardware engineer, I don't think this programming paradigm would sit well with them. Finally, congratulations on your book "Modern Software Engineering"; but I have to mention, my first degree is in Electrical Engineering. I don't recall any course called "Electrical Engineering" throughout my course of study, and I believe in modern s/w engineering programs, there should be no course titled "Software Engineering". Just my 2c.

@dpersh76 Жыл бұрын

Exactly! I'm not aware of any commercial general purpose operating system that is not concurrent at its core. Async programming languages take advantage of some sort of a concurrent engine under the hood to create an illusion of asynchronous execution. Async programming model is a very useful paradigm but, for the love of all that is holy, it is not the only useful model that exists.

@thatoneuser8600 Жыл бұрын

I mean, electrical engineering and software engineering are completely different because one of them is physical and the other is digital and thus more malleable, so I don't understand why you're trying to conflate the two with each other...

@markmitchell1290 Жыл бұрын

@@thatoneuser8600 I have a degree in Electronics Engineering - so I guess it would be a hybrid of the two. I would say there are a lot more parallels then differences. You can flowchart out an electrical system very much like you can a software application.

@lucasgroves137 Жыл бұрын

@@thatoneuser8600 For one thing, his point doesn't depend on _any_ similarity in detail between different kinds of engineering; he could have made exactly the same point if he'd instead studied history: when you major in history at any respectable institution, there's no single course or self-contained text titled "History." More importantly, the idea that a difference between two things renders them "completely different" is ridiculous. That kind of "thinking" takes me back to somewhere around the 3rd grade, when we had no developed notion of what comparison even meant. Analogy and comparison as concepts that leverage discourse and insight are well on their way to extinction... just another part of The Great Dumbing Down. SAD!

@thatoneuser8600 Жыл бұрын

@@lucasgroves137 There's more differences than similarities that I didn't mention. Comparisons will NEVER be perfect, or at least hardly EVER, because of the fact that you are using two different things to compare that aren't the same. If a comparison was perfect, then it wouldn't be a comparison because you would just be comparing the same two things with each other for seemingly no reason. That's why using an analogy as a crux for your argument will never work; the opponent will use the differences in comparison against you to show you why your argument doesn't make sense, as using only a comparison to make your point often has too many holes that don't make sense. If getting rid of "The Great Dumbing Down" involves getting rid of nuanced takes that account for the differences in comparisons, then that is literally a dumbing down in of itself, and you should be ashamed for even suggesting such a backwards line of thinking.

@HoD999x Жыл бұрын

imo, async is much better as long as you are able to model it all easily with callbacks, forks and merge points. if you can't, better use sync code

@anthonysalls Жыл бұрын

While I agree that we should face the complexity of the real world and computers are inherently non concurrent, the analogies are pretty lazy. CPUs don’t queue, data that needs a CPU to be thought do. Additionally, everything is taught from basic ideas to more complex. The idea that we should start with asynchronous is ridiculous. However, I do think CS education should move on from synch. programming much earlier than late term, or worse. Certainly a minor in CS should make this reality apparent to the student.

@ContinuousDelivery Жыл бұрын

CPUs *do* queue data. Modern intel processors coordinate their work via something called a QPI bus en.wikipedia.org/wiki/Intel_QuickPath_Interconnect. That assumes that the async model *is* more complex, but it is not obvious that it is. Erlang is based on this concept, and while it is not thought of as a beginners language, I think it would be an interesting experiment to try teaching someone programming from scratch with Erlang or more likely Elixir, which is based on the same ideas.