Coding the Architecture - dotnet tag

Design software as a long running process

Thu, 05 Nov 2009 20:42:51 GMT

I had an interesting discussion today about the differences between writing a Windows service in .NET and an ASP.NET web application. Somebody made a comment that Windows services were harder to write because you need to make sure you deal with memory properly in order to avoid memory leaks, whereas you didn't need to do this with an ASP.NET web application. In short, the perception was that Windows services are long running processes and that ASP.NET applications running under IIS aren't. There are several things to pick up on here.

First of all, .NET (like Java) is a managed platform that does its own garbage collection so you don't need to worry about explicitly allocating and disposing memory. Unless you're integrating with unmanaged code (e.g. older DLLs, COM objects, other native code, etc) you don't generally need to worry about low-level memory allocation.

Memory leaks *are* something that you need to worry about though and they're really easy to cause in .NET or Java applications. All you need to do is cache lots of data in static references, not dispose of resources you are using, etc. You're not really "leaking" memory, you're just storing it away somewhere and never reusing it again. If you're interested in this topic, InfoQ published a good article today called Dealing with Memory Leaks in .NET that digs into this some more.

The thing that I found the most surprising is the difference in how Windows services and ASP.NET applications are often viewed. A Windows service is clearly a long running process because once it's up and running, that's it until it gets restarted manually or from a system reboot. With a Windows service, any memory leak will start to become very obvious as the system slowly grinds to a halt and it's this that caused the comment about Windows services being harder to write. For some reason, ASP.NET applications aren't necessarily perceived as long running processes. With my Java background, I find this odd and several times people have mentioned that they rely on AppDomain recycling in IIS to prevent their applications from consuming too much memory. AppDomain recycling is essentially the same as what happens when you hot-deploy a web application on a Java EE server - drop the classloader and plug-in a new one to reload everything from a fresh state. For a moment then, let's think about what happens when an AppDomain behind an ASP.NET application is recycled in IIS (there's a much more detailed explanation here).

Any shared state in your application (e.g. stored by static variables) disappears. If you're caching frequently used data or data that takes a long time to calculate, then this will all vanish.
Any sessions backed by the in-process session store (i.e. in the AppDomain) get blasted.
You'll normally see a performance hit the next you hit the site as pages are reloaded and recompiled, connections are re-established, etc.

AppDomain recycling can have a fairly large overhead then, which brings me nicely onto the point of this. You're likely to have fewer issues in the future if you design every piece of software as a long running process. It doesn't matter whether you're building a Windows service, an ASP.NET web application or even a desktop application; you should always write code to avoid memory leaks rather than ignoring them. Relying on restarts or AppDomain recycling as a workaround for sloppy coding and memory leaks is not my idea of software craftsmanship.

Broadening the T

Thu, 15 Oct 2009 08:46:00 GMT

One of the sessions that I delivered at the recent Software Architect 2009 conference was entitled "Broadening the T" and covered the sort of skills and knowledge that I think are needed by hands-on software architects. This included things like seeing the big picture, dealing with non-functional requirements (we focussed on performance and scalability), using patterns at the architecture level, testing architectures, monitoring and diagnosing performance problems. Some concrete advice was given throughout the presentation with Java and .NET being used to give some real-world context.

I have a load of notes on the Keynote version of the slides and I'm going to put one or more essays together that cover the content in more detail. In the meantime, you can view or download the slides.

Simplifying deployment

Thu, 24 Sep 2009 15:29:58 GMT

We had an interesting discussion about simplifying deployment on the training course last week and I thought it would be good to re-iterate some of the points here. As part of the course, everybody is asked to put together an architecture for a small case study that can be decomposed into two major components. One of these is a scheduled/batch component responsible for processing some input files and the other is a user interface for users to modify some of the configuration used during the processing step. We've seen many different architectural approaches to solving this case study although it's natural for people to think about them as components that are deployed separately. One typical example is a Java web application providing the user interface and a separate standalone Java program initiated by cron for the batch processing. Another option would be an ASP.NET application and a Windows service.

We have a similar situation on one of my current projects. The main part of the system is an n-tier web application where the ASP.NET pages use WCF middle-tier services, which in turn communicate with either a backend system or a SQL Server database. There's also a batch element to the system, where a job is scheduled on the SQL Server box to look in the database and perform a very small amount of batch processing (in this case, generating files for onward transmission to another system). At a predefined interval, SQL server starts a standalone program up that looks for work to do, performs that work and then shuts down. At the next occurrence of the interval, the job is started up again.

In both of these cases, the architecture works and the use of a scheduled job means that we don't need to worry about failover and fault tolerance so much. If the job fails or crashes for some reason, the next run of the schedule will restart the process meaning that we don't (necessarily) need to worry about transient problems. We do need to make sure that the process initiating the scheduled job is always running, but typically this is something like an operating system or database, which are themselves usually monitored. One of the trade-offs with this approach is monitoring of the actual job though. Because such jobs are normally standalone programs that simply get executed on a scheduled basis, they have a very short window in which they are active and can be proactively monitored.

Another trade-off is that we've introduced a slightly more complicated deployment process. Okay, so it's not complicated to install a standalone application in the right place and schedule it to run, but we do have another *step* in the deployment process. In the case of our real-world system, we've put a lot of effort into making the build and deployment process as streamlined as possible for the majority of the application, but sometimes we even forget to deploy the scheduled job! Partially this is because it rarely changes, but it's also because it sits on the edge of the overall architecture. It *is* an important component, but it's not immediately apparent if it stops working because (for example) the underlying database schema has changed. We tend to notice the website not working though.

We're currently working on some new functionality that will see the introduction of another scheduled job into the architecture. In this case, we want to send e-mail from our application and have chosen to write e-mails into the database on an immediate basis so that they're captured, with a separate job sending them on a scheduled basis. With an existing scheduled job in place, it's very tempting to follow the same approach and build another standalone application that hooks into the same scheduler mechanism. But in doing this, we now have two components that we could potentially forget about and we've introduced yet another step into the deployment process.

This is one of those occasions where you can do some refactoring at the architecture level and simplify the deployment model by moving the scheduled jobs into our existing middle-tier. After all, it's a long running process with a very well understood build and deployment process, plus we have some bespoke diagnostics to monitor the status of the services it provides. Moving these standalone jobs into the middle-tier has been achieved by creating a very simple "timer service" framework (a wrapper around the platform provided timers) that kicks off a couple of timers to run the existing code every time an interval elapses. The benefits of doing this are that we've (a) simplified the deployment process and (b) we've introduced the ability to integrate these scheduled services with our existing middle-tier diagnostics.

Coming back to the case study in the training course, again, merging both of the batch and UI components into a single process is a great way to simplify the deployment for what is essentially a very simple system. This also provides additional benefits when the operations and support team aren't familiar with the technology, perhaps because you're introducing something new to them. Logically, the batch and UI components are very separate in their behaviour and responsibilities, but this is one of those occasions where bringing the logical design back to reality can help you identify opportunities for simplification. The logical to physical mapping doesn't have to be one-to-one.

Software architecture training in London

Tue, 01 Sep 2009 19:32:00 GMT

The next run of our software architecture training course is taking place at Skills Matter in London on the 15th and 16th of September. I posted a short review of the June 2009 course a while back but it's aimed squarely at software developers that want to get into software architecture and become more "architecturally aware". We like to think that our approach to software architecture is down to earth and pragmatic, while our training approach is a refreshing change:

This workshop is completly different from what you are used to where you are sent by your company to be trained. You don't arrive, sit down, listen and leave the room being an architect. Instead you only go through 50 slides in two days, and spend your time working in small groups and interacting with the others. At the end you leave the workshop with your head full of ideas.

We have some time in the schedule for one or two presentations so I might provide a preview of Documenting your software architecture - why and how? or Broadening the T, which I'm presenting at the Software Architect 2009 conference at the end of the month. Either way, I'm sure there'll be some great discussion about software architecture.

You can book online via the Skills Matter website, and the price is £1095.

To SQL or not to SQL?

Tue, 21 Jul 2009 10:07:00 GMT

Eric Lai wrote an interesting article for Computerworld entitled No to SQL? Anti-database movement gains steam that highlighted the small but growing trend for not using a traditional relational database for managing data. Nati Shalom's No to SQL? Anti-database movement gains steam - My Take is a good follow-up.

I'm sure that most of us have good experiences of using a relational database in our projects and, despite the pain of sometimes mapping the data into a relational schema, relational databases provide an easy to use known quantity for managing data. With this in mind, you should certainly let your experience guide you but bear in mind that relational databases aren't the answer to every question.

The case study that we use as a basis for the exercises in our software architecture training course is relatively small yet most people decide to use a relational database to store the data without really giving the alternatives a second thought. Most of the time it comes down to experience in that most people are comfortable with using a relational database in their architecture. But there are many viable alternatives; from using flat files and object databases through to in-memory data structures, data grids and the cloud. So while relational databases might be a solution for your particular problem, it's always worth spending a couple of minutes assessing whether they are the *best* solution. Here are some things to think about before deciding on whether to go down the SQL or non-SQL route.

Do you have special non-functional requirements that would be hard to satisfy with a relational database? (e.g. high performance/low latency, massive scalability, etc)
What is the available skillset of the team?
Do you have existing licenses for an RDBMS?
Could an open source RDBMS be appropriate?
Do you need to access legacy systems where the data is already in an RDBMS?
Do you have the hardware available to run an RDBMS?
Do you already have existing backup and archival processes and procedures for relational databases?
What are your management information and reporting requirements (scheduled and ad hoc)? Is it possible to satisfy these with a non-SQL solution?
Do other systems need access to your data via a SQL interface? (a service gateway might be a better approach, but that's another issue)
Do you have data migration requirements from an existing relational database?
Can the data management problem be split up into transactional and non-transactional partitions, maybe using a relational database for only one of them?
Do you really *need* persistence?

Relational databases are established mainstream solutions that are applicable in many cases. Just don't forget that there are other alternatives too.

A developer's guide to load testing - video

Mon, 15 Jun 2009 22:27:51 GMT

Just a quickie ... the video from A developer's guide to load testing at Skills Matter last week is now available to view online. The microphone picked up the questions and comments quite well, which is excellent. Enjoy, and feel free to use the Google Group to continue the discussion.

Thanks again to Skills Matter.

June 2009 training course

Fri, 12 Jun 2009 22:06:00 GMT

I ran our From Developer to Architect training course (Coding the Architecture Workshop) earlier this week at Skills Matter in London. 8 people came along, all with slightly different levels of software development/architecture experience and technology background. Historically this course has predominantly attracted people with a Java background, although this is starting to change with more people having experience of the .NET framework. As Antonio Goncalves mentions in his blog entry about the course:

This workshop is completly different from what you are used to where you are sent by your company to be trained. You don't arrive, sit down, listen and leave the room being an architect. Instead you only go through 50 slides in two days, and spend your time working in small groups and interacting with the others. At the end you leave the workshop with your head full of ideas.

If you've been along to one of the Coding the Architecture user groups then you'll know what to expect from this course. There's an element of presentation to set a baseline level of knowledge, but most of the course is very interactive and collaborative, with a focus on nurturing discussion rather than just being a 2-day question and answer session. From my perspective, it's a fantastic course to run because even *I* leave the workshop with my head full of ideas! There's some interesting discussion on TWiT 197 on how education should be less about learning how to pass exams and more about creativity/thinking for yourself. This is exactly the rationale behind our course too.

You can find more information about what the course covers on our training page, but I wanted to share some insight into the case study exercise. It's a collaborative exercise where groups are asked to define an architecture from a small set of functional and non-functional requirements. Given that everybody has different backgrounds and experiences, there's no right answer and the range of technical solutions can often be quite vast. What's important about the case study is looking at how to approach the architecture definition exercise ... which inputs to consider, where to start, how to convey the architecture, what level of detail to go to and, of course, which technologies to choose. The file linked below includes some of the diagrams produced as part of the case study; highlighting the different views, level of detail and notation used to convey solutions.

Diagrams from our "From Developer to Architect" training course (ZIP, 2.7MB)

Even without knowledge of the case study, the diagrams illustrate the variation in how architecture can be conveyed. Expect some essays about this and our overall approach to software architecture in the future; and feel free to get in touch if you have any questions about the course or how we can help you with your own software architectures. Oh, and thanks once again to everybody that came along and made it such an enjoyable couple of days. :-)

A developer's guide to load testing - slides

Thu, 11 Jun 2009 18:40:49 GMT

Thanks to everybody that came along to the CTA user group earlier in the week. The tube strike may had reduced the numbers but we still had some great discussion about load testing. My slides are available to download (~4MB) and if anybody wants to continue the discussion, please feel free to use the Google Group.

A developer's guide to load testing (PDF, ~4MB)

I'll post an update when the Skills Matter podcast/video is available to view online.

A developer's guide to load testing

Tue, 02 Jun 2009 08:39:00 GMT

Here are the details of the June 2009 London User Group.

Title : A developer's guide to load testing
Summary : Load testing is an often forgotten and seemingly difficult task that many people shy away from doing. It doesn't have to be this way though, with a basic level of load testing often enough to give you confidence that you've satisfied your non-functional requirements around performance and scalability. This session will look at load testing a website from a developers perspective. We'll look at the differences between load testing, stress testing and soak testing along with a hands-on demonstration of an open source load testing tool that you can use to get started. If you're building websites in Java, .NET, PHP or indeed any other programming language, this session will show you how easy it is to load test your website.
Date : Tuesday, 9th June 2009
Time : 18:30-20:00
Location : Skills Matter, 1 Sekforde Street
Format : Presentation and discussion, with further discussion in a local pub (The Crown).
Cost : Free, but registration is required.

Many thanks to Skills Matter for sponsoring the user group.

p.s. this session is being run after the second day of our software architecture training at Skills Matter in London ... there are a couple of places left if you want to come along and learn about software architecture.

Interview from DevWeek 2009

Wed, 20 May 2009 21:55:00 GMT

Eric Nelson from Microsoft interviewed me at the DevWeek 2009 conference about our software architecture workshop, transitioning into an architecture role and whether architects should code. Take a look ... it's a nice overview of our approach to software architecture and to training software developers to be more architecturally aware.

There are some other interesting interviews from DevWeek 2009 on the YouTube channel too. Thanks Eric!