Have you ever heard some truism or principle, immediately thought, “Exactly! It’s so simple and obvious!” then looked around at your colleagues and exchanged some knowing laughter. Maybe you even made fun of the poor bastards who didn’t get it? “Huh-huh-huh, yeah, like this guy, Durfin, he’ll NEVER GET IT!”
Well, whenever I used to hear things like “don’t use a hammer to drive screws”, “use the right tool for the job”, etc., I always reacted like that. Like a terd. Never bothering to really reflect upon whether or not my blind application of all things Microsoft was right. I am moving the other direction now and trying to really examine my assumptions about what’s necessary vs. what’s common. Instead of just being all abstract and gushy though, I’m going to be more specific and go over common assumptions that myself and others in Microsoft country have been stumbling over for quite some time now.
If You Need RPC, WCF Is Great!
In my experience, WCF is great if you enjoy spending a lot of time on high-learning-curve, low-return, frustrating, bloat-ware. I won’t revisit all the magical ways WCF can bite you, but I will say that WCF users generally fall into three groups:
1. Geniuses. These folks have no idea why anyone would complain about WCF.
2. The Frustrated. That includes people like me.
3. The clueless. These people think they’re in the first group. They’re using WCF in an over-simplistic, “look, ma, I made codez!”, demo quality applications which create more jobs for people in the first and second group when it all goes to hell.
My point is that WCF is solving a problem that doesn’t really exist outside of the Microsoft ecosystem. With the right tools, you can accomplish the same end-goal in much more simple and elegant ways:
Erlang – has the ability to communicate natively with distributed Erlang nodes built into the language itself. It’s accomplished via a trivial one liner that takes the form: <address> ! <message>. Simple. Elegant. Powerful.
AMQP and XMPP are open protocols which relate specifically to messaging. Lots of stuff use these two. Google’s Wave is built on an extension to XMPP. My favorite AMQP implementation is RabbitMQ (written in Erlang).
Take away here – WCF is overkill. It’s a jackhammer for jeweler’s screws.
If You Need To Store Something, Microsoft SQL Is King!
Microsoft SQL is a good RDMS. Hard to argue that. What are relational stores good for? Analytical processing of data. Most applications I’ve worked on actually need analytics but most of the time is spent figuring out how to make my application model save its state in a schema that’s well suited to analytics.
The NoSQL movement is good and bad. The problem is too many reactionaries (myself included) hear NoSQL and think “YAY, NO MORE RDBMS!!!” That’s actually a terrible idea for many business line applications or anything you need analytics for. If you want reporting, you’re going to find that writing reports against a document store is probably just as torturous as mapping a model to normalized tables.
Use the right tool for the right job. Use the document databases for your transactional store and use relational databases for your analytics. You can do both. (I’m not going to go into that right now). The important thing is realizing that it’s not all or nothing in one approach.
SOA Is The One True Architecture
SOA gets overused so much that it means different things to different people. Many developers, formerly myself, believed that SOA meant lots of atomic services which performed certain tasks and that combining these services was how you built out an application. For those of you who don’t have infinite time and resources to maintain your application, may I suggest that this implementation of SOA is really just 3 tiered architecture which rarely scales out well and is fairly difficult to architect, develop and maintain.
Instead, I would point you to Gregor Hophe, Udi Dahan and others that would suggest SOA is something very different. Messaging based architectures allow you to add services which look more like nodes on a bus. Each node performs a specific role and the beauty here is that the things putting messages on the bus and the things reacting to messages coming off the bus don’t have to know *anything* about each other. They only need to know about the message types and the bus. Ta-dow.
How All Of This Relates
I’m still working on that. In my last post I talked about the fallacy of thinking I was at least aware of everything I needed to know about. These are some of the things I thought I knew which were instrumental in leading me down a path of high frustration, long hours and low return.
I’m not saying I currently have everything figured out, but I am saying that looking into other tools and languages has helped me realize that there are far better ways to solve the problems that applications developers face daily. I’m blogging about this stuff because it’s exciting to me and I feel like it’s information worth passing around.
Tags: .net, erlang, amqp, xmpp, wcf