For those of you like myself that didn’t have the good fortune of going to Google I/O, I hope you caught this video, “Breaking the JavaScript Speed Barrier:”

As an aspiring developer, this was far and away the most intriguing and helpful video from the conference. This talk, delivered by Google’s Daniel Clifford, provides a number of essential guidelines for writing JavaScript that is better optimized for running on Google Chrome’s V8 JavaScript Engine. Google has been doing pretty incredible things in the last few years with JavaScript, improving benchmarks and narrowing the speed gap between JavaScript and other languages that was once thought to be unbridgeable.

We should be grateful that Google has invested so much time and energy into optimizing JavaScript performance. It has never been more important as a language, and its star is unlikely to fade anytime soon. For Clifford, optimizing JavaScript performance not only helps us do the same old things faster and better. It also broadens our development horizons and transforms the kinds of things that are possible, especially in the sphere of front-end development.

I won’t give a fully fleshed-out summary of the talk, as I would recommend watching it on your own. It’s briskly presented...

Read on...

Comparing a Platform-as-a-Service (PaaS) to traditional hosting like VPS/shared hosting (e.g. DreamHost, Host Gator, GoDaddy) or infrastructure-as-a-service hosting (e.g. Amazon Web Services, Linode, CenturyLink Cloud) is like comparing apples and oranges. One must look beyond hardware and price to get a true cost/value when picking a hosting provider.

Shopping for traditional hosting is too much like shopping for breakfast cereal: many mediocre options, little differentiation, annoyances for up-sell.

Traditional hosting… (aka “do it yourself”)

With traditional hosting developers have many responsibilities before they can even touch a line of code. Lets look at some of these responsibilities…

• Set up the application server (e.g. Apache, Nginx, etc.)
• Set up MySQL database
• Setting up the run-time platform like PHP, Ruby, etc
• Something isn’t working.
• Diagnose, re-configure/re-setup, try again.
• Dependencies… right, have to setup those up too.
• Setup FTP to deploy your code.
• Setup security and firewall.
• It worked on localhost, why isn’t it working now!!!

As you can see, before you get to the code, you’ll have to spend hours getting your production environment in a state which is just barely good enough to host your application. If you want your application to be reliable, scalable, and resilient against various failures, you’ll have to deal with additional issues like setting up monitoring, alerting, load...

Read on...

I know what you’re probably thinking: I’ve written this post to recommend developers to add swagger (note the small “s”) to their existing set of skills and attributes. While I certainly do not disrecommend swagger as a character trait, my purpose today is instead to talk about the Swagger (note the big “S”) API documentation and exploration tool.

Swagger enables you to transform your API into a sleek UI that makes it vastly easier for third-party users to see an exhaustive list of what your API offers, how requests are matched with URLs, and what the server will return in response to specific requests.

Swagger also provides a sandbox UI for experimentation with APIs. Have a look at the demo UI. What you find there is an API for a hypothetical pet store. If you click on “/pet” for example, this will open up a menu of all of the HTTP requests associated with that directory.

If I want to see what pets are available with the ID “Fido,” I simply need to open up the menu bar associated with GET /pet.json/{petId} requests, insert “Fido” into the text field, and hit the “Try it out!” button to get the API’s response:

What I get...

Read on...

Bruno Terkaly is a heck of an interesting and intelligent guy. I suggest you check out his many videos and writings. As a fellow developer evangelist, I look up to Bruno a lot. And like him, I’m heavily invested in the platform-as-a-service (PaaS) paradigm. And so when I came across this piece of his from a while back, I couldn’t help but devour it and ruminate on it for several days. It’s an impressive bit of thinking but I feel that there are some serious problems with his understanding of PaaS.

The argument of the piece, titled “Why Platform as a Service (Robotics) will rule the world,” is essentially this: PaaS will rule the (cloud) world because the principle behind PaaS is automation, and automation is the core of a “radical technology revolution” that is slowly but surely making our global digital architecture more efficient. Terkaly even goes as far as to equate PaaS and “robotics” in the very title of the piece. The premise is that PaaS essentially roboticizes cloud infrastructure and thereby makes it vastly more efficient and easier to use.

How does this roboticized system work? The answer lies in what Terkaly calls the Fabric Controller. It lies at...

Read on...

It’s no secret that there’s lots and lots going on in back-end web development these days. As an example, debates surrounding node and asynchronicity, to give just one example, have reached a fever pitch and have occasionally felt more like philosophical arguments than technical arguments.

The same has been true for debates between “thick” frameworks like Rails and Django versus “thin” frameworks like Sinatra, Flask, and Express. On top of these issues, we’re also witnessing an explosion of creativity in the world of full-stack frameworks (Padrino for Sinatra, Tower.js for node, etc.). (More on this very soon, so be sure to hit a subscribe link on the right)

But what has surprised me recently is that similar developments are afoot in the world of front-end development. The shining example par excellence: Twitter Bootstrap.

Bootstrap was essentially a big, juicy bone thrown to the web development community by Mark Otto and the folks in the design department at Twitter. The purpose is to allow third-party developers to easily lend some much-needed aesthetic consistency to the world of Twitter-related web apps, which now number in the hundreds of thousands (see this article by Drew Heatley, which gives a figure of a million, which I didn’t...

Read on...

For the 3rd straight year, CenturyLink Cloud was recognized by Gartner in its influential Magic Quadrant (MQ) for Cloud Infrastructure-as-as-Service. Readers of the MQ don’t just like it because it summarizes an entire industry with a single visual representation. Rather, its real value is derived from the deep analysis of vendors and market dynamics. Each year, the criteria for inclusion gets tougher as the demands of enterprise customers mature. In 2013, vendors can’t simply offer a warmed-over virtualization environment and brand it a cloud.

Gartner went hands-on with our platform and came away impressed.

CenturyLink Cloud combines an excellent, highly differentiated set of features on a well-engineered platform with an easy-to-use self-service portal. It is one of the few services with both cloud-native capabilities that are attractive to developers and the governance and management features needed by large enterprises.

In fact, one of their “cautions” about our company included an important compliment. Gartner says that we “will be challenged to match the engineering resources available to the market leaders, and therefore challenged to maintain its platform lead.” We aren’t a big company, but our engineering team has accepted that challenge head on. We look forward to building on this lead in...

Read on...

Can you understand what you just paid your cloud provider for? Did your accounting staff have to invest significant amounts of time deciphering the costs and figuring out how to bill each department for their usage?  There is often an unexpected human cost of cloud computing and billing is one area where you may end up frustrated if you don’t have a plan in place. At CenturyLink Cloud, we’re trying to ensure that our customers have an easy to understand bill that can be consumed in multiple ways.

There are five focus areas of our billing approach, and we believe that you should look for these from ANY cloud provider you work with.

1. Embrace the dynamic nature of the cloud

Paying for resources in the cloud is unlike anything that enterprise IT has experienced before. Unlike traditional servers where you pay an upfront cost, cloud servers are pay-as-you go and resizable on the fly. Need to double the CPU on a database server during an intense processing period? It’s easy, but it alters the cost of the server as originally provisioned. Cloud servers are inherently easy to create, easy to delete, and easy to scale. This can wreak havoc on financial...

Read on...

In a number of casual–and sometimes not-so-casual (!)–discussions about client-side JavaScript libraries, I’ve noticed that people have an unfortunate tendency to lump them all into a single amorphous blob. Backbone? Ember? Angular? Knockout? They all do something-or-other involving structuration on the front end; they’re all more or less the same thing.

WRONG!!!

There are indeed deep similarities between these libraries in terms of what they offer developers, but understanding their differences means understanding which use cases they’re best suited for. Here, I’ll make a foray into this discussion by outlining some of the basic characteristics of Knockout.js I’ve discussed Backbone previously, and I’ll discuss the others in a future post.

According to Knockout creator Steve Sanderson in this video, Knockout, like many other libraries, was meant to provide “rich client-side interactivity.” HTML and the DOM are never ever ever going to provide you this on their own. What you see is what you get. In 1992, that was just fine. In 2012 we expect a whole lot of interactivity on the client side, but this kind of interactivity can’t be built on sand. Doesn’t a library like jQuery get us there? Well, not quite.

Binding jQuery to an underlying data structure

Knockout is a library...

Read on...

Since having our infographic published on GigaOm, there has been a lot of controversy and FUD around “NoOps”. Paul Graham recently wrote about schlep blindness. NoOps is a response to the schlep blindness of developers doing SysOps.

What does NoOps mean?

• NoOps means developers can code and let a service deploy, manage and scale their code
• NoOps means automated systems like CloudFoundry managing app lifecycles, not SAs “the point isn’t that ops are going away, but they’re going away for developers” – Derrick Harris at GigaOm

What does NoOps NOT mean?

• NoOps doesn’t mean that operations are dead and nobody will do them (like this tweet thinks)
• NoOps isn’t a job role (like this tweet and this tweet thinks)
• NoOps isn’t blissful ignorance (like this tweet thinks)
• NoOps isn’t marketing fluff made up by non-technical idiots (like this tweet and this tweet thinks)

This is the true spirit of NoOps:

“Netflix runs NoOps … Netflix is a much larger example of a PaaS based NoNops organization … We claim a competitive advantage from the agility and automation of a PaaS based product and a NoOps organization.” – Adrian Cockcroft, Cloud Architect at Netflix (read more)

The growth of the SysOps movement has been driven mainly by developers who were tired of...

Read on...

We’re starting a new video blog series here– one focused on diving into some of the new features our engineers are building in our products.  Why now?

• Building cloud services is hard and requires serious engineering. We’ve learned a lot over the past 7 years, and like sharing our experiences. We’re often early adopters of technology that make distributed systems more powerful and easier to administer.
• We have a perspective the community may be interested in.  The cloud is maturing from basic dev/test scenarios towards true mission critical applications.  We’ve spent a lot of time thinking about the enterprise, and it requires a different mindset in a number of ways.  That is a topic we’ll be re-visiting from time to time.
• We have matured our development processes.  With the arrival of some very senior engineering leadership, we have been able to dramatically accelerate how quickly we deploy new features in our global footprint of data centers.  We also have a number of relevant “customer-driven innovation” practices that have informed our thinking and roadmap priorities.

First up: I speak with Troy from our dev team on our new global search feature.  The more VMs you have, the harder it can be to find them.  Several...

Read on...

Last week, CenturyLink Cloud attended the Microsoft Worldwide Partner Conference in Houston, TX and hosted a booth where hundreds of attendees stopped by to talk about the cloud. Besides seeking what one attendee called “the best t-shirt from any conference, ever”, most people wanted to have a discussion about how the cloud could positively impact their business. With over 15,000 attendees from over 150 countries represented, this conference offered us a prime opportunity to hear about the interests and needs of a diverse audience.

Over the course of four days, I noticed a theme among the conversations I had with software vendors, Managed Service Providers, consulting companies, and even Microsoft themselves!

#1 - We’re past the “cloud 101” discussion

It appears that a vast majority of technical staff now understand the basics of the cloud value proposition. There was no “what is this cloud thing people are talkin’ about?” types of questions from any of the attendees. Rather, the questions and conversations were more nuanced as Microsoft partners were trying to figure out how they could capitalize on the cloud, and where the cloud was forcing them to change their existing set of products and services. Most people understood that the cloud brings...

Read on...

Some of you might remember a Backbone blogging engine I made a while back. It certainly wasn’t the most advanced use case for Backbone, but I think that it did a decent job of elucidating some of Backbone’s features: event-driven responsiveness, templating, collections, and so on. It was also a great learning experience and my first foray into thick client-style development.

But then a few weeks ago, a number of trusted friends and colleagues began raving about AngularJS. Curious about what the fuss was about, I began doing some exploring, looking at sample apps, reading the API docs, and watching a few videos, and it became abundantly clear that Angular is an almost shockingly powerful library. I was surprised by the kinds of heavy lifting that can be accomplished with little effort. And so I set out to see how concisely I could re-implement my Backbone project in Angular.

I was quite pleased with the result.

Getting started

The first thing you need to do is specify within your <html> tag itself–I know, crazy, right?–that your HTML page is going to be staging an Angular app. Instead of the typical <html> tag, you need to insert a <html ng-app> tag instead. As you’ll see...

Read on...