Scalarium price reduction
2012/05/01
We are happy to announce the first ever Scalarium price drop.
We will lower our management fees by up to 48% effective today!
Check out the new hourly instance prices below.
The new prices
| Type | Old price | New price |
|---|---|---|
| Standard Instances | ||
| Small Instance | 0.03 € | 0.02 € |
| Medium | 0.06 € | 0.04 € |
| Large | 0.12 € | 0.08 € |
| Extra Large | 0.24 € | 0.16 € |
| High-Memory Instances | ||
| Extra Large | 0.18 € | 0.11 € |
| Double Extra Large | 0.42 € | 0.22 € |
| Quadruple Extra Large | 0.84 € | 0.44 € |
| High-CPU Instances | ||
| Medium | 0.06 € | 0.04 € |
| Extra Large | 0.24 € | 0.16 € |
The new pricing is effective immediatly as of May 1st 00:00 UTC for all instances, regardless if already running or not. The bill for April, which you will get in a couple of days, will have the old prices. The bill for May, which you will receive beginning of June, will have the new and lower prices.
You can view your current bill and the costs per cloud in your settings.
We would like to thank all our customers for their loyalty and feedback.
We <3 you!
Updates: South America region, Standard Medium instance, deployments out of Amazon S3, Scalarium API
2012/03/27
Our last update here was some time ago. We worked hard on awesome new features. Today we will announce only a few small things, but be assured that we have bigger features to announce soon ...
Support for new region and instance
We added support for the new South America (Sao Paulo) region as well as the new Standard Medium (m1.medium) instance. Be aware that the instance prices for regions differ (EC2 instance prices), the Scalarium costs are the same for all regions.
The new instance Standard Medium comes with:
- 3.75 GB memory,
- 1 core with 2 EC2 Compute Units,
- 410 GB instance storage,
- and with an 32-bit or 64-bit platform.
So this is the ideal box to use for a smaller database instead of the high CPU medium instance which has in comparison a little more CPU power and two cores but just 1.7 GB memory. Right now we offer the Standard Medium instance in its 64-bit flavor. We will add the support for 32-bit version later.
S3 deployments
We added the possibility to deploy directly out of Amazon S3.
Why did we do this although we already offer git, svn, and http download deployments?
S3 is a highly available, reliable and secure place to store your deployment artifacts. Because of S3s higher availability compared to your own git/svn server or services like github.com/beanstalkapp.com this could be very interesting if you want to ensure that you can deploy any time. This of course comes with a little drawback. You will have to update the S3 object manually or via your CI- or build-process. This is rather easy if you already use a continuous integration server like Jenkins.
If you want to deploy via S3 you can choose this option while creating a new, or editing an existing application.
The repository URL is the link to your S3 object, the username an AWS access key, and the password the corresponding secret key. You won't need to enter your 'Master' Access Keys. Instead you can create an IAM user in the AWS Management Console. This IAM user needs reading access to the object that shall be deployed - that's all.
In the following screen shot you can see the click path for creating a new IAM user.
You will have to attach a user policy to the newly created user. This user policy can be the predefined AmazonS3ReadOnlyAccess rule, which reads as the following:
{
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:Get*",
"s3:List*"
],
"Resource": "*"
}
]
}
In you deployment logs you will find instead of a svn or Git checkout the download from S3 and the extraction of the downloaded archive.
Here you can see another reason why deploying out of S3 is fun. It is really really fast!
Scalarium API
We also added the possibility to list, create, and delete Amazon Credentials in Scalarium. You can lookup how this works in our knowledge base article.
node.js version selection
2011/11/21
We deployed support for node.js apps some months ago. When you wanted to select a node.js version different from the default, you had to do so with, for example, custom JSON.
Until today.
You can now select the node.js version via the node.js settings, stored with your node.js app server role. Of course, you can still set the version by using custom JSON.
Improved instance selection when repeating deployments
2011/11/18
When you deploy an application with Scalarium, you can pick the instances to deploy to. Unless you explicitly deselect some instances, the deployment hits every running instance.
We changed that behavior slightly for repeated deployments.
Say you have a deployment in a cluster with two running instances. During that deployment you decided to skip one instance. When you repeat that deployment, the skipped instance is still skipped, all other running ones are selected for deployment.
For 24/7 instances that results in every instance that was selected before, but it also includes load and time based instances that were not running before but are running when you repeat the deployment.
Introducing the Scalarium client
2011/11/17
When working on an instance over SSH, there are lot of jobs that need to be done again, and again, and again. Because Scalarium focuses heavily on automation, we thought it would be a good idea to create a handy tool that helps us with these jobs - the Scalarium Client.
From now on, the client is part of the Scalarium agent, which runs on every instance. The client is symlinked in /usr/sbin, so you can use it from anywhere.
Here's what it looks like.
root@instance:/# scalarium-client
usage: scalarium-client command [command options]
Commands:
help - Shows list of commands or help for one command
list - List all chef JSON files and their activities (setup, configure, ...)
log - View the latest or a given chef log file
run - Do some real work, call help run for details
status - Display useful information
The client makes things easy that were possible before, but tedious. It tells you what happened on your instance, as an overview or in detail. It tells you the status of the Scalarium agent.
The client also lets you do things that weren't possible before.
Imagine you want to run a single custom recipe from the command line, but with all benefits from the Scalarium UI.
The client does that for you.
- Your recipe is run
- Custom JSON defined in the Scalarium UI is automatically included.
- The chef run is shown in the associated instance's logs in the Scalarium UI.
Give it a try, and have a look at our knowledge base for details and examples.
New Chef Event Type: Shutdown
2011/11/02
Scalarium is all about automation and customization. The main system behind the automation for the instance configuration in Scalarium is the life cycle system.
When an instance boots and connects back to Scalarium, it triggers the setup event and thus executes the bootstrapping.
Once an instance successfully finishes its setup, the configure event is triggered on all instances in the same cloud. This way they can update their configuration if necessary. So a load balancer instance will add the newly booted application server and the database server will add an ACL entry that allows this application server to connect to the database.
When an instance is stopped, the configure event is triggered again. This way your applications and services always know about the current state of your cloud and can respond to changes if necessary.
Scalarium also offers the deploy and the undeploy event that are triggered when you deploy or delete an application.
Today we introduce a new event type: shutdown.
The shutdown event is triggered when you stop an instance. Previously Scalarium would immediately stop the instance on EC2 and trigger a configure on the whole cloud.
From now on Scalarium first sends the shutdown event to the instance and waits 45 seconds and only then really stops the instance. During those 45 seconds you can run any cleanup recipes that e.g. shutdown services or deregister your instance from other services.
The built-in recipes make use of this to stop Apache or MySQL on the instances. This way instances are removed from the load balancer in a cleaner way.
As with all other event types, you can of course add your own Chef recipes for your role that will be run on shutdown.
If want to know more about the shutdown event or custom instance setup in general, make sure to check out the documentation.
Awesome customers are awesome
2011/10/21
Today I want you to introduce you to two of our customers. Both had a good last week and we thought we should share that with the rest of you.
Infopark
Thomas Witt sent us this nice mail
Dear everyone,
we just won the Computerwoche #1 award from Computerwoche's Best In Cloud award (category: platform as a service). Without AWS and Scalarium this wouldn't have been possible! Thank you guys!
Best, T.
Infopark offers a CMS called Fiona which is widely used especially in the German speaking countries.
The best in cloud award was handed out by a big German tech newspaper called Computerwoche (“computer week”). They applied with a project called “Airport Nürnberg auf Wolke 7 - Webauftritt, CMS und WebCRM als Plattform aus der Cloud”.
Infopark hosts the SaaS version of the Fiona CMS on Scalarium and automatically creates a tenant version for new customers with our API
Check the infopark cloud express CRM at infopark.com
Crashlytics
Scalarium customer Crashlytics had a great last week too. Jeff Seibert and Wayne Chang raised $1 million in a seed funding round.
Crashlytics addresses the needs of app makers to better understand what sort of bugs their mobile applications are experiencing. The lightweight Crashlytics SDK (~ 75 kB) works alongside other SDKs without any problem.
They care deeply about building great tools for developers and build a product for iOS crash reporting - with Android crash reporting coming soon.
If you are developing mobile apps you have to check it out and sign up - crashlytics.com
Crashlytics processes the crash reports and exceptions and hosts its public Web site on Scalarium. In this way they can ramp up staging systems and scale with the number of incoming crash reports in no time.
You have an awesome story you want to share? Feel free to shoot me an email at thomas.metschke@scalarium.com
Regards, Thomas
Permissions and Access Control
2011/09/22
As for access rights, until now there was only one possible difference between two users. A user was an admin, or he wasn't. As an admin, you had access to some features that you didn't as a normal user, like managing other users. Every newly created user had access to all existing clouds and every existing user had access to a new cloud. We wanted to let users manage access rights in their accounts per user and per cloud.
The distinction between admins and normal users still exists. You still need to be an admin in order to manage, for example, users, credentials or SSH keys, but access to clouds is handled with the new permission system.
Whenever you try to access a cloud or something that is a "child" of a cloud, your permissions are checked. In this respect applications, instances, roles and deployments are all children of clouds. This means that when you change a user's permissions for a cloud, you also change his permissions for any application, instance, role and deployment that belongs to that cloud.
Here's what the UI for managing permissions looks like.
There are a few things going on in this interface. Let's have a look at the details.
The tabs let you choose between "Clouds" and "Users". Inside these tabs you are able to change default permissions and concrete permissions.
When you are in the "Clouds" tab, the default permissions are the ones that existing users have to a new cloud. In the dropdown below you can select a cloud in order to see and edit every user's permissions to that cloud.
When you are in the "Users" tab, the default permissions are the ones that a new user has to existing clouds. In the dropdown below you can select a user in order to see and edit that user's permissions to every cloud.
For every combination of a user and a cloud we store a permission record. A permission record consists of a level and two flags. The level is something new and it can be one of "manage", "deploy", "show" and "none". The flags are not new, we just changed their scope.
In the past you could already decide whether SSH user handling was enabled for a user or not. On top of that, you could decide whether that user was also added to the sudoers file or not. Instead of making this decision per user, you can now make that decision per user and cloud. That's why we removed the according checkboxes from the user form.
But let's get back to that permission level. As stated above, it can be one of "manage", "deploy", "show" and "none".
The level "none"
prevents you from noticing a cloud. You won't see the cloud or any of it's children. And of course you can't trigger any actions or edit things.
The level "show"
lets you see a cloud and all its children, but you are not allowed to take any actions.
The level "deploy"
lets you deploy all applications belonging to this cloud as well as trigger cloud deployments like update cookbooks. You can't edit the cloud or any child.
The level "manage"
lets you do anything you were able to do before we introduced the permissions feature. So you can add, start/stop and remove servers, add, edit and remove roles and applications and so on.
As mentioned earlier, the distinction between admin and normal user still exists. Admins can change permissions, including their own ones. That's why we decided to not allow to restrict an admin's permissions at all.
Our API is also aware of permissions. When you try to access a cloud that just doesn't exist, we still respond with HTTP status code 404 and the message "Resource not found". However, an attempt to access a cloud that you don't have permission for results in a response with status code 403 and message "No permission".
Tagging Support
2011/09/21
One lesson of the EC2/Scalarium outage was that we need to make it easier to manually interact with the instances. If Scalarium has a problem you should still be able to manage your instances.
Today we released tagging support that makes exactly this a lot simpler.
We now tag every instance. If you look at your instances on the AWS console, you can immediately tell which instance is which.
When you boot an instance, Scalarium will tag the cloud, instance name and instance roles on EC2. All existing instances have been tagged too.
Default Datacenter (Availability Zone)
2011/08/26
Today we wanted to shine some light on a small but useful feature of Scalarium: the default datacenter (or availability zone) of a cloud.
When you create a cloud you chose an AWS region that this cloud should live in. This defines which global EC2 installation you want to use, e.g. start your servers in Virginia (us-east-1) or in the EU (eu-west-1).
Within every AWS region there are at least two different availability zones, the actual datacenter where your servers and EBS volumes will live. When you add an instance to a cluster you can set the availability zone of the instance. Scalarium always allowed (and encouraged) you to place your instances in multiple availability zones.
The reason why you want to spread your servers across multiple availability zones is redundancy. Should one availability zone experience a problem, you still have unaffected instances. A typicall setup would be to have most of your instances in for example eu-west-1b for performance and cost reasons and then have one or two backup slaves in eu-west-1c or eu-west-1a.
Another setup would be to place entire clouds into a dedicated availability zone, e.g. the production cloud in us-east-1a and the backup cloud in us-east-1b.
When managing such setups you have to remenber where a new instance should be placed. And this is where the default availability zone setting of a cloud comes into play. It allows you to specify exactly that: the default availability for new instances in this cloud.
You can set the default availability zone of a cloud when editing a cloud via the "Edit Cloud" link in the actions menu.
