We don't program the boards in C#, just the services/Silverlight. The communication methods between the boards is well abstracted - most of our devices are reac

We don't program the boards in C#, just the services/Silverlight. The communication methods between the boards is well abstracted - most of our devices are reached via phone number. They have a SIM card with a carrier and services essentially make a phone call to get the data. There's a lot to do with communication protocols (i.e. bytes 0-8 are the configuration, 9-12 readings, etc.) but .NET has nice support for binary constructs. Some RTUs are difficult to work with because they have conversations with our server, and the lifetime of that call must be maintained while a million other things are going on. I wasn't here when the C# decision was made, but it's worked out really well for us so far, Silverlight notwithstanding. Microservices work out really well for us too because there's a lot of code written for specific RTUs which will not (and should not) be shared, and having them explicitly separated keeps everything tidy. Microservices communicate via a centralized publisher using WCF, which uses MSMQ as the underlying transport method. Our #1 priority is to never loose data so these technologies are a pretty safe bet. Like I mentioned before, C# has good support for low-level stuff, but we don't do as much low-level as you think. Our greatest challenge is handling several distinct protocols with as much as the same code path as possible, and C# has really great generics support which makes our lives easy. We don't require the performance a C++ platform would bring. To elaborate a bit more, our basic control flow goes something like: Poll unit -> get data -> push data -> translate data -> assign data to business objects -> operate on data -> present data Each step usually involves a save to the database of critical info at that stage.