Truly scaling a web service doesn’t just require computer science expertise — the best operations and devops employees will also have an understanding of economics. The big picture at this year’sSurge Conference in Baltimore, Md. seemed to be about optimizing lower-level services such as DNS or even networking protocols, and optimizing at the higher level via an understanding of economics.
The talks at Surge are designed as how-to discussions for engineers and can get pretty deep in the weeds. But after spending two days at the show last week, I’ve realized that many of the tweaks engineers make to their cloud-based services occur in a relatively narrow band. They’re focused mainly on code tweaks or rethinking the architecture to optimize for a specific cloud (almost always Amazon Web Services).
But lower-level tweaks required buying services or maybe even certain impossibilities such as owning the client software. One of the most-effective elements people discussed went mostly unsaid, but seems obvious to those in the business world — optimizing your architecture for the clouds you’re on. Several of the presenters, such as Joe Kottke of BrightTag, took attendees through their particular usage scenario and explained how they chose a different instance or changed their app architecture to cut costs.
One of the most effective of these was a chat by Riley Berton of Viggle who shared how he changed the way his social TV startup changed the way his service matched the sound prints of TV shows submitted by users to its database. Changing the way his application was built enabled him to go from spending $ 180,000 a month on Amazon to spending $ 25,000. One might argue that his application was poorly architected in the first place if he was spending that much, but it’s not like most developers have a sense of how their app should perform and what it should cost when they get started. That’s part of the problem.
And that was probably the most important takeaway from the show. As common as it is to find startups building out services in the cloud, there is till a lot to learn about understanding how certain architecture decisions translate into costs as your app scales. Services like Cloudability are hoping to help companies track this, as are real-time monitoring services such as Boundary, but there’s still plenty of low-hanging fruit in just thinking about the best instance types for a memory-intensive application as opposed to what one should think about using if you need rapid IO.
In addition to that, most programmers should also think about whether or not they should even optimize their app for a certain criteria if the cost will turn out to be astronomical, or if perhaps they should trade down to a different optimization that comes at a lower price point. Most engineers are accustomed to thinking about these tradeoffs when it comes to hardware or a certain database, but translating it beyond just the application’s performance and into its cost is a new way of thinking. So maybe those CS majors might want to consider a business or economics class in addition to their normal coursework.
