Change MSMQ to RabbitMQ
alexeyzimarev opened this issue · 18 comments
MSMQ only works on Windows and I seriously doubt most people will use it in production anyway. I would suggest using RabbitMQ instead and include instructions to get/run it in a Docker container, since this would simplify the setup and will allow using macOS and Linux for the workshop.
@alexeyzimarev thanks for raising this. It's an interesting proposition. One thing that we have to bear in mind is that we still want to support the use of VS 2015 for now, which means we have to stick to the old-style verbose csproj format for now, which AFAIK cannot be used in an IDE on non-Windows OS's (correct me if I'm wrong?). Having said that, we would like to move to the new SDK-style csproj ASAP, and we'll be keeping a close eye on the requirement to keep supporting VS 2015, to see when we can drop it.
Rider and MonoDevelop (which also means VS for Mac, but I have not tested) supports any type of csproj file. Full framework projects also run fine on Mono. VS 2015 by the way supports new csproj files with Update 3.
But even with the old format, which is in fact, #182, using RabbitMQ will at least enable people to run Mono apps. MSMQ is the biggest issue (among with the mammoth of SQL Server).
I'd rather then change to the Learning Transport, which would then rule out using the platform tools like ServiceControl. So not ideal either.
I'm no expert on Docker, but afaik it needs hyper-v on Windows and that means Windows Home won't work. That would mean Windows attendees would have an additional prerequisite to run Windows Pro at the least. Also not ideal.
It is indeed an interesting proposition, but I'm not sure it's as easy as it sounds?
May be not, but I don't know the Learning Transport. I know that RMQ can provide great insights about exchanges and queues, which is very useful for learning how things work.
Speaking from experience - I have done the MassTransit three-hours workshop three times. Never had a single person running Windows Home. It is a question of priorities. I'd rather support the growing number of people using non-Windows environments, than a hypothetical Windows Home user.
I'd rather avoid the use of Mono for the workshop exercises. NServiceBus is neither tested nor officially supported on Mono and it would come at the risk of causing us a lot of overhead during the workshop. As long as we want to support VS 2015 then we cannot switch to .NET Core, which mean Windows is also going to remain a prerequisite until then. When we decide to drop support for VS 2015 then we can revisit this issue.
Ok, even if you rule out Mono, VS 2015 Update Whatever supports .NET Core. I would still change MSMQ to RMQ, this does not require any changes in project structure or platform.
As far as I can remember VS2015 supports only .NET Core 1.x
We are discussing #182 actually, not this issue :) I closed it.
I'd rather go with the learning transport, that implies zero friction and is fully F5 compliant.
I remember we discussed dropping MSMQ in favor of the learning transport (or any other brokered transport for the sake of the discussion) before, IIRC the reason why MSMQ was left in place is due to the routing configuration when it comes to events.
Given that with MSMQ subscriptions are message driven they require an explicit routing configuration. By moving to a brokered transport with native support for pub/sub we realized that the transition for users that want to use MSMQ (and we have many) would have been much harder.
I'm not opposed to this change, probably it's enough to point to the documentation we have.
I thought we didn't move to LearningTransport because of ServiceControl?
That can be solved by a transport adapter, but when we discussed MSMQ/Brokered we weren't discussing ServiceControl yet. Anyway The monitoring experience is a blocker for the learning transport.
Once we can support containers a docker-compose file will solve all this pain and we can configure solutions to just deploy a Rabbit container along with endpoints.
I'm not a big fan of the learning transport for this, because it feels a lot more "real" when you're using an actual transport. In the last few classes, I've just demoed RabbitMQ transport because it's good to have a contrast of broker-based transports.
Given that people often come in with corporate laptops, is Docker a reasonable pre-requisite?
Well, say, either Docker and RMQ image, or RMQ installed. They need to develop somehow.
I'm not a big fan of the learning transport for this, because it feels a lot more "real" when you're using an actual transport.
I'm not sure I agree, because we promote workshop is technology agnostic. Besides that we abstract away both the learning transport, rabbitmq and any other. I know there are differences, but if you don't look at configuration and just focus on sending, publishing and processing messages and the concepts behind the workshop, why would any other transport make a difference?
Besides the fact that I see a lot of people struggle setting up Docker on Windows, including myself. It took me quite a while before I had it running. And searching the internet for solutions, I wasn't the only one having issues. It could result in people not being able to do the exercises because they don't have Docker installed.
The audience, when I ask, mainly looks to use brokers.
I think this is the key. This is why I opened this issue. Azure ServiceBus, Windows ServiceBus and RMQ are the main candidates for most people anyway. MSMQ and SQL Server are important for NServiceBus but it is becoming marginal.
The slides only cover MSMQ
You are certainly right about that. That's an easier decision to make, to do something about the slides to not focus on MSMQ so much.