Updated NGINX Passenger packages will follow shortly (they’ll be available via a separate ppa)

See the blog post for full details…

It’s been almost 4 years since we started Brightbox, and our little hand drawn box logo has worked hard and served us well over this time – brightly adorning the chest of many a well-dressed ruby developer!

However, we felt that as we launch Brightbox Cloud and continue to grow, it was time for a review of our brand identity.

We collaborated with the awesome guys at Fudge Studios and PJD to develop the new identity which conveys more clearly what we consider are the distinguishing characteristics of Brightbox as a company: “clarity”, “openness” and “transparency”. Also, we like the colours ;)

Public launch of Brightbox Cloud

I’m happy to announce that the official launch of Brightbox Cloud will be on 3rd October 2011 (less than a week to go!), and the new website is now live.

Also, as you can see at the top of the page here, we’ve relabelled our established Ruby hosting service to “Brightbox Ruby”, to distinguish it from Brightbox Cloud.

Oh, and yes, there will be t-shirts.

mitre.org has links to more information about this bug.

Ubuntu released new versions of the Apache packages last night, which contain a fix for this bug.

We recommend that customers who are using Apache on their Brightboxes, should upgrade as soon as reasonably convenient. The default Brightbox install uses Apache, so if you are unsure whether or not this affects you then you should upgrade Apache using the instructions below.

The upgrade requires a restart of Apache, which will momentarily interrupt service. In cases where your Brightboxes are behind a load-balancer, the impact of this is minimal.

We believe the upgrade to be low-risk; we have already upgraded a large number of our own servers today without incident, and the only changes relative to the previous package are this security fix.

The necessary commands are

sudo apt-get update
sudo apt-get -y install apache2.2-common

We’ve had around 750 beta testers taking part in the private beta programme and we’re grateful to all those who submitted bugs, provided feature requests, and gave both postive and negative feedback. We’re also grateful to those who built web crawlers, TOR exit nodes etc and generally gave things a good hammering :)

Private beta testers get free cloud resources to play with as well as a 50% discount for the first 3 months when we “go public”.  We’ll be closing private beta registration on 25 August 2011 so this is the final call:  sign up for the private beta before it’s too late!

Brightbox Cloud Pricing

Now, the bit we’ve all been waiting for… I’m excited to announce provisional pricing for our new cloud offering.

Brightbox Cloud is a metered service, with resources charged by the hour or by the gigabyte. These new prices do not affect our existing unmetered Rails hosting platform – Brightbox Cloud is a completely separate platform.

Cloud servers

Cloud Servers are billed by the hour, depending on the “Server Type” which defines the RAM, disk size and CPU allocation of the server.

Load Balancers

Load Balancers are billed by the hour. Internet data in and out of Load Balancers is billed at the normal price. Each Load Balancer is highly available within a Region – designed to tolerate the loss of an entire Zone. Each Load Balancer supports multiple protocols and, at present, can handle 6000 concurrent connections (additional scaling options will be available soon to handle higher levels of traffic).

Price per load balancer instance (HA) = £0.04/hour

Cloud IPs

Cloud IPs are instantly re-mappable public IP addresses which can be mapped to any Cloud Server or Load Balancer within a Region. Each Cloud IP allocated to your account is billed by the hour. Cloud IPs can be allocated and released from your account at any time.

Price per Cloud IP allocated to account = £0.0035/hour (Free until 1 October)

Data charges

Internet data is billed by the gigabyte. Usage data is collected every minute by our billing system. Local data transfer, i.e. data transferred within the same Zone, is free-of-charge. Regional data, i.e data transferred between separate Zones, is free-of-charge until 1 Dec 2011.

Internet data (inbound) = £0.08 per GB
Internet data (outbound) = £0.12 per GB
Regional data transfer = £0.01 tbc (Free until 1 Dec 2011)

Any questions?

If you’ve got any questions about the pricing or anything else about the new cloud platform, drop us an email.

Updated NGINX Passenger packages will follow shortly (they’ll be available via a separate ppa)

We’ve also fixed the dependency problems that occurred in the past, where a newer version of Passenger broke the older NGINX packages. These NGINX packages now strictly depend on the Passenger packages, and we’ve put them in their own Launchpad archive so they’re always guaranteed to work (even if they ever lag behind the Apache packages).

You can add the PPA and install NGINX like this:

sudo apt-add-repository ppa:brightbox/passenger-nginx
sudo apt-get update
sudo apt-get install nginx-full

You’ll then need to enable the Passenger module, which can be usually done like this:

cat <<EOF > /etc/nginx/conf.d/passenger.conf
passenger_root /usr/lib/phusion-passenger;
EOF

We’ve also added our other Apache Passenger packages to Launchpad too (with Hardy support), just use:

sudo apt-add-repository ppa:brightbox/passenger

We’ll keep our own apt repository in sync with Launchpad for Hardy and Lucid too, in case you prefer that (use the passenger-nginx component for the nginx passenger packages).

Happy Passengering! (I’m pretty certain that’s not a real verb. It might be a proper verb. I’m pretty certain there is no such thing as a proper verb).

I don’t have to tell you why IPv6 is important – even the mainstream media has finally realised that the pool of IPv4 addresses is exhausted (it’s not like we needed tarot cards to predict it!). Any modern network must have support for IPv6.

We’ve been concentrating on perfecting IPv4 in Brightbox Cloud as that’s the immediate need, but we’ve considered IPv6 since day one of our network designs (over a year ago now!).  Every cloud server will get IPv6 addresses by default (and AAAA dns records of course), so you’ll be able to access your servers directly. We already have this working for our own test servers and we’ll have it in the hands of our customers very soon.

IPv6 will be a “first class citizen” in the Brightbox Cloud – supported throughout all of our services: Our Cloud Servers, Load Balancers, Firewall, Cloud IPs and of course our API. We’re currently working on the full implementation but I thought it was worthwhile announcing our plans, since this is such an important aspect of our service.

In the three and a half years since Brightbox started, we’ve built a solid reputation for our “Serious Rails Hosting” platform. We’ve spent the last twelve months building Brightbox Cloud our new cloud Infrastructure-as-a-Service which is already making big waves. We’re now looking for an experienced software engineer to join our small but highly productive development team. This is an awesome opportunity to use your skills and experience to help shape our future products and direction in this exciting and fast growing industry.

Main responsibilities:

• Lead development of our distributed cloud management and automation systems
• Break down complex projects into clear tasks and specs
• Proactively find ways of improving our services, systems and code
• Efficiently manage your own workload as well as that of others
• Extract code to be released as free software projects

The ideal candidate:

You have an insatiable desire to understand things, to break them apart and to fix them. You are continuously looking for ways to improve things. You are enthusiastic about some technologies and vocalise your reasoned dislike for others. You have strong opinions and stand by them when it really matters, but are willing to compromise when it doesn’t. You are able to communicate your ideas succinctly with eloquence and clarity. You have probably contributed to some free software projects, and perhaps started your own. You don’t take yourself too seriously and are comfortable with others reviewing your work. You love what you do.

Skills & Experience:

• Several years experience of coding in Ruby
• Experience with Ruby web frameworks, such as Rails, Sinatra
• Experience of testing frameworks, such as rspec
• Experience of deployment using tools, such as Capistrano
• In-depth knowledge of distributed cloud infrastructure concepts
• Experience programming asynchronous systems
• Experience consuming and creating APIs
• Experience of working in a fast-paced, agile environment
• Ability to empathise with users

Our team:

We’re Ruby developers and system engineers. We’re obsessive about great user experience and clear documentation.  We’re passionate about high availability, performance and consistency, though not all at once. We’ve coded seriously in Ruby, C, Delphi, Ada, C++, Python, Amiga AMOS, PHP, Java, Objective-C, Pascal, Eiffel, Basic, Perl, Informix 4GL, Javascript and Bash. We use Ubuntu, Centos and OS X. We take our work seriously but we have a lot of fun.

Like our systems, our teams are geographically distributed, communicating in real-time throughout the working day using our private Jabber conference or phone calls. We manage our work with Redmine, usually organising chunks of work into weekly sprints. We’re a lean organisation – you’ll have direct access to leadership as well as other teams. Our development, engineering and operations teams all work closely together which shortens the feedback loop and means we get things done better.

Location:

Remote, but ideally working within 2 hours of UTC.

Salary:

circa £55k p.a. (depending on experience).

Closing date:

Friday 22nd April 2011.

How to apply:

Send a hello email and a CV (PDF or plain text) to jobs@brightbox.co.uk. All correspondence from recruitment agents must be in Esperanto and to our special recruitment email address: root@localhost

I’m pleased to announce today the new web-based console facility for Brightbox Cloud beta. The console requires no special client, plugins or applets – only a reasonably modern browser that supports HTML5 “Canvas” such as Safari 5.0 (mac/win), Chrome (linux/mac/win), Firefox 3 (linux/mac/win).

The web-based console lets you connect securely to your servers with a time-limited token (avoiding the potential security risk of  leaving a permanent vnc server exposed, for example).

How does it work?

Firstly, get the latest version of the cli (version 0.11.2) by running gem install bbcloud or apt-get install bbcloud (see documentation for more info on installation).

Simply issue the activate_console command for the relevant server…

Note: this will work straightaway for newly created servers, for older servers you’ll need to restart them by issuing a shutdown followed by a start command to pick up the new console facility.

The API will return the secure console url and a token, which is valid for 15 minutes, after which time you’ll simply need to reissue the activate_console command to receive a new token.

Once you’re connected the console sessions themselves can last much longer of course, tokens are only used to initiate the session. Should you need to connect again later, simply reissue the activate_console command to receive a new token.

Copy and paste the console url into your browser, enter the token and you’ll be able to view whatever is currently being output to screen by your cloud server!

When you’ve finished, simply close your browser window and the console session will expire.

If you’ve not done so yet, sign up for our cloud beta now!

Cloud Balancers make it effortless to add fault tolerance and horizontal scalability to your systems by distributing traffic across a pool of Cloud Servers – even within separate Zones.

• Scalable – Cloud Balancers use our high performance distributed cloud infrastructure
• Resilient – automate fault tolerance by balancing across Cloud Servers in separate Zones
• Flexible – map Cloud IP addresses onto your balancers
• Familiar – point domain names at your balancers using standard DNS A-records or CNAMEs
• Simple – use our intuitive commandline interface (or REST API) to configure balancers
• Fast – instantly reconfigure any aspect of your existing balancers
• Customisable – configure custom healthchecks for your pool of Cloud Servers
• Extendable – add as many HTTP or TCP listeners you need per balancer

If you’re already part of the cloud beta programme you’ll simply need to install the latest version of the CLI tool (0.10.1) and you’ll be able to create Cloud Balancers straightaway (see the documentation for instructions).

If you’re not on the beta programme and would like to be, why not submit a beta request today? :)

Check out the screencast…

Cloud Balancer Q & A

How does it work?

Cloud Balancers are managed via the Brightbox API (or using the CLI tool, which uses the API). You create a new balancer, specifying which services should be balanced and to which back end Cloud Servers. The Cloud Balancer is then automatically built, within a minute or so, on top of the Cloud Balancing layer which spans each Zone within a Region. You can then map a Cloud IP onto the balancer and traffic is distributed across your servers according to the policy you define (the default is “least connections”). The Cloud Servers are continuously monitored according to a “healthcheck” you specify. Should one of your Cloud Servers become unresponsive it is removed from the active pool of servers until it is “up” again.

How does this compare to Amazon’s ELB (Elastic Load Balancing)?

Brightbox Cloud Balancers offer a number of advantages over Amazon’s ELB – here’s a few important ones…

1. Brightbox Cloud Balancers work with Cloud IPs so you can easily map and remap public IP addresses between servers and load balancers.
2. With Amazon ELB you are restricted to using only CNAME dns records, so you can’t use root domains (e.g http://example.com) – whereas with Brightbox you can use A-records and use domain names however you wish.
3. With Brightbox you can instantly reconfigure any aspect of your existing balancers, whereas in some situations you’d need to recreate a new ELB load balancer from scratch.

How will pricing work?

We plan to announce pricing information on both this and other Brightbox Cloud services within the next month.

There will be a standard fixed hourly rate for each Cloud Balancer plus a charge for load balanced internet data (per GB).

How quickly are load balancers created?

Load Balancers are normally created and handling traffic within 90 seconds.

How much traffic will a Brightbox Cloud Balancer handle?

Exactly how much traffic a single balancer can handle depends largely on your application, but they can comfortably handle 6000 concurrent connections as standard. This will also increase dramatically in the near future as we add new scaling features to the Cloud Balancing layer.

What kind of traffic can we balance?

You can balance most TCP-based protocols. Specifying an HTTP listener adds an “X-Forwarded-For” header.

The driver is available right now via our fork of libcloud on Github and will hopefully be merged into the official codebase soon.

Here’s a quick example using the Python shell…

libcloud-brightbox:trunk$ python
Python 2.6.5 (r265:79359, Mar 24 2010, 01:32:55)
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from libcloud.drivers.brightbox import BrightboxNodeDriver
>>> from libcloud.types import NodeState
>>> driver = BrightboxNodeDriver('my_client_id', 'my_client_secret')
>>> len(driver.list_nodes())
3
>>> size = driver.list_sizes()[0]
>>> image = driver.list_images()[0]
>>> node = driver.create_node(name='Libcloud test server', size=size, image=image)
>>> node.id
'srv-0dj5y'
>>> len(driver.list_nodes())
4

If you’ve not already done so, request a free cloud beta account and have a go yourself :)

We’ll also be around the “big smoke” earlier in the afternoon, so if you’d like to meet up for a drink and a chat drop us a line – we might even treat you to a live beta demo ;)

If you want to attend CloudCamp London too, register here and come say “hello”!

$ brightbox-images list img-1okdf img-aoubd

id         owner      type      created_on  status  size   name
-----------------------------------------------------------------------------------------
img-1okdf  brightbox  official  2010-11-19  public  20480  FreeBSD 8.1 minimal (i686)
img-aoubd  brightbox  official  2010-11-19  public  20480  FreeBSD 8.1 minimal (x86_64)
-----------------------------------------------------------------------------------------

As you’d expect, you can control FreeBSD servers via the API, just like any other Brightbox cloud server – and that includes snapshotting the disk. If you’re a FreeBSD nerd and want to have a play, then sign up to our beta.

Now I’m off to learn how to use FreeBSD to see what all the fuss is about :)

Created by Wesley Beary and recently adopted into Engine Yard’s open source programme, Fog has a lot of momentum and is a great way to get started with provisioning resources across multiple cloud providers.

If you’ve not yet done so, request a Brightbox Cloud beta account to get started.

We’ve now got Ubuntu Hardy and Lucid packages available on our apt repository and we consider it ready for production use. Brightbox customers can upgrade from Passengr 2.x simply by running these commands on their Brightboxes:

sudo apt-get update
sudo apt-get install -qy libapache2-mod-passenger

If you’ve not got a Brightbox, you’ll need to add our apt repository key and config first. You can read more about it on our wiki.

We’ve dedicated several months to developing and engineering our new cloud platform from the ground up (almost literally). We’ve kitted out two new datacentre “Zones”, set up a new resilient network across them and built-out a distributed cloud system which enables some very exciting features such as re-mappable cloud IP addresses, easy import/export of your cloud server images and much, much more.

We’re launching the private beta phase with our simple command-line client (a full control panel GUI will be available soon). Check out the screencast below to see how easy it is to get started.

If you’d like to get [free] access to our private beta programme, simply submit a request via the beta site and we’ll be in touch shortly!

I’m extremely proud of our achievement, Brightbox is the first company in the UK to offer a “true” distributed IaaS cloud – quite a shake-up for the European cloud market. Stay tuned – there’s a lot more in store!

Why use 64-bit?

There are a number of advantages to 64-bit architectures.

• Increased performance with >3GB of RAM – Addressing more than 3GB of RAM in userland on 32-bit linux requires the use a PAE which incurs a small performance overhead, this is not necessary with 64-bit. This can benefit applications that access large amounts of memory such as MySQL.
• Larger memory-mapped files – Particularly useful for a number of key-value/nosql databases such as Redis and others that use memory-mapped files for storage. MongoDB, for example, is limited to ~2.5GB of storage on 32-bit architectures.
• Certain number-crunching applications such as encryption and audio/video encoding can benefit greatly from access to 64-bit registers, offering considerable performance increases.

However, 64-bit isn’t always beneficial! In nearly all cases a 64-bit process will require (sometimes considerably) more memory than an identical 32-bit process due to larger pointers and other data-types occupying more space. This is particularly prevalent with Ruby where many of the internal data structures double in size when switching to 64-bit. Before deciding on 64-bit you should weigh up the pros and cons for your particular application.

Brightbox’s birthday is a matter of days away and we’re starting our fourth year by increasing RAM for all Brightboxes by 50%. We’ll be upgrading existing Brightboxes over the next couple of weeks, though the product names in the control panel will change straight away.

MySQL connection quotas doubled

Since you’ll now be able to fit more app processes on your Brightboxes, you’ll need more MySQL connections, so we’re doubling those for all products too.

New Relic RPM for all

And as if this wasn’t enough, we’re expanding our New Relic RPM offering to include all Brightbox sizes. See our wiki page for more details about getting it set up.

We’re taking the opportunity to rename our products too, as naming by RAM size starts to get a bit ugly when you move beyond powers of two. The table below shows how the products are being renamed and what your new RAM size will be. Happy birthday us!

We’ve got some other big things in the pipeline too, so stay tuned. The next few months are going to be great.

Update (19 October 2010): We have now completed these upgrades for all customers. The extra MySQL connections are already available to everyone. Customers who have not rebooted their Brightboxes recently will need to do so in order to start using their extra RAM.

We now have Passenger 3.0.0-pre3 packages available for Ubuntu 10.04 (Lucid) and Ubuntu 8.04 (Hardy). As they’re pre-release versions, we don’t recommend them in production just yet and have put them in their own repository to prevent any accidental upgrades.

If you’re not already a Brightbox customer, then you’ll need to set up base access to our apt repository first.

Otherwise, just add the new passenger-testing repository (switch “lucid” to “hardy” if you’re on Hardy):

sudo sh -c 'echo "deb http://apt.brightbox.net lucid passenger-testing" > /etc/apt/sources.list.d/brightbox-passenger-testing.list'

Then you can upgrade/install 3.0.0-1bbox1~pre3

apt-get update
apt-get install libapache2-mod-passenger

Passenger now has a native library, which depends on your version of ruby. For simplicity, these packages currently require the ruby1.8 packages to be installed. You can, of course, switch to ruby1.9 and passenger will auto-compile the necessary native support for you. We’ll be providing packages for 1.9 support soon, so you won’t need to rely on the auto-compiling.

Improved router syntax for Action Controller

The router syntax in Rails 3 has been completely revamped to build on the work from Rails 2 and provide a more elegant and flexible way to provide completely RESTful access for controllers. To get started see the new routing guide.

Brand new Action Mailer

Action Mailer was previously a bit of a hybrid, part controller, part model. Rails 3 sees Action Mailer completely rewritten purely as a controller, it now behaves much more like Action Controller. The new Action Mailer guide describes how to get going.

New query engine for Active Record

Active Record has adopted a new query engine to make complex queries more consistent and manageable. Execution of queries is now delayed until actually required and not when defined. For an introduction to the new query engine check out the new new Active Record guide.

Bundler

Traditionally, managing the dependencies for your Rails app deployment can be a bit of a nightmare. While Capistrano, Rake and other partial solutions make automating things easier, they’re often not elegant or simple. Bundler provides a complete solution to managing gems, libraries, frameworks and plugins that your app depends on. The latest release of the Brightbox deployment gem offers full support for Bundler.

Other improvements include built in XSS protection, an official plugins API, Agnosticism with plugins, Active Model callbacks & validations, better handling of character encoding and many more. For a more comprehensive list of changes see the release notes.

Rails 3 on your Brightboxes

Getting up and running with Rails 3 on your Brightboxes should be as simple as you’re used to with your existing Rails 2 apps.

Prerequisites

Rails 3 requires Ruby 1.8.7 or higher, Ruby 1.8.6 is no longer supported. If you’re using Hardy based Brightboxes you’ll need to upgrade the standard Ruby Enterprise Edition package, Lucid based Brightboxes include 1.8.7 by default. Ruby 1.9.2 is also supported, though we don’t have packages for it just yet.

Full support for Rails 3 deployment was added to the Brightbox deployment gem in version 2.3.7, so if you’re using an older version you’ll need to update. Don’t forget to update the brightbox-server-tools on your boxes too! The gem now has full bundler support for managing gem dependencies so if you’re using bundler you no longer need to define gems in your deployment recipe. Bundler is now our recommended solution for handling dependencies.

You’ll also need RubyGems 1.3.7 or newer. New Brightboxes include our 1.3.7 rubygems package for Ubuntu, if you’re running an older version you can upgrade like so

sudo apt-get update
sudo apt-get install rubygems

We’d also recommend running your app with the latest version of Phusion Passenger, especially if you plan on running Rails 2 and 3 side-by-side.

Installation

Installing Rails 3 is as simple as

gem install rails --version 3.0.0

Deployment

You can deploy your Rails 3 apps using the Brightbox gem just like you’re used to. Make sure you’re using the latest release of the gem which contains some new features to improve Rails 3 support.

Documentation

For more information on using Rails 3 see the newly updated official documentation. For help with running Rails 3 on your Brightbox, including information on running Rails 2 & 3 side-by-side see our Rails 3 wiki page.

That has now changed! Today, we’re really pleased to announce two new dedicated MySQL options: a single dedicated MySQL server and a dedicated HA (High Availability) cluster.

Both services provide you with the benefits of increased performance and predictability with guaranteed CPU and RAM resources, and also include 24/7 monitoring and managed backups!

Pricing starts at just £85/month for a single dedicated MySQL instance and £169/month for the HA cluster – a bargain for what are essentially fully-managed MySQL solutions. They’re available to all customers to purchase from the control panel right now.

For more information, check out the dedicated MySQL services page on our main site.

For further information on using these packages see the release announcement for our Ruby EE 2010.01 packages.

Available from today, you can now choose either Ubuntu Hardy or Lucid as the base OS when building new Brightboxes.

Ubuntu Lucid is the latest Long Term Support (LTS) version of Ubuntu with security fixes provided until April 2015. It brings a whole bunch of upgrades such as Ruby 1.8.7, Monit 5, Apache 2.2.14 and new packages like CouchDB, Sphinx, Chef, RabbitMQ, MongoDB, ejabberd and many more.

We’ve treated it to the usual Brightbox Ruby deployment tune-up, including our Ruby Enterprise Edition 1.8.7-2010.01 packages. Updated Phusion Passenger packages are now available on our newly Lucid-enabled apt repository.

When buying a new Brightbox, you’ll see a combo box that you can use to select Lucid (Hardy is still currently the default). Upgrading from Hardy to Lucid isn’t really viable due to the way Hardy boxes handle kernels, so you’ll either need to request a re-image (which involves wiping your box, so make backups!) or buy a new box and move your apps to it.