Scalarium Blog

Scalarium Beta Update: User Interface Overhaul, Support for all EC2 Regions

Peritor — Thu, 20 May 2010 10:28:17 +0000

This week we finally rolled out some noteworthy changes, and we thought it's a good time to give you a tour of what's new. The most visible change is the overhauled user interface. We simplified workflows, tried to gather more information of interest where possible and useful, and generally cleaned up lots of smaller things. The result is a cleaner interface, making it easier to navigate through and work with Scalarium.

When you log in, the first thing you'll notice is the new dashboard, now showing all the important information in one place, clouds, applications, events and the latest deployments. You can also see how many instances are running in any one cloud without having to go to the details page.

We also reworked the details pages for clouds and applications, moving less frequently used actions into sub menus.

You'll also notice that we sprinkled in some friendly reminders here and there, in case there's something you may have forgotten. After all, getting you application up and running as fast as possible is what the cloud is all about.

When an instance failed during its initial setup, it wasn't easy to figure out what exactly went wrong. Now we immediately bring the error to your attention, including a link to the logs for easier investigation of what caused the problem.

As mentioned in an earlier post, you can now start clouds in any of the available EC2 regions, therefore being able to easily deploy your apps across the globe using Scalarium.

Last week we sent out a big pile of beta invites. If you didn't get yours or haven't signed up for the beta yet, feel free to get in touch or sign up on our beta site.

We'll also be at a couple of conferences in June, namely RailsWayCon, Berlin Buzzwords and IT-Profits in Berlin and MongoUK in London. We'll always have invite codes with us, so come talk to us.

Scalarium Supports All EC2 Regions

Peritor — Fri, 30 Apr 2010 14:08:49 +0000

We just finished putting the finishing touches on a nice update for Scalarium: Support for all EC2 regions, including the new Asia Pacific region in Singapore, which was just opened to the public earlier this week. What that means is that you can create clouds in either the two US regions, Asia or in Europe, allowing you to create instances in their respective availability zones.

So far, Scalarium has focussed on supporting the EU region, simply because that's our home turf, but right from the start it was built to be agnostic to the region a cloud is running on, and we always intended on opening up to all the regions, allowing our customers to use Scalarium to run their applications close to their customers.

The change in Scalarium itself is rather subtle, but here's a peek, also giving you a preview of the UI changes we're currently working on:

We'll be rolling out the changes within a week or two, including the new interface, so stay tuned!

The Scalarium Pricing Model

Peritor — Thu, 08 Apr 2010 14:52:07 +0000

It's been a long time coming, but we finally published the prices for using Scalarium, including our support package. Long story short: You're paying for what you use. Only want to fire up an instance for an hour? Then in the true spirit of the cloud, we'll only charge you for an hour. No minimum usage, no baseline fee. Simple like that, after all, that's what Amazon does too, right? Scalarium usage costs are on top of Amazon's EC2 fees by the way. We're managing your instances, and we're using your keys. The instances are yours to keep. That way it's easy for you to buy Reserved Instances from Amazon, and reduce your cloud costs by a whole lot.

Anyway, what took us so long you ask? It sure isn't easy to find a pricing model that's cloud-ready, as in: pay only for what you use. However, that usually implies that you either have to somehow get the metering data from Amazon or simply meter the instance usage yourself. At first we refrained from doing the latter, as that'd imply quite some work on our part, and there's a tiny margin of error.

Of course it'd be awesome to be able to access Amazon's metering data through an API. In the sense of Amazon's Web Services, it'd only be logical. No such luck, amigo. Plus, we'd have to fetch them regularly, not just once per month, to always be in the loop about the full usage.

We've considered other options before we ended up deciding on the thing that'd be the hardest to work with: Charge per running instance per month, charge per average number of running instances, charge a monthly base fee on top, that'd include a couple of instances already. We were excited about this payment model at first, but there's problems with it.

It's simply not in the spirit of the cloud. Charging a full month for an instance you've only used for two hours? That just didn't feel right. So we dropped it and thought again, and the result was something that we, in the end, came up with independently. It'd be the only way we could fairly charge based on usage, and that'd enable even small companies to give Scalarium a spin without spending big money from the get go.

So that's where we ended up: No monthly baseline charges, you pay for what you use. Simple like that. After all, there's only work to do on our part when you have instances running. It's the fairest way to pay for a Scalarium's cloud management.

We'll probably add paid add-ons in the future that'll still be charged on a monthly basis, and we'll keep improving Scalarium constantly. If you find something's not to your liking, or you're missing a certain feature, please get in touch.

Scalarium has a Support System

Peritor — Wed, 31 Mar 2010 15:04:17 +0000

Over the last couple of days we started collecting material for a knowledge base, but had yet to set up something to collect the texts in. Apart from that we needed a common place to collect input, questions and problems from users, where our support staff could be at the ready to reply. Fret no more, we've got you (and ourselves, for that matter) covered. You can reach our support system at support.scalarium.com. We already added in the most important questions on Scalarium and how parts of it work. Let us know if there's things that you feel should be in there.

Scalarium Frequently Asked Questions

Peritor — Tue, 30 Mar 2010 10:40:08 +0000

We get asked a lot of questions on Scalarium, so we thought we'd compile the most important of them into an FAQ for you to enjoy. If you have more questions, don't hesitate to get in touch!

What cloud infrastructure do you support?

Right now we're supporting Amazon's EC2, simply because it has the best feature set and API out there.

Can I manage my already running EC2 instances?

As Scalarium is not a generic EC2 management solution, the answer is no. We're provisioning the instances with a client that communicates with our service. Since this bootstrapping is done using EC2's user data and happens once on boot, it's next to impossible to provision an instance with our software after it's already been booted through some other means.

Are the instances you're managing on my behalf mine to keep?

We're using your AWS credentials to manage your infrastructure, so we're running them on your behalf. You'll have full root access to your instances. Should you decide to not use Scalarium anymore, we won't kill your instances, they're still yours to keep and use.

Do you support Reserved Instances?

If you bought a reserved instance through Amazon, it'll be automatically applied to either an already running instance of the corresponding type or applied when you start the next instance.

Which EC2 datacenters do you support?

Right now we're focussing on eu-west, which is located in Ireland. We do have plans to support any region available on EC2 in the future.

Which application stacks do you support?

Our default stacks are Rails/Rack using Passenger running on Ruby Enterprise Edition and PHP using mod_php and Apache. Most of the work configuring them is done using Chef, so if you have a particular need, let us know, and we'll look into it. If all you want is to deploy some static files onto a web server, that's cool too, we got you covered.

We don't support Rails 3 yet.

Which database is the default?

You guessed it, it's MySQL. However, that's just our default. We foster a culture of alternative databases ourselves, so we'll definitely throw in PostgreSQL soon. In the meantime, you're free to roll your own Chef cookbooks to add in any database you wish. We started with a simple Redis installation, and will add CouchDB soon.

My application's deployment is a bit more complex than the average!

No problem. We're deploying your code using Chef's Deploy resource. You can include a couple of Ruby files in your application's code base that will be executed depending on the stage of deployment. There's four hooks available for you: before restart, before migrate, before symlink, after restart. If that's still not enough for you, you can provide Scalarium with a bunch of cookbooks which we're happy to run after we're done with our part of the development. We'll provide more documentation on this soon.

Can I use my own AMIs?

No, not so far at least. We're using a vanilla Ubuntu 9.10 image with some updates installed to speed up the initial boot process. Other than that we're provisioning the instances solely from scratch depending on their role in the cloud.

Can I monitor my instances using Scalarium?

We have some basic monitoring on Scalarium, including CPU, load average and memory, parameters on which we auto-scale your cloud, but so far we're not planning to offer a full monitoring solution a la Nagios or Munin with full alerting etc. We will however make it easy to set up one of them on your instances.

Can you automatically scale my database?

We're afraid we don't have any magic pixie dust we can sprinkle on your database so that it's really, really fast. We can only configure it to the best of our knowledge, take snapshots of it, and maybe set up the occasional slave for you. We can't, however, automatically detect bottlenecks in your application, which includes your database. We're glad to help you out with problems, but we think that trying to automatically scale a database by adding more and more slaves or even (gasp!) a master-master replication setup, is a bad idea.

Where the heck is my beta invite?

We're slowly opening up Scalarium for users, because at least at the moment, we want to make sure that we get good and valuable feedback while still having the option to change things without affecting too many users. We already have production sites running on Scalarium, so rest assured that we're getting there, just slowly. If you feel like you definitely deserve an invite, please let us know, and we'll see what we can do.

Scalarium Beta Update: Custom Roles, Multiple Roles per Instance, Custom Chef Cookbooks

Peritor — Fri, 26 Mar 2010 14:35:43 +0000

We've been quite busy ironing out quirks and adding new features over the last weeks, thanks to our awesome beta users providing valuable feedback. Time for an update on what's new and noteworthy.

Roles are a core concept of Scalarium, they describe what a particular instance is doing. Until now it was only possible to choose from a pre-defined set of roles that we found to be the most common. But of course the common case only covers so many use cases, and we ourselves want to be able to have roles like a Redis server, a CouchDB server or a RabbitMQ host. Enter custom roles. You can now specify your own roles. The process is pretty straight-forward, and I'll soon get to why it's so useful.

Before the most recent updates you could only have one instance per role. That means one instance served the database, and another served your application. For smaller setups this is not very desirable, so now you can assign multiple roles to a particular instance. So your Rails application server can now also serve as the database server. In the capture below I've assigned the roles "Rails Application Server" and "Redis-Server" to the same instance.

There's cases where we don't allow assigning multiple roles, e.g. a load balancer and a web server must be different instances, as both serve data from port 80.

It all comes together with the last noteworthy feature. It's no secret that we use and love Chef, a Ruby-based infrastructure management tool. We offer a pre-defined set of cookbooks, Chef's way to describe logical parts of Scalarium's infrastructure, to serve the default use cases to get your application running on Scalarium, but we want users to be able to customize their environment according to their needs, but through a way that is still in the spirit of the cloud.

Enter custom Chef cookbooks. You can now benefit from the big collection of publicly available cookbooks or simply role your own to customize your cloud infrastructure. Custom cookbooks are enabled on a per-cloud basis with the handy link as shown below.

To give you an idea how a cookbook is layed out, we built a simple collection to set up Redis as a server and a client for a Rails application. We'll expand the collection over time with more useful things. Your cookbooks can be put in a public or private Git or Subversion repository and will be pulled automatically.

We offer different events you can hook into, the initial setup (or provisioning) of an instance, its configuration and deploy. The configure event is sent whenever your cloud changes, e.g. instances going up or down. The deploy event is fired whenever you deploy your application through Scalarium. Just give us a comma-separated list of recipes you'd like to be run on one of the events, and Scalarium will make sure to get together all the right ingredients to cook up a delicious cloud soup on your instances.

We'll add some more detailed information on what kind of data you can access in your custom cookbooks and how to actually write a cookbook in the next blog post.

Just a while ago we added instance statistics, so you can get a small and a detailed overview at how your instances are doing. There's a tiny overview on every cloud's page.

To get the full picture, click on any instance, and follow the link "Monitoring".

That's far from all, we added support for deploying PHP applications and static code (e.g. plain HTML for web servers) and support for SSL. You can also specify a Rails environment for your application. Be sure to follow @scalarium for smaller updates as we go.

That's all for today, folks!

Mathias

Scalarium Screencast

Peritor — Wed, 17 Mar 2010 16:24:00 +0000

We just published our first screencast. In this introductory screencast Jonathan explains the basic functionality of Scalarium.

The screencast gives an overview of Scalarium and explains what clouds, roles, and instances are.

An example Rails application is created and deployed with Scalarium.

We are giving away more invite codes, so please register if you want to give Scalarium a go.

We also just added support for PHP application servers. PHP deployment to EC2 was never easier!

You can reach us via Twitter for feedback.

Introducing Scalarium

Peritor — Wed, 13 Jan 2010 15:20:55 +0000

We've been hard at work over the last couple of months, and it's time to take our baby public to show it to the world.

So what's this all about? We've been big fans of Amazon's EC2 for years now, but there's always been something that didn't fit in with the way we work. Being able to start and stop computing resources on demand is awesome, but having to manage the instances and your application deployments can get quite tedious. The cloud was dumb. Instances didn't know about each other, your application couldn't be sure where your database is, your web server didn't always know about all instances running in your cluster.

With Webistrano we already had an easy way of deploying applications, but it wasn't fit yet for the cloud. You still had to know about all of your instances, configuring them and keeping them up-to-date manually.

That didn't really fit with our usually automated way of life. We wanted to combine both, simplified cloud provising, management, and deployment. The idea for Scalarium was born. That was more than a year ago. The dumb cloud has become casual, no need to worry about the in-depth details anymore, the tedious work of manually managing your infrastructure is now automated.

Here we are now, putting the finishing touches on it so we can let a first group of people have a private look at it. I'm gonna spare you the marketing blabber, you can have a look at our teaser page for that. If you haven't already, now's a good time to sign up for our beta.

What can I expect?

We use Rails, we love Rails, we deploy Rails. Hence, it's the framework we'll be supporting first. Don't worry though, if you want to deploy PHP applications or simply just static content, who are we to deprive you of that joy?

We wanted to keep everything as simple as possible. Not too much noise that distracts you from the thing that's most important: managing and deploying your clouds. Here's a little sneak peek at the UI as it is today. It's still subject to change, but the idea will stay the same either way. First up the view of your cloud. It contains all instances defined sorted by their role in the group.

The applications view is where you'd do your everyday business, deploying your code. When you deploy Scalarium knows about all instances and their prospective roles, deploying and configuring them accordingly. It automatically configures database, load balancer and applications so that each knows the information it needs about the others.

Who are we?

We're Peritor from Berlin, a consultancy focused on Rails and Ruby, deployment and scaling, and Amazon Web Services.

What's next?

We're working hard to make Scalarium available as a private beta, stay tuned. Our aim is to set up camp in February. We'll keep you posted.