Recently in Professional Services Category

I like working with grownups.

Here's an example:

When I was a wee little New Hire at my current employer, one of the things that came up a lot was the "15 minute rule." That is, if you're stuck on a problem, take a solid 15 minutes to bash your brain against it in whatever manner you see fit. However, if you still don't have an answer after 15 minutes, you must ask someone. I shorten this down to "You must try, and then you must ask." It's a simply-worded rule, which works something like this:

1. If you've hit the point of giving up, you have to push yourself for another 15 minutes. The pressure is now off. You know that in 15 minutes, you'll be able to take what you found and talk to another person about it and get their help. For right now, all you have to do is step back and look at the whole problem from the top. Maybe you'll find the solution that was sitting there all along. Maybe you'll convince yourself it's completely unsolvable. Whatever you end up doing, those next 15 minutes are where you look at the problem one more time.

2. During those 15 minutes, you must document everything you're doing so that you can tell someone else. So, what does "look at the problem one more time" mean? It means taking notes. Lots of them. I'm a big fan of using a paper notebook with an excruciatingly fine-point pen, because I don't need to move windows out of the way to keep writing in it, and I can fit a lot of words on a single page. Use what you like, but keep writing. Write down all the steps, all the assumptions, everything you tried, and anythingyou can do to reproduce the problem. More likely than not, you've now probably figured out at least one other way to solve the problem, just by getting it out of your head and onto paper.

3. After that, you must ask someone for help. Okay, you've decided you need help, and you've spent another 15 minutes looking at the problem again (and again (and again)),and you've documented your approach.

   Now, stop.
   Stop trying to solve the problem, if only for a moment.

   Call for help. Even if you think that you almost have it, stop. Even if you think that an incarnation of the wisdom of the masters is perched on your shoulder whispering the answer in your ear, stop. Write that email or walk over to the office/cube/etc. or cast the appropriate summoning spell, but make sure that someone else knows that you need help. Request assistance, state the problem, and show your work. You may not get help right away, but now you've employed at least one other brain in helping you, and now they have a great head-start, courtesy of you.

So, that's the 15 Minute Rule in 3 easy steps.

Here's why it's important:

1. Your paid hours are costing someone money. You can be in a Professional Services Organization, an internal IT organization, or an independent contractor, but it all works out to the same thing; someone is paying for your skills. While it may feel good to figure out the answer on your own, there's no medal for wasting 3 hours worth of money on a problem that doesn't merit that kind of time. In a sneaky way, this also helps you value your own time, if only by making you ask yourself "Is this problem worth this much of my time?"

2. Your colleagues will help you because they're playing by the same rules. This means they're used to asking and listening to informed questions, and they'll be expecting the same from their peers. Needless to say, use your common sense... find someone that isn't heads-down in a problem of their own; no one likes to have their flow interrupted. That being said, your colleagues will know that if you come over to ask for help, you'll already have taken time to look it over and documented your findings so they can help you figure out the problem faster or point you in the right direction. It's possible you'll end up Rubber Duck Debugging the problem, and the act of talking through the problem will help you solve it.

3. Last but certainly not least, You have to interact with your colleagues because they have the answers you need. Building and maintaining an enterprise software platform (to choose something of appropriately fiendish complexity) is not a solo sport. Your colleagues have different ways of understanding problems and different ways of using the knowledge they have. This goes for many definitions of colleague and many definitions of knowledge.

This eventually turns into a virtuous cycle. People value each others' time and their own, so they do their own homework before asking a question. In turn, people are more likely to answer questions because they know the person asking will give them the interesting part of the problem to solve.

Put another way: by explicitly taking enough time, everyone saves time.

Matt Ringel is Enterprise Architect in Akamai's Professional Services team

The following is a guest post from Director Global Service Delivery Patrice Boffa and Associate Solutions Architect Seema Puthyapurayil.

We know that the average page size tends to increase overtime; we can confirm this statement using the available Web performance data in Google BigQuery and HTTP Archive. 

Analyzing the HTTP Archive data for + 300,000 popular sites in the last nine months, we can validate that the average page size increased by about 20%.

Total Bytes per Web site

Being the market leader we are constantly challenged to prove our acceleration services can improve the performance of any Web site. 

What public data is available to validate the fact that Akamai can make Web site faster even if they improve their page sizes?

To answer the question, we query HTTP Archive for the latest 1,000 Web sites that started using Akamai services in the last nine months. The HTTP Archive recorded the Web sites information twice a month and we analyzed the data before and after turning on Akamai services for those 1,000 Web sites. 

Fully loaded time

We decided to focus on "Fully Loaded time" that is measured as the time from the start of the initial navigation until there is 2 seconds of no network activity after Document Complete.  This will usually include any activity that is triggered by JavaScript after the main page loads.

The results for those 1000 Web sites show about a 35% fully loaded time improvement, it's a good number but we were expecting better.

Total Bytes per page

We also looked at the "Total bytes" per page to validate that if we were comparing "Fully Loaded time" numbers, we were actually downloading the same amount of data with Akamai than without Akamai.

The analysis results show on average a 4% increase in the page size the month after customers start using Akamai. 

SpeedIndex

The last metric we decided to look at is the "Speed Index", the Speed Index measures rendering speed; it's the average time (in milliseconds) at which visible parts of the page are displayed in the user browser. This gives a measurement around the user's perception of Web site speed.

The data shows on average an improvement of 12% of the Speed Index if we compare the before and after Akamai.

Akamai Professional Services team is key in helping customers get the most performance from their Web sites, by assessing their current applications and advising on the high performance best practices observed across the industry, tailoring them to our customers specific initiatives while helping them accomplish their performance goals efficiently.

Yes - you can increase the size of your page without affecting your performance by using Akamai delivery services. The analysis of a larger sample of Web sites (1,000 sites) over the last nine months using public accessible data (HTTP Archive and Google BigQuery) validated that Akamai services have successfully accelerated Web sites performance. The two main conclusions are that Akamai improves:

• Akamai improves the overall Fully loaded page times and the Site Speed Index considerably. 
• The improvements of those two indicators seem to allow our customers to provide a more rich experience to their end-users by increasing the Total Bytes per page.

The following is a guest post from Senior Enterprise Architect David Senecal and Sr. Solutions Architect Aseem Ahmed

Recent years have been very dramatic in security landscape with emerging threats; the application layer is now a more prominent target.  The new (and deadly) Layer 7 attacks called slow HTTP Denial of Service (DoS) attacks are on the rise.  Although they are not as new as they might sound, anything that is not frequently spoken of in the security world is often new!

In my experience, the common perception of DoS is a volumetric attack that occurs quickly, not slowly.  Traditionally, DoS/DDoS attacks have been volumetric, required a large number of clients and could be geographically distributed.  But slow attacks that consume minimal resources/bandwidth from the attacker side can still bring down your Web server. 

Here are the results of using slowhttptest against a vulnerable apache server in our lab environment.  The snippet below shows the tool in action where new connections are established very quickly with the server.  The Web server becomes unavailable after 5 seconds of launching the attack.

The HTML screenshot below shows the results of the same test.  The tool opens 1000 connections with rate of 200 connections per second, and the server is able to concurrently process only 351 connections, leaving the remaining 649 connections pending. 

Why is this a problem?

• These connections look like legitimate user connections.
• Traditional rate detection techniques will skip them.
• Existing IPS/IDS solutions that rely on signatures will generally not recognize them either.
• They require very few resources and little bandwidth for execution.
• Such attack can bring down a Web server, irrespective of its hardware capabilities.

How do these attack work?

Slow HTTP DoS attacks rely on the fact that a Web server will faithfully honor client requests.  The attacker's motive is to send a legitimate-looking request to keep the server resources busy handling said requests for the longest time possible. If the attacker keeps adding to such long-ended requests, the server can quickly run out of resources.

Slow HTTP Denial of service attacks have different variants, but before we get into the details, let's review the normal HTTP structure and flow:

Request

Response