9-804-158

REV: JUNE 8, 2010

BENJAMIN EDELMAN

THOMAS EISENMANN

ERIC VAN DEN STEEN

Akamai Technologies
It was part of Danny’s vision for the Akamai network that it would be able to handle the greatest stresses
imaginable. On Tuesday, it demonstrated that it could handle the unimaginable.
—Paul Sagan, President, Akamai Technologies1

On September 11, 2001, Akamai co-founder and chief technology officer Danny Lewin died
aboard one of the planes that struck the World Trade Center. In the hours that followed, Internet
traffic spiked as people e-mailed friends and family and turned to the Web for news. Many
companies called on Akamai for help with the unprecedented load on their websites. Akamai’s
network, which delivered customers’ content from thousands of servers co-located in Internet Service
Provider facilities close to end users, performed flawlessly—a tribute to Lewin and his work.

The loss of their brilliant and beloved colleague compounded the challenges confronting Akamai
CEO George Conrades and his team. The U.S. economy was mired in a recession that had hit
technology and advertising markets hard. This increased customer churn, contributing to a 14% drop
in Akamai’s revenue between Q2 and Q4 2001. Revenues continued to decline during 2002. In
response, Akamai cut headcount and other expenses. With ample cash reserves, management
believed that the company would reach cash flow break-even before it needed to raise additional
capital. Nevertheless, many investors had lost confidence. Akamai’s stock price, which had peaked at
$345 shortly after its 1999 IPO (valuing the firm’s equity at $35 billion), reached a low of $0.56 in
October 2002.

While scrambling to cope with this revenue downturn, Akamai managers were also rolling out a
new service that could fundamentally reposition the company. In the first quarter of 2001, Akamai
launched EdgeSuite, which moved the company beyond its traditional role of content delivery into the
assembly, presentation, and delivery of data from the Internet’s edge. By moving Web page assembly
and presentation from a customer’s centralized data center (i.e., the “origin” server) to Akamai’s edge
servers, EdgeSuite could significantly reduce a customer’s expenditures on web servers, data center
space, and technical staff. Such savings would be appealing to enterprise customers, who were trying
to control infrastructure costs.

EdgeSuite was a big success: by late 2003, it accounted for 60% of Akamai’s sales and rekindled its
growth. Revenues for Q4 2003 were up 28% over the prior year, and the company reported its first
________________________________________________________________________________________________________________

Professor Thomas Eisenmann and Research Associate Sanjay Pothen wrote the original version of this case, “Akamai Technologies,” HBS No.
802-132, which is being replaced by this version prepared by Professors Benjamin Edelman, Thomas Eisenmann, and Eric Van den Steen. HBS
cases are developed solely as the basis for class discussion. Cases are not intended to serve as endorsements, sources of primary data, or
illustrations of effective or ineffective management.

Copyright © 2004, 2007, 2010 President and Fellows of Harvard College. To order copies or request permission to reproduce materials, call 1-
800-545-7685, write Harvard Business School Publishing, Boston, MA 02163, or go to [Link] This publication may not
be digitized, photocopied, or otherwise reproduced, posted, or transmitted, without the permission of Harvard Business School.

This document is authorized for use only in Prof. Arunabha mukhopadhyay's PGPII/T4/BDC/2499 at Indian Institute of Management - Lucknow from May 2024 to Sep 2024.
 804-158 Akamai Technologies

positive net income. Wall Street was impressed: Akamai’s stock price rebounded to $14.90 in January
2004, valuing the company at $1.8 billion.

From this more secure vantage point, Conrades and his colleagues planned the next phase of
Akamai’s growth. They envisioned that Akamai would not only move content to the Internet’s edge,
but also transfer application processing tasks onto distributed Akamai servers. As a first step, in May
2003 Akamai and IBM jointly announced that their customers could use IBM’s WebSphere software
development tools to create Java applications that could be run from Akamai’s edge servers. As
Akamai morphed from a content delivery network into an application delivery network, the company
would be positioned to exploit the next wave in the Internet’s evolution: the growth of “web
services,” which used the Internet to exchange data between modular software applications.

Akamai’s application delivery strategy presented important challenges. Web sites used diverse
programming methods, and transferring complicated web sites onto Akamai servers would add
complexity to both setup and maintenance. Should Akamai remain platform agnostic, working with
all web server platforms, including IBM’s WebSphere and Microsoft’s .NET? Alternatively, were
there advantages to allying with just one partner?

Internet Architecture: The World Wide Wait

The Internet’s rapid growth, coupled with its “network of networks” architecture (see Exhibit 1),
led to some serious performance and reliability problems. Analysts feared that the “World Wide
Wait” would worsen with the proliferation of bandwidth-intensive applications such as streaming
media, peer-to-peer file sharing, and Internet protocol telephony.

Users sometimes experienced slow transaction processing at e-commerce sites and were unable to
access websites that had been inundated with user requests. More generally, the Internet was
vulnerable to the loss of data packets as they were routed through the network of networks. Early
Internet transmissions often experienced 25% to 40% packet loss, and users experienced delays when
lost packets were re-sent. 2

These performance problems resulted from three bottlenecks:3

• First mile. The Internet’s first-mile, which included a website’s origin data center and
infrastructure owned by the Internet Service Provider (ISP) that connected the site to the
Internet, had to cope with growing traffic loads. First-mile issues such as web and application
server configuration accounted for 70% of website performance problems.4 Each handoff
within a site’s origin data center (e.g., from load balancers through switches to database servers to
application servers to web servers and back through routers; see Exhibit 1) introduced a slight
processing delay, even under normal conditions. Moreover, when traffic spiked, it could
overwhelm server and switching capacity.

• Middle Mile. Further bottlenecks arose both within the backbone networks that transported
data across the Internet, and at the junctions between such networks.

• Backbone. Fiber-optic lines in backbone networks offered tremendous bandwidth in the

Internet’s long-haul (city-to-city) portions. Backbone networks could still contribute to
performance problems, however, due to normal processing delays as traffic passed
through an average of 17 to 20 routers en route to its destination.5 Traffic spikes could
exhaust router capacity at a given network node. Furthermore, while long-haul capacity
was plentiful, within some metropolitan areas there still was a shortage of bandwidth for

This document is authorized for use only in Prof. Arunabha mukhopadhyay's PGPII/T4/BDC/2499 at Indian Institute of Management - Lucknow from May 2024 to Sep 2024.
 Akamai Technologies 804-158

connecting ISPs, data centers, and NSPs. Local phone companies sometimes required
weeks to provision high-speed lines in metropolitan areas. In the meantime, traffic growth
could cause congestion.

• Peering. Even the largest NSPs had to rely on peers for global data delivery. No one’s
network reached into every market; on average, Internet transmissions passed through
four different networks.6 At Network Access Points (NAPs), large NSPs exchanged traffic
with one another free of charge, a practice called “peering.” NSPs, in turn, charged ISPs
“transit” fees for carrying their traffic over the Internet’s backbone. However, since
peering was free, NSP A had little incentive to give NSP B’s packets a long, free ride on
A’s backbone network. Often, A would hand off B’s packets to NSP C at the nearest
possible NAP. Such “hot potato” routing was done with little concern for overall network
congestion or efficiency.

• Last mile. The Internet’s last-mile, which included the end user’s access device (usually a PC)
along with infrastructure owned by the ISP that connected the end user to the Internet,
introduced potential performance problems. Traffic loads could strain capacity at ISP
facilities, which were called “points of presence” (POPs). Also, when multiple users shared
common bandwidth on a local area network, as with cable modems or office LANs, speeds
slowed when the LAN’s capacity was exhausted. Finally, users with older computers
experienced delays in accessing Internet data due to limitations on PC processor speed and
available memory.

Solutions to Bottlenecks
Telecommunications carriers had made enormous investments in fiber-optic lines to increase
network capacity. However, adding bandwidth could not solve all the performance and reliability
problems described above, so website owners and ISPs turned to other solutions.

Mirroring. Some website owners relied on a do-it-yourself solution called “mirroring,” which
reduced data delivery delays by fully replicated a site’s content at multiple locations, usually data
centers where space could be rented from hosting firms. However, mirroring was costly to
implement because each mirror site required the same hardware and software as a standalone
website, plus hosting fees and extra software for balancing server loads and synchronizing site
content. In fact, because there were scale economies in data center operations, a single large “server
farm” was usually much less expensive than a set of mirrored sites with similar aggregate capacity.

Caching. Caching entailed the temporary replication and storage of Web pages (or discrete
elements of Web pages, such as images or banner ads) at an ISP’s POP. When a user requested a
page, ISP software checked to see if a copy was in its cache. If a requested page was not available
locally, it would be fetched from the website’s origin server. Algorithms determined whether pages
would be retained in the cache—and if so, for how long.

Caching solutions, provided by vendors such as Inktomi and CacheFlow, benefited both ISPs and
content providers. ISPs saved on transit fees that they paid to NSPs and also enjoyed increased
subscriber satisfaction due to speedier data delivery. Content providers appreciated the reduced
loads on their origin servers and improved response times. However, caching had serious drawbacks
for content providers. Stale content could be delivered, since there was no proactive mechanism to
update the cache. Also, caching prevented content providers from measuring and analyzing activity
on their website (including advertisement click-throughs), since they had no ability to monitor an

This document is authorized for use only in Prof. Arunabha mukhopadhyay's PGPII/T4/BDC/2499 at Indian Institute of Management - Lucknow from May 2024 to Sep 2024.
 804-158 Akamai Technologies

ISP’s cache. For these reasons, caching solutions were sold to ISPs rather than website owners. Site
owners expressed their displeasure with caching, but could not prevent the practice.

Content delivery networks. Like mirroring and caching solutions, content delivery networks
(CDNs) distributed copies of Web page elements to the Internet’s edge. CDNs were comprised of 1)
hundreds or thousands of distributed servers located in NAPs and/or in ISPs’ POPs, each of which
held page elements from many different customers; 2) software that ensured that page elements on
distributed servers were synchronized with elements held on customers’ origin servers, to avoid
delivering stale content; 3) algorithms that routed end-user requests to the optimal CDN server based
on network congestion, rather than physical distance; and 4) software that allowed customers to
monitor CDN activity(including advertisement click-throughs). CDN solutions typically were sold to
website owners rather than ISPs. (See Exhibit 2 for a depiction of CDN architecture.)

Akamai, Version 1.0: FreeFlow

Akamai Technologies, Inc.—Akamai is a Hawaiian word that means “clever” or “cool”—operated
the leading content delivery network.7 The roots of the company dated to 1995 when Tim Berners-
Lee, who led the team that devised the World Wide Web in the early 1990s, challenged colleagues at
MIT to find a way to reduce Internet traffic congestion. Professor Tom Leighton of MIT’s Laboratory
of Computer Science and one of his graduate students, Danny Lewin, solved Berners-Lee’s problem.
They observed that half of the information required to present a typical Web page was related to
objects embedded in the page, for example, images and banner ads. The balance was from text on the
page and from HTML instructions used by the browser to build the page (specifying colors, fonts, the
positioning of page elements, etc.). Leighton and Lewin recognized that “heavy” objects could be
tagged and served through a dispersed network of servers closer to end users.

Lewin unveiled this solution at the 1998 MIT $50K Business Plan Competition. Although Lewin’s
entry did not win, it got the attention of Battery Venture Partners and Polaris Venture Partners,
which funded the startup. Polaris partner George Conrades became chairman and CEO. Leighton
and Lewin continued on as chief scientist and CTO, respectively. Berners-Lee served on Akamai’s
advisory board. (See Exhibit 3 for background on top management.)

FreeFlow Business Model

Customers and marketing approach Akamai’s first service, FreeFlow, was introduced in
April 1999. FreeFlow facilitated the delivery of bandwidth-intensive page elements such as banner
ads, pictures, and software downloads. Akamai targeted FreeFlow at the 500 most heavily trafficked
websites and sites run by the 2,000 largest global corporations.

To use FreeFlow, a content provider first tagged the objects that it wanted to serve over the
Akamai network. This process usually took about a week and did not require the customer to
purchase any new hardware or software. While sites could be fully functional within days, Akamai
often worked on an ongoing basis with a customer’s IT staff to optimize performance—especially for
advanced features. Switching to another CDN would require a customer to retag objects and replicate
optimization work. In any case, customers were required to sign up for a minimum usage level on a
contract basis, usually one to three years.

Some sites loaded over 10 times faster after they were “Akamaized.” FreeFlow also protected sites
against sudden traffic bursts. Finally, FreeFlow reduced a customer’s payments to ISPs for
bandwidth, since serving page elements from Akamai’s servers meant that an average of 50% less

This document is authorized for use only in Prof. Arunabha mukhopadhyay's PGPII/T4/BDC/2499 at Indian Institute of Management - Lucknow from May 2024 to Sep 2024.
 Akamai Technologies 804-158

data was sent from the website’s origin servers. Bandwidth costs savings typically did not fully offset
FreeFlow’s cost. Through 2001, Akamai charged about $1,995 per megabit per second (mpbs)
delivered per month, with discounts for volume usage. At that time, data center bandwidth for large
users was priced around $500 per mbps.

This value proposition proved appealing. By the second quarter of 2001, Akamai had signed up
over 1,300 FreeFlow customers, including Internet blue chips such as Adobe, Apple, [Link],
and Yahoo!. In early 2001, Akamai’s 10 largest accounts contributed about 30% of total revenue.8
Akamai generated about 80% of its FreeFlow revenue in early 2001 through a direct sales force with
130 reps; resellers accounted for the balance. Resellers included hosting firms, telecommunications
carriers, and systems integrators such as EDS and IBM. Depending on the services sold and volume
levels, resellers typically received a 30%–45% discount off Akamai’s retail prices.

Network partners Although the four largest ISPs—AOL, Earthlink, MSN, and Prodigy—
served about 81% of U.S. residential Internet dial-up users in mid-2001, they collectively operated
thousands of local networks—each with its own POP. The remaining 19% of U.S. Internet users were
served by several thousand smaller ISPs.9 Due to this fragmentation, a CDN would need servers in
5,500 local networks to access 75% of all Internet traffic.10 When they hosted CDN servers, ISPs
realized transit bandwidth cost savings as well as data-delivery performance benefits valued by their
subscribers. For this reason, Akamai typically was able to obtain data center space and transit
bandwidth free of charge from smaller ISPs, even though data center space was constrained and
costly to ISPs. Akamai compensated many larger NSPs and ISPs for space and bandwidth.11 By the
third quarter of 2001, Akamai had over 13,000 servers in 954 networks across 63 countries.12

Competition Akamai competed against caching providers and “do-it-yourself” mirroring

solutions, along with many CDN providers. Another startup, Sandpiper, was the CDN first mover; it
had launched services a few months before Akamai. However, Sandpiper and other CDN rivals soon
lagged Akamai in terms of their total number of server locations, so they formed alliances to share
their servers. CDNs posed a threat to hosting firms and NSPs because serving content from the
Internet’s edge reduced spending on hosting services and backbone transport. In response, several
hosting firms and NSPs built or acquired CDNs.

Akamai, Version 2.0: EdgeSuite

Notwithstanding competition, Akamai enjoyed great success with FreeFlow and completed a very
successful IPO in October 1999, just 13 months after incorporation. In 2000, the company had a 72%
share of the $125 million CDN market.13 (See Exhibit 4 for data on Akamai’s financial performance.)

In 2001, however, Akamai faced a dramatically changed environment. After the Internet bubble
burst, the quarterly churn rate in Akamai’s customer base jumped to 22% in Q3 2001, versus 11% for
Q1 2001.14 On the competitive front, developments were more positive. The leading CDN alliance,
Content Bridge, was mired in squabbles over members’ disparate strategic agendas and over how
members would compensate one another.15 Also, in the wake of the dot-com crash, several smaller
CDN rivals (such as Digital Island, which had acquired Sandpiper) were unable to raise new capital
and therefore had to cease operations.

A new competitive threat came from backbone operators such as MCI-Worldcom, AT&T, and
Qwest. As the dot-com crash stemmed demand for backbone operators’ core broadband transport
services, backbone operators found that they had dramatic overcapacity, so they increased efforts to

This document is authorized for use only in Prof. Arunabha mukhopadhyay's PGPII/T4/BDC/2499 at Indian Institute of Management - Lucknow from May 2024 to Sep 2024.
 804-158 Akamai Technologies

differentiate themselves by offering value-added services including content delivery. Conrades

discounted this threat:

As they enter our market, the big carriers will have trouble with the thousands of smaller
ISPs that you need to complete your content delivery network. AT&T’s WorldNet competes
directly with those ISPs. Do you think they’ll let AT&T put edge servers in their POPs for free,
especially when AT&T doesn’t carry much content to begin with?

Despite Conrades’ confidence vis-à-vis backbone operators, the dot-com crash almost claimed
Akamai as a further victim. During the preceding boom, many Internet companies raised large sums
in post-IPO secondary equity offerings. But Akamai missed this opportunity: Akamai’s February
2000 acquisition of INTERVU precluded secondary offerings until the SEC approved the merger. In
the interim, Akamai continued burning through cash but was unable to sell new equity. Fortunately,
in June 2000, the company found a narrow window during which it could sell $300 million in
convertible debt, which allowed Akamai to fund ongoing losses. Through 2001, the company had
invested over $500 million in capital expenditures and cash losses from operations.

EdgeSuite: The Opportunity

This shift in our strategy is akin to what Federal Express and UPS accomplished when they moved beyond
package delivery—that is, shipping—to supply chain management—picking, packing, and shipping. They said
to their customers, “You’re spending more money to get stuff ready for delivery than you spend on delivery
itself. If you let us into your factories and warehouses, with our assets and expertise, we can do that for you
better and cheaper.” I’d love to find out from Smith and Kelly [the CEOs of Federal Express and UPS,
respectively] how they persuaded customers to let them reach right down into the supply chain, to take over
functions that customers once thought were strategic.
— George Conrades

Facing an inflection point in 2001, Conrades and his top management team developed a plan to
evolve Akamai beyond its role in content delivery into a company that could facilitate the assembly,
presentation, and delivery of customers’ Internet data and applications. The centerpiece of this plan
was a new service called EdgeSuite, which employed Edge Side Includes (ESI), a markup language
used to accelerate the dynamic assembly and delivery of Web-based applications at the Internet’s
edge.16 ESI had originally been called “Akamai Side Includes,” but the name was changed after
Akamai, in partnership with Oracle, recruited a group of 15 firms to develop an open industry
standard. Other companies that had endorsed ESI included BEA Systems, IBM, MacroMedia, and
Vignette. The Worldwide Web Consortium, a standards-setting organization for Internet
technologies, approved ESI in September 2001.

Technology Many Web pages were dynamically generated, that is, created “on-the-fly,”
because they included components that had to be retrieved from databases and processed by
application servers before being presented by web servers. Examples included auction listings, stock
quotes, inventory availability, airline ticket prices, and weather reports. ESI allowed a website’s
managers to tag components that could be cached at an edge server as well as those that were non-
cacheable, like a bank account balance. For cacheable components, ESI was used to specify rules for
the allowable cache life span. For example, a news site might choose to refresh weather reports
hourly and sports scores daily.

With EdgeSuite, the same general-purpose servers that Akamai used for FreeFlow also handled
dynamic page assembly. When a user requested a Web page from an EdgeSuite customer, Akamai
assembled the page on an edge server and populated the page with relevant components resident in

This document is authorized for use only in Prof. Arunabha mukhopadhyay's PGPII/T4/BDC/2499 at Indian Institute of Management - Lucknow from May 2024 to Sep 2024.
 Akamai Technologies 804-158

the edge server’s cache. If a component was not available locally, then Akamai retrieved the
component from the origin website, using Akamai’s real-time monitoring of Internet traffic
conditions to retrieve the component via the fastest possible connection. (See Exhibit 5 for an
architectural diagram of ESI.)

Value proposition and target customers EdgeSuite offered an attractive value proposition,
both for Akamai’s traditional customers with content-rich websites and for enterprise customers that
increasingly relied on the Internet to distribute information and provide Web-based applications for
customers, channel partners, suppliers, and remote employees. EdgeSuite offered several advantages
over traditional CDN services like FreeFlow that strictly served “heavy” Web page elements:

• Performance. Serving dynamically generated Web pages from the Internet’s edge instead of
from the origin website improved page loading by a factor of at least two, on average.

• Origin website cost savings. Using Akamai’s edge servers allowed a customer to significantly
reduce its spending on web servers at its origin website and cut related expenses for data
center space and technical staff. For a typical EdgeSuite customer, the two-year return on
investment from these savings was in excess of 100%. (Investment included monthly
payments to Akamai as well as incremental staff to implement and maintain EdgeSuite.)17

• Bandwidth savings. EdgeSuite also would allow most customers to substantially reduce their
spending on bandwidth from origin servers. Recall that about half of information required to
present a typical Web page was related to page text and the HTML instructions required to
assemble pages. With EdgeSuite, HTML templates for page assembly were stored in edge
servers, substantially reducing data transfer. (See Exhibit 6.)

• Scalability. Customers relied on EdgeSuite as a “shock absorber.” Akamai’s distributed server

network could handle “flash crowds” that otherwise might overwhelm a customer’s origin
site. Symantec, for example, was able to use EdgeSuite to cut its server population in half yet
still meet sudden demand for antivirus software downloads.18

• Security. Origin servers were vulnerable to denial-of-service attacks (in which hackers
overwhelmed a server with data requests) and physical disasters. If its origin server was
inaccessible, an EdgeSuite customer could still rely on Akamai edge servers to present a
complete page to users, consistent with customer-defined ESI rules specifying which
components could be presented under such contingencies.

Given this value proposition, Akamai anticipated that the typical EdgeSuite customer would
spend about four times more than it currently spent on FreeFlow. Margins would be attractive
because EdgeSuite could leverage servers that Akamai had already installed for FreeFlow. Akamai
president Paul Sagan explained, “We were very lucky; with FreeFlow, the server disk fills up with
data objects, but the server’s processor is not used heavily. EdgeSuite needs lots of processing, but
less storage. These services put opposite loads on the server, so they complement each other
beautifully.”

Akamai made solid early progress selling EdgeSuite. At the end of 2001, after one year of use,
EdgeSuite accounted for 20% of Q4 2001 revenue and enjoyed 152 customers including Apple,
BestBuy, Coca-Cola, [Link], Novartis, Saatchi & Saatchi, Ticketmaster, and Victoria’s Secret.
About half of early adopters were existing FreeFlow customers; the balance were new users of
Akamai’s services.19

This document is authorized for use only in Prof. Arunabha mukhopadhyay's PGPII/T4/BDC/2499 at Indian Institute of Management - Lucknow from May 2024 to Sep 2024.
 804-158 Akamai Technologies

EdgeSuite: Implementation Challenges

EdgeSuite gave Akamai an opportunity to broaden its target market beyond content-driven
websites to include large enterprise customers. Sagan explained:

In a big enterprise, the CIO’s current hot buttons are simplicity, cost, security, and
accountability. It drives them crazy that they’ve had hundreds of separate Web efforts inside
their companies, spread all over the place, with some people buying Sun and others using IBM.
That party’s over; they’re pushing to rationalize. And we can go one step further for them. We
can outsource the whole mess, at lower cost, with much better performance.

However, Akamai faced challenges as it geared up to serve the enterprise market. Selling to
enterprise customers required a consultative approach to multiple parties influencing the purchase
decision. In this context, Akamai had to decide whether to upgrade its own sales force or rely to a
greater extent on resellers that had strong relationships within large corporations.

Sales challenges Conrades described the sales cycle for EdgeSuite and enterprise customers’
preconceptions about Akamai:

You start with the CIO, who likes to control the company’s IT infrastructure, so EdgeSuite
represents a paradigm shift for her. You also have to get past the bias that Akamai is all about
B2C [business-to-consumer] content delivery. The CIO says, “I’m comfortable with IBM and
EMC. Now you want to be my trusted ally in the center of all this infrastructure? Who the hell
are you?” That’s one reason we use resellers like EDS and IBM: they lend us credibility.

After two hours teaching her about EdgeSuite, she finally says, “We didn’t know you did
that. And if you really can do it, we’re very interested.” Now you go into the hellhole of
explaining EdgeSuite to every technical person there, some of whom will be disenfranchised
by our disruptive technology.

Sagan noted that targeting the enterprise market required new sales skills:

During the bubble, selling FreeFlow was pretty easy; we were often just dialing for dollars.
With a strong value proposition, we could close a sale in a couple of weeks and have the
customer online within the month. Our customer—the small team running website
operations—was under pressure from colleagues in sales and marketing, who said, “Just get it
done.” Now we’re dealing with corporate IT—a cost center, not a revenue center—in an
economic environment where every penny matters, even in big companies. The decision maker
is sorting out “nice to have” from “need to have.” And for the first time, we’re faced with a
consultative sale. It takes at least four or five meetings, and you’ve got to bring in more
technical support.

Facing these challenges, Akamai management gradually replaced most of the company’s sales
reps with individuals who had deeper experience with enterprise selling.

Roles for partners Akamai had always relied on partners—system integrators, hosting firms,
network carriers—to resell FreeFlow. Partners could play an even greater role with EdgeSuite.
Executive vice president of technology, networks, and support Chris Schoettle elaborated:

Proprietary was the wrong way to go with a concept like ESI that touches so many different
parts of the Internet’s infrastructure. We could never do this all ourselves. Even if we could
figure it all out, no one would let us make it happen. There’s a big role for alliance partners to
play in separating out business logic from presentation logic. Business logic is concerned with

This document is authorized for use only in Prof. Arunabha mukhopadhyay's PGPII/T4/BDC/2499 at Indian Institute of Management - Lucknow from May 2024 to Sep 2024.
 Akamai Technologies 804-158

how data is stored and processed in applications. Presentation logic is concerned with how
page components—the outputs of business logic—are assembled by web servers and routed to
users. ESI draws a line right through the data center, separating business logic from
presentation logic. To make ESI work, you need allies on both sides of that line.

For a lot of technology companies, selling software as service is the Holy Grail. We do that
already, we bring that to the party. Our partners bring technical expertise in their respective
domains, along with skills and relationships in the enterprise market. There’s big upside for
everyone in working together to develop and promote these standards. IBM, for example, has
two dozen reps sitting right inside in some of its enterprise accounts—their desks are on-site.
Sure, we give up a third of our revenue or more when we sell through them, but we’d be
pushing against the rock all day trying to get through the door in some of these accounts. IBM
can go right in and sell a bunch of our stuff. They often can sell $2–$3 of professional services
for every dollar the customer spends on Akamai—far more than they ever earned from
reselling FreeFlow.

Given partners’ skills and relationships in the enterprise market, did it make sense for Akamai to
rely entirely on resellers and drop its direct selling efforts? Conrades commented:

I’ve long believed that you don’t want to entrust everything to resellers. Having a direct
sales force helps you keep the game straight; it’s a backstop. What if a reseller abandons you?
Sure, with dual channels you end up tripping over each other sometimes, and you have to
figure out whether to double commission your in-house reps for sales made in their accounts
by resellers. But it’s worth accepting the conflict that goes along with a dual-channel structure.

Consistent with Conrades’ views, Akamai did not dramatically increase its dependence on
resellers. They accounted for 25% of Akamai’s revenue by Q4 2003, up from 20% in early 2001.

Performance Through 2003

EdgeSuite was successful: by the end of 2003, it accounted for 60% of Akamai’s revenue. During
2003, the company’s customer base increased 18% to 1,126. Akamai’s biggest customer, accounting
for 20% of Q3 2003 revenue, was Microsoft, which relied on Akamai’s network to deliver software
patches. With the demise of many CDN competitors, Akamai’s share of the content delivery market
had increased to 80%.

With EdgeSuite’s growth, the company’s financial performance improved. Revenue for Q4 2003
was $45.2 million, up 28% from Q4 2002. Leveraging aggressive cost-reduction efforts, Akamai
reported positive net income for the first time in Q4 2003. Capital expenditures had declined to 6% of
revenue because server prices had dropped sharply and Akamai had slowed its pace of network
expansion, having achieved widespread coverage. As of year-end 2003, Akamai had 14,733 servers in
1,072 networks across 71 countries.

For fiscal 2004, Akamai was projected to earn $31 million in operating income and $54 million in
EBITDA on revenues of $187 million.20 Buoyed by these positive trends, its stock price had rebounded
sharply; in January 2004, Akamai’s equity was valued at $1.8 billion.

This document is authorized for use only in Prof. Arunabha mukhopadhyay's PGPII/T4/BDC/2499 at Indian Institute of Management - Lucknow from May 2024 to Sep 2024.
 804-158 Akamai Technologies

Akamai, Version 3.0: EdgeComputing

We turned another corner in the last six months. For three years, we were living day to day, struggling to
survive, dealing with layoffs and renegotiating our bandwidth and [ISP data center] real estate deals. At the
same time, we were managing a huge transition from Version 1.0 to 2.0. Thankfully, we’re past all that. It’s
easy now to see how we could grow at a steady annual rate of at least 20% and earn steady profits for a while.
But we won’t stop with Version 2.0; we’ve got the breathing room now to be able to think months and even
years ahead. With that new freedom, we’ve got to figure out how to get to $1 billion in revenue.
— Tom Leighton, Co-Founder and Chief Scientist

EdgeSuite represented an early step in the evolution of content delivery networks into application
delivery networks (ADNs). ADNs would move not just content presentation and delivery to the
Internet’s edge but also application processing and databases.21 For example, an ADN might use edge
servers to process an online retailing transaction, subject to its customer’s predefined rules (e.g.,
“Only complete the transaction at the edge if there were at least 10,000 units in inventory the last time
data was synchronized; otherwise, query inventory status at the origin data base before proceeding”).

During 2003, Akamai moved ADNs from concept to commercial service. In May 2003, Akamai
and IBM announced that EdgeComputing customers could run Java applications created using IBM’s
WebSphere software development tools from Akamai’s edge servers. WebSphere was IBM’s brand
name for its web services initiatives. Web services were modular collections of applications that could
be mixed and matched to provide business functionality via an Internet connection. Web services
relied on standard Internet protocols such as Extensible Markup Language (XML) to ensure
interoperability between modules and across companies. For example, web services could enable “a
travel website that takes a reservation from a customer, and then sends a message to a hotel
application, accessed via the Web, to determine if a room is available, books it, and tells the customer
he or she has a reservation.”

By early 2004, Akamai had a dozen customers running Java applications. For example, the
computer peripheral manufacturer Logitech held a contest on its website that gave away tens of
thousands of prizes in a matter of hours. By dispersing the processing load across Akamai’s servers,
Logitech was able to handle a burst of traffic without adding additional internal server capacity.

Akamai’s managers faced two decisions as they formulated their edge-computing strategy. First,
which applications should they focus on? Second, which software companies should they team with?

Applications
Akamai chief scientist Tom Leighton discussed potential lead applications for edge computing:

We have a lot of choices in this space, and unlike content delivery, the killer application
isn’t obvious. We look for two things. First, do we have a sophisticated and influential early
adopter able and willing to work closely with us? Second, can we envision at least 1,000
customers each paying several thousand dollars per month for the application? Those criteria
lead you to look at horizontal applications like dealer locators, enterprise search, e-commerce
suites, sales force productivity tools, and CRM [customer relationship management software].

Partnerships
Most leading enterprise software companies offered platforms for creating and managing web
services. These platforms included IBM’s “WebSphere,” Microsoft’s “.NET,” EDS’s “Framework for

10

This document is authorized for use only in Prof. Arunabha mukhopadhyay's PGPII/T4/BDC/2499 at Indian Institute of Management - Lucknow from May 2024 to Sep 2024.
 Akamai Technologies 804-158

Accelerated Solutions (FAS),” Hewlett-Packard’s “Adaptive Enterprise,” BEA’s “WebLogic,” and

Sun’s “Open Net Environment (ONE).” All the platforms offered proprietary features but
incorporated middleware that facilitated interoperability with web services built using other
platforms. This meant that Akamai would need to undertake custom software development work to
support each platform. In this environment, should and could Akamai remain platform agnostic?
Sagan explained:

To oversimplify a complex situation, you can lump most of the major players except
Microsoft into the Java camp. IBM is the biggest player on that side; their WebSphere platform
has Java at its core with a lot of extra bells and whistles. So, the next battle is between Java and
Microsoft’s .NET. The battle won’t be decided quickly, and it might never be decided, because
some customers will deliberately support both sides to keep either camp from prevailing.

Our Java development is slightly ahead of .NET right now. But it’s hard to ignore the fact
that Microsoft and Java could each eventually control half the web services market.

Neither camp would want to see Akamai committed solely to the other side. We’re pretty
much the only game in town if you want to serve applications, on demand, from the network’s
edges. So, we’ve got a lot of support, based on both love and fear. For now, we’re in a central
position. We operate only at the network level, so we don’t represent a direct competitive
threat to any of the big enterprise software companies. But can this continue? Sometimes, I feel
we’re straddling two big ice floes that could start drifting apart. A little guy can’t hold the floes
together. At some point, we’ll have to decide if we must jump to one side or the other.

Leighton commented on the opportunity to work with both camps and the possibility that large
enterprise software companies would build their own ADNs:

I’m not as worried as I used to be about our ability to work with both camps. From a
technical perspective, we’ve learned that they aren’t too far apart. Ninety percent of the
software development effort is shared across the platforms; the command languages are very
similar. So, we can engineer solutions for both sides.

For now, both camps seem to accept that we’ll be working with the other side. Microsoft is
our biggest customer, so we’ve gotten to know them well. And IBM is our largest reseller.
We’ve integrated our services tightly with IBM’s and linked our sales efforts very effectively.

IBM’s CEO has declared that the company’s future will be built around “on-demand”
computing. And they’ve transformed themselves from a hardware manufacturer into a service
provider. Is it a little awkward that for now they have to rely on another service provider,
Akamai, to deliver their on-demand applications? Maybe, but let’s say they decide they need
their own delivery capability for on-demand computing. They might extend that capability to
25 data centers, but they’d never get it into 2,500 networks. You can satisfy a big part of the
market from 25 locations. Even if that got you 90%, that still would leave 10% for us. We’d be
thrilled to get 10% of what’s bound to be an enormous business.

A robust delivery capability is mission critical for .NET, too. That might have pushed
Microsoft to own network assets, but three years ago, they decided not to enter our business.
They wanted to sell software, not to run service businesses. Instead, they supported multiple
[content delivery] network providers, figuring that a competitive space would get the job done
for .NET. But the others they supported have all failed—Exodus, UUNET, Cable & Wireless—
every one. No one else is left standing to deliver 1.0 [CDN] services, let alone 2.0 [ADN
services]. So, for now, Microsoft has no real choice but to work with us. From our perspective,

11

This document is authorized for use only in Prof. Arunabha mukhopadhyay's PGPII/T4/BDC/2499 at Indian Institute of Management - Lucknow from May 2024 to Sep 2024.
 804-158 Akamai Technologies

this is a very promising relationship: Microsoft is big and smart, and they’ve got a terrific
enterprise sales force.

Conrades added:

When we built our network, we paid $8,000 for each server. Today, you can buy them for
$2,000. So, you’re looking at a $30 million capital expenditure to duplicate our 15,000-server
network. Of course, that wouldn’t be a showstopper for firms like Microsoft, IBM, or EDS. But
the investment in servers is just the start. You’d have to build relationships with 1,100
networks to get your servers co-located. You’d have to write 6 million lines of code, and we’ve
got patents galore. And you’d have to master concomitant business practices like quickly
addressing quality and capacity problems. We’ve been running a state-of-the-art NOC
[network operations center] for five years, and we’ve learned a lot.

So, yeah, there are big guys with clubs out there. But they’re swinging at each other, not at
us—as long as we keep focused on the network and stay out of the software layer. In the best
case, we’ll work with everyone, and we’ll become indispensable. We’ll become the “Intel
Inside” web services. We’re a lot more credible in this role now that we are EPS [earnings per
share] positive. Earning a profit pulled us out of the primordial ooze of start-ups that might
not be around next year!

Update – March 2010

From 2003 to 2009, Akamai’s financial performance was stellar: Revenue grew at a compounded
annual growth rate of more than 32%, with a 26% operating margin in 2009. Akamai also broadened
its worldwide customer base, with 28% of 2009 revenue coming from outside the United States, up
from 23% two years earlier.

Growth came in part from Akamai’s core content delivery service. As web sites implemented
increasingly complex interactivity, pages included ever more components. Akamai’s statistics
indicated that between 2003 and 2008, the average web page doubled in complexity from 25
component files to 50, and more than tripled in size, reaching an average above 300KB. This
complexity threatened to slow page-loads—making Akamai’s optimization that much more valuable.

Akamai’s growth also reflected consumers’ seemingly-insatiable demand for online video:
Delivering a single minute of web-based video to a single viewer typically required about 2MB of
bandwidth, while a minute of high-definition video distributed by Netflix’s on-demand video service
used 3MB to 15MB per minute.22 Furthermore, consumers expected videos to start quickly and to
proceed without delays, stutters, or “rebuffering” messages—challenging for sites hosting videos on
their own. With millions of viewers watching ever-longer videos, including full television episodes,
video drove demand for Akamai service.

Akamai continued its expansion from content delivery into new services. Combining in-house
systems with technology from its 2007 $177 million acquisition of Netli, Akamai’s Web Application
Accelerator (WAA) increased the speed and reliability of remote access to applications that needed to
run on (or access) a company’s central servers. For example, an airline reservation application needed
direct access to databases that changed continuously and therefore must be centralized. WAA used
several methods to accelerate data transfer between users and remote applications: Akamai’s
proprietary “Akamai Communication Protocol” converted the Internet’s standard TCP/IP
communications into a faster and more reliable protocol that could be sent quickly between two
Akamai servers without repeated delays for transmission confirmations. Because Akamai’s servers

12

This document is authorized for use only in Prof. Arunabha mukhopadhyay's PGPII/T4/BDC/2499 at Indian Institute of Management - Lucknow from May 2024 to Sep 2024.
 Akamai Technologies 804-158

decoded Akamai Protocol back to TCP/IP, neither user nor server needed any update to use WAA.
At the same time, WAA’s routing systems found the best path between source and destination,
continuously monitoring Internet congestion and avoiding routers and networks that were suffering
delay. WAA’s compression technology reduced the size of certain files, speeding transmission. For
certain applications, WAA added pre-fetching to obtain information from a remote server if a user
was likely to need that information soon, even if the user had not yet requested it.

Akamai felt its central position on the Internet created additional opportunities for expansion.
Paul Sagan, who was Akamai’s fifteenth employee and had become Akamai's CEO in 2005, identified
one top candidate: “We were sitting on a huge amount of real-time data, and targeted advertising
seemed to be an enormous profit opportunity.” In October 2008, as the US economy plunged into
recession, Akamai decided to acquire acerno, a behavioral advertising company, for approximately
$95 million in cash. This acquisition became the basis for Akamai’s Advertising Decision Solutions
(ADS). In ADS, participating web sites embedded Akamai codes that let Akamai anonymously track
certain aspects of user behavior such as recent purchases. Then Akamai used these behaviors to select
ads to be shown on other participating sites. For example, a user who had just purchased a stroller
might receive other baby-related offers, while a user who purchased a bicycle might receive sports
equipment ads. Akamai charged advertisers on a performance basis, only getting paid if users made
purchases. Looking back on the deal sixteen months later, Sagan remained optimistic: “We took a real
risk, but I think it was the right decision to try to build an advertising-based data business as a third
major revenue stream for Akamai.”

13

This document is authorized for use only in Prof. Arunabha mukhopadhyay's PGPII/T4/BDC/2499 at Indian Institute of Management - Lucknow from May 2024 to Sep 2024.
 804-158 Akamai Technologies

Exhibit 1 Internet Architecture and Bottlenecks

1. First Mile 2. Backbone 3. Peering 4. Last Mile

Business End User

NSP

Internet Data
Residential End User
Center

NAP IAP

Business End User

NSP

Internet Data
Center Residential End User

NAP IAP

Business End User

NSP

Internet Data
Center

The Internet was comprised of an amalgam of infrastructure owned by end users, local telephone companies, Internet
access providers, network service providers, and organizations operating websites.

“The last mile.” End users—both consumers and businesses—connected to the Internet through an Internet access
provider (IAP), commonly referred to as an Internet service provider (ISP). In 2004, most consumers and small businesses still
accessed the Internet through dial-up modems with transmission rates of only 56 kilobits per second (kbps). Some users
achieved “broadband” transmission speeds of 500 kbps to 3 megabits per second (mbps) through digital subscriber line (DSL)
or cable modem services. Large corporations usually connected their broadband local area networks (LANs) to the Internet
through high-speed telecommunications lines. The ISP’s modems were located at its nearest “point-of-presence” (POP), which
also contained equipment for routing traffic to a network access point (described in the next paragraph). The POP, the
telecommunications lines connecting the POP to the end user, and the end user’s access device collectively comprised the “last
mile” of Internet access.

The backbone. IAP POPs were connected by high-speed telecommunications lines to network access points (NAPs, also
23
called metropolitan area exchanges, or MAEs). In early 2004, there were about three dozen NAPs in North America. NAPs
were junctions where IAPs interconnected with network service providers (NSPs), which carried Internet traffic over long-haul
(city-to-city) networks. At NAPs, NSPs also interconnected with one another.

“The first mile.” When end users loaded a page from a website (e.g., Yahoo!’s), their requests were routed to a data center,
where they passed through firewalls, which provided security functions, and load balancers, which ensured that requests did not
overwhelm specific servers. Depending on the nature of the request, application servers might first retrieve information from
database servers—some inside the data center, others operated by third-party information providers at remote facilities. Then, a
web server assembled the information into a page that could be read by the user’s browser. Finally, the page was routed to the
Internet, typically over high-speed telecommunications lines. For small websites, a single general-purpose server connected to
an ISP’s network might perform all the above functions.

Source: Adapted from “Akamai Technologies,” Prudential Securities Equity Research, June 12, 2001, p. 29.

Note: NSP = network service provider; NAP = network access point; IAP = Internet access provider.

14

This document is authorized for use only in Prof. Arunabha mukhopadhyay's PGPII/T4/BDC/2499 at Indian Institute of Management - Lucknow from May 2024 to Sep 2024.
 Akamai Technologies 804-158

Exhibit 2 Content Delivery Network (CDN) Architecture

The public Internet is not an

efficient delivery medium.

How content travels

without CDN

Internet
Local POP IAP
End User IAP
Content
Provider

CDN edge server

at local POP

How content travels with CDN

Source: Adapted from “Akamai Technologies, Inc.,” Bear, Stearns Equity Research, May 10, 2001, p. 3.

15

This document is authorized for use only in Prof. Arunabha mukhopadhyay's PGPII/T4/BDC/2499 at Indian Institute of Management - Lucknow from May 2024 to Sep 2024.
 804-158 Akamai Technologies

Exhibit 3 Akamai Management Team

George Conrades has served as chairman of Akamai since April 1999 and as a director since
November 1998. He was the company’s first CEO until 2005. Mr. Conrades also served as a venture
partner with Polaris Venture Partners. Previously, he served as executive vice president of GTE,
president of GTE Internetworking, chairman and CEO of BBN Corp., and senior vice president and
member of the Corporate Management Board at IBM. Mr. Conrades is a director at Harley-Davidson
and Oracle.

Paul Sagan has served as Akamai’s president since May 1999 and as CEO since April 2005. He
became a member of the board of directors in January 2005. He joined the company in October 1998
and has also served as chief operating officer. Previously, Mr. Sagan was the senior advisor to the
World Economic Forum, president and editor of Time Inc. New Media, and senior vice president of
Time Warner Cable. Mr. Sagan originally joined Time Warner in 1991 to design and launch NY 1
News, a New York cable news network. Mr. Sagan serves as a director of EMC Corp and iRobot.

Tom Leighton has served as chief scientist and director since co-founding Akamai in 1998. Dr.
Leighton is a professor of applied mathematics at MIT and has headed the Algorithms Group in
MIT’s Laboratory for Computer Science since its inception in 1996. He holds numerous patents
involving cryptography, digital rights management, and algorithms for networks, many of which
have been licensed or sold to major corporations.

J.D. Sherman has served as Akamai's Chief Financial Officer since he joined the company in 2005.
Prior to Akamai, Mr. Sherman served as the chief financial executive of IBM's $21 billion Systems and
Technology Group. During his 15-year career at IBM, Mr. Sherman held a number of senior executive
positions in Finance, including Vice President, Finance and Planning, zSeries Server Division, and
Assistant Controller of IBM Corporate Financial Strategy and Budgets.

Chris Schoettle joined Akamai in March 2001 and is executive vice president of Products. Prior to
this position, he was Akamai’s executive vice president of Technology, Networks and Support. Mr.
Schoettle was previously president of the Broadband Access unit within the InterNetworking
Systems Group of Lucent Technologies. He also served as vice president and general manager of
VoIP (Voice-over-IP) Access Networks and vice president of IP Communications at Lucent. Mr.
Schoettle has also held various positions at AT&T, Novell, Unix Systems Laboratories, and NCR.

Robert (Bob) Hughes is the executive vice president of Global Sales, Services and Marketing for
Akamai. He joined Akamai in 1999 and today his responsibilities include leading Akamai's global
sales and marketing teams, as well as directing the company's professional services, technical
consulting and customer care organizations. With over 20 years of high-technology sales, marketing
and business development experience, Mr. Hughes has helped to build and lead Akamai's direct and
channel sales teams, and to position Akamai as the leader in powering rich media, dynamic
transactions and enterprise applications online. Prior to Akamai, Mr. Hughes held senior sales and
business development positions at PictureTel Corporation, as well as sales and marketing roles at
Boston Scientific Corporation.

Source: Adapted from “Management Team,” Akamai, available at

[Link] .

16

This document is authorized for use only in Prof. Arunabha mukhopadhyay's PGPII/T4/BDC/2499 at Indian Institute of Management - Lucknow from May 2024 to Sep 2024.
 Akamai Technologies 804-158

Exhibit 4 Akamai Technologies Income Statements, 1999–2003

(fiscal year-end December 31, $ millions)

2003 2002 2001 2000 1999

Revenue $161.3 $145.0 $163.2 $89.8 $4.0

Operating Expenses
Cost of revenue (before depreciation) 27.4 38.4 34.5 36.6 6.8
Research & development 10.2 17.2 44.8 39.6b 11.7
Sales, general & administrative 83.8 108.9 214.8 201.5 28.4
Depreciation 47.5 78.5 73.8 35.6 3.4
Amortization of goodwill, intangibles, etc. 2.2 17.5 255.8 676.1 --
Impairment of goodwill -- -- 1,912.8 -- --
Restructuring charges (8.5) 45.8 40.5 -- --
Equity-related compensation 9.8 21.2 a a 10.0
Total Operating Expenses 172.4 327.5 2,577.1 989.4 60.4

Operating Income (11.1) (182.5) (2,413.9) (899.6) (56.4)

c
Capital Expenditures 1.4 7.2 64.5 131.9 25.7

Source: Akamai SEC filings.

a Equity-related compensation of $31.4 million and $25.6 million is allocated to other expense items for 2001 and 2000,
respectively.
b Includes $1.4 million of acquired in-process R&D.

c Reflects expenditures for property and equipment; excludes capitalization of internal-use software.

17

This document is authorized for use only in Prof. Arunabha mukhopadhyay's PGPII/T4/BDC/2499 at Indian Institute of Management - Lucknow from May 2024 to Sep 2024.
 804-158 Akamai Technologies

Exhibit 5 Edge Side Includes Architecture

TRADITIONAL ARCHITECTURE

ESI ARCHITECTURE

Source: “Edge Side Includes (ESI) Overview,” available at [Link] accessed January 7, 2002.

18

This document is authorized for use only in Prof. Arunabha mukhopadhyay's PGPII/T4/BDC/2499 at Indian Institute of Management - Lucknow from May 2024 to Sep 2024.
 Akamai Technologies 804-158

Exhibit 6 Bandwidth Requirement Estimate for Medium-sized and Popular Websites

850 Mbps
-19 T3s
$425,000/month

425 Mbps
$212,500/month

1 Mbps 1 Mbps
$500/month $500/month
Typical Medium-sized Popular Site Popular Site with Popular Site
Web Site (e.g., Yahoo!) Traditional CDN With ESI
• 100,000 hits/day • 100,000 simultaneous • 100,000 simultaneous • 100,000 simultaneous
• 65 Kbytes/user users refresh every users refresh every users refresh every
• Low simultaneous traffic 60 seconds 60 seconds 60 seconds
• 65 Kbytes/user and • 33 Kbytes/user and • 100 bytes/refresh
refresh refresh • Static and dynamic
• No static or dynamic • Static content content solution cuts
content solutions solution cuts bytes bytes to negligible
delivered per user in amount
half

Source: Adapted from “Akamai Technologies, Inc.,” CSFB Equity Research, May 1, 2001, p. 5.

Note: Assumes that a typical page requires downloading 65 kilobytes of data.

19

This document is authorized for use only in Prof. Arunabha mukhopadhyay's PGPII/T4/BDC/2499 at Indian Institute of Management - Lucknow from May 2024 to Sep 2024.
 804-158 Akamai Technologies

References

1 Boston Globe obituary, “Daniel L. Lewin, Co-Founded Akamai Technologies; at 31,” September 17, 2001.
2 Robert Fagin, “Akamai Technologies: At a Strategic Inflection Point,” Bear Stearns, May 10, 2001, p. 16.
3
This taxonomy of problems is outlined in Michael Turits and Mark Smaldon, “Akamai Technologies,”
Prudential Financial Equity Research, June 12, 2001, pp. 28–33.
4 Mercury Interactive data cited in Turits and Smaldon, p. 30.
5 Fagin, p. 16.
6 Fagin, p. 16.
7 See Paul Gompers and Howard Reitz, “Cachet Technologies,” HBS Case No. 200-031 (Boston: Harvard
Business School Publishing, March 6, 2000), for additional background on Akamai’s launch.
8 Harry Blount, “Akamai Technologies,” Lehman Brothers Equity Research, July 19, 2001, p. 2.
9 John Corcoran, “Earthlink,” CIBC Equity Research, July 12, 2001, p. 7.
10 Turits and Smaldon, p. 24.
11 Turits and Smaldon, p. 21.
12 Stephen Mahedy, “Akamai Technologies, Inc.,” Salomon Smith Barney Equity Research, October 12, 2001,
p. 4.
13 Yankee Group data cited in Turits and Smaldon, p. 16.
14 Mahedy, p. 2.
15 April Jacobs and Jennifer Mears, “Content Peer Groups Fall Flat,” Network World, November 5, 2001, p. 23.
16 Definition provided by <[Link]>, a website operated by the Edge Side Includes consortium,
accessed January 12, 2002.
17
Jon Erickson and Joel Yaffe, “An Analysis of the Total Economic Impact™ of Akamai’s EdgeSuite Service,”
Giga Information Group, July 2, 2001.
18 Lyons, pp. 135–136.
19
Blount, p. 2.
20 Harry Blount, “Akamai Technologies,” Lehman Brothers Equity Research, December 10, 2003, p. 2.
21 See Neal Goldman, “Content Acceleration Tools: Solving Flaws in the Internet Architecture,” Yankee
Group Report, November 2001, for a description of application delivery networks.
22
Netflix, “Encoding for Streaming.” <[Link]
accessed March 22, 2010.
23 Colosource, “Internet eXchange Points.” Available at <[Link] accessed
January 19, 2004.

20

This document is authorized for use only in Prof. Arunabha mukhopadhyay's PGPII/T4/BDC/2499 at Indian Institute of Management - Lucknow from May 2024 to Sep 2024.