Hadoop is one of the hottest enterprise big data technologies in the cloud today. To make big data in the cloud easier for our customers, 8 Cloudera Hadoop Add-on Services are now available for CenturyLink Cloud®. Through an ecosystem of open-source components, Hadoop Add-on Services fundamentally changes the way enterprises store, process, and analyze data to solve all kinds of big data problems.

For many, Hadoop is too difficult to deploy and manage. Automating a four-node cluster can be a daunting task. But not with the Cloudera Blueprint for CenturyLink Cloud! We've taken the complexity out of Hadoop by automating the dozens of deployment steps associated with a new cluster environment. We reduced all these steps to just a few clicks of the mouse.

Benefits of Cloudera Blueprint for CenturyLink Cloud

CenturyLink's Cloudera Blueprint simplifies the process of installing, configuring, and adding components for an entire Hadoop cluster. The Blueprints come in 1 and 4 server configurations. If you need more than 4 nodes, additional nodes can be added in minutes by upgrading the Cloudera Blueprint version.

Log into the Control Portal.

Read on...

Developers love Docker. It’s simple, fast, and lightweight. There’s even an open-source community behind this tech that’s growing at an exponential rate. And there’s a decent chance that your organization is already using Docker; 70% of enterprises are using containers.

Further, Docker usage is serious business, notes Donnie Berkholz, Research Director at 451 Research (slide 13 of the deck):

Build or Buy

For organizations considering the next step in their evolution toward cloud-native development, a new choice emerges: Build on my current container usage today and advance it into a Platform with internal resources, or look outside my organization to buy these capabilities?

These two options are summarized nicely by Sam Ramji, CEO of the Cloud Foundry Foundation. Cloud Foundry is represented as the Platform option on the left. The Do It Yourself option on the right features the Kubernetes/Mesos approach to Docker.

Each option offers a thoughtful ways to embrace the 4 principles that will shape the future of IT. Both choices:

• Are based on open-source.
• Embrace the elastic, cheap compute of the public cloud (and private cloud where required).
• Offer significant abstraction, keeping IT out of the guts of the stack. Some assembly is required to get to this point for the "Do It Yourself" path,

Read on...

Today, we’ve announced a new way for developers to quickly deploy Docker containers on CenturyLink Cloud with automated scripts to configure and launch Kubernetes, the open source container orchestration system.

Why Docker and Kubernetes?

Docker containers allow you to run your software across multiple platforms, giving you reduced load times, version control, and reusable software components while removing the need to manage shared software dependencies. Kubernetes is the open-source platform for automating the deployment, scaling, and operations of application containers across clusters of hosts. Together, Docker and Kubernetes enable our customers to accelerate development, simplify operations, and deliver a truly open hybrid cloud strategy.

Both Docker and Kubernetes are open-source projects with large active communities. They are constantly rolling out new features and are being used in both small and large scale production environments.

Types of Applications

Docker and Kubernetes are the ideal combination for many types of applications. They enable 12-factor applications, micro-services, and cloud-native applications, as well as more traditional back-end services like databases, big data stacks, and file stores. Using a "pets" versus "cattle" analogy, this solution provides you with the tools required to run your applications like "cattle", not "pets".

Why Kubernetes on CenturyLink Cloud?

CenturyLink’s Infrastructure-as-a-Service (IaaS) offers on-demand virtual and...

Read on...

Periodically, we turn over control of the CenturyLink Cloud blog to members of our certified technology ecosystem to share how they leverage our platform to enable customer success. This week’s guest author from the Cloud Marketplace Provider Program is Erica Brescia, from one click application tool Bitnami.

Ever wished you had an easy way to deploy Redmine, SugarCRM, Alfresco, Drupal, or your favorite app in the cloud? Preferably one that didn't involve dealing with complicated server infrastructure, cryptic configuration files and multiple software versions?

Well, now you have one. We're pleased to announce that many of Bitnami's server applications and development environments are now available to CenturyLink Cloud customers as Bitnami Cloud Blueprints. With this integration, you can deploy over 100 Bitnami pre-configured applications quickly and securely on your CenturyLink cloud server...no tweaking necessary!

At Bitnami, we've taken the data we get from our million-plus deployments each month and used it to make sure that launching complex, multi-tiered application environments with our cloud images is as painless as possible.

Here’s how:

• All our applications are pre-compiled and pre-configured with all necessary dependencies so that they work out-of-the-box.
• They’re quick and easy to install; simply sign into your CenturyLink account and select the Bitnami Cloud Blueprint of your

Read on...

We value participating in the Open Source community at CenturyLink. Just in the past year we have made sizeable contributions to the community with tools such as Panamax, Lorry, Image Layers, Chef integration with VMware, Iron Foundry, Cloud Foundry, xUnit.net, Chocolatey, and ElasticLinq. We just recently announced even more contributions.

Today is a special day as we get to talk about how we are transforming internally to streamline the process for enabling the usage of open source and contributions.

Where we started was what would be called a very traditional enterprise policy that limited contributions but also made it very complex and cumbersome if you wanted to use open source or contribute. This could take weeks of approvals and in some cases just didn’t make sense for our engineers to pursue.

We have made major changes to our policy focusing on how not only can we embrace open source technology but also give back. Here are the highlights of our open source policy at CenturyLink now:

• Any engineer can contribute to a project as long as they follow the project’s guidelines. If they want to do this during working hours they just need their manager’s permission.

• While building products and services, it is acceptable

Read on...

I am happy to announce that we have recently open sourced our Chef provisioning driver for vSphere. This driver makes it easy to provision Chef nodes on VMware vSphere infrastructure.

What is Chef-Provisioning?

Chef-Provisioning (formerly known as Chef-Metal) is a fairly new offering from Chef that allows you to create Chef recipes to bootstrap machines. It extends the functionality of a recipe typically used for defining an individual node to potentially define all infrastructure for a distributed application or even an entire data center.

Chef-Provisioning introduces a collection of new resources to your recipes and at the center of these is the machine resource. With the machine resource one describes:

• Hypervisor or cloud-specific properties of a machine
• Node attributes to associate with the machine
• A runlist that the created machine will converge

Chef Provisioning exposes a driver interface making it possible for any hypervisor, cloud or even some bare metal infrastructures to interact with these machine resources. There are currently several drivers available and today, CenturyLink introduces our own driver for vSphere.

Chef Provisioning for the Enterprise

The CenturyLink-released driver fills in a significant gap for provisioning Chef nodes in enterprise shops that use VMware for their core virtualization technology. We began working on this in the spring of...

Read on...

I’ve had the honor of sitting in the same room with many customers and prospects who share their business models and technology challenges. In the exact words of one of our customers, “Our cloud deployment is a horrendous process.” From others, “Our developers work in their own private cloud, and they send us the release code and it takes us days to weeks to get it running in production.”

Doesn’t the cloud promise faster, more agile development with reduced costs? Why then isn’t this promise being fulfilled at most companies adopting DevOps and cloud?

Why Is It Broken?

I keep hearing a recurring theme. Heavy use of open source tools and development and production environments that don’t mirror each other. Developers have their favorite list of tools and operations theirs. Neither group understands how to use and configure the tools the other group is using. Throw in multiple versions of these tools and it quickly becomes an unwieldy mess. Here’s a sample set of technologies and stacks we come across:

We commonly see development teams using these technologies:

• Python
• MySQL
• Git
• Jenkins
• MongoDB
• Node.js
• ADD MORE

We commonly see operations teams using these technologies:

• Chef
• Puppet
• Ansible
• Nginx
• Splunk
• New Relic
• AppDynamics
• ADD MORE

And we see development, test, QA, and production run on these clouds and platforms:

• Amazon AWS
• Google Compute
• Microsoft Azure
• VMware

Read on...

Just about every software engineer has had the experience of onboarding with a new team and spending a day, a week or more getting their development environments situated so they can actually run the application they signed up to work on and start committing code and being productive. Some teams try to improve upon this by maintaining a team wiki that documents setup instructions and may even include setup scripts. Unless these are actively maintained and curated they may cause more harm than help, leading the new developer down dead ends and on wild goose chases.

The best solution is less narrative and more executable documentation. One tool that many developers use to facilitate this and one we use on the infrastructure automation team at CenturyLink Cloud is Vagrant. Vagrant is a tool that makes it easy to share virtual environments across different virtualization platforms and makes destroying and recreating those environments an easily repeatable process. It also provides a mechanism that allows you to code in your native environment while your app runs in a VM.

In my first few months on the CenturyLink Cloud team, I worked on a Windows machine using Hyper-V for virtualization. Now I’m on an Ubuntu...

Read on...

On the heels of the opening of Cloud Development Center, it seems timely to revisit one of our founding beliefs: the embrace of, and contribution to, open source technologies.

We have seen open-source win in the enterprise again and again - especially as it relates to cloud computing and new web-scale architectures.  Why?

• Many developers, rather than few publishers.  The creativity of the masses is fundamental to open source; with a diverse set of creators, a diverse set of technologies is the result.  Some of them are bound to stick.
• No “innovators dilemma.”  While traditional vendors are focused on existing revenue streams, new players and individual developers are free to experiment without cannibalizing an existing product.
• Low cost of failure.  Developers can download bits, and start experimenting.  If something doesn’t work out, the only loss is time.  With a licensing model, there are usually more complex business terms involved in even trying a new product or tool.
• New business models focused on usage and support, not licensing.  The companies that have successfully commercialized open source tend monetize “customer success” and “win-win” scenarios instead of a multi-year licensing model that is likely to favor the publisher.
• More options. Open source doesn’t always mean you are free from

Read on...

CenturyLink the Cloud Development Center contributes ElasticLINQ to the community

Today I’m pleased to announce that the developers of the CenturyLink Cloud Development Center are contributing ElasticLINQ to the community. ElasticLINQ is a tool for those who wish to find and retrieve documents from Elasticsearch and easily convert those documents into .NET classes.

ElasticLINQ will help developers ease the transition from relational databases to distributed NoSQL systems. Using the same query language for SQL and NoSQL makes the transition simpler. This code was created by .NET devs for .NET devs and today we’ve made it available on GitHub under the Apache 2 license.

Who might use it? Any company looking to write for or port software into a distributed cloud environment could benefit from these technologies.  A typical use case is devs who are using Elasticsearch as a full-featured search system for an existing NoSQL database (such as a document storage system like Couchbase).  They will use ElasticLINQ to give them LINQ syntax to query documents stored in Elasticsearch.

This is a familiar use case for our CenturyLink Cloud engineering team here in Seattle.  ElasticLINQ was one of the outputs of our efforts to transition from MS SQL Server. Our team uses Couchbase and...

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

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

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

You know what’s pretty easy nowadays? Throwing a bunch of processes onto a server running somewhere far away. Dozens. Thousands. Millions. As many as you want. This was really, exasperatingly hard just a few years ago. But Amazon Web Service, CenturyLink, and other players have come along to make this pretty painless.

But you know what’s still really hard? Making those processes completely self-contained and yet running on one kernel and manageable from a single interface. This is the problem that Docker was meant to solve.

Brief intro to Docker

Docker chose to address this problem by building a developer-friendly abstraction layer on top of Linux containers (LXC). LXC is a powerful concept, but it simply wasn’t built as an intuitive interface. It’s a pain to use and prohibitively complicated for anyone but the most adept Linux power users.

And so the idea of enabling developers of all stripes to actually use them in a way that gets rid of tons of conceptual overhead and streamlines the use of containers into an actual runtime that makes real sense amounts to a massive win over the more low-level containerization tools that already exist.

Docker takes LXC and constructs a set of basic commands around it, commands...

Read on...

Iron Foundry” fills PaaS market gap for popular enterprise developer framework, accelerating cloud deployment for mission-critical enterprise applications

BELLEVUE, Wash.—December 13, 2011— CenturyLink Cloud, Inc., the enterprise cloud platform provider, today announced that has contributed to the open source community a .NET Framework implementation of the Cloud Foundry™ Open Platform as a Service (Paas). Named Iron Foundry, this contribution gives the industry’s fastest growing open source PaaS an implementation based on the popular development framework, .NET.

CenturyLink Cloud’s Iron Foundry contribution consists of the three key components required for developers to quickly leverage the open source project for their own PaaS implementation or to leverage Iron Foundry to deploy applications to the cloud immediately. In addition to a core .NET Framework fork of Cloud Foundry, which CenturyLink Cloud is committing to keep it in synch with the main Cloud Foundry branch, developers can also access IronFoundry.org for both a Windows version of Cloud Foundry Explorer as well as a Visual Studio Plugin for Cloud Foundry. CenturyLink Cloud will also make the core code available on GitHub under an Apache 2.0 license.

At CenturyLink Cloud, we believe that PaaS is so universal and so foundational to the adoption of cloud for web applications that...

Read on...

At CenturyLink Cloud, we’ve been big supporters of Cloud Foundry—the VMware-led, open-source PaaS framework—from the beginning. That said, we’re a .NET shop and many of our customers’ most critical applications are .NET-based. So today we’ve decided to contribute Iron Foundry, our own .NET fork of Cloud Foundry, back to the community as an open-source project.

This project includes both the primary framework as well as both a Windows version of Cloud Foundry Explorer and a Visual Studio Plugin for Cloud Foundry. (Video demos for the command line interface and Visual Studio plugin are located at the bottom of this post.) Because developers can run their own instances of Iron Foundry in-house or with any service provider who supports it, developers finally have a truly open, interoperable .NET PaaS solution that can be run inside and outside the firewall. And because you can run your own instances of Iron Foundry, it’s easy to have a full test, QA, and staging environment before pushing to production.

In addition, operations teams now have the freedom to choose among various service providers that meet their needs in areas such as security, compliance, availability, location, etc. For developers who are interested in trying Iron Foundry, we have...

Read on...