thinking-out-loud

Concurrency in .NET

Last year around this time I posted about the comming need for multi-threaded applicaiton architecture.  Just recently Caleb sent me an aritcle by Sam Gentile on Parallel Computer in .NET that communicates the need/opportunity better. 

On the ASP.NET side of things, IIS is already multi-threaded so you get a lot of concurrency benefits automatically.  But in high-volume request environments, you may want to free up your threads when doing I/O.  Jeff Prosise has an article on Asynchronous Pages, HTTP Handlers, and Modules that raises awareness of what's possible there.

In WinForms, I've had several people ask me why background threads can't update controls on a form.  Craig Neuwirt of Improving covered this topic at the Dallas C# SIG meeting a few months ago and showed off his Facility in Castle to handle if invoke required logic transparently through inversion of control.  Craig's source code demonstrating the difference in complexity between handling the delegation explicity vs using Castle is available here labeled Containing Complexity, mismarked as May 2006 instead of 2007.

WSS & CS2007 Built on ASP.Net

I've recently had a couple of customers choose not to use the .Net 2.0 Membership system for user authentication in favor of a home-grown solution.  The decision was based on time-to-market using an older solution they had each developed independently.  At the time I wasn't comfortable prolonging the life of legacy infrastructure.  And, now we can really see that adopting the new model as soon as possible is a good idea.

Scott Guthrie points out that SharePoint 2007 and Commerce Server 2007 are built directly on ASP.Net 2.0 API's.  So making portable web parts is easy and highly leveraged across potential solution spaces.  Moreover, using the new Membership Provider Model for authentication gives you flexibility to easily adapt your applications to a future or shifting enterprise archiecture. 

For example, build an ASP.Net application today, port it into SharePoint 2007 tomorrow, then build a custom Membership provider for better authentication and identity management within the enterprises and see the benefits across all of your applications.

SharePoint 2007 & Commerce Server 2007

I recently took (and passed on my second try) the SharePoint Portal Design test. It took two tries because the piece of crap is 50+% about Commerce Server, Content Management Server, Internet Business Accelerator, and other things not truely SharePoint.  Oh, and those topics are NOT covered in courses 2014 or 8036 which are listed for pre-reque's, as you can see from the outlines.  Moreover, I've worked on a handful of SharePoint projects and never had to use MCMS or CS.  Should that knowledge really be required for basic certification?

As it turns out, though, I'm working on a SharePoint project that today was deamed an SPS 2007 project.  It also happens to have a shopping cart requirement for ordering supplies within the organization.  So, after studying the CS stuff, I actually get to implement it. :) 

And, while researching the risks of integrating two beta products, I found a couple of interesting things.  First, the new Commerce Server is now branded CS 2007.  And more importantly, it looks like the MS peeps are working hard to make sure it integrates well with SPS. According to Ryan Donovan's post, most of what anybody needs to make the two work can be done without coding any glue.

Vogels, Scalability, Testing

Werner Vogels puts forth some coherent thoughts on Scalability (like we'd expect any less). I love the part about heterogeneity in long-lived products. Moore's Law is still in effect, and any architect that doesn't pay attention to this is naive. A good friend of mine once told me a story of a great architect who was developing a process control system in Smalltalk for a large semi-conductor manufacturing system. The architect knew that the project was at least 5 years in duration, and so he designed the system taking into account that computing power would have increased roughly an order of magnitude in that timeframe. Clever.

I've discussed scalability before, so I won't dwell on the difference between scalability and performance, but I did want to talk a little bit about what it means to design a system to be scalable and then verify that the design works.

First, let me reiterate and paraphrase the point that Werner makes so well: scalability is about adding resources to increase capacity of a system without imposing a deleterious effect on performance.

So, Jef, if scalability is about adding resources, what kinds of resources contribute to the scalability of an architecture?

Well, you could add memory, processors, disk, NICs, whole computers, data centers, (people?) ... you get the point. Resources that affect scalability scale from the very smallest computer components to the largest system of computers. Oftentimes, it is more interesting to discuss not the scalability of the system, but instead the marginal cost to scale a system. If I spend a couple thousand dollars on some new memory for a computer and I double it's capacity, then the marginal cost is very low. If I have to spend $50K for a new database server -- eh, not so much. So one things you need to do up front is figure out whether you are interested in maximizing the scalability of the system OR minimizing the marginal cost to scale.

So, Jef -- once I have made an architectural decision about how I will choose to scale my application, how do I tell if it works or not?

One of the best ways to tell, of course, is to actually scale it.

Wh-wh-what? How, Jef?

Well, there are a couple of things to consider.

First, you need to have something to compare against -- a baseline. To get a baseline, create a load/utlization test. Run your system up to the desired utilization and/or maximum response time, whichever comes first, and determine the threshold for capacity. Record the throughput, response times, and faults, if any. Second, you need to add resources in the dimension along which you intend to scale the system. Take the resources, pour them in, and rerun your tests, increasing the volume by the desired marginal percentage. Did your performance degrade? How much? Where are the bottlenecks now? Can you fix those bottleneck? Ok, then, rinse and repeat.

But wait, Jef. I don't need that much capacity right now. In fact, I can't afford that much capacity right now. I just want to make sure that when I do need the capacity, I can obtain it in a cost effective, performant manner. If I've already bought the extra hardware, then I am no longer really concerned with building a scalable system, right? I have more capacity than I need, right?

Good point. You know more about this than you originally led me to believe.

Obviously, testing for scalability can get very expensive very quickly. Most of the time, when you are designing a system to scale, you aren't intending to take it to scale right then. How do you manage that cost? You scale down the scope of the test to a miniature version of your architecture. First, you prove it works for one unit of increment, and then, if you can afford it, you prove it works for 2, and so on. Then by [a really weak form of] induction you have verified that it scaled. The induction never quite works the way it did in math class, because different forces come into play as systems get very large. Eventually, scaling one dimension of a system is going to create a constrained resource in another dimension of the system, and then the dynamics of the environment change.

I like Werner's point about the argument ender - "but that doesn’t scale." When I hear that, I want to make sure that there is an implied "to the levels that we need to have a successful solution," as in but that doesn’t scale to the levels that we need to have a successful solution." What I explicitly don't want is "But that doesn't scale to support all of the users on the internet."

What about Google, Jef?

Google. Right. Unless I am working for Google. Ack.

There are lots of things that "don't scale," but it is important to understand what the necessary range of scale (read: requirements) is to be able to speak intelligently about the scalability of a system. Most of the time, that range should be driven by the financial implications at scale. In business, money is a key arbiter and a convenient shared language in which to discuss the value of a solution.

Atlas vs. Ajax.NET

I went to the DDNUG meeting on Thursday. Caleb Jenkins presented on Atlas, which is MS’s answer to Ajax.NET. Caleb is a good presenter who keeps the audience entertained. I think he’s a great addition the MS developer evangelism team. Coincidentally (not?), I phone-screened Caleb when he was interviewing to work at Geniant. At the time, he was the most knowledgeable .Net developer I’d interviewed and still probably ties for first.

Atlas seems pretty easy to use, especially for those who like drag-n-drop custom controls in your VS toolbox. There was a little confusion about which came first, Atlas or Ajax.NET. I guess some people think that Ajax.NET is knock-off created quickly after some guys saw an Atlas demo at TechNet or the PDC. Ajax.NET work was first published in April 2005 as far as I can tell. And, it looks like Ajax.NET is still the better tool since it isn’t still in beta, works with .Net v1.1, and has a Pro version with lots of great features.

Caleb dropped some URLs to the audience, so I thought I’d repeat them here:

• Official Atlas site by Microsoft: http://atlas.asp.net
• Ajax Gadgets for Live.com (and Windows Vista desktop?): http://microsoftgadgets.com
• Nice little debugging proxy for web dev: http://www.fiddlertool.com

The Ajax Architecture

In case you haven't heard, AJAX stands for Asynchronous JavaScript and XML and is a nice architectural tool, a browser-to-application interaction pattern if you will, that makes web-based applications more responsive and therefore more feasibly interactive. For more detail, check out Jesse James Garrett's full description of the technique.

I found this crafty Ajax.NET library that adds AJAX support to ASP.Net apps via simple attribution. The package comes with a single DLL that you reference from your WebApp, as well as a complete usage guide. The author, Michael Schwarz, has a blog and is even lobbying to get AJAX support added to Whidbey, which would be very cool, but not likely at this date.

The implications of Ajax are wide reaching. Most obviously, groovy applications like Google Maps can be made.  But many of the standard web controls we're used to could also be made more interactive with the server without requiring traditional page postbacks. And, where one might struggle with whether or not to query a large result set from a web page due to potentially slow information retrieval, Ajax brings the possibility of paging through data and retrieving each chunk via an XML request instead of a postback and page refresh.

SQL Server 2005

Last week I attended the Microsoft Architect Council where several speakers presented new/updated MS products built on SQL Server 2005.  Here are the highlights.

SQL Server Mobile – Kevin Collins

• Syncs w/ SQL Server  using Merge Replication w/ column tracking (e.g. pictures don’t sync every time a row changes) – actually a feature of SQL Svr 2005 and usable by SQL Express
• Syncs over HTTP/S with compression
• Multi-user (more than one app at a time, background sync)
• Based on .Net Compact Framework 2.0, ADO.Net 2.0
• Histograms for indexed columns – improved performance over SQL Server CE
• SQLCEResultSet – direct cursor mechanism – don’t use DataSet b/c causes double/triple buffering
• Create large DBs on desktop & dist to devices via file rather than long sync for each client

SQL Server Integration Server (www.sqlis.com) – Donald Farmer

• Collect/Analyze/Report
• Motivations: 24/7 business, greater volumes of data (e-commerce, RFID, call-center)
• Before Integration Services – doesn’t scale
  • separate, staged operations for different sources
  • different applications for each type of data
  • then warehousing, then data mining
• With Integration Service
  • data transformation, cleansing, merging, mining all done in single auditable process
  • warehouse separately for auditing
  • gen reports and access via mobile out of merged data, parallel w/ warehousing
• Components: sources, transformations, destinations
  • Source Adapters: .Net code writes app data into internal buffer format (effectively a row set)
  • Transformations: row set operations (union, intersection, sorting, etc.) and *fuzzy grouping*
  • Destination Adapters: translate buffer format to external apps
• Performance: proven to scale to 117 GB/Hr, 64bit allows operations on enormous datasets (e.g. MSN click-tracking)
• Case Study – Barnes & Noble: 1.6TB raw data => 50% less dev time vs. Oracle, 400% improved perf, more meaningful, up-to-date info for stock levels
• Graphical description of data processing flow, transformations, output, visualization w/ drill-down to composite flow charts
• Interactive selection/data profiling
• Note: isn’t designed for streaming information such as live click-stream.  Can use a polling mode and get small batches.  Also can pull data from SQL server using a built-in SQL Server adapter w/o .Net coding.

SQL Server 2005 Reporting Services - Brian Walker, Program Manager

• Uses ADO.Net driver and any DB supported by that
• Nice drag-n-drop interface to building a queries and setting up filtering, ditto for visual design of reports
• New data-picker control in next beta
• Sorting can be done with nested groups – re-sorts with a click of the sort control appearing on the report
• Headers stay on page with scrolling through the report
• Improved expression editor with syntax checking using a .Net expression language (defaults to VB.Net)
• SP2 will contain a set of WebParts for use with Sharepoint (ReportExplorer and ReportViewer, which can be linked together automatically)
• Visual Studio 2005 will have a report viewer control so apps can connect to Reporting Server or local databases (doesn’t require SQL Server)
• Direct-print (via ActiveX control) where server gens report and browser routes to printer (adjustable margins, etc. during run-time)
• ReportBuilder: design tool for business user
  • click-once app running as low-privileged user
  • template-based with drag-n-drop table/field assignment
  • auto-totaling and sub-totaling is easy
  • the “model schema” is sent to server and translated into a query by the server
  • Model Designer tool can public models to the Report Server
  • Part of SQL Server license but require Report Server running

Marketing is hard, didn't you know?

Kevin Schofield over at Microsoft rants on marketing, how hard it is, and how most techies dis marketing types [case in point].

Marketing is a difficult discipline, that requires both theoretical and practical knowledge. Just as marketing people should respect technical people, technical people should respect marketing people. I think in the long run one of the most important business lessons that people will take away from studying Microsoft is that when you put sharp technical people and sharp marketing people together and things click, you can create a very, very profitable business.

Luke Hohmann has a book title Beyond Software Architecture in the AW Martin Fowler Signature series of books that addresses some of the topics around Product and Marketing Management.

Luke's book provides an excellent introduction to product marketing and management, especially for software architects. He drills down into the method of what may sometimes seem to be marketing madness. Luke is a fairly engaging writer, and I enjoyed the work. I have a couple of nits I would pick: the chapter on logging seems like it is not congruent with the rest of the book, and I was yearning for more insight and depth in the effect of brand on software design than making brand names configurable, but of course that leaves room for book 2 (or 3, really). Well worth the read, even if he ought to lose the beard pic on his site.

Via the scobleizer.

Stress Driven Architecture

Wensel blogs about a concept he calls stress driven architecture. It is interesting and relevant to Todd and me, given a more generalized architecture process we are developing. More about this later.

Clemens Vasters on Scalability

Clemens Vasters, though he know it not, has had a non-negligible impact on my thoughts about service-oriented architecture. I usually enjoy what he has to say about topics architectural in nature, and topics related to service oriented architecture in particular. He did some interesting skunkworks with Microsoft on a reference architecture called "Fabriq," working closely with Arvindra Sehmi, an architect from Microsoft who is also an editor for the new Microsoft Architecture Journal. I saw a webcast of a joint presentation by the two. It dug into the notion of service agents in the context of Fabriq. Really interesting, somewhat heady stuff -- I need to find the link.

Additionally, he took the open-source blogx (rip) and turned it into dasBlog (with some help, of course), and that is a great public good.

Finally, he, through is company, newtelligence, has contributed some excellent web services management extensions for .NET. I am looking for a good excuse to sneak these into my current projects.

Because he has that influence on me, he earns a [perhaps someday] coveted spot in the thought leaders list.

Now.

I recently published an entry on architectural qualities, and it was superficial at best. A position statement, but not much more.

Then.

Clemens published a number of entries on his blog that he is providing as background material for one of his presentations at the Microsoft PDC, and despite the fact that it would most likely mean I would be away from my lovely wife and daughter, I wish I were there. I have only attended one PDC back in Denver ('98?), but it was great fun.

The first of his list of articles, Stateless?! delves into a commonly touted, oft-misunderstood statement (and I paraphrase): "Stateless [Services Components (collectively here for brevity--services)] are more scalable." This will be a platform for digging into scalability a bit more.

He then attempts to describe a scenario where a stateless service does not scale, but he focuses on performance rather than scalability. It is completely relevant that the increased response time of a hog of a stateless service will tie up precious system or otherwise resources that then have a negative impact on scalability. But that does not mean that the service would not scale. It merely means that it would scale all that well. You could still go with his earlier explained approach of throwing more hardware at it, and you would have a scalable solution. He tends to focus on the vertical load scalability aspects, while ignoring the horizontal scalability aspects.

Now, ignoring the quibble over scalablity vs. performance, I especially like a statement toward the end.

The scalability recipe isn’t to try achieving static statelessness by avoiding holding state across calls. Using this as a pattern certainly helps the naïve, but the actual goal is rather to keep sessions (interaction sequence duration) as short as possible and therefore limit the resource consumption of a single activity.

I might amend it slightly, though:

"the actual goal is rather to limit the resource consumption."

Limiting session duration is certainly one approach, and focusing on individual activities is another, but they two together are not the only approach. He mentions other approaches, such as pooling earlier in the article, and they are perfectly valid approaches to increasing the scalability of a solution as well.

RichB follows up with a comment that deserved some attention along the lines of "performance != scalability notion:"

Of course scalability may be increased by having a stateful service in certain scenarios. What if the service had millions of requests per minute, but only had a very few unique clients making those requests? You could save bandwidth by storing state on a per-client basis. For example - instead of sending a large amount of stateful data back to the client on every round trip, it could be stored in memory on in a state store - and the amount of data saved in every round trip is multiplied by the millions of requests per minute to get a large bandwidth saving.

Rich again does not seem to be addressing scalability, which has to do with how well a system responds under some dimension of growth. That dimension is usually load, concurrent number of client request, etc. Rich doesn't create a situation that describe a scalability problem, and the solution is couched in terms of increased performance (throughput, response time, network efficiency, and so on). The distinction may or may not be subtle, but I think it is relevant, because you may have a situation where your system performs well under the current load, and you know that you are about to bring on a new client that is going to appreciably increase that load beyond the scale of the current solution. You can dig into the software looking for ways to reduce the session duration in the name of scalability, or you can go with the more naive [and probably faster and easier to implement and test] solution of throwing more hardware at it (horizontal scalability).

Now, that being said, it is worth noting that there are other types of scalability than just load scalability -- internationalization, for instance, is a type of scalability.

Another type is domain scalability -- how well does your architecture incorporate new products, new concepts, new lines of business? This is a pet interest of mine (among others) under the name of Adaptive Object Models.