Autoscale – with an enterprise slant – now available from CenturyLink Cloud

August 5, 2013
By Richard Seroter, Senior Product Manager. Find Richard on Twitter

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

Two reasons why PaaS is so much more than automation

August 4, 2013
By Originally Published On AppFog

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

Twitter Bootstrap and the rise of total front-end frameworks

August 4, 2013
By Originally Published On AppFog

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

The developer’s toolkit: HTTPie

August 4, 2013
By Originally Published On AppFog

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

Optimizing JavaScript for the V8 Engine

August 4, 2013
By Originally Published On AppFog

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

Traditional vs PaaS hosting

August 4, 2013
By Originally Published On AppFog

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

Why Cloud Foundry matters to Hackers

August 4, 2013
By Originally Published On AppFog

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

The developer’s toolkit: Swagger

August 4, 2013
By Originally Published On AppFog

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

Putting the MOVE framework in proper perspective

August 4, 2013
By Originally Published On AppFog

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

Cloud Infrastructure Grows Up: Gartner MQ 2013 Analysis

July 23, 2013
By Richard Seroter, Senior Product Manager. Find Richard on Twitter

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.

CenturyLink Cloud on the Gartner Magic Quadrant

[**Download Report >>**](http://www.tier3.com/lp/gmq-2013)

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

Cloud Billing That Doesn’t Suck: The 5 Principles to Help IT Understand Their Spend

July 8, 2013
By Richard Seroter, Senior Product Manager. Find Richard on Twitter

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. CenturyLink Cloud Billing Widget 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...

The magic of not-even-rendering: on Knockout.js

July 4, 2013
By Originally Published On AppFog

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


Connect

    Follow us on


Start Your Free Trial

High performance, fast deployment times and intuitive management capabilities that will push your business forward

*We will send a SMS message to verify your account, standard rates apply.