By Leigh Shevchik

January, 2012

You know that going to the DMV takes forever. You know that, occasionally, something gets lost in the mail. Or when you place a complicated lunch order, there is a good chance it will come out wrong. And no matter what mobile provider you use, you know the network is unreliable and will sometimes drop a call. Whenever any of these things actually happen, you still get ticked off because no one likes a bad experience. Even when you expect an inconvenience, you want to be pleasantly surprised. When you’re not, you most likely look for someone to blame.

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.

By Leigh Shevchik

January, 2012

In this week’s roundup find out how to speed up your website, look at how Ruby, PHP and Python stack up, and learn the new rules for enterprise applications.

- 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.

By Leigh Shevchik

January, 2012

Welcome to Part 2 of my series on Removing the OS Barrier with PaaS. In Part 1, I covered the Platform as a Service (PaaS) product based on Open Source Software (OSS) Cloud Foundry and the .NET fork called Iron Foundry. In this entry I want to dive into some of the various parts, configuration, and setup of these products.

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.

By Leigh Shevchik

January, 2012

Cloud computing, the consumerization of IT, and the rise of the do-it yourself developer all make creating and deploying apps easier. InfoWorld calls this the biggest shift in IT since the start of the PC-era in the early 1980s. And the speed of this change is only accelerating. But one unintended side effect of today’s incredibly fast-paced development cycles is that app monitoring and management tools often times can’t keep pace, resulting in the deployment of apps with limited visibility. This introduces risk into projects and amplifies the effort required to ensure ongoing performance and availability of web applications.

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.

By Leigh Shevchik

For the past four years, we’ve been a Silver Sponsor of LA Ruby Conf, a three day event focusing on hands on Ruby training, code immersion and skill improvement. The 2012 conference takes place February 2 – 4 at the Holiday Inn Media Center in Burbank, CA.

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