8 Comments

Summary:

For most people scaling out a web service is a matter of thinking about hardware and software. But the recent Surge conference taught me that most devops folk need to look down to the physical infrastructure as well as the economic tradeoffs of building a service.

20120927_090643

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’s Surge 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 his social TV startup changed the way the 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.

  1. Application optimization is definitely the first place to start. Without a speedy app, other things such as DNS and network will have much less of an impact. But DO LOOK at those items later. Many organizations underestimate how poor DNS impacts performance, and that’s something we specialize in at Total Uptime: http://totaluptimetech.com/solutions/cloud-dns/

    Share
  2. Vinod Shintre Tuesday, October 2, 2012

    great point & certainly there is a need for a recommendation service which would seamlessly fit into existing devops processes. As cloud consumption grows beyond few 1000 $, this will see a new challenge in enforcing the CLOUD IT consumption policy one may want to put in place. Attribo is solving this piece of the puzzle which will avoid friction in devops & offer real-time view into your amazon cloud infra. more at http://www.attribo.com

    Share
  3. Thanks for posting this. Today I watched documentary film that deals with the subject of Economic Calculation, Market Rationale and its effects, along with considerations of the Scientific Principles of Sustainability titled ‘Culture in Decline: Economics 101′. I recommend you to watch this, if you did n’t watch yet.

    http://www.thegreatplanet.com/culture-in-decline-economics-101-2012/

    Share
  4. Stacey, great points, they very much match experience. When first we started to build cloud based application we were regularly had unexpected rises in our costs. When we designed and built originally there was some ignorance regarding the choices and so we did what we’d normally do, we built the app. Then we came to the initial deployment and what we really cared about was the availability not cost. We improved on what we had and recruited a few trial users and became interested in response time. We recruited more users and needed to know about quality of service. Only when you start to recruit users in numbers do the implications of the performance / architecture / cost trade off become apparent. Now we care about cost again.
    Odd really since the tools we were building were to help identify and ameliorate just these problems.

    Share
  5. We are still in trial mode so anyone that has the same problems can get some help at
    http://www.foglight-on-demand.com/content/en/index.html

    Share
  6. This strikes me as excellent advice, though I’m not sure the takeaway is that CS majors need to take more econ and business courses – it’s more that developers need to be aware of the business impact of what they may think of as purely technical decisions. Your company’s specific business goals for the system being developed should be shaping the tradeoffs that you make. And any decision that has the potential to add or subtract overhead – as with the fit of your architecture to your hosting solution – needs to be considered very carefully.

    Share
  7. This is good insight, especially for people who think this stuff is easy :) Managing web services on a large scale for companies the size of Amazon requires a lot of outside the box thinking. If you’re ever interested in learning more, this is a great resource that I’ve been reading at my library: http://www.igi-global.com/journal/international-journal-web-services-research/1079

    Share
  8. Devops is an industry buzzword that arose to describe the collaboration of
    development and operations teams to obliterate the silos that impede projects.
    Along the same lines, continuous delivery is the automated implementation of
    the build, deploy, test, and release processes. As more teams embrace the
    devops philosophy and implement continuous delivery on their projects, more
    platforms and services will move toward a self-service model that encourages
    this collaboration. A traditional product development approach with a thorough planning stage
    and several years long delivery is no longer acceptable. Efficiency today means receiving maximum profit from each resource unit as early as possible. In the same time, development process should be perfect from both technological and business side. That’s why DevOps aims to build effective teams and configure systems, which lead to the delivery of reliable software and business benefit. Agile developers to provide agile support by giving developers production access to their applications, servers, and databases to improve their ability to do application support and troubleshooting.

    Share

Comments have been disabled for this post