Announcer:

It's Wed, April 18th, 2007, and you are watching ARCast TV.

Ron Jacobs:

Hey, welcome back friends. This is your host, Ron Jacobs. Today we are going around the world again with one of our community correspondents. We are talking to Bob Familiar today, who is a Microsoft architect evangelist in the Boston area. Bob is going to bring us the story of Tyco Fire & Security.


Now, these are some very smart guys who are having to build distributed systems, and kind of the story of how they looked at the past technology, the things that were familiar, and decided to make a bet on a future technology, and the story of how they made that decision. You know, being kind of the person that likes to be on the cutting edge of things, I always like to know how you do that, how you talk people into doing that, how you talk your management into doing it. It's a very interesting story.


Then later we will go back to Kuala Lumpur for another interview there, but first let's go to Boston and Bob Familiar. Bob, take it away!

Bob Familiar:

Tyco Fire & Security develops security solutions that are used in some of the most highly secure facilities in the world. They are also leveraged by half the companies on the Fortune 500. To develop their next-generation access control system, called C-CURE 9000, the Tyco Fire & Security architecture team selected the Microsoft platform, and in particular, the.NET 3.0. Today I will be speaking with Stephen Tarmey, architect on the C-CURE 9000 project. He is going to give us some insight into why they selected the Windows Communication Foundation for their service-oriented architecture.


Myself and my audience were very curious about how you ended up selecting the.NET framework for your C-CURE 9000 project.

Stephen Tarmey:

We went down to the MTC at Microsoft to do a proof-of-concept to solve an original problem that we had, which was that we weren't seeing the performance that we would have hoped through.NET remoting. And what ended up happening was that we wanted to prove out that.NET remoting, that we were using it in the best possible way to optimize performance on the wire. And the original architecture of our system determined that we thought that it would be better to do a chatty architecture instead of a chunky architecture. And what ended up happening when we went down there was not only did we prove that that was wrong, but while we were there WCF was in beta, early beta, and we decided to see what WCF could do in the same scenarios as.NET remoting.


And what ended up happening was that WCF beat.NET remoting in a chunky method. Using it in a chunky method, it beat it by, I think it was about nine times the performance on the wire of sending in objects. So when I came back with the numbers to my management, basically the original idea was to say that we want to use remoting in a different way, but what ended up happening was the numbers for WCF were so good that my management said "Let's go with it."

Bob:

So you selected Windows Communication Foundation and.NET 3.0 as the technology for your service architecture?

Stephen:

That's right, yes. We actually leveraged it in two ways in our architecture. We leveraged it through the standard net TCP/IP binding to talk server to client, but we also used the Named Pipe binding on the same box.

Bob:

Great. Now, you selected.NET 3.0 Windows Communication Foundation, and obviously Visual Studio is your development environment, you are a few weeks away from releasing a product, a very exciting time here at Tyco Fire & Security. What benefits have you seen throughout the life cycle of this project?

Stephen:

Well, one of the key benefits I think that we found was that a lot of the features that I would have had to implement in the client-server architecture, I didn't need to do, because they come out of the box in WCF. For instance, encryption, security, we also have reliability. Even though TCP/IP is a reliable protocol, who knows, we might want to implement another one. Which is one of the coolest features of this technology, is that it is so configuration-file driven that we can actually switch the protocol of our application and switch the whole way that it communicates on the wire just by adding a few XML entries in a config file.


So that really is a benefit to us moving ahead because we can then, say for instance, if we wanted to do in the next version of our product, we wanted to do a web client. Well, our whole application is TCP/IP based, but if we just add a new binding to our service and distribute HTTP, we can start communicating just by adding a config file. Just the amount of code to have to write is so much less than we would have had to if we didn't have this technology.

Bob:

Very good. Less code, more productive, higher performance.

Stephen:

Can't beat it.

Bob:

Tyco Fire & Security experienced faster time-to-market, less complexity in their code, and extremely high performance by selecting the.NET framework 3.0 for their service-oriented architecture.


This is Bob Familiar, architect evangelist, reporting to you from Lexington, Massachusetts.

Ron:

Whoa, Bob! Hey, you sound like you're ready for CNN or something. I don't know, man, he's so, you know, got the journalist thing down. Man, that's too serious. But, hey, that was really interesting to hear the process that Tyco went through, to kind of learn about WCF and how they made the choice to go that way.


Now we are going to jet around the world to Kuala Lumpur, where I was there for TechEd, and we had a great little time chatting with some of the MVPs who were also there speaking. So let's go there now and listen to Norman and Dondy.


Hey, this is Ron Jacobs back in Kuala Lumpur where I am joined by a couple of very important guys here.


[laughter]


I'm going to let them introduce themselves. Go ahead.

Norman Sasono:

OK. Hi, my name is Norman Sasono. I'm a software architect from Intimedia, an ISP in Jakarta, Indonesia. I'm also a C# MVP for Microsoft. And I am being honored being interviewed by Ron Jacobs.


[laughter]

Ron:

OK, and...?

Dondy Bappedyanto:

Hi! My name is Dondy Bappedyanto. I'm a solution architect MVP. Currently I'm doing independent consulting for software architecture. And, like Norman, I'm very honored to be interviewed by Ron Jacobs.

Ron:

Whoa!

Dondy:

Because I see Ron Jacobs for the answer every time!


[laughter]

Ron:

OK. OK, so guys, you know we've been thinking about... Here in Kuala Lumpur we are talking about performance and architecture. And, you know, a lot of times things that architects do, really mess up performance. And sometimes it's the developers fault, we can be honest here, sometimes the developers do kind of poor coding and that messes things up, but usually that is this much of the problem. You know, the biggest performance problems come in like bad architectures or improper use of technologies, and these are architectural decisions. What kind of mistakes do you see people making?

Norman:

First, we cannot just choose a particular technology or a particular architecture just by reading some materials in some websites or some books, but we have to measure. Sometimes architects forget to do some kind of Spike solutions or PoC.

Ron:

Yeah.

Norman:

So before the real project begins we should start with some kind of small PoC and measure performance, see whether it is acceptable according to the SLA or not. If it is acceptable, then we can go with that technology. Sometimes I see, especially with some of my clients, they usually decide which architecture or style that they adapt to the project without measuring. So, they don't do the measuring.

Ron:

OK, so let's define some of the terms you used there. So, an SLA first, a very important concept, I think most people know that is Service Level Agreement, which is just a way of saying what the performance expectation is, right?


The other one you mentioned was sort of a PoC, or Proof of Concept, or sometimes just Spike is another way we would talk about those, which is sort of an experimental project to see if... If you have an idea about an architecture, and you thought "Well, this might work, it might not, " you might do a little Spike to build enough of it to measure to see if you had a good idea, if it would work or not. Right?

Norman:

Yes.

Ron:

OK. Good, good. OK, what do you think?

Dondy:

I concur with Norman, but I see it like this: Most of the architects--I mean in Indonesia but I think it is happening in the rest of the world as well--tend to go for a trend on the framework. For example, currently Hibernate is booming.

Ron:

Yeah.

Dondy:

The architect says, "OK, if I don't use Hibernate, then I'm not cool. My solution is not cool enough."

Ron:

Right, right.

Dondy:

Or they tend to mix some other frameworks and create some bloated frameworks. For example, mixing iBATIS with NHibernate and then putting it together with Enterprise Library, I don't know.

Ron:

Oh, yeah.

Dondy:

It will happen. But that is what I see, I mean an architect creating some bloated architecture and they don't... An architect has to see the solution coming out from the simple solution.

Ron:

Yes.

Dondy:

It works for performance. From the simple solution, it works for the performance; it's run better for the performance. Unless you are creating such a big project that needs a lot of developer activity, you can compromise your performance for this productivity, then, well, maybe use that framework. But if you want to get the performance, like you know, in a critical project, then I think you have to go to the lowest level.

Ron:

You know, that's a good point. I remember years ago creating a framework for a company I worked for that was very robust, very object-oriented and elegant. The design was terrific. I'm telling you, it was a great design. But performance was poor because everything kind of at run-time kind of wired up and hooked up and all these notifications going back and forth, so the run-time performance was not as good as we had hoped. And what we found was, after listening to our customers, people said, "You know, all that extensibility and all that stuff is great, but we really want the performance."


So in version two what we did was we sat back and said "You know, we don't have to design to hook everything up at run-time so that it is ultimately extensible. What we can do is just say at design time you can pick what you want, we'll generate a whole bunch of code, and then just run it and it runs really fast, it runs way faster, a lot better."


And it occurs to me, like NHibernate is a great example of this, NHibernate is very flexible, kind of a run-time oriented framework for doing object binding sort of to database type things. But there's a lot of people who build those solutions. You point at a database, it generates a bunch of classes that are very hardwired, ADO.NET calls are going to be very fast, very simple, easy to debug and understand. Maybe that is a good way to go.

Dondy:

Well, the way I see it, it depends on the project. I'm not saying that I'm against the NHibernate or iBATIS or whatever framework on that, I'm just saying it depends on the project that you are working on. I mean if it is an immense monumental project, then why bother using NHibernate unless you are doing a very large project, have like 100+ developers; then maybe NHibernate is the only solution, the only option for finishing the project.

Ron:

Yeah, but you know what the thing is with something like NHibernate, and I'm not opposed to NHibernate, it's just that here's another thing to think about. Now, every developer you bring on the project, let's say you have 100 developers, now you need 100 developers who know.NET and NHibernate. And so now you have got to teach people about NHibernate, right? Or now when, you know, a year from now or two years from now when you are gone and the project team is gone and somebody else comes along, they hire somebody to fix a bug on this and they don't know NHibernate, then they've got to learn NHibernate.


So, I mean, once you start piling these things on top of.NET, then it's just more surface area for what you have to know.

Norman:

Right. But as architects, the way I see it, what architects should really do is managing trade-offs, right?

Ron:

Yes.

Norman:

So performance is a goal, but sometimes it's not the primary goal that we want to achieve in our projects, because sometimes we do want to achieve the extensibility, the maintainability. And so we have to decide what is the priority of those qualities of service.

Ron:

Right.

Norman:

And then after that, again back to the SLA--what is the acceptable level of performance? Then we have to measure.

Dondy:

Right.

Ron:

Yeah. Well that's very important because a lot of people I see, a big mistake I see a lot of people make is that they go crazy trying to think of all kinds of clever ways to get great performance, when they either don't know what their SLA is, or they haven't even bothered to measure the simple thing. And they say, "Why don't you just write the simple thing first and see if that works. And it could be that that's fast enough and you don't have to do anything else."

Dondy:

Well, that's true. But, like Norman said, maybe performance is not... I mean, in some cases performance is not everything.

Ron:

Yeah.

Dondy:

Maybe you have to sacrifice the performance for the creative needs. For example, productivity.

Ron:

Yeah.

Dondy:

As I said before, if you ask me... Say if you have 100+ developers, then you need to have 100+ developers who know.NET and NHibernate. Well, as an architect, I used to segment my developers, some doing LOP, some doing access layers, some are doing all the back-end library sort of things. So, I don't need 100+ developers who know NHibernate, but definitely I need 100+ developers who know.NET, right?

Ron:

Yeah, that's true. So, I think what I hear you saying is, a mistake that an architect might make is to get fixated on performance when it is not the primary goal.

Norman:

True, yes.

Ron:

Ah, OK. Now, what kind of disasters have you seen with performance? Have you been on projects where the performance has really suffered?

Dondy:

Yeah, currently...

Norman:

Currently [laughs].

Dondy:

Currently, currently. We have a project, I'm not the architect, a friend of mine is the architect. And he is doing a workflow kind of thing, and the performance is... He needs about a hundred object and connection pulls.

Ron:

Oh.

Dondy:

Sorry, about a thousand object and connection pulls. So they need to set the maximum connection to 1,000.

Ron:

Wow.

Norman:

That's a nice pull.

Dondy:

So that's my previous experience.

Ron:

A lot of pull.


[laughter]


You know, that's an important point though. What you are talking about is recognizing that resource utilization is part of the equation of performance.


I look at performance as sort of having three parts to it. There is response time, which is sort of the user's perception. There is throughput, which is in the overall system how many transactions can we push through it. And then there is resource utilization, like how may connections, how much CPU are we using, how much memory, and so forth; because that is going to be a limiting factor on how you can scale and so forth, right?

Dondy:

Oh, wait a minute. I forgot one more thing. Architects tend to mis-implement the design patterns, the basic patterns, the design patterns.

Norman:

Yes. Sometimes architects become patterns addicts.

Ron:

Oh yeah.

Dondy:

In the case that I mentioned to you before, where the application needs to set the connection pull to 1,000, it's because they use a single conduit for the connection. That is evil! Evil, evil, evil!


[laughter]

Ron:

OK. There you go. All right. You have to understand. But this is the kind of things that architects do sometimes. We hear about some good thing, we go, "Oh, patterns. That must be really good." So we go buy a bunch of patterns, books, and get all excited about it, and then dive in and maybe hurt ourselves.

Norman:

Then you get the technical praise from your neighborhood: "Oh, wow! That's an elegant code."

Ron:

Well, so there you have it. There is a lot of danger for architects out there getting a little bit overboard on some cool trends. Simplicity is the best way to get good performance.

Norman:

Yes.

Dondy:

Yes, pattern.


[laughter]

Ron:

There's a pattern. All right.


Hey, well I hope you enjoyed that little pop over to Kuala Lumpur. I know at a time like this it makes me think of warmer places, and it definitely was hot and humid. And I'll be coming back to Malaysia next September for their TechEd, so you guys in Southeast Asia, I look forward to seeing you there.


And I'm working on plans for a lot of different TechEds this year, maybe China. I'm hoping to get there for the first time. And I'll be on my way to Japan in April. So, a lot of interesting things happening in Asia this year.


And performance is always one of the crucial things that you have got to get right for most applications. It's the one thing that people just really lock in to, and they say, "Oh, I don't like it, it's too slow." My wife works at a hospital and they got a new system and that's all she complains about is how slow the thing is. Well, you know, if people complain, then you've got a problem. But hopefully we are going to get to some solutions on this.


We will have more thoughts about performance and scalability from Malaysia and Kuala Lumpur. So, see you next time on ARCast TV.

Announcer:

ARCast TV is a production of...