Roundup #62: ConfigureAwait, System.Threading.Channels, New Executive Director of .NET Foundation, Event Driven Collaboration, What You Need to Know About Open Source

Here are the things that caught my eye recently in .NET.  I’d love to hear what you found most interesting this week.  Let me know in the comments or on Twitter.

ConfigureAwait FAQ

.NET added async/await to the languages and libraries over seven years ago. In that time, it’s caught on like wildfire, not only across the .NET ecosystem, but also being replicated in a myriad of other languages and frameworks. It’s also seen a ton of improvements in .NET, in terms of additional language constructs that utilize asynchrony, APIs offering async support, and fundamental improvements in the infrastructure that makes async/await tick (in particular performance and diagnostic-enabling improvements in .NET Core).

However, one aspect of async/await that continues to draw questions is ConfigureAwait. In this post, I hope to answer many of them. I intend for this post to be both readable from start to finish as well as being a list of Frequently Asked Questions (FAQ) that can be used as future reference.

To really understand ConfigureAwait, we need to start a bit earlier…

Link: https://devblogs.microsoft.com/dotnet/configureawait-faq/

An Introduction to System.Threading.Channels

“Producer/consumer” problems are everywhere, in all facets of our lives. A line cook at a fast food restaurant, slicing tomatoes that are handed off to another cook to assemble a burger, which is handed off to a register worker to fulfill your order, which you happily gobble down. Postal drivers delivering mail all along their routes, and you either seeing a truck arrive and going out to the mailbox to retrieve your deliveries or just checking later in the day when you get home from work. An airline employee offloading suitcases from a cargo hold of a jetliner, placing them onto a conveyer belt, where they’re shuttled down to another employee who transfers bags to a van and drives them to yet another conveyer that will take them to you. And a happy engaged couple preparing to send out invites to their wedding, with one partner addressing an envelope and handing it off to the other who stuffs and licks it.

Link; https://devblogs.microsoft.com/dotnet/an-introduction-to-system-threading-channels/

Welcoming Oren Novotny as the new Executive Director of .NET Foundation

I started as .NET Foundation Executive Director in February 2017, and a lot has happened over the past nearly three years. We’ve added dozens of high quality projects and added a lot of services to support them, like automated code signing and releases. We launched a worldwide Meetup program that includes over a quarter of a million members, and supported them with hundreds of local events in our .NET Conf Local series. We’ve also ushered in substantial changes, literally years in the making, to open up membership, run an election for the board’s first elected directors, introduce a corporate sponsorship program, and lay the groundwork for the .NET Foundation to grow into its next stage. 

Link: https://www.dotnetfoundation.org/blog/2019/12/16/welcoming-oren-novotny-as-the-new-executive-director-of-net-foundation-

Event Driven Collaboration – Ian Cooper

When we move from a monolith to microservices we abandon integrating via a shared database, as each service must own its own data to allow them it to be autonomous. But now we have a new problem, our data is distributed. What happens if I need one service needs to talk to another about a shared concept such as a product, a hotel room, or an order? Does every service need to have a list of all our users? Who knows what users have permissions to the entities within the micro service? What happens if my REST endpoint needs to include data from a graph that includes other services to make it responsive? And I am not breaking the boundary of my service when all of this data leaves my service boundary in response to a request?

Naive request-based solutions result in chatty calls as each service engages with multiple other services to fulfil a request, or in large message payloads as services add all the data required to process a message to each message. Neither scale well.

In 2005, Pat Helland wrote a paper ‘Data on the Inside vs. Data on the Outside’ which answers the question by distinguishing between data a service owns and reference data that it can use. Martin Fowler named the resulting architectural style; Event Driven Collaboration. This style is significant because it shifts the pattern from request to receiver-driven flow control.

In this presentation we will explain how events help us integrate our service architectures. We’ll provide examples in C#, Python and Go as well as using RMQ and Kafka.

Link: https://www.youtube.com/watch?v=PreAnSofAsA

What You Need to Know About Open Source – Trust Me, I’m a Lawyer – Jeff Strauss

eff is a software developer, an entrepreneur, and an attorney. As a consultant at WWT Asynchrony Labs, with unique experiences that combine technology and law, he maintains a passion for solving problems with inspired solutions, improving life through technology. A dedicated member of the developer community, Jeff travels internationally to speak on both technical and business-oriented topics. He is a Microsoft MVP and enjoys serving on the board of directors for the Kansas City Developer Conference.

Link: https://www.youtube.com/watch?v=k6kpS7q869Y

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Roundup #61: .NET Core 3.1, AWS CDK, JetBrains Space, How Buildings Learn

Here are the things that caught my eye recently in .NET.  I’d love to hear what you found most interesting this week.  Let me know in the comments or on Twitter.

Announcing .NET Core 3.1

We’re excited to announce the release of .NET Core 3.1. It’s really just a small set of fixes and refinements over .NET Core 3.0, which we released just over two months ago. The most important feature is that .NET Core 3.1 is an long-term supported (LTS) release and will be supported for three years. As we’ve done in the past, we wanted to take our time before releasing the next LTS release. The extra two months (after .NET Core 3.0) allowed us to select and implement the right set of improvements over what was already a very stable base. .NET Core 3.1 is now ready to be used wherever your imagination or business need takes it.

Link: https://devblogs.microsoft.com/dotnet/announcing-net-core-3-1/

AWS Cloud Development Kit (CDK) – Java and .NET are Now Generally Available

Today, we are happy to announce that Java and .NET support inside the AWS Cloud Development Kit (CDK) is now generally available. The AWS CDK is an open-source software development framework to model and provision your cloud application resources through AWS CloudFormationAWS CDK also offers support for TypeScript and Python.

Link: https://aws.amazon.com/blogs/aws/aws-cloud-development-kit-cdk-java-and-net-are-now-generally-available/

JetBrains: Welcome to Space!

Today at KotlinConf, we announced our brand new product Space, and we have already opened the Early Access Program.

Space is an integrated team environment that provides teams and organizations with the tools they need to collaborate effectively and efficiently. It has Git-based Version Control, Code Review, Automation (CI/CD) based on Kotlin Scripting, Package Repositories, Planning tools, Issue Tracker, Chats, Blogs, Meetings, and Team Directory, among other features.

Link: https://blog.jetbrains.com/blog/2019/12/05/welcome-to-space/

How Buildings Learn

Link: https://www.youtube.com/watch?v=AvEqfg2sIH0

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Message Properties

Message Properties

Over the years I’ve learned various aspects of messaging either through using various products, reading other blogs, or unfortunately in a lot of cases, discovering them myself. One of those aspects is is message properties.

Specifically, (meta) data that you might want to include in your messages to solve some common problems.

My plan is to dive deeper with implementation examples for each topic listed in this post. Hopefully, this post can serve as a reference point to your adventures in messaging or possibly gain some insight that provides a solution for a pain point you may (already) be experiencing.

I was inspired to write this post after seeing this tweet:

Type/Name

The naming of messages is incredibly important for a variety of reasons. When talking about events, it’s important to name them in the past tense because it conveys that they are statements of fact.

Most often the name of an event is used to determine how to deserialize into a specific type. Where I’ve personally run into problems, in .NET specifically, is using the CLR type name as the event name to determine how to deserialize. The issue with this is you’re very likely to change the name of your CLR type.

Prefer to having a static name for an event and not using the CLR type name at runtime to create the event name.

More info on naming can be found in my post Message Naming Guidelines

Message Version

Most often when needing to version a message is to simply create a new type/name. With events, I think this approach works fairly well when you discover a better way to describe the event and along with it the data to expose.

When a new event isn’t required, but rather a slight change in data is to specify the version in the message. Consuming clients can use the message name along with the version to determine how to process the body of the message.

Message ID

A unique identifier of a message. This can be used for idempotency and concurrency. Message Handlerscan keep track of which messages IDs they have processed and determine if they should act upon receiving a message.

This is important because message handlers should be reentrant and messages can be delivered more than once.

Correlation ID

A unique identifier that allows you to reference the flow of events (event chain) or a transaction. Also, often called a Trace ID. Assigning a correlation ID as soon as possible and any message handler that receives a message with a correlation ID then uses that same ID for any messages it outputs.

This is very useful for logging and error handling in asynchronous and distributed environments.

Contract Owner

Who owns the message contract can be important. Depending on how messages are distributed, there may be many messages from various owners. Knowing who owns a message contract is helpful for troubleshooting as well as how to handle that message.

An OrderPlaced event seems like it could be unique across all services, however, in a distribution domain, is that a Sales OrderPlaced from the Sales service or a Purch OrderPlaced from the purchasing service?

Having the owner of the message provides the ability to distinguish how to handle the message when the name alone doesn’t provide enough distinction.

UTC Timestamp

This seems obvious but it gives more context to when the message was created. A useful is keeping track of latency between a message being created to how long it’s taking a given service to process it.

Sender

Who originated the message. Not the service, but rather the user. This could be an access token that is then used to determine if the sender has the correct permissions or is authorized to perform the given request.

Resource/Entity Version

The version of the resource/entity that you are performing an action on. Similar to the message ID this can be used for concurrency. A wonderful example of this is Azure Cosmos DB which uses an ETag as the resource version which is then used with an If-None-Match header for optimistic concurrency. If you’re using Cosmos DB check out my post on Optimistic Concurrency in Azure Cosmos DB

Message Properties

I’ll be going in-depth in each of the above topics with code examples for the actual implementation of how you would use these message properties. Stay tuned.

If you’d like to add to the list, let me know in the comments or on Twitter.

Related

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.