In a recent trip to Southeast Asia, I visited the Malaysian city of Kuala Lumpur. It is a sprawling urban area, more like Los Angeles than New York. With all the congestion and constant traffic jams the question of city planning struck me. On a more abstract level this is the same challenge that faces web application and internet website designers. Architect and bake the quality into the framework, or hack it from start to finish?
Urban Un-Planning
Looking at cities like Los Angeles you can’t help but think that no one imagined there would ever be this many cars. You think the same thought when you are in Kuala Lumpur. The traffic reaches absurd levels at times. A local friend told me that when the delegates travel through the city, they have a cavalcade of cars, and a complement of traffic cops to literally move the traffic out of the way. It’s that bad!
Of course predicting how traffic will grow is no science. But still cities can be planned. Take a mega-city like New York for example. The grid helps with traffic. A system of one way streets, a few main arteries, and travelers and taxis a like can make better informed decisions about which way to travel. What’s more the city core is confined to an island, so new space is built upward rather than outward. Suddenly the economics of closeness wins out. Many buildings in midtown you can walk between, or at most take a quick taxi ride. Suddenly a car becomes a burden. What’s more the train system, a spider web of subways and regional transit branches North to upstate New York, Northeast to Connecticut, East to Long Island, and West to New Jersey.
If you’ve lived in the New York metropolitan region and bought a home, or work in real estate you know that proximity to a major train station affects the prices of homes. This is the density of urban development working for us. It is tough to add this sauce to a city that has already sprawled. And so it is with architecting websites and applications.
Architecting for the Web
Traffic to a website can be as unpredictable as traffic within the confines of an urban landscape. And the spending that goes into such infrastructure as delicate. Spend too much and you risk building for people who will never arrive. What’s more while the site traffic remains moderate, it is difficult to predict patterns of larger volumes of users. What areas of the site will the be most interested in? Have we done sufficient capacity planning around those functions? Do those particular functions cause bottlenecks around the basic functioning of the site, such as user logins, and tracking?
Baking in the sauce for scalability will never be an exact science of course. In urban planning you try to learn from the mistakes of cities that did things wrong, and try to replicate some of the things that you see in cities doing it right. Much the same can be said for websites and scalability.
For instance it may be difficult to do bullet proof stress testing and functional testing to cover every single possible combination. But there are best practices for architecting an application that will scale. Basics such as using version control – of course but I have seen clients who don’t. There are a few options to choose from, but they all provide versioning, and self-document your development process. Next build redundancy into the mix. Load balance your application servers of course, and build various levels of caching – reverse proxy caching such as varnish, and a key-value caching system like memcache. Build redundancy into the database layer, even if you aren’t adding all those servers just yet. Your application should be multi-database aware. Either use an abstraction layer, or organize your code around write queries, and read-only queries. If possible build in checks for stale data.
Also consider various cloud providers to host your application, such as Amazon’s Elastic Compute Cloud. These environments allow you to script your infrastructure, and build further redundancy into the mix. Not only can you take advantage of features like auto-scaling to support dynamic growth in traffic, but you can scale servers in place, moving your server images from medium to large, to x-large servers with minimal outage. In fact with MySQL multi-master active/passive replication on the database tier, you could quite easily switch to larger instances or from larger to smaller instances dynamically, without *any* downtime to your application.
Conclusion
Just as no urban planner would claim they can predict the growth of a city, a devops engineer won’t claim they can predict how traffic to your website will grow. What we can do is mitigate that growth, build quality by building scaffolding so it can grow organically, and then monitor, collect metrics and do basic capacity planning. A small amount of design up front will payoff over and over again.
Book Review: How To Disappear by Frank M Ahearn
With such an intimidating title you might think at first glance that this is a book only for the paranoid or criminally minded. Now granted Mr Ahearn is a Skip Tracer, and if you were one already you certainly wouldn’t need this book. Still Skip Tracers have a talent for finding people, just as an investigator or a detective has of catching the bad guys. And what a person like this can teach us about how they find people is definitely worth knowing.
If you’ve had your concerns about privacy, what companies have your personal information and how they use it, this is a very interesting real-world introduction to the topic. Of particular interest might be the chapter on identity thieves and another on social media. All-in-all a quick read and certainly one-of-a-kind advice!
View on Amazon – How To Disappear