In a few weeks, CenturyLink Cloud will roll out the first phase of visual changes to our Control Portal cloud management software. These changes are not only visually stunning, but functionally significant for our customers. Why are we making these changes, and what should you expect? This blog post dives into our motivation for the changes, and provides a sneak peek into what’s coming in the months ahead.

Why the Change?

We’ve all heard the saying “if ain’t broke, don’t fix it.” CenturyLink Cloud constantly receives positive recognition for our Control Portal, and Gartner recently lauded our “easy-to-use self-service portal” that showcases an “excellent, highly differentiated set of features.” Why are we moving forward with some substantial modifications to the user experience? We’re focused on five reasons:

• Improve Application Performance. Web applications need to be fast to maximize utility, and so too does our Control Portal. We want our users to spend _less time _in our interface, create and manage complex environments, and more time solving strategic business problems. We’re constantly tweaking the current software experience to squeeze out performance improvements, but needed to take a new approach if we wanted to speed up the experience _and achieve new embedded analytics functionality. Our

Read on...

It’s hopeless trying to keep up with developments in the Node.js community. Believe me, I’ve tried.

Once upon a time, I held out hope that I would be able to keep my finger on the pulse of Node-related discourse, but it all turned out to be in vain. New modules are added and updated to npmjs.org on an almost minute-by-minute basis. It’s enough to make your head spin (in a good way, if that makes sense). However, there have been a few big and bold movements in the Node.js space that have caught my attention recently that I think are incredibly promising and that I just couldn’t keep to myself: desktop client creation with App.js and WebRTC.

Make some room, Qt: App.js is the new kid in town

Did you ever want to use JavaScript to construct a rich UI experience in a non-browser setting? Well, now is your chance. Did it never even occur to you to try such a thing? Well, that’s okay, too, because I always assumed that I would have to learn C++ to ever accomplish such a thing. But playing around with App.js, which is available as an NPM module, has convinced me that this is a really...

Read on...

Does running your application in the cloud mean that it’s suddenly able to survive any problem that arises? Alas, no. Even while some foundational services of distributed systems are built for high availability, a high performing cloud application needs to be explicitly architected for fault-tolerance. In this multi-part blog series, we will walk through the various application layers and example how to build a resilient system in the Public Cloud solution. Over the course of the next few posts, we will define what’s needed to build a complete, highly available system. The reference architecture below illustrates the components needed for a fictitious eCommerce web application.

In this first post, we look at a core aspect of every software system: storage. What type of storage is typically offered by cloud vendors?

  *Temporary VM storage. Some cloud providers offer gobs of storage with each VM instance, but with the caveat that the storage isn’t durable and does not survive server shutdown or server failure. While this type of cheap and easy accessible block storage is useful in some situations, it’s not as familiar to enterprise IT staff who are used to storage that’s durable by default.

  *Persistent VM storage....

Read on...

Earlier this week, over 450 developers and cloud leaders gathered in Santa Clara for the first Cloud Foundry Conference - Platform. The event brought together contributors to the open platform as a service product, as well as real world users for two days to discuss technical topics, product roadmap priorities, community contributions, and operational best practices.

CenturyLink Cloud founder and CTO Jared Wray was one of the thought leaders who spoke during the conference. His topic: Extending Cloud Foundry to .NET via Iron Foundry.  This open-source project unites two large ecosystems: .NET developers and Cloud Foundry.

To learn more, check out the slides and video of Jared’s presentation.

We were happy to be sponsors of this event and are looking forward to the next one!

[University Students from China who have used Iron Foundry to deploy .Net applications]

Read on...

Elasticity is a core tenet of cloud computing. Cloud has become so popular simply because resources can be adjusted up or down, based on business need, instantly. Manually resizing cloud environments is still MUCH easier than altering physical hardware. But human action is still required, adding human cost to cloud.

A few cloud vendors have attempted to automate this process through “auto scaling” – services that expand and reduce the size environments based on user-defined parameters. However, this capability by and large automates the addition and removal of virtual machines to an existing resource pool.  In engineering terms, this is “horizontal scaling” – adding capacity across multiple virtual machines. This approach is useful for consumer applications (think Netflix scaling up for Saturday night), but the enterprise scenario is much different, as we found out in our market research when developing this feature.

While we always recommend that our customers build highly available cloud systems with no single points of failure, there is value is sizing those resources up and down (i.e. “vertical scaling”) instead of only being able to add or remove entire servers. Having multiple servers is key for fault tolerance, but some workloads can benefit from additional server capacity, not...

Read on...

In a recent post, on data models and persistence, I made what I now realized to be a pretty fundamental mistake: I talked about the use of data models in web development, but I restricted my discussion to MVC-style frameworks alone and should have said more about alternative design patterns.

I restricted my discussion in this way more for the sake of brevity than anything else, but I’ve learned a lot in the last few weeks about alternative architectures and want to begin weighing in. Next week, I will discuss Knockout.js’s MVVM (model-view-view model) front-end architecture and the abstraction gains associated with it. But first, I want to discuss another alternative to MVC that’s been getting a lot of traction on the webs in the last few days: the MOVE framework, as outlined by Conrad Irwin.

MOVE is an (admittedly quite clever) acronym for Models-Operations-Views-Events. What the term seeks to capture is an emerging way of structuring applications that doesn’t rely on an explicitly defined and coded controller. The problem, according to Irwin, is that quite often “you end up stuffing too much code into your controllers, because you don’t know where else to put it.”

A much better way of doing things...

Read on...

Make no mistake: for people who hack on UNIX-based systems, curl is a really powerful command. It enables you to extract the client-side content of any web page in an instant and also to do all kinds of things with the result, like dumping it into a .txt file (a trick which has been extremely useful to me in learning web development).

But the curl command doesn’t always function all that intuitively on the input side, and the output always comes out monochromatic, making it difficult to immediately discern what’s going on in the stream of text you’re presented with in the CLI.

HTTPie, in the words of its creator, was built “out of frustration with existing tools.” It provides the capacity to make both more intuitive requests and polychromatic output. Using it couldn’t be any more simple. The commands underlying an HTTPie request look like this in generic form:

http [flags] [METHOD] URL [items] Let’s have a look at a sample POST request (taken from HTTPie’s GitHub readme):

http --form POST api.example.org/person/1 name=’John Smith’ email=john@example.org The equivalent request done with the curl command:

curl --data “name=John+Smith&email=john%40example.org” api.example.org/person/1 Requests in HTTPie aren’t necessarily significantly less verbose than curl requests. But that’s not their primary function. The benefit of...

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

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

Unless you live under a rock, you have heard of Cloud Foundry. However there is still a lot of skepticism out there about PaaS in general and Cloud Foundry in particular.

I’ve been an open source hacker for over a decade. Compiling linux kernels, hacking MySQL, and generally getting my hands into every system that I could. I have also authored over a dozen open source libraries, some being used widely.

When I saw PaaS in the early days, with EngineYard and Heroku, I thought it was really cool and inspiring. Like many hackers though, it is hard to trust something or fully enjoy it when you can not get under the hood.

Why does Cloud Foundry matter?

EDIT — It is a great PaaS. As the first commentator noted, none of this matters if the technology sucks. Cloud Foundry is a great, easy to use technology that works reliably, simply, and smartly. It supports many languages and many services. To a hacker and tinkerer, it is a haven for fun.

It is well designed. Example: A message bus acts as a nerve center to various components via pub/sub. For example, when a new app server comes online, it subscribes to listen for new app...

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