Image Source: HTC's Instagram Profile
Image Source: HTC's Instagram Profile
[url "ssh://git@github.com/"]
insteadOf = gh:
insteadOf = gh:~
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.
One of the promises of PaaS is productivity. Services like Heroku increase productivity because they abstract from the user the underlying infrastructure.
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.
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”.
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…
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.
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.
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.
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.
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.
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.
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 :)