October 2008 Archives

For this entry I thought I'd take a break from the typical SaaS performance/delivery/design entries to something a little different:  resume styles for IT / Sys Admins.  In the 10+ years I've been in the industry I've had the (dis)pleasure of interviewing something along the lines of 150-200 potential sys admin candidates, along with having to read something like 500 resumes.  I fully concede that there are others who have read/interviewed way more than I have, but since my resume gets complimented and imitated fairly often by my friends and colleagues, I thought I'd share how mine is structured.

My approach was to keep it simple, with (what I feel to be) the more relevant things up top, and scaling down to the less relevant things.  (Note: my resume is at www.eliminated.org/resume.php, feel free to provide any comments or feedback.)

----- Resume Layout -----

NAME (bigger font than anything else on the page, but not distastefully so)
contact info (in smaller font than anything else on the page)

Profile
I know a lot of people hate these "this is who I am in a nutshell" sections but I feel like this is a good place to give your audience an idea of who you are and where you see yourself going.  Anything more than a 2 or 3 sentences becomes a bit much to digest, and if you find yourself needing more than 2 or 3 sentences then maybe it's time to re-think what it is you'd like to get across first.

Skills / Knowledge
Next to your name and how to get ahold of you, this is the next most important section for a tech resume.  By the time a company gets around to interviewing someone for a position they usually have a decent idea of which skills would be required.  Providing a brief and easy to read summary of what you know will allow someone to gather this information about you in a very little amount of time.  A little sub-categorization is nice here, depending on your focus.  For example, don't put "Office 2000/2003" in the same category as "Apache 2.x"- these are significantly different technologies and realistically anyone who cares about one isn't going to care as much about the other.  On my resume, you will find the following sections: Operating Systems, Programming Languages, Software, and Services. 

Recent Experience
This section is what most people think of when they think resume.  Here, list your -relevant- job experiences, with 2-3 highlights from each job that you believe are indicative of your best/most employable qualities.  I would say that 2 or 3 of your most recent relevant jobs should be more than enough for a clear indication of what you are capable of.  A lot of times people have way too many jobs in this section, and list way too much about the specifics of what they do.  I tend to speak broadly enough that 1) someone with a non-technical background could accurately convey what I do, and 2) shows the scope of what I've done.  A good rule of thumb seems to be that if you can't describe it in one sentence, then you need to re-consider what you're trying to say.

Education, References, etc.
These sections are more there for formality than anything else.  If you have college degree, list which college, the year you graduated in, and which degree you have.  I've seen resumes that listed the fraternities/clubs that that someone belonged to, and frankly, it's just not all that important in the decision making process. 

For references, a simple "References available upon request." is more than enough.  If a company wants you bad enough they will call you and ask for the data.  This is also a good control loop to put around access to your references.  These people are (hopefully) people with whom you've made a positive impression; you don't want to lose that because they are now getting spammed because of you.

If you need more space to fill, then you could put in anything else you feel might be relevant.  For example, I put down that I'm fluent in Mandarin Chinese.  This skill isn't something I hope to have to count on for a job, but it shouldn't hurt and really can only help.

I think one of the main problems with Sys Admin resumes that I've seen is that SA's typically (or stereotypically) aren't the kind of people who are all that great with marketing themselves.  The problem is that in order to get better jobs and to climb that proverbial ladder, you have to convince people who ARE good at marketing themselves that you too are worth it.  There are lots of ways most people could market themselves better, but at the end of the day, the first thing a prospective employer will see is your resume, and you should make that a top priority to get in order.

I welcome any feedback and suggestions that anyone reading this may have, since I don't work in HR and don't claim to have all the knowledge in their arena.  I do believe, however, that you should keep your resume up to date and accurate even while not searching for a new job. 

Scaling websites that deliver static content has sadly become an old trick.  Anyone who has ever heard the letters CDN used next to each other can put together an intelligent solution for scaling static content delivery.  However, what happens when a web application that requires "sticky sessions" needs to be horizontally scaled?  Even Akamai (the only CDN with a dynamic acceleration product) necessarily forwards all of the dynamic requests back to origin.  While they do lessen the load on origin servers, the very nature of dynamic applications is such that all the processing needs to be handled by -your- servers.

Despite the fact that this entry will focus explicitly on how to do this with .NET applications, the approach to this problem is basically the same, no matter which middleware you use.

In essence, when a user signs into an application using sticky sessions, the user is assigned a cookie that identifies the session.  The server also needs to know about this, since there are server-side controls, such as session timeouts, etc.  In .NET the "session" is known as "state" and the server-side controls are governed by config files scoped by the server (machine.config) or the web app itself (web.config). 

Microsoft provides a few different ways of managing state.  At the highest level, the distinction is drawn between "InProc" (local server memory) or not.  The InProc model is a monolithic one, essentially designed for a one server + failover scenario.  While this is fine for redundancy, this will not help if your user load overwhelms that single server.  

If you do not use the InProc model, Microsoft has provided an ASP.NET state server service, which is a service that will store and retrieve state data from any ASP.NET web application.  They also provide a handful of registry keys with which to tweak the service.  I'm not a big fan of this particular mechanism, since it's very much a "black box" approach.  I've found that utilizing the state server is fine most of the time, but when it doesn't work you are more or less reduced to the traditional Windows troubleshooting method (rebooting).

An alternative for storing state data out of the memory is SQL Server.  You can take any SQL Server instance and create a special state database (the schema for which is publicly available), and then point your web applications to the SQL instance for storing and retrieving state data.  This approach is easier to troubleshoot, since you have the full array of SQL tools available, but it is much harder to setup, and is also slower than the InProc or state server models.  When I've used this in a production environment I found that it worked a little more reliably than the state server, but there was a very noticeable hit on performance.  (Note:  the performance impact can probably be minimized with intelligent coding but that sadly was not an option for us at the time.)

So far, I've written about InProc, state server, and SQL server as methods of storing and retrieving state data.  Another way of scaling your web front-end while ensuring that your end user sessions are not lost is the following:

Say I have a web application, available at http://app.company.com.  I'd like to scale this hostname such that thousands of simultaneous users will not bring my server down, but I'm also sensitive enough to end user experience such that the unreliabe or slower performance of the state server and SQL Server is not acceptable.  Consider the following flow:

1) User loads http://app.company.com.
2) The webserver for http://app.company.com does an HTTP 302 on the end user agent, and sends them to either http://app1.company.com or http://app2.company.com.
3) All further interactions with the end user happens over the hostname http://app1.company.com or http://app2.company.com.

In this scenario, we assume that machines app1 and app2 are fully contained instances of the application you are trying to scale.  These machines should be configured for InProc.  SInce we rewrote the end user's URL in their browser, we can therefore be assured that all following interactions is with app1 or app2 directly.  The downside to this approach is the introduction of a very piece of code:  the redirector.  This code will basically have to round robin through a list of hostnames, and ideally perform some manner of a healthcheck so end users are never sent to a machine that isn't working.  Also, while this approach does not scale forever, it does introduce extra layers of scalability which can be used (load balancing to a pair of redirector servers, etc, ad nauseum).

While some of the methodologies discussed here are specific to the .NET framework, most MW tiers have the ability to maintain state in something other than local memory.  The redirector approach is completely agnostic and should be applicable to most any scenario, but as always, none of the stuff I discuss here is an endorsement of any sort, these are more a synopsis of my experiences in having worked with this stuff for a relatively high volume environment with (what I consider to be) unreasonable demands ;)