Clemens Vasters - Microsoft

Help Wanted

Tue, 08 May 2007 03:07:58 GMT

After roughly 15 months of working for the firm I've got to say that while it was fun talking about the .NET Framework and BizTalk at conferences and in writing, it's quite a bit more fun to be part of building the .NET Framework and BizTalk. You could be part of it, too, if you have the Jedi skills it takes. [The listed Assistant job requires the mastering the art of coordinating the Jedi Council's schedule across the galaxy; you just believe me - and that's just a small part of the job]. The good news is that we're growing quite a bit:

Job Title	Job Category	Product	Location
Product Manager	Marketing	.NET Framework	WA - Redmond
Group Program Manager	Program Management	.NET Framework	WA - Redmond
Software Development Engineer in Test	Software Testing	.NET Framework	WA - Redmond
Software Development Engineer in Test	Software Testing	.NET Framework	WA - Redmond
Software Development Engineer	Software Development	.NET Framework	WA - Redmond
Program Manager	Program Management	.NET Framework	WA - Redmond
Program Manager	Program Management	.NET Framework	WA - Redmond
Program Manager	Program Management	.NET Framework	WA - Redmond
Program Manager	Program Management	.NET Framework	WA - Seattle
Software Development Engineer	Software Development	.NET Framework	WA - Redmond
Product Manager	Marketing	Biz Talk Server	WA - Redmond
Software Development Engineer	Software Development	.NET Framework	WA - Redmond
Software Development Engineer in Test	Software Testing	.NET Framework	WA - Redmond
Software Development Engineer	Software Development	.NET Framework	WA - Redmond
Business Manager	Software Development	.NET Framework	WA - Redmond
Technical Writer	User Assistance & Education	Biz Talk Server	WA - Redmond
Program Manager	Software Development	.NET Framework	WA - Redmond
Assistant	Administrative Services	.NET Framework	WA - Redmond
Software Development Engineer in Test	Software Development	.NET Framework	WA - Redmond
Program Manager	Program Management	Biz Talk Server	WA - Redmond
Product Manager	Marketing	.NET Framework	WA - Redmond
Program Manager	Program Management	.NET Framework	WA - Redmond
Program Manager	Program Management	.NET Framework	WA - Redmond
Test Manager	Software Testing	.NET Framework	WA - Redmond

For privacy and other reasons, please do not send resumes or job applications to me! Go through the jobs site. I'm just pointing to the right place ... ;-)

Internet Service Bus

Wed, 25 Apr 2007 03:28:23 GMT

"ESB" (for "Enterprise Service Bus") is an acronym floating around in the SOA/BPM space for quite a while now. The notion is that you have a set of shared services in an enterprise that act as a shared foundation for discovering, connecting and federating services. That's a good thing and there's not much of a debate about the usefulness, except whether ESB is the actual term is being used to describe this service fabric or whether there's a concrete product with that name. Microsoft has, for instance, directory services, the UDDI registry, and our P2P resolution services that contribute to the discovery portion, we've got BizTalk Server as a scalable business process, integration and federation hub, we've got the Windows Communication Foundation for building service oriented applications and endpoints, we've got the Windows Workflow Foundation for building workflow-driven endpoint applications, and we have the Identity Platform with ILM/MIIS, ADFS, and CardSpace that provides the federated identity backplane.

Today, the division I work in (Connected Systems Division) has announced BizTalk Services, which John Shewchuk explains here and Dennis Pilarinos drills into here.

Two aspects that make the idea of a "service bus" generally very attractive are that the service bus enables identity federation and connectivity federation. This idea gets far more interesting and more broadly applicable when we remove the "Enterprise" constraint from ESB it and put "Internet" into its place, thus elevating it to an "Internet Services Bus", or ISB. If we look at the most popular Internet-dependent applications outside of the browser these days, like the many Instant Messaging apps, BitTorrent, Limewire, VoIP, Orb/Slingbox, Skype, Halo, Project Gotham Racing, and others, many of them depend on one or two key services must be provided for each of them: Identity Federation (or, in absence of that, a central identity service) and some sort of message relay in order to connect up two or more application instances that each sit behind firewalls - and at the very least some stable, shared rendezvous point or directory to seed P2P connections. The question "how does Messenger work?" has, from an high-level architecture perspective a simple answer: The Messenger "switchboard" acts as a message relay.

The problem gets really juicy when we look at the reality of what connecting such applications means and what an ISV (or you!) were to come up with the next cool thing on the Internet:

You'll soon find out that you will have to run a whole lot of server infrastructure and the routing of all of that traffic goes through your pipes. If your cool thing involves moving lots of large files around (let's say you'd want to build a photo sharing app like the very unfortunately deceased Microsoft Max) you'd suddenly find yourself running some significant sets of pipes (tubes?) into your basement even though your users are just passing data from one place to the next. That's a killer for lots of good ideas as this represents a significant entry barrier. Interesting stuff can get popular very, very fast these days and sometimes faster than you can say "Venture Capital".

Messenger runs such infrastructure. And the need for such infrastructure was indeed an (not entirely unexpected) important takeaway from the cited Max project. What looked just to be a very polished and cool client app to showcase all the Vista and NETFX 3.0 goodness was just the tip of a significant iceberg of (just as cool) server functionality that was running in a Microsoft data center to make the sharing experience as seamless and easy as it was. Once you want to do cool stuff that goes beyond the request/response browser thing, you easily end up running a data center. And people will quickly think that your application sucks if that data center doesn't "just work". And that translates into several "nines" in terms of availability in my book. And that'll cost you.

As cool as Flickr and YouTube are, I don't think of none of them or their brethren to be nearly as disruptive in terms of architectural paradigm shift and long-term technology impact as Napster, ICQ and Skype were as they appeared on the scene. YouTube is just a place with interesting content. ICQ changed the world of collaboration. Napster's and Skype's impact changed and is changing entire industries. The Internet is far more and has more potential than just having some shared, mashed-up places where lots of people go to consume, search and upload stuff. "Personal computing" where I'm in control of MY stuff and share between MY places from wherever I happen to be and NOT giving that data to someone else so that they can decorate my stuff with ads has a future. The pendulum will swing back. I want to be able to take a family picture with my digital camera and snap that into a digital picture frame at my dad's house at the push of a button without some "place" being in the middle of that. The picture frame just has to be able to stick its head out to a place where my camera can talk to it so that it can accept that picture and know that it's me who is sending it.

Another personal, and very concrete and real point in case: I am running, and I've written about that before, a custom-built (software/hardware) combo of two machines (one in Germany, one here in the US) that provide me and my family with full Windows Media Center embedded access to live and recorded TV along with electronic program guide data for 45+ German TV channels, Sports Pay-TV included. The work of getting the connectivity right (dynamic DNS, port mappings, firewall holes), dealing with the bandwidth constraints and shielding this against unwanted access were ridiculously complicated. This solution and IP telephony and video conferencing (over Messenger, Skype) are shrinking the distance to home to what's effectively just the inconvenience of the time difference of 9 hours and that we don't see family and friends in person all that often. Otherwise we're completely "plugged in" on what's going on at home and in Germany in general. That's an immediate and huge improvement of the quality of living for us, is enabled by the Internet, and has very little to do with "the Web", let alone "Web 2.0" - except that my Program Guide app for Media Center happens to be an AJAX app today. Using BizTalk Services would throw out a whole lot of complexity that I had to deal with myself, especially on the access control/identity and connectivity and discoverability fronts. Of course, as I've done it the hard way and it's working to a degree that my wife is very happy with it as it stands (which is the customer satisfaction metric that matters here), I'm not making changes for technology's sake until I'm attacking the next revision of this or I'll wait for one of the alternative and improving solutions (Orb is on a good path) to catch up with what I have.

But I digress. Just as much as the services that were just announced (and the ones that are lined up to follow) are a potential enabler for new Napster/ICQ/Skype type consumer space applications from innovative companies who don't have the capacity or expertise to run their own data center, they are also and just as importantly the "Small and Medium Enterprise Service Bus".

If you are an ISV catering shrink-wrapped business solutions to SMEs whose network infrastructure may be as simple as a DSL line (with dynamic IP) that goes into a (wireless) hub and is as locked down as it possibly can be by the local networking company that services them, we can do as much as we want as an industry in trying to make inter-company B2B work and expand it to SMEs; your customers just aren't playing in that game if they can't get over these basic connectivity hurdles.

Your app, that lives behind the firewall shield and NAT and a dynamic IP, doesn't have a stable, public place where it can publish its endpoints and you have no way to federate identity (and access control) unless you are doing some pretty invasive surgery on their network setup or you end up building and running run a bunch of infrastructure on-site or for them. And that's the same problem as the mentioned consumer apps have. Even more so, if you look at the list of "coming soon" services, you'll find that problems like relaying events or coordinating work with workflows are very suitable for many common use-cases in SME business applications once you imagine expanding their scope to inter-company collaboration.

So where's "Megacorp Enterprises" in that play? First of all, Megacorp isn't an island. Every Megacorp depends on lots of SME suppliers and retailers (or their equivalents in the respective lingo of the verticals). Plugging all of them directly into Megacorp's "ESB" often isn't feasible for lots of reasons and increasingly less so if the SME had a second or third (imagine that!) customer and/or supplier.

Second, Megacorp isn't a uniform big entity. The count of "enterprise applications" running inside of Megacorp is measured in thousands rather than dozens. We're often inclined to think of SAP or Siebel when we think of enterprise applications, but the vast majority are much simpler and more scoped than that. It's not entirely ridiculous to think that some of those applications runs (gasp!) under someone's desk or in a cabinet in an extra room of a department. And it's also not entirely ridiculous to think that these applications are so vertical and special that their integration into the "ESB" gets continuously overridden by someone else's higher priorities and yet, the respective business department needs a very practical way to connect with partners now and be "connectable" even though it sits deeply inside the network thicket of Megacorp. While it is likely on every CIO's goal sheet to contain that sort of IT anarchy, it's a reality that needs answers in order to keep the business bring in the money.

Third, Megacorp needs to work with Gigacorp. To make it interesting, let's assume that Megacorp and Gigacorp don't like each other much and trust each other even less. They even compete. Yet, they've got to work on a standard and hence they need to collaborate. It turns out that this scenario is almost entirely the same as the "Panic! Our departments take IT in their own hands!" scenario described above. At most, Megacorp wants to give Gigacorp a rendezvous and identity federation point on neutral ground. So instead of letting Gigacorp on their ESB, they both hook their apps and their identity infrastructures into the ISB and let the ISB be the mediator in that play.

Bottom line: There are very many solution scenarios, of which I mentioned just a few, where "I" is a much more suitable scope than "E". Sometimes the appropriate scope is just "I", sometimes the appropriate scope is just "E". They key to achieve the agility that SOA strategies commonly promise is the ability to do the "E to I" scale-up whenever you need it in order to enable broader communication. If you need to elevate one or a set services from your ESB to Internet scope, you have the option to go and do so as appropriate and integrated with your identity infrastructure. And since this all strictly WS-* standards based, your "E" might actually be "whatever you happen to run today". BizTalk Services is the "I".

Or, in other words, this is a pretty big deal.

Wow. Cleveland 1946. Wow.

Mon, 26 Feb 2007 03:51:11 GMT

Wow! I'm watching the Oscars with my wife and she just thought I completely lost it during the last commercial break. I actually started cheering. Why? I've seen the first Microsoft commercial that made me think ... Wow. The firm starts getting how to do this. Short, witty, provocative, impactful. Cool. "Wow" Cleveland, 1946. "Wow" 2007. More of that please.

One Microsoft Way, Redmond, WA 98052, USA

Mon, 21 Aug 2006 17:05:00 GMT

We moved. For the most part. Sabine and I now live in a temporary housing location that Microsoft set us up in while we wait for practically everything we own except for the 5 suitcases that we brought along with us a week ago. One half of the rest are about 9 boxes that were sent as air-freight and sit at Seattle-Tacoma Airport and we’re expecting to clear customs and be shipped to our temporary apartment any day now. The other half is a 40-feet long sea container with our furniture and most everything else that we own that’s somewhere in the belly of a container freighter between Bremerhaven and California at this time. I write “in the belly” because I hope it’s not in one of the upper 3-4 layers above deck – which are actually supposed to go overboard when the ship gets into heavy seas …

So between the last few posts here just after our wedding and today, there was hardly any time to get much serious work done. Not that moving isn’t any work, but it’s not what I consider being productive in the job. Right after we came back from our honeymoon in beautiful Vietnam (it’s a great place with gorgeous landscapes, very friendly people and lethally dangerous street traffic) we started to wrap and pack our things. While the moving company wouldn’t let us pack anything in our apartment and even repacked the boxes from the last move that ended up in the basement, dealing with the immaterial things to wrap up proved to be a lot more time consuming than we both anticipated. Cancelling insurances and contracts like mobile phones and cable TV, negotiating with the service providers to avoid early cancellation fees, selling both of our cars, etctetc. And of course there was some sort of “farewell” party/dinner/drinks event with friends and family almost every evening in the last two weeks – with all the emotional stress that comes with that, especially for Sabine’s family. My family took it a little easier since they are used to me circling the globe and I’ve already done the move from Germany to America once before for a while.

However, by now all of that stress has mostly dissolved thanks to the excellent communication options at hand these days. We’ve got Webcams along with Messenger and Skype, friends and family are looking up the best phone rates for Germany-to-US calls from the website billiger-telefonieren.de (depending on time of day, there are providers offering calls for less than 1 (one) Euro Cent per minute) and Sabine sends lots of pictures around so everyone knows where we landed.

Microsoft. Ah, yes, Microsoft. The relocation benefits that the company offers for international hires are quite astonishing. Except for doing your personal paperwork to get rid of your contracts, selling your cars (forget about bringing foreign cars to the US unless they are collector’s items and more than 30 years old) and selling or renting out your house, everything else is taken care of. We got a temporary furnished apartment and a rental car and a lump sum expense payment so that we can, for instance, replace all those small appliances like coffee maker, toaster, and mixer that aren’t compatible between Europe and here. It goes so far that if you lose money on the sale of your house or car by having to sell it quickly and under fair market value (which is common when you sell a car to a dealer), you will get compensated for the difference (up to a certain cap). For the first couple of months we even have someone personally assigned to us who helps with setting up banking, getting our driver’s licenses, finding a new place to live, getting shopping advice, etcetc. It’s great.

While all of that was and is going on, our team is putting the finishing touches on our first release of the Windows Communication Foundation in the .NET Framework 3.0. And we’re doing very good. Between all the moving craziness I’ve been contributing a tiny little bit to the product by writing two of the SDK samples to help landing the SDK smoothly on the deadline for the RTM SDK code content. Besides that, there was no time for blogging and therefore I didn’t. Yes, I might have been able to, but I’m not Scoble ;-) Sorry for the long blog-silence. I’ll better myself. Have good start into your work week.

Good Morning.

Wed, 01 Feb 2006 12:38:39 GMT

Good Morning!

My name is Clemens Vasters and I am Community Relations Program Manager for the Windows Communication Foundation at Microsoft Corporation.

[Boy, writing that feels a little strange. I guess I'll get used to it. ;-) ]