Microsoft Orleans-My first podcast interview!

I was recently interviewed by GaProgMan for his show “The .NET Core Podcast”!

Episode 21 - Orleans with Russell Hammett

Microsoft Orleans — My first podcast interview!

Lately, I’ve been trying to blog more. In the past, I’ve blogged off and on, but I’ve had a *bit* more success with it lately; I’m hoping I can keep it up! My employer Huntington Ingalls Industries (formerly G2 Inc.) has had me on an awesome project for the past 2 years — a project where I need to learn more every day, and reinforce the knowledge I already have. Basically, I’m trying to say is I’m lucky to be working for a company that appreciates growth!

GaProgMan approached me (at least I think he approached me?) about the possibility of doing a podcast interview on Orleans; as he knew I at least had some cursory experience in it due to the blog posts I’ve written. After clearing it with the powers that be (my managers and NIST) — we scheduled the interview!

I wasn’t sure how much we would actually talk about the project in the interview, but I wanted to get it cleared either way. That episode has now been released and is available for your listening pleasure!

Doing a podcast was pretty scary for me, being a pretty socially anxious person. I’ve been trying to put myself out there more lately — with the blog posts, the game streaming, and the small amount of mentoring. I’d like to do more, maybe start teaching and/or twitch code streaming, to get me even more out of my comfort zone, and to work on that “muscle”; if that’s a thing that exists.

Since Jamie and I touched on the project I’m on, but not especially deeply, thought I’d cover a bit more of that here. I work on a project with NIST called the Automated Cryptographic Validation Protocol (ACVP):

usnistgov/ACVP

In this project, we are working to create an API that will allow for the testing of your cryptographic algorithm implementations. Having your hardware/software/firmware used within the government requires this sort of validation (among others).

Since the beginning of the project, we knew that the “distribution” of our crypto calls to a cluster of compute would eventually be needed; as we expected to have to run hundreds to thousands of crypto calls for each validated algorithm. This had been researched for a while, and after proofs of concept around implementation and ease of administration, etc., we decided on giving Microsoft Orleans a shot. Orleans did not *exactly* fit our use case, as in the documentation it was stated that Microsoft Orleans was intended to be used for asynchronous code. Through research, blog posts in my own time, trial, and error, we have seemingly, successfully, implemented Orleans into our project.

So you can obviously find out more about Orleans through the series of posts I’ve done on the subject (among all the other resources out there), but just to elaborate a bit on what we’re doing with Orleans (as I haven’t specifically written about that):

• Each algorithm we’re testing can have anywhere from hundreds to thousands of potentially varying cryptographic invocations. Many of these invocations are occurring in tight loops.
• Each algorithm was created using synchronous code, but Orleans expects asynchronous.
• We’ve implemented each algorithm as its own grain, that uses an observer pattern to subscribe/unsubscribe to the grain for dispatching and receiving the “answers” to the crypto operation.
• Since Orleans expects everything to be asynchronous, we had to get around that is by utilizing asynchronous “entry” into our grains, which then immediately dispatches the actual CPU intensive work onto its own task scheduler and immediately yielding back to the caller.
• The task scheduler being used is one that only allows for a limited set of concurrency — the intention is to never let the CPU get fully “engaged” to leave some room for the asynchronous Orleans task runner to always have “room” to acknowledge incoming work.
• Through Orleans, we can spin up or down additional nodes in the cluster for additional compute power whenever needed.

That is the very basics of how we’re using Orleans, a (very) early proof of concept of what we were trying to accomplish with the separate scheduler can be found here:

Question/Sample Request: Long running function execution via Orleans · Issue #4826 · dotnet/orleans

Anyway, please listen to the episode yourselves! We are using Orleans in a very specific, non standard way, so I’m really hoping I didn’t screw anything up too badly! Jamie and I talk a bit about the project I’m working on with HII and NIST, and a whole lot about Orleans and tea!

Spoiler warning: My voice is a LOT nerdier sounding than I think it is :P

Related:

• The podcast episode on the .NET Core Podcast with Jamie Taylor
• Huntington Ingalls Industries
• Getting Started with Microsoft Orleans
• Microsoft Orleans — Reusing Grains and Grain State
• Using polymorphism to update Orleans Project to be ready for new Orleans Examples!
• Microsoft Orleans — Reporting Dashboard
• Microsoft Orleans — Code Generation Issue
• Microsoft Orleans — Dependency Injection
• Microsoft Orleans — Reminders and Grains Calling Grains
• Microsoft Orleans — Easily switching between “development” and “production” configurations.
• Microsoft Orleans — Observables
• Microsoft Orleans — Dashboard Update-CPU/Memory Stats