http://www.winnersdontlose.com/ A gathering of rants, raves, and sometimes useful information. en-US Copyright 2008 Fri, 17 Oct 2008 11:38:23 -0800 http://www.sixapart.com/movabletype/ http://www.rssboard.org/rss-specification
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. 










]]> http://www.winnersdontlose.com/2008/10/it-sys-admin-resume.html http://www.winnersdontlose.com/2008/10/it-sys-admin-resume.html IT job hunting resume systems administrator Fri, 17 Oct 2008 11:38:23 -0800
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 ;)

 


]]> http://www.winnersdontlose.com/2008/10/sticky-sessions-and-scalabilit-5.html http://www.winnersdontlose.com/2008/10/sticky-sessions-and-scalabilit-5.html .NET CLR CDN scalability sticky sessions Wed, 08 Oct 2008 10:50:30 -0800
Akamai's approach is a generalized caching and forward mechanism layered on top of their SureRoute platform.  While this is effective en masse, there is a lot of room for targeted improvement.  The knobs and switches provided for WAA are mostly time to live (TTL) settings and other caching options.  Those of us wishing to go for a more controlled, targeted application acceleration network were historically left on our own, working through WAN replication, database sharding, and other "good enough" type solutions.  Thankfully, application acceleration and end user experience management has become a bit of a hot topic in 2008 and now the big networking companies (F5, Citrix, etc) are all developing product lines aimed at accelerating dynamic applications. A potential sleeper in this race is StrangeLoop (well, for .NET applications  anyways [for now?]), whose approach is very easily adaptable for a hosted (CDN) scenario.

In order to convey the approach behind this design I will provide some examples of products currently on the market (which is not an endorsement of any sort).

This approach requires a separation of presentation and data access.  Basically, your front-end webservers (hosting the application you're trying to accelerate) needs to be able to access a data access tier, who in turn makes requests directly to your data store (usually a database).  This is a very common approach and allows for back-end operations to be managed independently of the front-end.  Typically, messages passed between front- and back-end servers via SOAP or something similar.  If we're going to push these over WAN, 128-bit SSL is a minimum (alternatively, you could pipe these requests through an SSH tunnel). .

Since the end user's experience deals largely with your front-end servers, a concept called TCP multiplexing or connection pooling decreases end user render time.  This feature is available on any layer-7 capable load balancer, like the Citrix NetScaler, or the A10 load balancers.  To most effectively utilize a WAN accelerating appliance like the Citrix WANScaler or F5's WANJet, data access requests from presentation servers should also be multiplexed into one persistent connection back to your data access servers (so you only move large amounts of data between the database and data access, which should be physically near each other).

If possible, the interfaces used for acceleration to origin should be separate from those serving end user requests.

With this approach a company utilizing WAA can reduce their cost of goods sold by only targeting regions where business is conducted.  While there is an upfront investment of hardware, ongoing operations should be much cheaper, with a speedier end user experience.

]]> http://www.winnersdontlose.com/2008/03/diy-application-acceleration-n.html http://www.winnersdontlose.com/2008/03/diy-application-acceleration-n.html application acceleration content delivery network end user experience SaaS performance WAN acceleration Thu, 06 Mar 2008 20:25:48 -0800 Technorati Profile

]]> http://www.winnersdontlose.com/2008/03/welcome-technorati.html http://www.winnersdontlose.com/2008/03/welcome-technorati.html technorati Sun, 02 Mar 2008 22:42:57 -0800
Typically, end users, who are considered as being part of the "last mile," experience greater latency and/or packet loss (resulting in poor end user experience) by going beyond the "edge."  Without an edge delivery service, end users have to go from the "last mile," to the "edge," to the "middle mile (depending on who you ask and where the end user is)," to the "backbone." 

Note:  Anyone concerned with end user performance should get transit from a major backbone provider in order to deliver the fastest possible to the most networks.  Static edge delivery will still shave time off of the overall transaction but the performance benefit is greatest when the origin is on a major backbone, or someone like InterNAP.

Most of the above-mentioned services work by having a number of servers strategically located in the major edge networks which cache the static content going out to the end users.  If a file is being requested for the first time (from the perspective of the edge server), a request is made back to origin for the file and then transparently sent to the end user.  From that point on, the accessed edge server will cache a copy of whatever files were requested for a configurable period of time (cache TTL).

In order to not impact end user experience when requesting a file that the edge doesn't have, the origin request is accelerated through what is usually a proprietary network acceleration algorithm.  In a nutshell, the CDN companies rely on an algorithm faster than BGP in order to appear seamless.  Akamai, for example, utilizes their SureRoute platform as the cornerstone of most of their acceleration services.

A typical end user transaction for static content delivered by edge servers looks like the following:

- user requests some URL which is accelerated at the edge
- the user is directed to the fastest local edge server, as determined by the CDN provider, either via BGP Anycast or DNS redirection
- if the edge server in question doesn't have the requested content, the edge server makes a request to origin on an accelerated and/or optimized path
- once the edge server has the data requested, it is cached per policy and served to the end user

It's worth mentioning before we get any further that hostnames and URLs are what is accelerated, not networks, servers, or anything along those lines.

If we assume the user to be in New York and the origin to be in San Francisco, we are able to shave a lot of time off in the transaction.  A request spanning the width of this country, on average, takes something on the order of 200ms.  That's 100ms spent going from NY to SF and another 100ms spent from SF to NY.  While 200ms isn't a big deal for most people, keep in mind this is 200ms for each and every request on the page.  So if you host a website with 50 10k images, end users in NY will have to wait a theoretical maximum of 10 seconds just for network latency.  (Since we're assuming static content here origin server performance is rarely an issue.)  For comparison, routing to the edge of Comcast's residential cable network in SF takes something like 15ms.  For the example above, the same 50 objects will take less than a second (~750ms) to download in an edge delivery scenario.  There is a slightly longer latency for files being requested for the first time but that should only affect one user once, with all subsequent requests happening at accelerated rates.

Please do not consider the CDN references above to be an endorsement of any type.  I am only trying to relay information, it is up to you to find the best network to suit your needs.


]]> http://www.winnersdontlose.com/2008/03/how-it-works-static-edge-deliv.html http://www.winnersdontlose.com/2008/03/how-it-works-static-edge-deliv.html edge acceleration end user experience SaaS performance Sun, 02 Mar 2008 10:44:45 -0800
For web-based applications, the following almost always happens (regardless of industry, form, or function):

Steps (necessarily very high-level)
1) user pulls up some hostname (app.company.com) in a browser
2) user sees a page, usually a login page, accompanied with text and images
3) user logs in and proceeds to use the application in any number of ways

Since these three steps are effectively universal in SaaS, it is worth our while to analyze these steps in an effort to increase the accessibility of these things from the edge.

Analysis
1) An end user typing a hostname into the address bar of his browser and clicking "go" triggers a number of events.  First, the hostname typed in needs to be resolved to an IP address via DNS.  Once the IP is known, our end user connects to the IP requested, and issues HTTP GET's based on the server response (HTML).

Leveraging an edge DNS service, such as Akamai's eDNS service, will ensure that a nameserver most accessible to the end user will pick up the request and respond.  This is theoretically faster than having ns1.company.com hosted in Silicon Valley with end users in New York.  With eDNS, users in New York will have their requests answered by servers which are usually physically much closer, and therefore faster.

2) An end user downloading and rendering the login page of a web-based application is probably the easiest part to deal with.  Since there's nothing user-specific at this point generally object here are statically cacheable.

Leveraging an edge HTTP content delivery service, such as Akamai's EdgeSuite service, tries to make sure the end user will be downloading this static content from a webserver cache somewhere closer than the origin.  Static content here typically includes JavaScript, JPG, GIF, PNG, CSS, and text.  Edge delivery services also tend to add gzip compression to these files, reducing data transfer and speed to transfer.  Files are cached for some configurable time and new files are retrieved from origin by the edge servers when an end user makes a request.

This is a well-understood problem and solution, and most CDN's in existence today basically provide this as a baseline service.

3)  Once a user types in their identifying information and clicks login is where the complexity gets introduced.  Usually when a user clicks the login button, there's a database lookup to validate user-supplied credentials, a session is instantiated for the user, amongst other things.  In either case, these server-side events require end user interaction with the origin and the edge delivery model above simply cannot handle it.  For this, a new trend in CDN technology has developed in the form of dynamic application acceleration.  Akamai's service in this arena is called Web Application Accelerator (WAA) and utilizes their SureRoute technology to pass end user traffic back to origin and vice versa.  In theory, WAA bypasses the BGP that most providers use by maintaining their own (more optimized) route tables, thereby decreasing the latency an end user experiences.

Since this is a relatively new challenge to address en masse, it's understandable that Akamai's solution leaves a lot to be desired.  However, their service is significantly faster for almost any type of application, and smaller companies simply don't have the expertise or funds to build their own application acceleration infrastructure.  The major online retailers and MMOG operators figured this out years ago and have been building out their own infrastructure, but the cost-prohibitive nature of these undertakings is a large obstacle to overcome.

Interesting note:  there have been more and more companies competing in the application acceleration space with packaged solutions but I think we're still a bit aways from having your average medium-sized SaaS company deploy these things.


]]> http://www.winnersdontlose.com/2008/02/application-acceleration-strat.html http://www.winnersdontlose.com/2008/02/application-acceleration-strat.html akamai application acceleration end user experience SaaS Tue, 26 Feb 2008 10:28:42 -0800 ]]> http://www.winnersdontlose.com/2008/01/first-post.html http://www.winnersdontlose.com/2008/01/first-post.html Tue, 15 Jan 2008 11:17:54 -0800