I went to my first Gartner Symposium last week for a big picture view of the intersection between business and IT. Symposium is billed as “the one show to go to if you only go to one show a year.” As such, my expectations were high.  It did not disappoint.

Keynote speakers, most notably Peter Sondergaard, in full prophet mode, discussed the disruptive nature of new cloud architectures, the Internet of Things, and 3D printing.  These trends, combined with other socioeconomic factors, would bring about the “Digital Industrial Economy.”

He then offered this choice to today’s IT executive: either enable your enterprise to thrive in the Digital Industrial Economy, or be relegated to caretaker of legacy systems while other roles lead the transformation.

The unease in the audience was palpable.  Squirming continued as he discussed a simple graphic on-screen: 90% of CIOs believe they are doing a good job, while 50% of CEOs say they need more from IT.  The keynotes set the tone for the rest of the conference.  Clearly, Gartner is advising clients to do more, and think bigger.

Our first analyst meeting the next day reinforced this.  The Gartner research team focused on “Web-Scale IT” mentioned that many clients are asking...

Read on...

Last month, CenturyLink Cloud rented a house in St. George, Utah to provide our engineers time to collaborate – they coded their hands off and had fun while doing so!

We asked our Sr. Software Engineer, Mr. Matthew Osborn (@osbornm), about his time at the Hack House and what he found most rewarding about the experience. His highlights:

• Time spent solving problems. Often problems, especially big ones – related to computer science, engineering, or anything for that matter - take hours of work to solve. Having more than the standard 8-hour day to think about and solve these problems is amazingly helpful. Yes it’s a lot of work, and it sucks some of the time, but you can do some truly awesome stuff.
• Time spent with the team. In a normal setting, you come to work do your job and then go home. You interact with your coworkers on a purely work-related level. Living with these same people changes that dynamic, and you are forced to build relationship that you otherwise would never choose to make. Interacting with folks on not just a work level but on a social level helps you understand their thinking and ultimately can really improve collaboration.
• Time spent on

Read on...

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 CenturyLink Cloud cloud. 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...

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

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

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

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

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