We continue our monthly look at thought leaders in the “connected systems” space by interviewing Yossi Dahan. Yossi is a great technologist, prolific blogger, Microsoft MVP as well as a good tipper. Yossi recently attending Microsoft’s PDC conference in Los Angeles, and I wanted to get some insight from him as to what he saw there.
Yossi provides some great insight into technology, and also tests the PG-13 limits of my blog with his answer to this month’s “stupid question.” Enjoy.
Q: At the just-completed Microsoft PDC conference, we saw a wide range of new technologies announced including Azure, Oslo, and Dublin. Given that you have a real job and canāt play with technology all day, which of the just-announced products/frameworks do you expect to spend the most time with, and why?
A: I will undoubtedly try to spend as much as I can looking at all of the above as I sincerely believe they are all pieces of a big change that is coming to how software is developed and run; of course, you are quite right, and it is rather unlikely that anyone with a day job will be able to spend enough time learning all of these, and so I think I will probably focus initially at the Azure platform and the services built on top of that.
The main reason is that out of the various technologies announced during PDC and the weeks leading to it, I believe that the Azure platform is the one with the highest impact on how software is architected and designed; also, if my understanding is correct (and there are not concrete statements on this one yet) it is the .net services and bit of the Azure platform that will be the first āout of the doorā while there is still some time before we could consider using Dublin or Oslo in a production environment.
If I have a little bit more time left (or maybe āofflineā time) to spend on anything else Osloās āMā would be what Iād spend it on. I find this (defining modeling and textual dsls) a fascinating area and I really want to look deeper into this; it kind of doing my head in at the moment, just trying to grasp the concepts and potential they carry, but I have a feeling that for some of us this can make a big difference in how we work (and help others work).
Last I would add that Iām already looking at some of the Geneva aspects, mostly the Geneva Framework (formerly known as āZermattā) and think this will also become a very common component in the enterprise environment.
Q: You and I were recently chatting about a PDC pre-conference session that you attending where Juval Lowy was trying to convince the audience that āeverything should be a service.ā Explain what he meant by that, and whether or not you agree.
A: It would be pretentious of me to try to explain Juvalās ideas, so letās just say Iāll try to convey some of the points Iāve taken from his talkā¦
Basically Juval argues that WCF is a lot more than just a āframework for developing servicesā much like .net is more than just a āframework for developing web servicesā as it was once presented; he argues that WCF services have so much āgoodnessā that it would be silly not to want to use them for every class developed and he goes on to give quite a few examples, here are a couple of examples (he must have had over half a dozen)ā Take the timeout default behavior in WCF for example – with WCF every call to a service operation has built in support for timeout, so if the methodās implementation takes forever (because of a deadlock situation for example, or simply an endless loop) the caller would receive a timeout exception after the configured time; this is a great feature, and to implement it in custom code, while possible, will take some effort (on the client side); to implement it around every method call seems unthinkable, let alone in every client out there.
Another example that Juval goes through is tracing ā with WCF you get built in tracking for each method call, including correlation of multiple logs (client and server for example etc) and the trace viewer provided with the framework; how much effort would it take you to build that into your code? with WCF you simply get it for free through configuration; quite neat.
Juval goes on to list many such benefits like Fault tolerance , built-in performance counters, security, reliability, transactions, versioning tolerance etc. I will not repeat all of it here, but I hope you get the point; Juval actually goes as far as suggesting that every class should be a service ā including type once known as primitive types such as String and Integer (they are already classes in .net, and now Juval suggests they could benefit from being a service)
That was pretty much Juvalās point of view as I understand it; as for my perspective ā do I like his idea? I certainly think itās a great a food-for-thought exercise; do I agree? Not completely. It is true that WCF incorporates a lot of goodies, and I love it, but – and thereās a big but ā it comes with a cost; it comes with a performance cost, which Juval tries to play down, but I think heās taking a rather convenient stand; it comes with a complexity cost ā WCF is not simple, especially when you start to combine things like security, reliability, transactions, instance management; do we want/need all that complexity in every class we write? I doubt it.
Many of the benefits Juval lists really only apply once youāve decided you want to use services; if Iām not using services ā do I need reliable messaging? Do I need security? Itās easy to argue for WCF once youāve decided that you need to run everything as a service, which I guess is Juvalās starting point, but if youāre not in that thinking mode (yet?), and I am certainly not ā then you might think he has gone just a little bit too far š
Now ā I was never interested in looking too far into the future, Iām pretty much a now-and-there-and-around-the-corner type of guy who argues that itās important to know where things are going but in my day to day job I need to give my clientās solid advice on what they can (and should) do now. Looking into the future performance is certainly going to be less of an issue, and Iām sure WCF management will improve significantly (Dublin is already a great step in the right direction) so we might end up very close; but thatās not present tense.
It is worth noting that I do not at all disagree that we will be seeing a lot more services; weāve already seeing a lot of enterprises and ISVās adopt SOA architecture of one flavor or another, and the cloud services/platforms will only add more capabilities in that space, so I donāt want to play down the role of services and WCF in enterprise IT, I just think this will still be, for the foreseen future at least, another tool in the toolbox, albeit a major one.
Q: As we now know that BizTalk Server has a new lease on life (i.e. releases planned after 2009), what types of engine-level changes would you like to see? In your opinion, what would make BizTalk messaging even more robust?
A: I should probably start by saying that I truly believe that BizTalk is, and has been for a while now, a very complete and mature product, and while there are clearly a few quirks and rough edges, the good definitely out-weighs the bad⦠I suspect it was not by chance that you have asked me to focus on engine-level changes – most of the stuff I have āon my listā is related to user experience ā both developer and administrator, there are less things that I believe need changing around the engine, but here are a few examples –
One thing I would have like to see is the management database thinned a little bit – I donāt think, for example, that the entire schema is needed in the database (which makes deployment of updates harder); I would imagine that this could have been reduced in scope to store only xpaths related to promoted/distinguished fields etc.
I also think, as both me and Mike Stephenson talked about in the past, that it would be a good idea to get rid of the compiled-pipeline concept and instead make it a configuration artifact, such as send ports for example; at the end of the day all a pipeline is just a set of components and their properties, represented as xml; sounds familiar? Doesnāt it feel suspiciously like a binding file element?
While I donāt know if you would consider the above as engine-level changes (I think they could be considered as such), the next one certainly is ā
Better support for low latency scenario; several people have mentioned this in the past ā BizTalk is great (no! really!) but it seems to be positioned a little bit in the middle ā itās not the best tool for large batch files processing (ETL is the technology of choice there), but with the latency introduced by multiple message box hops it is hard to position it in low latency scenarios; I know that Dublin is getting into that space, but I think Microsoft will do well to add in-memory pub-sub support to BizTalk to better support low latency scenarios.
Others on the list – Somebody clever (not mentioning names!) once suggested giving better control over (orchestration) instance throttling, I completely second that. Also nice to have would be the ability to run a map on a typeless message (XmlDocument) ā let my xslt figure out which template to run .
Not much to ask, is it!?
Q [stupid question]: If you work in the same office for quite a while, you may tend to let your guard down and ask questions or make comments that you wouldnāt typically say to strangers. Everyoneās had those awkward moments such as congratulating a woman on her pregnancy when no such congratulations were in order. Or, my new personal favorite, someone walking into your office and saying āLast night I had a wildly vivid, erotic dream and you were in it!ā What is your example of a terribly awkward āofficeā conversation?
A: Unfortunately finding embarrassing moments is not very hard, hereās one from the far history , I just hope I can correctly paint the scene –
Quite a few years ago, letās just say ā before BizTalk was invented ā I did a relatively small project in Sydney, Australia. The client was a lingerie company wishing to build a web application to compete with Victoriaās Secret very successful ecommerce web site, and I was called to the flag to build that.
The owners of the company, if my memory serves me right, were a couple of playboy type guys (with most of the staff seem to be either ex-models or models-to-be) and once or twice a week they would come over to our dev shop, accompanied by one or two such assistants, to discuss the current status and any open issues around the development and design.
I canāt remember what it was now, but there was this one thing they kept asking for time after time which made absolutely no sense ā not from a visual design or usability perspective, not from an architecture perspective, and, as these things often go, it was also very hard to achieve technically; and so we constantly had debates in those meetings about whether and how we should implement this requirement. In one of those meetings they kept going on and on about this thing, while me and my Australian colleagues (yes ā worth stating that was not at all alone in my reluctance to implement this) were trying to explain why it was so difficult to implement, but mostly, why it simply does not make sense as a feature on the web site. Eventually, being quite young and inexperienced (and Israeli, some would say) I got into a slightly too heated debate about it and eventually lost my cool and said, rather loudly, something like ā āI only have two words to sayā I canātā.
On its own ā itās not too bad (although now I know that such discussions are often doomed to failure from the beginning, but I had much less experience back then :)), but, and hereās the hard thing to explain perhaps, stupidly, I was trying at the time, with a fair bit of effort, to assume an Australian accent. Being Israeli, brought up on American television and having been in Australia for just about 3 weeks at the time, it did not go too well as you can imagine, and mostly it screwed up any chance I could have to be understandable, and thatās when not in a way-too-heated- debates; and so what I said and what they heard were two completely different things (Iām sure you can guess what they had in mind). Being the playboy types that they were they were certainly not going to let this one slip and so I they were having a laugh at my expense for the rest of that meeting (and the rest of that week in fact); much to my embarrassment.
At least it made me stop trying to assume any accents, and with me working all over Europe, then landing in the north of England and now living just outside London I would say ā good thing that I did, itās all messed up as it is!
Great job Yossi. You are an engrossing storyteller.