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.

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!

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.

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.

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.