Skip to content

  1. This week’s Heroku debacle

    A blog post went viral this week and uncovered an issue in PaaS provider, Heroku’s routing mesh, which has caused a significant degradation of Ruby on Rails app performance. Essentially, over the past three years Heroku moved from “smart” to “random” web request routing among an account’s “dynos”, Heroku’s processing units. Each dyno runs about $35/month.

    The change in architecture, which is explained in detail here, is only a portion of why Heroku is catching heat. Here are the real reasons:

    Same cost, less value

    First and foremost, there have been no reductions in price for the net reduction in capacity provided by the service. This is especially frustrating to the community at a time when other PaaS providers like Amazon Web Services (AWS) continue to lower their prices. Heroku’s platform leverages AWS in its architecture. Over time, users were purchasing more dynos for their accounts with diminishing returns. Each additional $35 dyno does not provide $35 in value.

    Appearance of deception

    Second, Heroku boasts robust monitoring tools that allow you to see the performance of your applications across many layers of their architecture. However, the monitoring tools provided by Heroku and New Relic don’t reflect the area of latency caused by random request routing. For a highly sophisticated platform provider, this oversight comes across to the community as deceptive rather than as an oversight.

    Lack of coherent communication

    Finally, there was no communication to customers about the change, and no consistent and coherent documentation. In fact, documentation around Heroku’s site was confusing and contradictory. Again, the appearance of deception.

    Response

    Heroku is responding openly and humbly, which is the proper way to handle the situation, but there are many who don’t think the responses go far enough. They want monetary reparations as well. I’d guess Heroku is considering concessions quietly by necessity as they are part of a publicly traded company and any concessions could have an impact on current and prior period financials of the company.

    The whole debacle reminds us that the lack of transparency over time can cause much larger PR problems for companies than the issues themselves. Individual customers have the platform to tell their story and initiate change.

    Categories: Business of Software, Platforms, Technology.

  2. Organizing platform development

    Dealing with shared services (AKF Partners blog) strikes a chord for a platform product manager. I can attest to the issues that arise with shared platform teams: overloaded backlogs, undecipherable priorities, increased time to market, loss of ability to drive innovation.

    In the end, platform must exist to increase the speed of software products to market. As soon it becomes an encumbrance, it should be re-imagined, replaced or removed altogether. From the article:

    Remember, whatever mechanisms you put in place, your shared service or tools team should be a gas pedal and not a break for TTM.

    During planning, teams will regularly take dependencies on platform to deliver necessary features for their market. When all of the requests are summed up, many teams will be let down because their requests cannot be fulfilled.

    So, the suggestion to run internal platform components similarly to open source projects is a good one and is a fertile middle ground between complete lockdown and utter chaos. It does, however, come with taxes in the form of code reviews, merges, documentation and collaboration with other contributors. But running platform in this way allows continued innovation and a strategic roadmap while putting more control into the hands of product teams.

     

    Categories: Platforms, Product Development, Technology.

  3. Why I built Giftr and What I Learned

    I built Giftr for myself. I wanted a mobile app to easily save gift ideas for my family and friends. I also took it as an opportunity to learn Ruby on Rails, jQuery Mobile, PostgreSQL, Facebook/Amazon APIs, and Heroku.

     

    Aside from the technology, the biggest learning so far is that most people don’t want to log into my app with their Facebook account. I posted Giftr on Hacker News on Saturday, November 10 and had approximately 38 hits on the index page, 12 hits on the sign_in page, and exactly 0 new accounts created. The only commenter, tuscon, had this to say:

    Interesting title. But… I wanted to try, but I don’t want to sign in with facebook. Sorry.

    I’m not planning to change the sign in approach for now, but if you don’t mind logging in with Facebook (Giftr doesn’t post anything to your wall) and would like to try it out, feel free. If you do, I’d value your feedback. You can contact me here.

    (word count: 165)

     

     

     

    Categories: 100 words per day, Giftr, Personal, Product Development, Technology, Uncategorized.

  4. If This Then That (IFTTT) – A Platform for Enterprise?

    IFTTT is planning to add an open API channel to its service. This might just be a big deal for enterprise software.

    If you’re unfamiliar with IFTTT, or “If This Then That”, it’s a service that allows end users to stitch together their online services like Twitter, Facebook, Gmail, Evernote, even Craigslist (and more). Users choose an event from one service, i.e channel, to listen for, like a Tweet, and an action from another service, like create a file in Dropbox. It’s all done from a slick, simple web page.

    Today, IFTTT opens up channels as new online services and social apps spring up. But like any good platform, they need to free developers up to publish their own event and action API’s. Sounds like they have plans to do just that.

    This could be a really big deal but not just because any consumer app can integrate more easily. It’s big because enterprise apps can integrate. Enterprise users have grown accustomed to software that is cheap and easy to use. Now even the CRM, finance, and time tracking apps they use at work will integrate with the apps they use on their iPhones, iPads and Android devices.

    But here’s where it gets really interesting: IFTTT could become the “Internet Service Bus” for enterprise applications that need to talk with one another. This concept is increasingly important as more enterprise products are offered and consumed in the cloud. Other companies have tried to “cloudify” traditional enterprise integration tools but they remain expensive to obtain, complex to configure, and despite the marketing, you have to have technical people to make good use of them.

    Enterprise product companies will have a fantastic opportunity to leverage the best consumer and enterprise services on the market into their products. Those that avoid this will do so at their own peril.

    If not IFTTT, another player could easily swoop in and provide this capability for the enterprise software market. It is a winner-take-all proposition to the product attracting the most customers by creating the best platform experience for enterprise product engineers.

    Categories: Platforms, Product Management, Technology.

  5. The Product is the Platform

    I was surprised to hear a colleague make the following comment a few weeks ago:

    We did the platform team a favor and designed our new feature so that it could be reused by other teams.

    My reaction was “Sweet! But… Aren’t we all building platforms?” If we’re not maybe we should be. My definition of “platform” is the collection of services, libraries and tools available to speed delivery of valuable product to users. By extension, the platform roadmap should be driven not by what is feasible and flashy from a technology perspective, but by what customers need and what gets product to the market fastest.

    In a now-famous rant by Steve Yegge of Google, he recollects his time at Amazon where Jeff Bezos’ mandated that all teams deliver their products as services which other teams could leverage through standardized API’s. This, in essence, helped transformed Amazon from being a very successful ecommerce company into a platform. Whatever the product, I would argue that it always makes sense to think about your product as a part of a larger ecosystem, even if the ecosystem only consists of other internal departments or business units.

    A few benefits of taking the platform mindset:

    • Compartmentalized ownership – A good product manager considers themselves the CEO of the product. By compartmentalizing your product, you ensure that control is maintained and that you can accurately monitor your application and its usage. Of course, as soon as you open the application up to the company, you are then responsible for its SLA’s and integrity as a service. But this is all part of true ownership and should be welcomed.
    • Leverage across product lines - Share functionality and data assets across multiple products. Reuse techniques have been around for decades, but we now have the luxury of open web standards and technologies which allow heterogeneous platforms to be more simply and reliably stitched together.
    • Future flexibility – By limiting the surface area of your applications through API’s future flexibility can be ensured because you know exactly how outside applications connecting to the service. Therefore you, can feel free to change underlying structure as long as the original service contracts remains intact.
    • Broadened reach – Platforms can increase the scalability of your product beyond the initial markets they were designed to serve. Niche product makers use API’s to build new solutions and can be a valuable source of new subscribers and licensees. Apps can be delivered to your users which would never be more than mirage on a long-term product roadmap. Resources are limited and you can’t build everything. Companies that enable an ecosystem of development have often have leverage against their competitors who believe they can build everything themselves, in house.

    You need look no further than Amazon Web Services which may already be a billion dollar business. Amazon exposed their massive online retail infrastructure to their internal teams as well as to outside developers and product shops across the globe to be leveraged by API’s on a pay-as-you-go basis. Whenever you are using a social media app, chances are good there’s an AWS service behind the scenes serving up portions of the request.

    There are costs associated with delivering your product as a platform, but doing so can multiply your product’s value. Let me be clear, there is no substitute for a compelling product, validated by customers, but, we live in a technology era where tools and creative engineers are ubiquitous. Providing thoughtful access to your data and functionality unlocks the potential of those assets to existing and potential customers.

    Categories: Agile, Platforms, Product Development, Product Management, Technology.

  6. Scale up AND Scale out – the Stackoverflow.com way

    Interesting article on the High Scalability blog this week highlights the scale up architecture of Stackoverflow.com. If you’re not familiar with this site, it’s a question and answer site for programmers that takes a new, more social approach to technical Q&A than has ever been available on the internet. Due to its usability and relevance it has become one of the top 200 web sites in the world with over 95 million page views monthly.

    While the High Scalability post highlights the scale up approach, it’s also important to note the places where Stackoverflow has scaled out. Here are a few highlights pulled directly from the post:

    • Web Tier – Web farm with 3 dedicated web servers for stackoverflow.com
    • Web Statistics – Web logs stored in a separate SQL Server database (inferred) – 20GB of logs generated per day
      • One table created per day to store statistics
    • Caching Layer (Redis) – Every request doesn’t hit the database. Sticky switches keep user requests on the same server and state can be served directly out of RAM cache
    • Content Delivery Network – CDN serves static resources for global access. Typically involves images, CSS, JavaScript, etc
    • Data – Stackoverflow.com is the largest of the sites in the Stack Exchange network and is hosted on its own database cluster in a single database, but other sites such as serverfault.com, and any of the stack exchange network sites are hosted on a separate cluster
    • Chat server is hosted in the Oregon data center while the main stack overflow site is hosted in NY

    George Beech, sysadmin for the Stackoverflow.com network notes in the original article that the data tier is only about 20% utilized leaving headroom for growth and unexpected spikes in volume.

    To achieve high scalability, there is usually going to be a healthy mix of scaling up and out. The key is to avoid painting yourself into a corner which the stack exchange guys have a done a nice job of.

    Categories: Product Development, Technology.

© Copyright Jay Nathan, 2010-2013