Design software as a long running process
Relying on restarts is bad software craftsmanship
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.
Software architecture manifesto
Taking some inspiration from the recently published SOA and FAIL manifestos, I thought I'd have a go at writing my own for software architecture.
- Some up-front architecture over doing the whole lot or none at all
- Designing for non-functional requirements over trying to tack them on at the end of the project
- Evaluating technology over just choosing it because it looks good on your CV/resume
- Experimentation over hoping your design will work
- Code over endless discussions, meetings and diagrams
- Collaboration over ivory tower dictation
- Involvement over running away and letting the team deal with the "implementation" problems
- Coaching team members over stroking your own ego
- Pragmatism over perfection
- Real problems over intellectual (self) stimulation
- Simplicity and common sense over complex and convoluted ideas
- Short and useful architecture documentation that reflects reality over encyclopaedias that nobody reads, understands or cares about
Humour aside, this does reflect my view of the role of a software architect. What else would you include?
Software architecture for developers
A two day training course to broaden your software development skills
We've been running our software architecture course for a couple of years now and although we've consistently received very positive feedback, we're always looking for ways to improve it. And that's exactly what we've done over the past few weeks.
First of all, the name of the course has been changed to "Software architecture for developers" as it better reflects the intent of the course, which is about broadening people's software development skills and making them more architecturally aware. We want people to better understand how to make design decisions on software projects and be more confident that their choices will work.
The other major change to the course is that the structure now reflects the new organisation of the website, where content is broken down into the following categories:
- What is software architecture?: This category covers all of the basics such as what software architecture is all about and why it's important.
- What is the role of a software architect?: This is probably the largest category on the site where you'll find lots of discussion about what software architects (should, in our opinion) do.
- How do you define software architecture?: This category is about putting software architecture into practice, where you'll find articles about what drives architecture, technology selection, dealing with non-functional requirements and so on.
- How do you share software architecture?: Having a software architecture is only part of the puzzle and this category is all about collaborating, documenting and sharing it.
- How do you deliver software architecture?: The final category is about delivering the architecture; covering aspects such as process, methodology, evaluating and testing architectures.
In addition, more exercises have been introduced and we now have more dedicated content to delve into things like creating software architecture documentation and evaluating software architectures. This content *was* included before through a number of supplementary presentations, but the new structure gives these topics their own focus. You can take a (thumbnail sized) peek at the slides and you can find more detailed information about the course at http://www.softwarearchitecturefordevelopers.com. The next public runs of the course this year are the 8th of December (London) and 14th of December (Paris), but you can see the Skills Matter website for other dates.
Feel free to get in touch (e-mail or Twitter) if you have any questions or would like talk about a private/internal run of the course for your team.
Software architecture document guidelines
Guidelines for creating your own software architecture documents
Back in March last year we published an initial set of software architecture document guidelines and I thought that it was time for an update. There are no major changes although I've modified some of the section headings so that you can use this as a complementary resource to the slides from my Documenting your software architecture - why and how? presentation. As before, I hope you find these resources useful in creating your own software architecture documentation.
Strategy rather than code
Is enterprise architecture the next step for your software career?
There are many different types of architecture and many names to describe the same thing. This essay summarises application, system and enterprise architecture before looking at whether enterprise architecture is the next logical step for people on the software architecture career path.
The code doesn't tell the whole story
We all know that writing good code is important and refactoring forces us to think about making methods smaller, more reusable and self-documenting. Some people say that comments are bad and that self-commenting code is what we should strive for. And I don't disagree. Everybody *should* strive for good code that's easy to read, understand and maintain. But the code doesn't tell the whole story.
Documenting your software architecture - why and how?
Describe what the code itself doesn't
Another of the sessions that I delivered at the recent Software Architect 2009 conference was entitled "Documenting your software architecture - why and how?" and covered some of the drivers for creating software architecture documentation along with some guidelines on how to do this. As I said in the session, any software architecture documentation should be complementary to the code and describe what the code itself doesn't. For example, it's really hard to identify things like architectural principles, operational aspects and how security works from just the code itself.
As with Broadening the T, 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.
Broadening the T
A breadth of experience is key
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.
Site updates
Making it easier to find stuff!
As you may have noticed, I've been making a few updates to the site recently with the goal of making content easier to find. We've accumulated some excellent content over the past few years and much of what we wrote about when we started the site is as relevant now as it was then. The site started out purely as a blog and while this makes the addition of content really easy, the older content tends to fade into the background. Part of what I've done is review and (attempt to!) organise the majority of the content into five key categories, which should make it easier for you to find specific types of information. They are...
- What is software architecture?: This category covers all of the basics such as what software architecture is all about and why it's important.
- What is the role of a software architect?: This is probably the largest category on the site where you'll find lots of discussion about what software architects (should, in our opinion) do.
- How do you define software architecture?: This category is about putting software architecture into practice, where you'll find articles about what drives architecture, technology selection, dealing with non-functional requirements and so on.
- How do you share software architecture?: Having a software architecture is only part of the puzzle and this category is all about collaborating, documenting and sharing it.
- How do you deliver software architecture?: The final category is about delivering the architecture; covering aspects such as process, methodology, evaluating and testing architectures.
At the moment, the first two categories have landing pages that summarise some of the key content and link to some of the other resources that we have such as presentation slides. I'll be doing the same for the other categories over the next week or so. If there are any articles or blog entries that you think are particularly worth highlighting, please let me know.
Simplifying deployment
The logical to physical mapping doesn't have to be one-to-one
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.
