Growing Up Fast: OpenStack Turns 4

by Sebastian Stadil on Jul 21, 2014 7:00:00 AM

OpenStack celebrates its 4th birthday today, and while the champagne corks are popping over at, we thought it would be another good opportunity to reflect on what we have observed in the OpenStack community in the last 4 years. We shared some of our impressions in our blog “OpenStack and the Top 5 Reasons for Private Cloud Adoption” after we returned from OpenStack Summit in Atlanta in May.

OpenStack can now proudly state that there are now more than 70 global user groups and 17,000 community members across 139 countries, spanning more than 370 organizations. What we find compelling is that they are no longer just early adopters dipping their toes in the water. While we love working with those brave enough to go where no one has gone before, it’s now exciting to see the plethora of traditional retail, media, banking, and finance companies that are adopting OpenStack. But we think OpenStack is just beginning to hit its prime.

Read More

Topics: Community, OpenStack, Cloud Platform, enterprise cloud

Top 3 IT Concerns When Adopting A Cloud Platform, And How To Approach Them

by Thomas Orozco on Jul 17, 2014 5:38:00 PM

Here at Scalr, we often work with IT organizations that are evaluating or adopting a Cloud Platform (such as AWS, Google Compute Engine, OpenStack or CloudStack), largely due to the nature of the software we are building (the Scalr Cloud Management Platform).

In our experience, IT departments that evaluate clouds are very aware of their business’s requirements for a cloud platform. They know that their cloud needs to be self-service, that it needs to be fast, that it needs to be flexible, etc.

But what about IT’s own requirements? Regardless of whether the company adopts cloud or not, IT is responsible for:

  • The security of the company’s infrastructure

  • The cost of operating said infrastructure

  • The enforcement of change management policies across said infrastructure

Oftentimes, IT departments are not sure about how to solve those problems once the company adopts cloud. In this post, we’d like to share our experience working with IT departments that have successfully identified and solved these problems.

The Underlying Problem: With Cloud, IT Is Accountable, But Giving Up Control

In a non-cloud environment, IT can enforce policies by carefully reviewing provisioning requests that are made by developers, and making sure they comply with the company’s policies.

However, when the company adopts cloud, developers gain the ability to provision resources on a self-service basis: they can use their cloud’s API to provision the resources that they need. IT is kept out of the loop, and is left unable to enforce its policies.

In turn, this means that IT must now rely on developers to:

  • Follow IT’s security policies

  • Follow IT’s cost-control policies

  • Follow IT’s change-management policies

Unfortunately — and regardless of their best intentions — developers usually fail to meet IT’s requirements, if only because they already have plenty on their plate, and because they aren’t particularly qualified to follow numerous and ever-evolving IT policies.

One solution is for IT and developers to work more efficiently together (that is, to adopt DevOps). and that’s ultimately what the organization should strive for. But regardless of how enthusiastic the organization is about DevOps, IT departments usually need a bit more control and guarantees than “let’s trust that people will do the right thing”.

Read More

Topics: Cloud Platform, Cost, Security, compliance

Cloud APIs Are An Assembly Language For Infrastructure

by Thomas Orozco on Jul 8, 2014 11:59:00 AM

What will your compiler choice be?

Cloud is a transformational technology, because it introduces instantaneous self-service provisioning where there used to be long-winded provisioning processes. Consider this:

  • Prior to cloud, developers had to make a request to IT and wait for days on end to get access to resources.

  • With cloud, developers can simply make an API call (or use a web-based frontend) and instantly get access to what they need, largely increasing their agility and ability to react to customer needs and market changes.

Of course, I’m not trying to say that cloud invented self-service provisioning. Surely, forms of self-service existed before cloud. But the truth is: cloud made self-service so pervasive that it literally changed what we mean when we say “self-service”.

Developers used to have “self-service” access to a shared MySQL database and an Apache VirtualHost or IIS environment if they were lucky. Now, they have self-service access to entire operating systems, complete with scalable multi-node templates including Node.js or Rails application stacks, software and hardware load balancers, and even Hadoop clusters.

But is that enough? Is cloud the nirvana of developer agility? Probably not.

Cloud is a Foundational Technology

Cloud is first and foremost an abstraction over hardware (mainly compute, storage, and networking). In turn, this new abstraction enables new abstractions to be created.

In fact, you can draw a parallel with how programming evolved.  

We started with assembly languages (in our example, they are the equivalent of hardware). Then, we added new languages (e.g. C) and their associated compilers, libraries and runtimes (the equivalent of cloud here). In turn, these low-level languages were used to create new higher-level languages (e.g. Java, JavaScript, Ruby, and many, many others).

High-level languages like Java offer higher-level abstractions that enable programmers to create software more efficiently than if they were using low-level languages such as C. In turn, this increases the business’s agility. Today, these languages are used to create the applications that power Google, Facebook, Twitter, and many others.

So how does that relate to cloud? Just like a number of successful companies built their business using high-level programming languages, successful companies built their cloud architecture using high-level abstractions layered on top of what cloud provided.

Netflix is the quintessential example of success with cloud. The company achieved that success by building higher-level abstractions on top of what existed in their cloud (AWS), such as Asgard and the famous Simian Army.

Read More

Topics: API, Strategy, Multi-Cloud, Opinion, Cloud Platform, AWS, Cloud Management, Amazon, enterprise cloud, Automation

Cloud Security: Putting IT in Control

by Thomas Orozco on Jun 30, 2014 7:30:00 AM

Cloud adoption is driven by enterprise business users looking to increase their agility and the business’s competitiveness. Often, out of frustration with slow or inefficient IT processes, they bypass IT entirely, getting their resources from external providers that haven’t been vetted by IT at all. Welcome to Shadow IT.

Whether or not business users turn to Shadow IT, it’s no wonder that security is consistently ranked as a chief concern that enterprises face when adopting cloud. A defining characteristic of cloud is the transfer of control over data and resources (i.e. self-service access) from IT professionals to business users, who are not as experienced or trained in information security. Yet IT remains responsible for the overall information security of the enterprise.

In order to regain control and remain relevant to the business, IT has to revise its processes to deliver agility and restore security. It must ensure the business has access to the cloud resources it needs to remain competitive in the short term, and yet ensure that these resources are secure so as to not compromise the business’s long term viability.

Read More

Topics: Cloud Management, Security, Tips, enterprise cloud, cloud adoption

Cloud-Native Is to Infrastructure What DevOps Is to Organizations

by Thomas Orozco on May 29, 2014 2:50:00 PM

We’ve often posted about it on this very blog: cloud warrants new “cloud-native” architectures, which are fully automated, and where every single resource is considered disposable because it is so easily replaceable.

What we haven’t posted about (until now!) is why cloud native is a good design paradigm in the first place. But before we get to that, let’s look at how exactly cloud native architectures are different from traditional infrastructure.

Lifecycle Management, from Infrastructure to Application

The defining characteristic of cloud native architectures is thorough lifecycle management automation. Thanks to that automation, cloud native applications are able to autonomously handle scaling needs, and withstand failures.

In more detail:

  • Cloud-native applications are scaled by dynamically adding and configuring hosts when needed, instead of relying on more powerful or resized hosts. In other words, cloud-native applications autoscale horizontally, instead of vertically. Therefore, cloud native applications can scale regardless of whether the underlying infrastructure can.

  • Cloud-native applications handle failures by automatically provisioning replacement nodes, instead of relying on hardware-level or hypervisor-level high-availability. Therefore, cloud native applications are highly-available regardless of whether the underlying infrastructure is.

To summarize: cloud-native applications largely provide for their own lifecycle management, and do not rely on the underlying infrastructure to provide it.

Read More

Topics: Opinion, Cloud Native, DevOps, Autoscaling, enterprise cloud, Lifecycle Management, Automation

Welcome to the Scalr blog!

We build a Cloud Management tool that helps businesses efficiently design and manage infrastructure across multiple clouds.

Here, we post about our experience working with the Cloud, and building Scalr. On average, we do that twice a week.

Sometimes, we'll also cover Cloud-related news.

Subscribe to Email Updates