config file or crucial piece of data. If
that happens when you are fighting a
real fire, then something you do not
want will be hitting that office fan.
Fire drills allow a team to run
through the motions, before they really need to. Your company should task
part of its ops team with restoring its
entire application a few times a year.
With AWS and cloud servers, this is
easier than it once was. It is a good idea
to spin up servers just to prove that all
your components are being backed up.
In the process you will learn how long
it takes, where the difficult steps lie,
and what to look out for.
7.Insufficient Monitoring and
Metrics. Monitoring falls into the
same category of best practices as
version control: it should be so basic
you cannot imagine working without
it; yet there are Web shops that go
without, or with insufficient monitoring—some server or key component
is left out.
Collecting this data over time for
system and server-level data, as well as
application and business-level availability, are equally important. If you
do not want to roll your own, consider a Web services solution to provide
your business with real uptime.
8. Cowboy Operations. You roll
into town on a fast horse, walk into
the saloon with guns blazing, and you
think you are going to make friends?
Nope, you are only going to scare everyone into complying but with no
real loyalty. That is because you will
probably break things as often as you
fix them. Confidence is great, but it is
best to work with teams. The intelligence of the team is greater than any
of the individuals.
Teams need to communicate what
they are changing, do so in a managed
way, plan for any outage, and so forth.
Caution and risk aversion win the
day. Always have a Plan B. You should
be able to undo the change you just
made, and be aware which commands
are destructive and which ones cannot
9. Growing Technical Debt. As an
app evolves over the years, the team
may spend more and more time maintaining and supporting old code,
squashing bugs, or ironing out kinks.
Therefore, they have less time to devote
to new features. This balance of time
devoted to debt servicing versus real
new features must be managed closely.
If you find your technical debt increas-
ing, it may be time to bite the bullet
and rewrite. It will take time away from
the immediate business benefit of new
functionality and customer features,
but it is best for the long term.
Technical debt is not always easy
to recognize or focus on. As you are
building features or squashing bugs,
you are more attuned to details at the
five-foot level. It is easy to miss the
forest for the trees. That is why gen-
eralists are better at scaling the Web
10. Insufficient Logging.
Logging is closely related to metrics and
monitoring. You may enable a lot
more of it when you are troubleshooting and debugging, but on an ongoing
basis you will need it for key essential
services. Server syslogs, Apache and
MySQL logs, caching logs, among others should all be working. You can always dial down logging if you are getting too much of it, or trim and rotate
log files, discarding the old ones.
These 20 obstacles can affect scalability and result in performance degradation of a Web application. By avoiding these obstacles and following the
practices outlined here, Web-applica-tion developers will be able to minimize latency and guarantee that their
applications can scale as needed.
Building Scalable Web Services
Improving Performance on the Internet
Sean hull ( firstname.lastname@example.org; http://www.iheavy.
com/blog/) is the founder and senior consultant at
heavyweight Internet group in new york. he has
more than two decades of experience as a technology
consultant and adviser working with clients such as
appnexus, the hollywood reporter, billboard, nbC
universal, and Zagats, among other hyper-growth
companies that handle up to 100 million unique visitors
© 2013 aCm 0001-0782/13/09 $15.00
caution and risk
aversion win the
day. always have
a Plan B.