Building Cloud Native Infrastructure With Scalr At PeerJ

by Thomas Orozco on Mar 25, 2014 1:18:00 PM

Are you concerned that cloud is a complicated beast, and that getting all the little details (such as autoscaling, high availability, and lifecycle management!) right will take days on end?

The team at PeerJ felt the same when they adopted Amazon Web Services.

Just like you, they were concerned that building tooling to manage their cloud infrastructure would redirect their engineering efforts away from the goal they set out to achieve: building PeerJ, and revolutionizing how scholarly knowledge is published today.

So, instead of building the tooling in-house, the PeerJ team selected Scalr. Was it the right choice? Jason Hoyt, Ph.D., Co-founder and CEO of PeerJ puts it better than we could:

“Thanks to Scalr, we’ve been able to focus on what matters to our business: building PeerJ. Naturally, infrastructure management is critical, but it’s definitely not our core business. Scalr’s Cloud Management software has been a great help in automating that aspect of our operations.

The good news is that the PeerJ team agreed to sit down with us, walk us through their adoption process, and tell us how they cracked those cloud challenges one after the other.

If you’re curious to learn how they succeeded, and would like the same for your business, you should check out the new case study we’re releasing in collaboration with PeerJ.
Read More

Topics: Cloud Platform, AWS, Case Study, Cloud Native

If you're using cloud, Chef may be good enough

by Thomas Orozco on Mar 13, 2014 3:37:00 PM


Earlier this week, Domen Ko┼żar published a blog post titled “Why Puppet/Chef/Ansible aren't good enough (and we can do better)”; it’s an interesting read, and the corresponding Hacker News discussion is equally insightful.

Among other things, Domen makes the point that bash scripts, Chef, and similar configuration management tools are fundamentally designed to alter state, not define state. In other words, they take a transition as input (e.g.: a Chef recipe defines a transition), instead of the desired final state this transition seeks to achieve.

Read More

Why Cloud Native?

by Thomas Orozco on Feb 27, 2014 2:00:00 PM

It is a known fact that cloud adoption has ushered in new best practices for infrastructure design and application management. These best practices are usually described as cloud native, and the most prominent among these are designing for failure and building horizontally scalable services.

Read More

Topics: Strategy, OpenStack, Opinion, Cloud Management, Cloud Native

Tips: Getting Your OpenStack All-In-One POC off the ground

by Thomas Orozco on Feb 12, 2014 12:35:00 PM

A couple weeks ago, I was working on Scalr’s new Chef-based installer. As a good cloud citizen with a slow laptop, I was using AWS EC2 to provision VMs to run my tests. The tests themselves were run through Chef’s “development environment”: test-kitchen.

But I hit one of those issues inherent to Public Cloud: the latency was just too high. For every iteration (those were numerous!), I had to wait for my cookbooks to be uploaded to AWS on my slow DSL connection (I work remotely).

Read More

Topics: OpenStack, Technical, Tips

Why You Can't Afford Not To Have a Multi-Cloud Strategy

by Thomas Orozco on Jan 22, 2014 11:30:00 AM

(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:

Read More

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