Ubuntu tablet coming ... is the hardware HTC?

I have no inside information at all, and the following should be taken with a HUGE pinch of salt ... but with a countdown ending Feb 19th on Ubuntu.com hinting at a Tablet announcement, and also HTC's Feb 19th announcement countdown one has to wonder a little bit. And now even more when HTC posted the picture below to Instagram as a teaser with what looks like it has some tablet sized devices on the bottom row under covers ... make your own judgement call, how cool would that be. I for one will be eagerly waiting tomorrow to find out :)

Image Source: Instagram

A misc git tip

For those that have used bzr in the past and are accustomed to “bzr branch lp:~imbrandon/some-project” or similar should like adding this to their ~/.gitconfig
[url "ssh://git@github.com/"]
insteadOf = gh:
insteadOf = gh:~
This allows you to “git clone gh:~bholtsclaw/git-bzr” in much the same way. Also if you are a heavy github user I’d highly recommend checking out the “hub” git cli wrapper found here.

Do Something that Scares You

A guest post on @fat’s blog by @divya is a great read I think everyone should take a moment to checkout, in part below are a few quotes.
By idolising people, I gave up on my opportunity to change the world, learn something exhilaratingly new, call out the wrongs done, and contribute to right some of the wrongs.
And this one, referring to herself:
None of these required any particular skill or talent, they are merely results of taking an action.
Don’t simply do what the rest of us do, do it differently, do it with pride, do it faster. Take a stance and have an opinion. Don’t be afraid to be wrong. In fact, you should expect to be proved wrong. We learn the most when we take a chance on something and discover our assumptions were incorrect. Taking risks with our own ideas is how we learn to be stay both humble and ambitious. It’s a delicate balance, but one of the most important.

How Not to Fail at the Cloud

Lets reflect on recent outages at Amazon that crippled Pintrest, Heroku, and others:

One of the promises of PaaS is productivity. Services like Heroku increase productivity because they abstract from the user the underlying infrastructure.

1: Choose Wisely

The main lesson from this outage is that relying on the provider to carry all your operations isn’t always a safe bet. When we move to a PaaS provider we still need to understand how they run their disaster recovery, high-availability, and scaling procedures. Heroku-like PaaS also forces you to a lowest common denominator approach to deal with continuous availability. In reality, however, there are many trade-offs between scalability, performance, and high availability and deciding between those trade-offs tends to be application specific, so compromising on a lowest common denominator could be not at all what was intended at the end of the day.

PaaS is meant to provide a higher productivity for running our apps on the cloud by abstracting the details of how we run our application (the operation) from the application developer. The black-box approach of many of the public PaaS offerings, such as Heroku, is often an extreme.

There is often a close coupling between what the application does and the way we run it. A new class of platform like juju offer a different open source alternative that gives you more control of your underlying PaaS platform. Juju uses an open model for its Charms that can easily integrate with Puppet, Chef/Chef-Solo, bcfg2, or most any configuration management enabling you to easily customize and control your operations creating your own PaaS and without affecting developer productivity.

2: Database Availability

Most public PaaS offering don’t adequately address is database high-availability, which is obviously a tough area. Specifically, in the event of data center failure or availability zone failure, as in the present case. To deal with database availability, it is necessary to ensure real-time synchronization of the database across sites, or Hot-spare / “Continuous Backup”.

3: Coping with Failure, Avoiding a Single Point of Failure

The general lesson from this and previous failures is actually not new. To be fair, this lesson is not specific to AWS or to any cloud service. Failures are inevitable, and often happen when and where we least expect them to. Instead of trying to prevent failure from happening we should design our systems to cope with failure. The method of dealing with failures is also not that new – use redundancy, don’t rely on a single point failure (including a data center or even a data center provider). Automate the fail-over process, etc…

Haven’t Learned from Past Lessons?

The question that comes out of this is not necessarily how to deal with failures, but instead – why are we failing to implement the lessons?

Assuming that the people running these systems are among the best in the industry makes this question even more interesting … We’re giving up responsibility when we move to the cloud: When we move our operations to the cloud, we often assume that we’re out-sourcing our data center operation completely, including our disaster recovery procedures. The truth is that when we move to the cloud we’re only outsourcing the infrastructure, not our operations, and the responsibility of how to use this infrastructure remain ours.

Implementing Past Lessons in the Cloud

We need to assume full responsibility for our applications’ disaster recovery procedures, in the cloud world just as if we were running our own data center.

The hard part in the cloud is that we often have less visibility, control, and knowledge of the infrastructure, which affects our ability to protect our applications – and each sub-component of our application – from failure. On the other hand, the cloud enables us to spawn new instances easily on various data center locations, a.k.a Availability Zones.

And so, most failures can be addressed by moving from the failed system to a completely different system regardless of the root cause of the failure. Therefore, the first lesson is that in the cloud world it is easier to implement disaster recovery plans, by moving our application traffic to a completely different redundant system in a snap, rather than trying to protect every component of our application from a failure.

If we’re willing to tolerate a short window of downtime, we can even use an on-demand backup site rather than pay the consistent cost and overhead of maintaining a hot backup site.

What do we need to build such a solution?

juju

Providing a consistent way to launch, configure, manage, and scale a primary as well as redundant environments that are ready to take over in case of failure. Specifically, the ability to deploy your application, then orchestrate services and configuration in a consistent way across sites, and on demand.

How to get started ?

In an upcoming post I’ll detail taking a real world webapp from a traditional 1 or 2 VPS “mom and pop” setup that will likely resemble many readers current setups at home or work, then show you how I transform it to apply the above information using juju in detail. Hopefully this will give you a better look into some of the things you may encounter doing the same thing versus setting a new project up from scratch.

Premium Newrelic Accounts for AWS

Do you use juju on AWS or Azure ?

Now there is no reason not to try Newrelic to monitor those services. Newrelic just anounced that users of AWS can now signup for a free Premium account at http://www.newrelic.com/aws or for Azure as well http://www.newrelic.com/azure !

Setting it up to monitor your juju services could not be easier either using the newrelic charm in the juju charm store, to monitor an existing service just …

$ juju deploy newrelic
$ juju set newrelic key=YOUR_API_KEY
$ juju add-relation newrelic nginx

And thats all it takes to have newrelic reporting from your app ( nginx in this example but it will be happy to relate to any service ) to your shiney new account.

  • Note: you can also deploy newrelic-php charm in the same manner if your application is written in PHP to get some additional metrics that are php specific.
  • Disclosure: Although I am the author of the Newrelic juju charms I’m in no other way affiliated with Newrelic nor are the links above Affliate links, just a happy User :)

I'm on the lookout.

I’m looking for my next challenge , so if you are looking for someone that loves to move the web forward, be sure to check out my resume or LinkedIn Profile and get in touch.

Download for Ubuntu Button ...

I Spent a little time this morning in-between waiting for VM’s to spin up to create a CSS3 Based version of the “Download for Ubuntu” Button, my goals were to a) have it look nicer that the blurry image based one currently available and b) be easy to implement pretty much anywhere. You can find instructions for adding it to your page here at http://bholtsclaw.github.com/assets/buttons/download-for-ubuntu.html, but you just need to add these two lines where you would like the button to appear and put your own download url for whatever app your linking to.

<div id="download-for-ubuntu" data-link="https://apps.ubuntu.com/YOUR_APP_LINK"></div>
<script src="http://bholtsclaw.github.com/download-for-ubuntu.min.js" type="text/javascript"></script>

And it should end up looking like this below …

Feel free to leave a comment with suggestions and such :)

JUJU Everywhere!

I’ve just published the first iteration of RPM’s targeted at Fedora along with the .spec file used to build them. Its available on github at http://github.com/jujutools/rpm-juju ( along side the Mac Port ), so Fedora users go fourth and test please! Feedback very welcomed along with any patches or contributions. The goal is for to have these added to the official Fedora, CentOS, and SuSE repositories as they mature and get the early kinks worked out of the packages. Cheers!
Page 1 of 212