(DBA) will come to the team with a very
slow-running, very ugly query and say,
“Where is this in the application? We
need to fix it. It needs to be rewritten.”
Your dev team then says, “We do not
know!” And an incredulous look is re-
turned from the ops team.
The ability to track down bad SQL
and root it out is essential. It will hap-
pen, and your DBA team will need to
index properly. If queries are coming
from ORMs, they do not lend them-
selves to all of this. Then you are faced
with a huge technical debt and the
challenge of ripping and replacing.
10. Missing Instrumentation. In-
strumentation provides speedometers
and fuel guages for Web applications.
You would not drive a car without
them, would you? They expose infor-
mation about an application’s inter-
nal workings. They record timings and
provide feedback about where an ap-
plication spends most of its time.
One very popular Web services so-
lution is New Relic (http://newrelic.
com/), which provides visual dash-
boards that appeal to everyone—proj-
ect managers, developers, the opera-
tions team, and even business units
all can peer at the graphs and see what
Some open source instrumentation
projects are also available.
10 obstacles to scaling
Beyond optimization speed
Speed is not the only thing that can
gum up scalability. The following 10
problems affect the ability to maintain and build scalability for a Web
application. Best practices can avoid
1. Lack of a Code Repository and Version Control. Though it is rare these
days, some Internet companies do still
try to build software without version
control. Those who use it, however,
know the everyday advantage and organizational control it provides for a team.
If you are not using it, you are going
to spiral into technical debt as your
application becomes more complex.
It will not be possible to add more developers and work on different parts
of your architecture and scaffolding.
Once you start using version con-
trol, be sure to get all components in
there, including configuration files
and other essentials. Missing pieces
that have to be located and tracked
down at deployment time become an
2. Single Points of Failure. If your
data is on a single master database, that
is a single point of failure. If your server
is sitting on a single disk, that is a sin-
gle point of failure. This is just techni-
cal vernacular for an Achilles heel.
These single points of failure must
be rooted out at all costs. The trouble
is recognizing them. Even relying on a
single cloud provider can be a single
point of failure. Amazon’s data center
or zone failures are a case in point. If
it had multiple providers or used Am-
azon differently, AirBNB would not
have failed when part of Amazon Web
Services went down in October 2012
3. Lack of Browse-only mode. If
you have ever tried to post a comment
on Yelp, Facebook, or Tumblr late
at night, you have probably gotten a
message to the effect, “This feature is
not available. Try again later.” “Later”
might be five minutes or 60 minutes.
Or maybe you are trying to book airline tickets and you have to retry a few
times. To nontechnical users, the site
still appears to be working normally,
but it just has this strange blip.
What’s happening here is that the
application is allowing you to browse
the site, but not make any changes. It
means the master database or some
storage component is offline.
Browse-only mode is implemented
by keeping multiple read-only copies
of the master database, using some-
thing such as MySQL replication or
Amazon read replicas. Since the appli-
cation will run almost fully in browse
mode, it can hit those databases with-
out the need for the master database.
This is a big, big win.
4. Weak communication. Communi-
cation may seem a strange place to take
a discussion on scalability, but the tech-
nical layers of Web applications cannot
be separated from the social and cultur-
al ones that the team navigates.
Strong lines of communication are
necessary, and team members must
know whom to go to when they are
in trouble. Good communication de-
mands confident and knowledgeable
leadership, with the openness to listen and improve.
5. Lack of Documentation.
Documentation happens at a lot of layers in a Web application. Developers
need to document procedures, functions, and pages to provide hints and
insight to future generations looking
at that code. Operations teams need
to add comments to config files to
provide change history and insight
when things break. Business processes and relationships can and should
be documented in company wikis to
help people find their own solutions
Documentation helps at all levels
and is a habit everyone should embrace.
6. Lack of Fire drills. Fire drills always get pushed to the backburner.
Teams may say, “We have our backups; we’re covered.” True, until they
try to restore those backups and find
they are incomplete, missing some