It’s not a totally rational attitude, but it seems especially common when people interact with what they perceive as sluggish web applications. We discussed relying on expectation management in last week’s post about the ‘Latency is Zero’ fallacy. In part three of our series on the Fallacies of Distributed Computing -  assuming bandwidth is infinite – we’ll again see why user expectations are not a sufficient barometer of success for web apps, and why this is even more applicable to mobile experiences.

Without a doubt, the one area in which networks have dramatically improved since Deutsch drafted the Fallacies in 1994 is bandwidth. Infrastructure providers are constantly working to make their series of tubes bigger and faster. But infinite is really, really big, and no one has quite accomplished that feat yet. Plus, even though bandwidth continues to increase, corresponding performance improvements aren’t always apparent because we’re also cramming bigger and bigger chunks of data through the pipe. Social games. Fantasy football podcasts. Streaming video of baby pandas. That episode of that TV show you missed. You know, important stuff.

We’re also predominantly doing all these things on wireless and cellular networks now. (Cisco estimates mobile data traffic will approach 2.5 million terabytes per month by next year.) Everyone loves mobile connectivity, but it does have the unfortunate side effect of offsetting bandwidth improvements. Wireless connections are far more susceptible to packet loss than ye olde wired LAN, which means requests are more likely to fail regardless of a connection’s total bandwidth potential. Of course, this variable is beyond the control of even the most reliable web and mobile apps.

For developers, designing apps without taking bandwidth limitations into consideration can lead to excruciatingly slow interactions and, in some cases, critical failures that will doom an app’s future. The latter seems to be of particular concern in the mobile environment, where packet loss glitches can cause apps to cycle endlessly without completing a request. This is where user expectations start to come into play.

We’ve mentioned before that the purpose of this series is to examine some of the contrasting viewpoints on the Fallacies’ relevance in contemporary web development, and we’ve been using Tim Bray’s article ‘The Web vs. The Fallacies’ as the antipode. His perspective on the fallacy of infinite bandwidth is similar to his take on the fallacy of zero latency. Through years of using the web, he contends, we’ve gotten used to these ‘networking realities’ and fully expect to encounter them.

With regard to bandwidth, he argues that people know large requests are going to slow down the experience. The tacit suggestion is that it’s not essential for developers to consider bandwidth limitations because users already factor it into their expectations. What Bray does not imply, but may also be true, is that users tend to blame their network providers – and not app developers – for any bandwidth issues that degrade their experiences.

Letting the user’s anticipation of bandwidth congestion influence one’s development decisions is problematic, however. First and foremost, it can discourage developers from addressing foreseeable performance issues that can be prevented. In other words, inducing them to naively and unnecessarily engineer a negative experience. Recalling our initial examples, even if users expect the inconvenience, it’s still going to be unsatisfying and deter them from using the app.

But that’s only half the story. For developers of mobile apps, restrictions imposed by cellular networks and hardware providers’ app distribution channels are another key reason to be mindful of bandwidth. Carbon Five wrote about this in detail, pointing out that Apple’s guidelines limit apps to a download size of 20MB, require bandwidth-defined video streaming options, and prescribe an audio streaming threshold of 5MB per five minutes. Developers who forget the fallacy of infinite bandwidth run a greater risk of being rejected by the App Store before user expectations and experience even matter.

Under these circumstances, the best approach seems straightforward: take steps to ration the amount of data being transmitted over time. However, as other systems experts have noted, it’s not quite that simple. Accounting for the effects of latency and the aforementioned threat of packet loss would suggest doing the exact opposite – issuing a smaller number of large requests. So once again it comes down to comprehensive testing, conducted in a simulated production environment.

That’s ultimately the only way to know how much bandwidth your app is using and adjust it accordingly to get within acceptable limits. Carbon Five recommends using Charles for testing purposes, but other utilities are available as well. By taking this extra precaution, you’ll know what kind of performance to expect under various bandwidth conditions – making your app more likely to pass inspection and deliver an optimal experience that doesn’t leave users frustrated.

Coming up: There’s no debate when it comes to network security.

- The Website Performance Alliance takes a look at the top 100 ecommerce sites in the UK and describes five ways to speed up your website.

- An infographic from Udemy compares the history, success and employment stats for PHP, Ruby and Python.

- InfoWorld explains the new rules for enterprise apps.

- ReadWriteCloud describes how PaaS out performed expectations in 2011.

- Seriti Consulting shows how to avoid ‘web stress’ and keep customers on your site.

- GigaOm shares a CTO’s take on the cloud.

- Our partner Joyent wins $85 Million in new funding.

- Practical Cloud Computing analyzes the state of NoSQL in 2012.

- Romiko Derbynew shares a tutorial on getting started with Heroku Toolbelt/Neo4j on Windows.

Running with Cloud Foundry
The easiest way to get up and running with Cloud Foundry is to use one of the existing services that use Cloud Foundry such as AppFog or CloudFoundry.com. But I’m not going to take the easy route. Instead I’m going to dive into getting some real instances up and running. I will however talk more about AppFog, Tier3/Iron Foundry and Cloud Foundry services in a later part of this series.

Another thing to be aware of is the difference in Cloud Foundry sites. They’re working with and for the open source project, but one is http://www.cloudfoundry.com and the other is http://www.cloudfoundry.org. The .org site is setup around organizing the Cloud Foundry OSS project, while the .com site is setup around advocating, community, and future offerings of the Cloud Foundry service. While working with the Cloud Foundry product, there are times I refer to the .com or the .org. In these situations, I will write Cloud Foundry and postfix the name with .com or .org.

Getting the Ops in DevOps
Unless you want to go the completely manual path, the first thing you’ll need to do is sign up for an account. (See the instructions below if you want to install things yourself.) I’d highly suggest signing up so you can participate, or at least lurk, in the Cloud Foundry community forums. (Don’t worry – the VMware and Cloud Foundry teams won’t spam you.) If you’re working with the .NET stack, you’ll also want to dive into the .NET Iron Foundry forums.

If you’re interested in the path of least resistance and just want to deploy something as soon as possible, signup and then download the pre-configured image that’s available on the Cloud Foundry site.

Once you’ve checked out those sources, you’re ready to install things manually to learn all the nitty gritty details or have downloaded the VMware image to get started deploying. (If  you’ve done the latter, skip to the Targeting for Deployment section.)

CloudFoundry Manual Setup
First you’ll need to get an Ubuntu 10.04.2 Server 64 bit OS image. You can download that from Ubuntu or directly. Once the download is complete, build a virtual machine with the image.

Troubleshooting Tip: Whatever virtualization software package you’re using to get your image up and running, you’ll want to set your network configuration to NAT instead of Bridged. This is a very common practice to resolve issues that often occur.

Once the Ubuntu server image is booted up and running bring up a terminal to complete the following process. Open up a terminal to issue commands by clicking on CTRL + Alt + T or navigate through the menu Application -> Accessories -> Terminal. The first thing we’ll need is to update the apt-get with the following command in the terminal.

sudo apt-get update

Once apt-get updates, then install the open ssh server with the following command.

sudo apt-get install openssh-server

The next step is to run the automated setup process. This process will take some time, probably 45 – 65 minutes depending on power and speed of the VM. To get curl and run the automated installer code, execute these commands.

sudo apt-get install curl
bash < <(curl -s -k -B
https://raw.github.com/cloudfoundry/vcap/master/setup/install)

In the near future this automated installation code will be replaced by a Chef recipe. (It works well today too, so don’t hesitate to give it a try.)

Now connect to the system with SSH. First get the IP of the Linux Machine with ifconfig.

ifconfig

Open a terminal in Mac or Linux (or if you’re using Windows you’ll need something that executes SSH connections such as PuTTY). Now you can connect with your system account and the IP number.

ssh adron@192.168.108.141

The machine will then connect, request your password, and show the login information.

Now create a local port tunnel.

sudo ssh –L 80:192.168.108.141:80 adron@192.168.108.141 -N

Just to become more familiar with the setup, check out the directory for Cloud Foundry now. A simple ls and cd will provide a list for your review.

The cloudfoundry directory exists within the ~ user directory, while there is a vcap directory within the cloudfoundry directory. If everything looks in order, we’ll keep moving. At this point, we’re at the point the prepackaged VM available from the cloudfoundry.com site.

Now target your Cloud Founry Ubuntu Instance with the following command and take a look at information about the instance.

vmc target api.vcap.me
vmc info

The final step in getting the manual setup completed is adding a user. Issue the following commands and the instance will be all set.

vmc register -email yourAddy@someplace.com –passwd somePassword
vmc login -email yourAddy@someplace.com –passwd somePassword

You’re set!

Targeting for Deployment
At this point we have three options for setting up our Cloud Foundry instance:

- Create a private micro Cloud Foundry instance with the downloaded virtual machine
- Create a public micro Cloud Foundry instance with the downloaded virtual machine
- Use the manually created instance that we built with the instructions above

Private or Offline Micro Cloud Foundry
The idea behind the private micro Cloud Foundry instance is if you’ll be offline or disconnected for some reason or another. With a private or offline instance you can develop anywhere, such as with a simple MacBook Air running your development environment and the micro Cloud Foundry virtual machine you’ve created.

The really great thing is that the micro Cloud Foundry instance requires a very small resource imprint. Some have even run Cloud Foundry on the small 256 MB RAM w/ 10 GB Disk instances at Rackspace with great results.

Instead of just reproducing instructions here, check out the Cloud Foundry blog entry Working Offline with Micro Cloud Foundry for step-by-step instructions to get running.

Public Micro Cloud Foundry
This configuration is setup around being able to always get to the micro Cloud Foundry instance from an Internet accessible machine. This is a great way to setup an instance for experimenting with network configurations, routing, or other things you may need to customize per a specific environment.

To get setup with a public micro Cloud Foundry instance check out the Cloud Foundry quick start article Micro Cloud Foundry Installation and Setup.

.NET and Iron Foundry on Windows 2008 Server
Windows 2008 Server Iron Foundry, the .NET Cloud Foundry fork, will be available in the coming days and posted on the Iron Foundry blog. So keep reading and I’ll have more information about Iron Foundry, Cloud Foundry, and the related necessities to get .NET up and running in the Iron Foundry PaaS!

Summary
In this entry we’ve covered a lot of topics and target points for Cloud Foundry. With this basic knowledge around the installation and setup of Cloud Foundry an environment can easily be setup on AWS, Rackspace or any environment with virtual instances. In addition, nothing is there to prevent this from being done on systems that are running directly on hardware.

In my next entry, we’ll step into actually getting some deployments moving forward so that we can get a view of the real power of Cloud Foundry. So keep reading and Part 3 of Removing the Operating System Barrier with Platform as a Service will be coming to you in two weeks!

This is the second of five guest posts from writer Adron Hall. Adron is a jovial, TDD, BDD, get things done well software architect, engineer, coder and jack of all trades. He runs the gamut of dev stack from Ruby on Rails to Node.js to.NET (though his favorite these days is Ruby with a growing admiration for the chaos of JavaScript). He’s passionate about DevOps and loves to get involved in hackathons, user groups, and other tech community events. He tries diligently to keep improving and writes about his adventures at his blog Composite Code.

Jonah Kowall, Research Director at Gartner, Inc. said today “With changes in both the way applications are developed and deployed there is an ever increasing complexity, but also unprecedented agility. Enterprises need to deploy tools which are easily implemented, maintained, and provide business value. The cloud is driving many of these new approaches to IT management, which provide visibility while still being adaptable to keep pace with the rapid pace of change.”

Today we released a white paper describing five best practices companies can implement to take advantage of the benefits of rapid app development and deployment while regaining control over app performance. Organizations that successfully implement these processes can improve online service delivery, respond faster to changing market conditions, and increase employee morale and productivity.

To help enterprises take advantage of these benefits, we have launched a new program that guides organizations through an evaluation of our APM tool. Highlights of the program include:

- A free trial of New Relic on 100 (or more) managed servers
- Support from a dedicated technical expert
- A detailed installation planning session
- In-depth technical training
- An end-of-trial performance review

If your organization is interested in taking advantage of the program, check out our Enterprise site.

Congrats to our winner Dave Proffer!  We hope to see you there.

TL;DR:

What’s with all the t-shirt giveaways lately? 

First and foremost, we love developers and we want you to have one of our shirts when you deploy New Relic. So go deploy us now and get your free shirt here.

Secondly, New Relic is on a mission. We are creating app management that ANY organization with a business-critical web app can use. We think EVERY developer will benefit from a New Relic account, hooked up to WHATEVER app they are working on.  Big apps.  Small apps.  We’ve worked VERY hard to make our product an experience that people fall in love with the moment they start using it.

The other reality at play here is that New Relic is a high-volume, high-transaction online business. We are interested in acquiring new customers and are doing what we can to achieve our business objectives. The thing is — New Relic is a new concept; sure, we have over 15,000 active accounts and many times more users than that, but the idea of a SaaS app performance tool is still pretty new to a lot of people. To get people over the hump of “hey, neat idea – maybe I’ll try it someday”, and move ‘em to “Rockin’, now’s the time!” We offer incentives.  We’ve tried RC helicopters, but t-shirts are much more cost effective.  So far, we’ve given a few hundred of these incentives away, and we’re not going to stop.

At the end of the day though, we are providing a service that we know will help you deliver and maintain high performance web apps. We are invested in your success. 

Here’s our formula for YOUR success:

1) Try it.
2) You’ll love it.
3) But you have to do step 1 before step 2

This model works at this company because we believe we have a truly useful, unique, magical, wonderful product. If we didn’t, this type of marketing would be wasteful.

Where we’d prefer our money to go, anyway!

Even more important, we look at our marketing budget this way:  We’d prefer to spend a little money outfitting our users in cool shirts rather than giving it to google for expensive adwords. We end up doing both, but we love the idea of you wearing our shirts to your next local meetup.  We’re a global company, but hey…we act locally.

Only new people who come to New Relic?  What about existing customers!?

We haven’t forgotten about you and are taking steps to ensure that you have the chance to participate in our online promotions going forward. Case in point: we’ve been overwhelmed with the interest in our t-shirts from our existing customers.  As mentioned above, we use the Ts to help us acquire new customers.

We can’t buy 60,000+ t-shirts for all New Relic users around the world, but here’s what we can do, it’s simple:

1.  Share New Relic with friends, developers, etc.

2.  When one of your friends signs up AND deploys our agent into their app, we’ll notify you and send you a T-shirt!

3.  Your friend who followed your link and deployed will get a free RC helicopter! (or T-shirt if we run out)

4.  Bam!  That’s it.

Seriously! NO Purchase Necessary (But please don’t rip us off; we’re good people )

We know there will be a few bad apples who will inevitably try to beat the system for a $20 t-shirt (it’s a nice american apparel shirt!). They will install our agent in their app, claim victory, demand a tshirt, then rip us out of the app.  Please don’t do this.  We have a free version – we think you’ll like it!  Our model works like many freemium models (like, say… Dropbox).  You try us.  80% of you will never buy from us. But 20% will, and we make money on that math.

Proof that this isn’t a scam?  

It isn’t.  Here’s two customers who have tweeted about receiving their tshirts.  How much did they pay?  Zip.  But now they see the power of New Relic!

So go ahead, please consider telling all your friends about this initiative.  Share this post on Twitter.  Let’s double this customer base of active accounts together!

In case you missed it, here’s our holiday video.  We LOVE developers.  And we want them all wearing our schwag!

The report suggests that Developers plan to invest most of their time, talent and energy in mobile and API projects over the coming year — and will continue to code in a variety of languages.  Apparently the survey itself was conducted in late November 2011; around 3,335 respondents were polled.  Zend’s products are used at over 40,000 companies.  As you surely know, PHP is the programming language that powers about a third of the Internet, including Facebook, Wikipedia, WordPress, Zynga and many other household-name-type websites and services.  It is one of the fastest growing segments of New Relic‘s Web App Performance business, and is popping up more and more in the cloud – including Zend’s PHPcloud.com and Engine Yard’s purchase of Orchestra.

The Developer Pulse report tells us around two thirds of developers around the world will be working on mobile app development projects in the next 12 months. And a further 67 percent of the developers surveyed said they wanted to improve their mobile app development skills this year.

The report is skewed toward PHP developers (shocker!) but the results are still very interesting and relevant.  Anyway, the report is full of great nuggets about 2012 – see the charts below.  Feel free to add any comments!  Oh, and the biggest, most important piece of data I learned from the report?  A full 86% of developers like to listen to music while coding.

Thanks to the team at Zend for the interesting data.  Of course, with all this great new PHP code being written, someone needs to monitor and manage the performance, right?  That’s where we come in!  Below is borrowed directly from their press release:

Key Survey Findings:

Technology investment and developer areas of focus for 2012
Key areas of technology investment are revealed by the types of projects that developers expect to tackle as well as their priorities for career and skills development in the new year.
Key project focus areas:

•    66 percent of developers will be engaged in mobile app development projects
•    For each of these four key technology areas —cloud, social media integration, big data/analytics, and producing APIs — between 40-50 percent of developers said they will have projects underway in 2012

Career and skills development priorities:

•    Next-generation UI development scored high both in the large enterprise and overall (75 percent)
•    67 percent of all developers surveyed are looking to hone their app development skills on mobile platforms, and 46 percent in cloud application development
•   As one might expect, among corporate developers at companies over 100 employees, another priority is gaining expertise with Big Data/analytics (44 percent)

Strong Interest in Cloud Development

•    More than 60 percent intend to use some form of public cloud in their development projects, with Amazon ranked the most popular at 30 percent
•    As far as skills are concerned, 46 percent of all developers surveyed are looking to hone their skills in cloud computing, with a high desire to gain expertise among 52 percent of developers in large enterprises. This result is consistent with the high level of interest that Zend is seeing at phpcloud.com (launched in October 2011), where developers are actively building apps for the cloud, in the cloud, in the Zend Developer Cloud sandbox.

State of Languages
The new norm among developers is use of multiple languages, and rising use of dynamic open source languages, and the Zend Developer Pulse™ survey echoes this trend.

•   Four languages, PHP, C, Java and Javascript dominated survey results, with a number of other languages trailing far behind
•   Two-thirds of all developers surveyed spend more than 50 percent of their time with PHP, using PHP as their core language; this includes an uptake of PHP in the enterprise
•   Developers reported that in addition to PHP, they use 1-2 other languages on a regular basis; as high as 33 percent of enterprise developers report using both PHP and Java

Demand for PHP Skills
Survey results show that developers see rising demand for PHP skills in 2011-12 compared to previous years, and independent data strongly support this trend.

•   From an employment perspective, more than half of developers surveyed see increasing demand for PHP skills in 2011-12. This finding is supported by data from oDesk, an online employment platform, which posts an average of more than 4,000 new PHP jobs per month and reports PHP as its #1 job posting.
•   Looking to bolster its talent pool with experts in PHP and several other leading programming languages, Facebook recently bypassed the standard résumé request in favor of setting up online coding tests to pre-qualify candidates for phone interviews.

According to Andi Gutmans, CEO and co-founder of Zend, “As our survey and other industry findings confirm, 2012 brings with it escalating requirements for cloud, mobile and social apps.  Enterprises are investing in PHP development projects and skills, and turning to Zend to help meet these requirements so they can build and deploy business-critical PHP apps that drive real business value.”

JAVA

Java Performance Tips
Java Performance on Wikipedia
Intel’s report on Java Performance tips
Java performance tuning (book)

.NET

.net Performance Tips
Improving .net performance (book)
Improving .net and asp performance

PHP

PYTHON

Python Performance Tips
Python Performance Tips
10 Optimization Tips and Issues (for Python)
Python Patterns
Python Profiling

RUBY
Super Simple Ruby Performance Tips
10 Controversial Ruby Performance Tips
10 Tips to Boost your Ruby on Rails Performance
Rails Lab

Great resource list from Alex Podelko:  Performance Engineering

 GENERAL PERFORMANCE TIPS

Stoyan Stefanov’ “Book of Speed”
Strangeloop’s Web Performance Hub
Steve Souder’s Web Performance Site
Yahoo’s developer center:  Web performance
Performance Calendar
Presentation on web performance
Web Performance Matters Blog
Apdex – an industry standard for performance measurement
10 Realistic Steps to a Faster Website

PS – If you haven’t tried New Relic’s app performance tool – now’s the time – go here and when you deploy the free service, you’ll get a free “data nerd” t-shirt.

- @analyticsseo shows us how they used New Relic to identify the cause of their site’s recent outage.

- Steve Souders talks about improving JavaScript performance.

- Darren Jones tells us why you should consider using both Rails and Sinatra for Ruby development.

- Ben Curtis describes how he deployed New Relic’s Server Monitoring feature with Chef.

- Robert Booth of Zenoss tells what DevOps and Borat have in common.

- InfoWorld digs deeper into the open source versus commercial app server debate.

- Romiko Derbynew discusses Neo4j application performance profiling with New Relic.

- Pantheon gives their perspective on our recent partnership

- Randall Degges gives his reflections on Waza, Heroku’s developer event.

- Application Development Trends eulogizes the single-language developer.

We spent last Wednesday at Waza, Heroku’s first developer event. (Waza is the Japanese word for art and technique.) New Relic was invited to give a talk that proposed and investigated a particular development method.

Held at Yoshi’s San Francisco, Waza was one of the most polished events we’ve attended. Adam Seligman and his team did an amazing job focusing on the developer experience, putting careful consideration into ensuring high value conversations all around the venue.

Our own Darin Swanson gave a talk about ‘Ripping Needles out of the Haystack’ in which he ‘ran’ through the parallels of development technique and ultrarunning races. In both, you not only need to train to race, but you also need to race to race. Much like training is not racing, your staging environment is not production. Therefore, it’s critical to incorporate post-production feedback into your development process since no race plan survives past the starting line. Darin rounded out the talk with a real-life story of how New Relic incorporated post-deploy feedback to identify and resolve an issue (a bot that hit our Documentation app) and improve our application performance.

If you missed Darin’s talk, don’t worry, the entire event was recorded. We’ll update this post with the recordings as soon as they’re available, so check back soon.