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.
Why You Can't Afford Not To Have a Multi-Cloud Strategy (Tip: It's not About Availability)
In 2014, Multi-Cloud is an integral part of any corporate cloud strategy. The argument we hear most often is that multi-cloud lets your company seamlessly transition from one provider to another provider in case the former goes down.
This is, of course, a huge asset to your business! There is, however, a significant flaw in that reasoning.
Remember Netflix, the company that pioneered cloud-native infrastructure? When did you first hear about them? Maybe in 2012, when they released their famous Asgard tool. Well, at that point, they had been using AWS for two years already.
Nonetheless, it wasn’t until December 2013 that they finally announced that they were capable of doing hot cross-region failovers — the kind where you switch clouds in real-time for disaster recovery. That is three years after they started using AWS — and they’re doing it between AWS regions, not even between different clouds.
There are two important learnings here. First: three years is a long time to see return on your investment. Second: you don’t actually need multi-cloud to do hot failovers (note: us-east and us-west have never gone down simultaneously).
Ultimately, availability just isn’t the most significant driver for multi-cloud. Don’t worry, though! Multi-cloud is still a good idea, but here’s why:
Workload Placement Optimization
Hot failovers are all the hype, but what happens when your infrastructure is running smoothly? Having access to multiple cloud providers lets your engineers pick the one that is the most appropriate for the workload they want to run.
There are of course multiple considerations in that decision. Latency to non-cloud systems is one, pricing is another, then there’s compliance, and even performance! Ultimately, having access to multiple cloud providers will get you more bang for your buck. And that’s a good thing.
Digging into the detail of which cloud is the best for which workload is somewhat out of scope for this blog post, but — you’re in luck! — we covered that a short while back in a blog post about the economics of private and public cloud. Enjoy!
Vendor Leverage and Supplier Risk Management
What happens when your cloud provider changes their pricing? What if they close down shop? This is the kind of “failover” that a multi-cloud strategy addresses effectively.
If you designed your applications to be multi-cloud from the get-go, then transitioning everything to a different cloud provider will be a relatively simple undertaking. The complexity of quietly moving your applications across clouds over a couple of months has nothing to do with the complexity of doing a real-time hot failover when your service is down — so it certainly won’t take three years to get there!
Better yet, if your provider is being unreasonable with pricing, you may not even need to do it. Having the ability to failover will give you leverage in your negotiations.
So, at this point, you’re probably thinking “Well, this isn’t groundbreaking. I’ve been doing supplier risk management for years.”
Excellent! That is the point! Multi-cloud is just that: supplier relationship management. It’s just not the panacea to your infrastructure availability problems (though it may help you get there).
One question many of you ask the team here at Scalr: “Why don’t you provide built-in configuration management? Why do I have to learn Chef if I want configuration management with Scalr?”
Excellent question! Our objective with Scalr is to deliver businesses with the one-stop-shop for all cloud resources that their engineers need — thus, it might come as a surprise that configuration management is not something we’ve included.
Instead, we've chosen to integrate with Chef, and we're actively considering Puppet integration. Here’s why!
Not Invented Here
This is probably something that will resonate with most of the engineers among us!
Integrating with Chef lets us leverage the impressive amount of effort that has gone into building that configuration management tool and the ecosystem of cookbooks that now exists around it.
Furthermore, it lets us focus on our objective and core competency: building the best cloud management platform.
Ultimately, this benefits you, our users, as you get best in class configuration management and best in class cloud management.
Learning Curve
When an enterprise adopts Scalr as cloud management platform, they often have a lot of engineers to onboard.
Integrating with tools that those engineers may already be familiar with lets us make Scalr easier to adopt, as they only need to learn the new cloud management bits.
Additionally, Chef is a prevalent configuration management tool. Cooking with Chef is a valuable skill an engineer can use in other areas as well as throughout their career. Job security!
Curious to see what Chef integration looks like in Scalr? Start here!
Ever wondered what successful cloud adoption looks like? You’re in luck! We are proud to present our latest customer case study, created in collaboration with the fantastic team at Think Through Math.
Think Through Math had been using Heroku for a while, but as performance started dwindling, they had to look for a replacement. After an evaluation period, they settled on Amazon EC2, but were concerned that EC2 complexity would constrain developer productivity.
They selected Scalr to improve developer agility. The icing on the cake? It took only a couple months for Think Through Math to start reaping the rewards of their investment!
Curious to know how Scalr could benefit your business? Get the case study on our website.
Quick tip: Secure access to AWS infrastructure with IAM Roles
If we had to name just one thing we love about Amazon’s Cloud (Amazon Web Services — AWS), it would certainly be the seemingly infinite list of on-demand services that are available.
Indeed, AWS is not just EC2. There’s also S3 and Glacier, DynamoDB, ElastiCache, RDS, RedShift, etc. The list is just too long, but I’m sure you get the point: there’s a lot of choice.
The problem that arises from having a plethora of services is access control: for your applications to be able to use those services, they need access credentials. This is where things tend to get a bit hairy!
There are really two orthogonal problems to solve here:
Credential Distribution: you need to easily distribute and rotate credentials across your instances and applications.
Credential Scoping: you need to grant access only to the services an application requires, and not to your entire infrastructure.
Of course, the good folks at AWS have thought of that!
IAM users and IAM Permissions
AWS introduced IAM — Identify and Access Management — back in 2011. IAM lets you create additional users on your account.
Those users get their their own credentials — “Access Keys”, in AWS parlance. The good news is those users can also have restricted permissions — so you can make sure you don’t create root keys to your infrastructure!
For your applications, this allows you to create machine users which will only be able to access the services they need, e.g. a specific S3 bucket.
Unfortunately, this doesn’t fully address all access management issues. IAM users and permissions solves the credential scoping problem, but doesn’t really address the credential distribution problem. You still need to manually distribute and rotate keys across your applications.
IAM Roles to the rescue!
Fortunately, credential distribution is also something the AWS team covered! They did this with IAM Roles.
IAM Roles behave similarly to users in the sense that they can be assigned restricted permissions. However, they differ in the sense that they don’t have Access Keys associated with them.
Instead, EC2 instances can “assume” an IAM Role. Here’s how it works:
You first create an IAM Role, and assign it a specific set of permissions
When you launch an instance in EC2, you specify that the instance should assume this IAM Role.
Once the instance is up, it can retrieve temporary credentials to access AWS services with the permissions for the IAM Role (here’s how you do that).
Note: IAM Roles actually do a lot more than help distribute credentials and they apply to much more than EC2 instances. However, we won’t cover those other aspects here.
Using Scalr? Start taking advantage of IAM Roles now!
If you’re using Scalr, you’ll be thrilled to hear that we’ve just added support for IAM Roles. For maximum flexibility, Scalr uses IAM Instance Profiles, which are essentially containers for IAM Roles.
There are two ways you can now use IAM Roles in Scalr:
In the Farm Designer: you can specify an IAM Role for a Farm Role. Instances of that Farm Role will assume the IAM Role you specified when they are launched. For example, your developers could use this to grant DynamoDB access to their application servers, or S3 access to their Hadoop farms!
In the Governance Panel: you can restrict the IAM Roles that are made available to your users. If you are using a single AWS account or multiple purposes, this lets you ensure developers don’t have access to AWS API they shouldn’t.
I’m proud to announce that Open Source Scalr 4.5 was released earlier this week by the engineering team here at Scalr!
When we released Open Source Scalr 4.4 last quarter, we took a moment to look back at how far Scalr had come since its humble beginnings 6 years ago. This time, I’d like us to instead look forward to where Scalr is headed.
The Road Ahead: The Enterprise
Scalr adoption in the Enterprise is expanding at an outstanding pace. Companies such as Expedia and Samsung are successfully using it in production, and providing extremely useful feedback regarding their use cases and expectations for a CMP.
Therefore, you shouldn’t be surprised to learn that Scalr has added new features that are highly appealing to Enterprise IT! Notable features include:
Lease Management: Never worry about terminating unused cloud resources ever again. Let Scalr handle it. Use Lease Management to reduce waste and save money.
Governance: Transparently enforce IT policies and restrict the network topologies and cloud resources that are available to your Scalr end-users.
Role Based Access Control, LDAP authentication: Restrict access to Scalr features on a per-user basis and integrate with existing identity management systems.
Windows support: Scalarizr support for Windows is now on par with Linux. It even supports Orchestration!
For this release, we’ve also added support for two enterprise OpenStack-based cloud platforms: Nebula and CloudScaling OCS.
That’s Not All!
The Scalr engineers have been extremely busy, and we have many other features to announce! The headlines are as follows.
New and Improved Built-In Role Automations
Scalr now has built-in role automation for HAProxy. The Nginx automation was rewritten to give users more control over which Farm Roles should be used as upstreams.
Extended Orchestration
Orchestration was extended to support Local Scripts, as well as Chef Runlists as Orchestration Actions.
We’re consolidating a lot of automation around Orchestration, so we’ve also deprecated Deployments, as this feature can be trivially replaced using Orchestration.
More Control Over Security Groups
Scalr no longer automatically creates Security Groups for instances that it launches — except for the one group that lets Scalarizr communicate with your Scalr hosts.
Instead, Security Groups can now be configured from within the Farm Designer (provided you have the permissions!), giving you more control over those.
UI Redesign
The icing on the cake: Scalr now features flat design and retina-ready visuals!
We hope you’ll enjoy using this new release as much as we enjoyed building it!
Now, it’s time to head to the Scalr Wiki for installation instructions or to get the installer. Instructions for upgrading your existing Scalr deployment and exhaustive release notes can be found there too.
One of the promises of Cloud was usage-based billing that would lead to improved utilization and reduced cost. Unfortunately, cost is also one of the great disillusions of Cloud, which has made it infamously difficult to prevent waste.
Why? Because it's very easy for a developer to power up Cloud infrastructure for a quick experiment and forget about it — leaving it running and inflating the business's Cloud bill for very long — but it's very difficult to track down unused pieces of infrastructure and shut them dow.
Our partners at Cloudyn have even built a product that will track those down for you: the "EC2 Optimizer". Today, we're tackling the problem from the bottom up and introducing Scalr Lease Management — a feature that was designed in close cooperation with one of Scalr's Enterprise customers.
What is Lease Management?
Instead of having to track down unused instances, what if you had a policy to shut everything down after 30 days of activity and tracked down what should be spared instead?
That may sound unrealistic but it really isn't — as long as it's automated. That's precisely what Scalr Lease Management does. Here's what happens if you enable it:
Whenever someone launches a new Farm, the Farm will be granted a (configurable) 30-day lease period. When the lease nears its end, Scalr will offer the owner the option to request a Lease Extension. If they don't, Scalr will shut the Farm down.
Of course, lease extensions are the cornerstone of this new system, so let's dig into what we're offering there. Lease Extensions fall in two categories: Standard and Nonstandard.
Standard Extensions, Nonstandard Extensions
Standard extensions are a solution designed to ease the burden of Lease Management on IT and ensure that they don't need to review every single lease extension request. To that end, standard lease extensions do not require administrator approval and take effect immediately. However, their duration isn't configurable by the end user.
To prevent abuse, the administrator can limit the maximum number of standard lease extensions that can be requested for a Farm. Naturally, the duration of the extension itself is also up to the administrator to define.
Now, we're well aware that there will be cases where you actually want a service to run for the foreseeable future, or for a fixed duration that doesn't correspond to the standard extension period.
For those cases, Scalr also has the option to request a "Nonstandard extension.” Those will need to be reviewed and accepted by an administrator before they take effect, but the user is basically free to request whatever they want.
Of course, the administrator can also refuse the extension. In this case, the user will have to go back and request something more considerate!
Note that you'll find extra documentation about Lease Management on the Scalr Wiki.
What's Next?
We sincerely feel that reducing cost is a promise Cloud has failed to deliver on. It's even reasonable to say that, for large deployments, Cloud has actually made things worse in terms of cost management. At Scalr, we hope to right this wrong.
As such, we'll continue developing features around Lease Management, Showback and Chargeback. You should expect new developments in those areas over the coming six months, as we collaborate with Scalr Enterprise customers to define and deliver those.
Why Do Developers Care About Cloud API Compatibility?
EC2 API compatibility has been an ongoing debate in the OpenStack community for quite a while now, and we’ve seen well-formed arguments on both sides of the community (here and here).
I’m a bit confused as to why respected members of the OpenStack community would disagree on what I don’t even consider to be a problem, as the OpenStack APIs didn’t feel foreign at all when I used them myself! (see this talk from the OpenStack summit)
Since you’re reading this post, I’m hoping you agree! But I digress.
I decided to consult with the developers here at Scalr. After all, they have a fair bit of experience integrating different and API-incompatible clouds: the Scalr Cloud Management Platform works with numerous Public Clouds (Amazon EC2, Google Compute Engine and more) and Private Clouds (OpenStack, CloudStack, Eucalyptus).
So, in a quest for a better understanding, I asked three Scalr developers for their opinion:
Igor Savchenko, CTO at Scalr.
Vitaliy Demidov, who owns the “Scalr Core” project, which is the backend for the Scalr UI.
Marat Komarov, who’s responsible for the “Scalarizr” project, which is the guest agent for Scalr that lives on Scalr-managed instances.
Syntactic Compatibility and Semantic Compatibility
Igor pointed out that there really are two levels of API compatibility.
The first and most obvious level is API syntax. This refers to the actual API calls being available at the same location with the same parameters. If two APIs are syntactically compatible, you can use a client that was designed for one with the other one. For example, the EC2 and Eucalyptus APIs are syntactically compatible, whereas the EC2 and GCE APIs are not.
The more subtle level is API semantics. Two semantically compatible APIs allow you to manipulate equivalent objects and relationships, at a commensurate level of abstraction. For example, the EC2 and OpenStack APIs are (mostly) semantically compatible, but the EC2 and CloudFormation APIs aren’t.
Of course, API compatibility isn’t an all-or-nothing affair. For example, despite OpenStack being mostly semantically compatible with EC2 as it manipulates instances, volumes and the likes, it’s not fully compatible. For example, the NetApp Cinder backend will allow for a volume to be simultaneously mounted on multiple instances, which isn’t possible with EBS.
Semantic Compatibility is What Matters
Next, I went to Vitaliy and Marat and asked whether API compatibility mattered to them when building multi-cloud software — and if it did, whether it was syntactic compatibility, semantic compatibility, or both.
They indicated that syntactic compatibility doesn’t matter much. Marat pointed out that you could “just create or use a wrapper” to work around its absence. However, he indicated that this is only possible if the two APIs are semantically compatible.
Why? Because semantic compatibility is what lets you reuse the experience you’ve accumulated and the workflows you’ve created. Also, because semantic compatibility is what lets you design high-level abstractions in your code so that the logic (the workflows) can remain the same although the implementations (the API client) vary.
Among others, this is leveraged by the Scalr and Apache Libcloud codebases.
Should semantic API compatibility be an objective?
Marat and Vitaliy concurred that OpenStack needs semantic compatibility with EC2 to be relevant. Naturally, the same goes for CloudStack! Eucalyptus is a bit of an outlier here, as it strives for both syntactic and semantic API compatibility with EC2 and other relevant AWS services.
They supported their point by referencing VMware vCloud. They indicated that maintaining compatibility with vCloud is much more difficult because its API is foreign to other services, and does not have semantic API compatibility with those.
Turns out, API semantics may also be the reason why developers consider vCloud and EC2 (and others) as entirely different beasts, and sometimes get frustrated with the former.
Compute Engine Load Balancing serves 1 million requests per second, here’s why you should care
A couple days ago, Anthony of the Google Cloud Platform team announced a benchmark that showed Google Cloud Load Balancing routing 1 million requests per second.
That’s no small feat, but Google was nonetheless called out — at least on Hacker News — for a “Marketing blog post”! Why is that, you ask? Because Google wasn’t doing anything in the backend, and serving constant 1 byte (plus headers) HTTP responses from their upstream servers.
Thing is, this benchmark isn’t about backend performance. It’s about load balancer performance, and it shows two interesting results.
Compute Engine Load Balancing scales very, very fast
On Twitter, @cloudpundit pointed out that unlike Amazon's ELB, Google's Load Balancer doesn't need pre-warming to deliver stellar performance:
Relevance of GCE LB load test: With AWS ELB, if you expect a big spike load, must contact AWS support to have ELB pre-warmed to handle load.
— Lydia Leong (@cloudpundit) November 25, 2013
Well, there's not much more to say here... Except that you should follow Lydia on Twitter!
If you want a more detailed rundown, you can check out Reuven Cohen's take, published in Forbes.
Now, let's move on to another feature that we think has been overlooked in recent coverage.
Compute Engine Load Balancing uses a single IP
Here's a bit of context from our experience using Google Compute Engine to power the Eurovision Song Contest mobile backend:
We were running the backend for a mobile application
Our frontend servers were Nginx instances
We had one DNS record set up to point to these Nginx frontend servers
Now, a problem we had was that our users were on mobile devices, so most of them shared DNS resolvers (their ISPs'). Naturally, we didn’t control those resolvers or their caching policy.
Consequently, when we needed to scale up our frontend, the end users didn't immediately connect to new instances. Ultimately, we saw largely uneven load on our frontend instances.
Compute Engine Load Balancing uses a single IP, and this benchmark demonstrates that this IP can route at least one million requests per second (that’s a lot!).
This seemingly minor feature means that, using Compute Engine Load Balancing, you are in full control of scaling your frontend. All your end users will ever see is a single IP.
Compute Engine LB is a tool, not the solution
Compute Engine Load Balancing isn't the "solution to scaling", and we will still need to carefully architect our applications so that they scale horizontally.
Nonetheless, those benchmarks show that Google has delivered a tool we certainly needed to "solve scaling” — at the very least for the frontend!
And it’s available to just about anyone.
So, hats off to the Google Compute Engine LB team!
AWS re:Invent is starting next week, and the Scalr Team will be traveling back from the Hong Kong OpenStack Summit to attend!
AWS is the premier public cloud service provider out there, so it only makes sense that Scalr would be attending its yearly developer conference.
We'd love you to drop by our booth, spend some time chatting about all things cloud with the Scalr Team, and maybe have our latest integrations with AWS showcased to you — including Governance and VPC!
We'll be waiting for you at booth 208 — see you in Vegas!
We’re going to the OpenStack Summit! Will you be there?
The OpenStack Summit is coming to Asia, and so are we!
OpenStack is arguably the most ambitious cloud platform out there — we covered why we think so here — and we're excited to see it living up to expectations: every six months, the OpenStack summit draws greater attendance!
This time, we'll not only be attending, but also sponsoring the summit.
Meet us there!
Feel free to drop by booth C40. We'll be there all summit long to chat with you about cloud management and — who knows? — get you a fancy Scalr T-shirt!
And if you'd like something a bit more formal, you can fill in this small form and we'll set something up.
We'll also be hosting the following sessions:
Tuesday 2:20pm: "Attention IT Departments: Want to know why your developers don't use your Private Cloud?". We'll talk about IT can drive cloud adoption.
Thursday, 1:50pm: "Best practices for delivering DevOps on OpenStack" (panel). Scalr CEO Sebastian Stadil will participate in a panel debating the involvement on DevOps with cloud
Friday, 4:10pm: "Making your apps cloud-aware". We'll demonstrate how you can design applications that integrate with their cloud hosting environment. We'll take the example of our cloudbench disk benchmarking suite.
And... Every day around 4PM, your favorite cloud management platform will host a friendly competion (with prizes!). We'll update you with additional details soon!
The summit is scheduled for November 5 through 8. We hope to see you there!
Is Private Cloud the most cost effective? The questions you should ask.
In an earlier blog post, we compared the competing Open Source Private Cloud Platforms: OpenStack, CloudStack, and Eucalyptus. What we didn't cover was why you'd want to use a Private Cloud in the first place! Let's answer this here.
Before we start, it's important to point out that there are two groups of workloads with regard to Cloud.
The first group is that of workloads that cannot run on a Public Cloud. Good examples are low-latency applications and applications dealing with highly-regulated data. For those, Private Cloud is a great — if not the only! — option to increase agility.
Then, there's the group of workloads that can run on a Public Cloud. For those, an argument that comes up often is cost, Private Cloud being largely regarded as more cost effective than Public Cloud.
But is Private Cloud always the most cost effective? It turns out that the answer largely depends on the type of workload. Let's find out which workloads belong on which Cloud, and identify the questions you should ask when comparing the cost of Public and Private Cloud.
It's not (really) about scale, it's about elasticity
It's a given that there exist businesses that are extremely cost effective with massive Public Cloud deployments. We're of course talking about Netflix, but also about Illumina and others.
But does the fact that Netflix makes Public Cloud cost-effective mean you will? Especially since their product involves an extremely elastic workload which, cost-wise, puts Private Cloud at serious a disadvantage?
Actually, it does, but only to a certain extent.
Indeed, you should bear in mind that your business most likely operates some elastic workloads too, and that Public Cloud will (almost) always be more cost-effective for those, regardless of their scale.
The obvious example is that of Dev, Test, and Demo environments. It's not the only one, though: another common use case is that of batch reporting: among others, financial reports that run quarterly will feel right at home on a Public Cloud.
Your private Cloud will most likely be Hybrid
Consequently, even if you decide to invest in a Private Cloud, you'll probably retain a footprint in the Public Cloud for those elastic workloads where it's generally the most cost effective. As such, your Private Cloud deployment will, in fact, constitute a Hybrid Cloud deployment.
Now, contrary to Netflix, those elastic workloads probably don't constitute the entirety of your Cloud usage. That is, it's very likely that you are also using the Cloud for workloads where you weren't looking for elasticity, but for agility, and reduced time to market.
Those non-elastic workloads are the ones for which you'll definitely want to do the math to figure out whether you'll be able to achieve savings if you move them to a Private Cloud.
Running the Hybrid Cloud numbers: the questions you should ask
Finding out whether Private Cloud will be cost effective is of course an exercise in careful cost planning.
Naturally, you'll need to account for the "obvious" costs. They're very self explanatory, so let's just list them. We're talking about racks, networking, servers, power, cooling, staffing, support, and an optional implementation partner (e.g. Redapt).
Now, let's focus on the category of more subtle costs. Here, we're talking about the numerous features that you can take for granted on a Public Cloud, but that you must manage yourself on a Private cloud (the list is below).
The good news is, you may not need everything that Public Cloud has to offer — so that's an area where you could secure cost savings down the road! Consequently, your first step will be to decide on the features you need, the second one will be to decide on how you'll implement them, and the third one to estimate how much they will cost.
Here's the list, and the questions you should ask to properly plan. We focused on AWS, which is still the most complete Public Cloud offering today.
Headroom to grow: AWS has unlimited capacity. What are your growth expectations, and how confident are you that you’ll meet them?
Availability & Failover: AWS has multiple DCs in each region. How much redundancy do you need?
Global Distribution: AWS is everywhere. Where are your end users located?
Security: AWS has high security standards. What security certifications do you need?
Supplemental Cloud Services: AWS has quality, highly-available, Cloud services such as RDS, or RedShift. Which ones are you using?
In the end, transitioning to a Hybrid Cloud can definitely be cost effective, but will require that you identify the workloads that can benefit from it, understand their requirements, and locate the cost centers where you can achieve significant savings.
Choosing the right Private Cloud Platform for your Enterprise
So you're building a Private Cloud, and looking for the right platform? After some research, you probably found out that the three main contenders are OpenStack, CloudStack, and Eucalyptus.
Now, the question is: how do you choose? Of course, there is no single answer. But from our experience working with Enterprise IT deploying Private Clouds, there are definitely a few things you should bear in mind when making your decision.
So here we go: what are the questions you need to ask to decide on your Private Cloud Platform? In the end, we'll see that your choice should be dictated by the level of involvement you want with your Private Cloud, and the level of risk you're ready to accept.
#1: Do you want a project or a product?
OpenStack differentiates from CloudStack and Eucalyptus in the sense that it's not really a self-contained piece of software, or product. Instead, OpenStack is a project.
Need proof? Navigate to OpenStack's Github account, and look for an "OpenStack" repo. It's not there. Why? Because OpenStack is not code. Instead, OpenStack is an umbrella organization, a constellation of subprojects projects small and large that let you build your own Cloud Platform.
As such, OpenStack gives you a lot more control over the components you choose and how you configure them: as one of Scalr’s customers — an OpenStack user — put it: “got a problem with OpenStack? There’s a subproject for it!”
OpenStack's Flexibility has a price
Unfortunately, this flexibility means that it's a lot more work to get OpenStack up and running, and as such, OpenStack is the riskier option for your Cloud.
As a matter of fact, our experience with Enterprises deploying OpenStack has shown that the rate of first-time success with OpenStack is quite low when compared to the alternatives.
So before you decide on your platform, you need to ask: will you commit resources to take advantage of OpenStack's unparalleled flexibility, and truly benefit from your choice of platform? Or would you rather install your Cloud Platform and move on to something else?
Update: What about OpenStack distributions?
Reuven Cohen pointed out on twitter that this article initially didn't mention the fact that there are numerous "productized" OpenStack distributions out there, which are supported by integrators.
A distribution is of course easier to install and maintain, and you can get commercial support for it. As such, using a distribution constitutes a less risky option, technology-wise.
However, bear in mind that there is a large — and growing! — number of competing OpenStack distributions, so you'll have to choose an integrator that you trust will keep their distribution up to date. Ultimately, opting for a distribution is a tradeoff between technology risk and supplier risk.
So — haven’t made up your mind yet? Let’s move on to our next differentiator.
#2: AWS Compatibility
AWS is the elephant in the Cloud room: although we're talking about Private Clouds here, we all know your engineers are going to want to use AWS too.
Compatibility with AWS happens to be the other big differentiator between our Cloud Platforms.
OpenStack is the odd one out on AWS compatibility
On the one hand, Eucalyptus has support for most of the AWS APIs (including EC2, S3, EBS, IAM, AutoScaling, CloudWatch, and ELB!); it is, as they say, "like having your own AZ". And although CloudStack isn't anywhere near Eucalyptus in that regard, it does reasonably well with a compatibility mode for the AWS APIs.
On the other hand, OpenStack doesn't have any level of AWS compatibility. And according to Cloudscaling CTO Randy Bias, OpenStack may even face "irrelevance and death" if it does not eventually converge to use the AWS APIs, which he considers are the de-facto standard for Cloud (you might want to read this rebuttal from Robert Scoble of Rackspace).
But should you rule out OpenStack on incompatibility? There are really two things at play here.
Does OpenStack need AWS compatibility to survive?
Of course, you certainly don't want to bet on a dying horse. But does OpenStack need AWS compatibility to survive?
It's still early to tell; but with the largest contributor and user base of all three Cloud Platforms, and impressive corporate support, OpenStack definitely has muscle of its own.
In the end, the key deciding factor here should be your own needs.
Do you need AWS compatibility?
There are three reasons why you might.
The first one is the ability to cloudburst, that is, to run your baseline infrastructure on a Private Cloud, and expand to a Public Cloud to face traffic spikes. Well, bear in mind that although cloudbursting is very attractive, it's oftentimes impractical, if only for network reasons.
The second one is the ability to develop your applications on one platform and deploy them on another. This lets you minimize your time to market, and get better control over your infrastructure costs. This may be a reasonable reason to rule out OpenStack, but definitely make sure that you would actually be doing it if you had the ability.
The third and last one is the ability to reuse the AWS tooling that you built — or purchased — with your private cloud. Of course, before you make a decision based on this criteria, bear in mind that there is also tooling to abstract incompatibilities away — that's the goal of the Apache Deltacloud project —, and that a lot of tooling is cloud-agnostic, that's of course the case with Scalr.
#3 Do you want to make running a Cloud a core competency?
OpenStack is obviously the most polarizing option out there. It's very configurable, but it's hard to get right. It has the most momentum, but it's not compatible with the Public Cloud your developers want to use.
Ultimately, the best question to ask is this one: how involved do you want to be with your Cloud? Are you going to dedicate engineers to take advantage of OpenStack's flexibility? Are you going to dedicate resources to acquire the tooling you'll need to make your software multi-cloud in spite of API incompatibilities?
In other words, do you see Cloud as a strategic, core, competency that you want to develop to gain a competitive advantage? If yes, and if you're ready to accept the inherent risk, then OpenStack may very well be your best option. If not, then you should probably be looking at CloudStack and Eucalyptus instead.
What you should most definitely know before you yank PaaS for IaaS
A couple of months ago, we covered where the difference between PaaS and IaaS lies in practice.
The goal of that article was to help you choose between PaaS and IaaS. Here, I'd like to spend some time about what I think you should know if you decide to move your app off of PaaS, and onto IaaS.
So, why would you not use PaaS? What should you be on the lookout for? What is autoscaling like on IaaS? What are the tools you can leverage? Let's find out!
Why would you use IaaS in the first place?
Because you'll need something to run your private PaaS (e.g. OpenShift) on!
Jokes aside, PaaS really is a one-size-fits-all solution. That's perfect for support applications, but not so much for core, revenue-generating, apps. For those, you'll eventually want to squeeze out the last drop of performance, and you'll want full control over your stack (see that earlier blog post we talked about). This is of course where IaaS comes in.
That's exactly what happened to one of our customers - grandcentrix. As they secured a deal to provide the backend for the Eurovision contest - Europe's largest TV event -, they chose to migrate to Google Compute Engine.
We've got to know them as they turned to Cloud Management (and Scalr specifically) to retain the "focus-on-getting-your-job-done magic" that PaaS offers.
Now, let's dive in, and look at what we learned as we worked with them on their project.
You can't (always) scale IaaS by throwing more money at it
The worse that could happen on PaaS is traffic outdoing your credit card (or allowance, if the PaaS is yours). Your users would experience some latency, but that's something you can promptly fix.
On the other hand, using IaaS, your app may very well serve multiple hundred requests per second per node, but your backend could spectacularly crash as you try to scale up a measly 2x.
Here's an amusing example from our experience working with the grandcentrix folks (fortunately, this didn't happen in production).
Their setup was as follows: Nginx was proxying requests to a PHP app powered by multiple Apache servers. The Apache servers connected to a few Redis instances in the backend.
As the Redis backend reached full capacity, the app servers started timing out on requests. It turns out that, by default, Nginx retries the requests that time out. So, just as the backend was saturating, Nginx replayed every single request on every single app server. Of course, the app servers would then in turn connect to the Redis backend, bringing it down for good. So long, Redis!
If you want autoscaling on IaaS, you'll have to work for it
What this silly story tells us is that you can't always expect performance to be linear on IaaS (which you can on PaaS: this is actually the core capability of PaaS).
In fact, as opposed to PaaS, where you can autoscale by "throwing more dynos at it", autoscaling on IaaS requires that you do your homework first. You'll have to understand what your bottlenecks are, figure out which ones can be addressed by autoscaling, and fix the others yourself.
As such, we can categorize bottlenecks in two families.
There's the first family of mere scale issues that you can solve by adding more nodes, like insufficient CPU capacity. Those are really OK: you can autoscale them out of existence.
Then, there's the second family, that of architectural issues and misconfigurations. Those are what break your linear scalability, and consequently, your autoscaling policy. You'll have to fix those before you can autoscale (note that this actually is your PaaS provider's business).
Here's how you find them.
Performance is an experimental science, so you should experiment
To find bottlenecks from that second, nasty, family, you'll have to run load tests. All throughout, you should be on the lookout for situations where performance doesn't scale linearly: this is a sign that you're hitting one of those bottlenecks.
The following methodology works well:
Start small: a few requests per second per server. Observe your performance (response times and errors rates are good indicators).
Grow your test traffic until performance starts sliding, stop there (you should be hitting a "first family" bottleneck).
Grow your infrastructure 2x. Grow your test traffic 2x.
Run your load test again. If your performance isn't as good as in step #1, you hit a "second family" bottleneck.
Fix the bottleneck, and repeat steps #3 through #5 (note that to fix OS bottlenecks, this article is a very good start).
You're not on your own: there are tools to help you
Specifically for Eurovision, the tool we used for load testing was Locust. Locust makes it trivially easy to prepare a scenario for your load test, and supports distributed load testing with little-to-none extra configuration, which makes it a compelling choice for Cloud infrastructure. But if you're not the DIY type of person, SOASTA's CloudTest suite may be just what you're loooking for.
Regarding performance measurement, your load testing tool will usually give you some metrics (response times and error rates). But to get better insight, you could also integrate application monitoring tools, such as New Relic.
Of course, standing up and down your test cluster can get challenging at a large scale. When this becomes a problem for you, you'll want to look at Cloud Management and its integration with tools like Chef to automate the process of adding, configuring, and orchestrating nodes.
Today, Citrix is announcing the availability of CloudPlatform 4.2, its commercial distribution of the Apache CloudStack ("ACS") project it donated to the Apache Foundation in 2012.
Are we excited? Yes. Should you? Definitely. Why? Because CloudPlatform / ACS works, and it's only going to get better.
The quiet kid on the block
It is definitely a challenge to write a blog post about CloudPlatform / ACS without so much as mentioning its rowdy competitor, OpenStack. OpenStack's bigger, that's a given. But does that mean it's better? Not necessarily.
While OpenStack is driven by manifold and sometimes conflicting interests, CloudStack has fewer contributors, but they contribute more. And while OpenStack has innumerable configuration options, CloudStack is an opionionated platform that varies very little from deployment to deployment.
To a certain extent, CloudPlatform / ACS is not only a project: it's also a product. To us, at Scalr, this means that it is much easier to support, and yields better reliability.
Production Grade ®
As a matter of fact, we've seen a larger number of first time success for CloudPlatform users, and CloudPlatform has been successfully and reliably used by one of our larger customers, Samsung Electronics (we even have a case study about that).
Naturally, initial successes don't tell the entire story, but CloudPlatform doesn't disappoint in the longer run. The platform settled on a solid upgrade path very early in its development, which has made it possible for our customers to enjoy enduring success with it.
Getting the Enterprise onto the Cloud
It's great to see that the development pace of CloudStack is keeping up with this new release. With over 1900 bug fixes, the CloudStack team has certainly been busy. But it's not just bug fixes: 4.2 is also loaded with exciting new features.
Extended VMware support, which includes dynamic rescaling of VMs and VMware DVS, is sure to please our Enterprise customers. The same goes for the support CloudStack is adding for advanced network appliances, including Cisco, Juniper, F5 and Citrix hardware.
Regarding Cloud-Native workloads, we can expect the tighter integration of CloudStack 4.2 with S3-like object stores to facilitate the onboarding of existing Cloud projects that are moved from the Public Cloud back to a Private Cloud for security or cost reasons.
Here's to yet another great release for Citrix CloudPlatform and Apache CloudStack - the second one as an Apache Foundation top-level project!
The Five Signs That Tell You Need Cloud Management
In an earlier blog post, we showed that Cloud Management really is about abstracting away the gap between your requirements - as a user or as a business - and the APIs the Cloud has to offer.
But how do you tell there's a gap? What are the signs that your business might need Cloud Management?
They fall in two categories: Rogue IT and Cloud Disillusion.
Rogue IT is the process by which developers bypass IT to get their resources directly from the Cloud Providers. Cloud Disillusion is what happens when you realize your high hopes of increased productivity and better cost effectiveness aren't materializing.
So, what are the symptoms? What can you do about it? Read on!
You're faced with Rogue IT
#1: Your Cloud bill is skyrocketting, but revenue isn't
Cloud Computing makes it infamously difficult to keep track of who owns a particular piece of infrastructure.
A direct consequence is that your engineers are not incentivized to keep costs and waste in check. Instead, they're free to overprovision infrastructure and forget about it; confident that the added expenses will be invisible in the business' aggregate bill.
To rein in those runaway costs, you need to restore accountability for the costs your organizational units generate by charging them back. Cloud Management keeps track of ownership data for your infrastructure, and can help you achieve that objective.
#2: Your InfoSec and legal teams are panicking
As you rushed to the Cloud, you sacrificed meticulous planning for reduced time to market. Now, your business owns hundreds of AWS accounts, and some of them might even be personal accounts that are formally outside your organization's control!
This sorry state of affairs has left you with little control over the security of your infrastructure and a limited ability to properly protect your confidential data. As regulators and consumers push for stronger data protection, regaining control will become a priority for your business and its shareholders.
Your first step should be to consolidate existing infrastructure behind a single pane of glass, and ensure that appropriate security policies are in place and can't be worked around. To this end, you could leverage Cloud Management to implement a much-needed governance layer between your engineers and the Cloud.
#3: Your Engineers are not using your Private Cloud or Public Cloud corporate account
You listened to your engineers, and you're ready to provide them with the keys to a company-owned Public Cloud account, or even a Private Cloud deployment. But in spite of your efforts, they're still bypassing you.
In an effort to control cost (#1) and risk (#2), it's very likely that you implemented complex policies that regulate how developers can access internal Cloud resources. Unfortunately, this could have suppressed the agility that led your engineers to use the Cloud in the first place.
Providing your developers with an internal Cloud is a challenging project where you must balance the need for regulation with that for agility. Cloud Management, acting as a middle layer, can solve this challenge and let you relinquish overarching control, yet retain oversight.
You're experiencing Cloud Disillusion
#4: Productivity hasn't increased, you're considering building tooling
As you transitioned your development efforts to the Cloud, you might have expected a substantial productivity boost that unfortunately didn't materialize.
Cloud comes with its own unique challenges and idiosyncrasies, and those can slow down your development efforts as your engineers focus on solving "Cloud problems" instead of your delivering the solutions your clients expect.
What you actually need is the higher level abstractions that Cloud Management provides your developers with, which let them focus on delivering value to your customers instead of working around the intricacies of their Cloud.
#5: You can't take advantage of the Public vs. Private Cloud cost models
Public Cloud lets you replace CapEx with OpEx, and therefore constitutes a compelling choice for new, risky, projects. However, the Public Cloud is also everything but inexpensive, and Private Cloud can thus prove more cost-effective in the long run. As such, you might want to deploy uncertain ventures to the Public Cloud before bringing them back in house to the Private Cloud if they prove to be successful.
Unfortunately, building software that works on multiple Clouds is much easier said than done: the APIs are still vastly different, and you can't transfer Cloud resources (e.g. Images) from one Cloud Platform to the other.
Cloud Management empowers your engineers to build Cloud-agnostic applications, which can be deployed anywhere, and seamlessly transitioned from one Cloud to another.
And here we are already, at the end of our list - any of those sound familiar? Have your developers embraced Rogue IT? Is your business disillusioned with Cloud?
If that's the case, then maybe it's time you had a look at Cloud Management.
It's time to Regain Control of your Cloud: Introducing Scalr Governance
A few weeks ago, we announced that Scalr was "going Enterprise" - we were just releasing new features that included advanced User Management, VPC support, Naming Conventions, and Customization.
Today we're taking yet another step in that direction, and introducing Scalr Governance.
Why do we need policy enforcement in Scalr?
Large, successful, enterprises require policies to ensure they comply with industry regulations and minimize operations risk. Failure to enforce those may results in lawsuits, fines, and waste of effort and resources.
Unfortunately, policy enforcement today still largely relies on complex processes and reviews, slowing down entire engineering departments.
This can even result in an adverse reaction from engineering, where developers circumvent processes and get their infrastructure directly from Cloud providers, such as Amazon Web Services.
How do we walk this fine line between overreaching control and insufficient control? As Scalr becomes a self-service portal for enterprise IT, it made sense to look here.
Policy enforcement made easy
Our new governance features make it possible for enterprises to enforce IT policies transparently, thus preserving engineering freedom and velocity.
Let's have a closer look at these features we're introducing. Note that they're documented on the Scalr Wiki, here.
Mandatory VPC and restricted regions
Ensuring compliance with data custody and protection regulation just go a lot easier.
You can now enforce VPC usage to isolate your instances, and restrict your developers to specific regions - so your data never leaves its country.
Restricted subsets of allowed instance types
It's now possible to control the instance types your developers can use, so you can finally take advantage of those reserved instances you paid for.
Control over security groups and SSH access
We've also made it possible to transparently enforce the presence of specific SSH public keys on your instances, or require specific security groups.
Ensuring your security team has connectivity and access to your instances at all times has become trivial!
Keep tabs on permissions: a refactored ACL Framework
Scalr shipped access control a few months ago, but we weren't entirely happy with it: some permissions were clunky to use, and the API wasn't covered.
This is all changing now: we're releasing a refactor of our ACL framework that makes it trivial to restrict users to the features they should be accessing. On top of that, this new iteration properly supports the API.
This new framework is all documented here.
This is a whole new direction for Scalr, and we appreciate your feedback and suggestions as we tread this new ground! As always, you can reach us via the Scalr website, or on our uservoice board.
Focus on your Job, not on your Cloud API: Why you might need Cloud Management
Before we even get started about why you might need a Cloud Management Platform, let's talk about what a Cloud Management Platform is.
For starters, it's what we build at Scalr - although we're not the only ones!
Generally speaking, Cloud Management is an extra layer that sits between you and your Cloud Provider(s). It automates common Cloud practices, and gives you a high level overview and control over what's going on in your Cloud(s).
Why would you want yet another layer?
Here's a good question we hear a lot: "Why would I need an extra layer when I already have OpenStack sitting between me and my hardware? (or whatever other Cloud Provider you're using) I can interact with my Cloud Provider's UI and API directly."
For one thing, having an extra layer lets you become less dependent on the underlying Cloud Provider. It becomes easier (if not trivial) to switch between AWS and Rackspace, OpenStack and CloudStack, and so on.
But there's a catch: as you become less dependent on your Cloud Provider, you create a new dependency on your Cloud Management Provider. Arguably, that's good for us, but maybe not for you!
So, here we are, back to square one: why would you want yet an extra layer: Cloud Management?
Cloud Management is about Abstraction, not Automation
I could dwell on how the built-in automation of Cloud Management will increase your productivity and could justify adding this extra layer. But I'm not going to do that for the following reasons:
First, you probably didn't come here to read a feature list, and I'd rather write about something that's of interest to you (if you actually did, look here).
Second, AWS has been around since 2006, so at this point it's likely that you've already invested in and built your own tooling and automation - or used someone else's (e.g. Netflix's).
Third, and most importantly, I think that trying to justify the existence of the Cloud Management layer is fundamentally biased. Cloud Management is not just an extra layer, it's a valuable Abstraction Layer.
What is an Abstraction Layer, exactly?
Glad you asked! An Abstraction Layer is something that lets you deal with higher-level primitives than what is being abstracted. In our case, this something is software, but abstractions are everywhere in your everyday life too!
Here's an example: there's one Abstraction Layer you're already familiar with, it's your Cloud.
Cloud boosts the productivity of your engineers by abstracting away the complexity of provisioning servers and their auxiliary services, and instead presenting users with Instances, Images, Volumes... (we ran a series on this blog about that, here )
In practice, Cloud abstraction means your engineers don't have to call up and wait on IT to get a new server or an entire cluster: they can finally get the infrastructure they need, when they need it.
Cloud + Cloud Management: That's two Abstraction Layers already!
At this point, you're probably thinking "If Cloud and Cloud Management are two Abstraction Layers - why would I need both?!".
That's a good question, and here's why: Cloud APIs aren't exactly designed with humans in mind, but are instead better suited for consumption by machines (we'll see an example soon).
Cloud Management abstracts away this complexity and does the translation for you: when your Cloud talks in terms of Instances, Images, and Volumes; Cloud Management talks in terms of Projects and Services.
What's the benefit, in practice?
Here's an example: launching an Ubuntu instance in EC2 with 2 EBS volumes assembled into a RAID 0 array. Pretty common case for a DB.
Using the AWS APIs, you would do the following:
Locate the latest Ubuntu AMI
Launch the instance using the AMI
Provision the EBS volumes
Wait for the instance to come online
Attach the EBS volumes
Wait for the volumes to attach
Setup RAID 0
You'll agree that, as a human, this isn't exactly how your brain functions. Now, if you used Cloud Management, you'd do:
Launch an Ubuntu Instance with 2 EBS volumes assembled into a RAID 0 array
That's more like it!
Note: how is that not BS, you ask? This is possible because a Cloud Management Platform lets us a design an abstraction that is built around your thought process, not around your Cloud Provider's underlying architecture. We've discussed that in this blog post.
Focus on what you want to be doing, not on how you do it
The value of adding an extra Abstraction Layer should be clear now: it lets you focus your efforts on what you want to be doing, not on how you do it.
In other words, abstraction lets you become more expressive. It lets you write less code and save effort and time, which means:
Less code to write and more code reuse: you become more productive
Less code to maintain: you make less mistakes
Less code to read: you gain better understanding of your systems
But you certainly knew all this already. Or were you writing your web services in x86 assembly?
