Yesterday, on This Week in Google, Leo and friends shared a very important piece of information to protect yourself from Heartbleed.
It is worse than you think it is. Bruce Schneier, says that from 1 to 10, it’s an 11.
First off, if you own or manage any website that have SSL, please use this tool to find out if your website is vulnerable.
To personally protect yourself, TWiG recommends to update your browser settings to ask for updated certificates.
If you are using Chrome, click Chrome > Preferences > Show advanced settings… > then check the box “Check for server certificate revocation”
On Safari, its a bit more complicated. Open Keychain Access > Preferences > Certificates > then hold the ‘Option’ key and select “Require for all certificates” for both OCSP and CRL.
Further to this, Mashable has published a list for all the major sites that were affected and if you can change your password. Some of these include Facebook, Gmail, Amazon Web Services, and Dropbox.
60 second read.
What follows is a guest post from Suzanne Cohen, General Manager at FollowUp.cc, about surviving a technical hail storm and how Copper gave them the tools they needed in a pinch.
FollowUp.cc is a simple email reminder system that works within email and with any email client. The system has been around for 7 years and was in need of a complete technology overhaul. We had been working on a rebuild of the system from the ground up and were getting ready to deploy.
Since the system we were retiring had been built organically and didn’t have architecture documentation, our development team knew that we were going to need to make some changes on the fly once the new system was in place. Email is tricky and unforgiving – especially timed email.
To further complicate things; FollowUp.cc supports users internationally, so there is never a time the system can be down without affecting some users. We knew we needed to schedule downtime and notify customers to avoid flooding our support staff with inquiries on known issues.
Enter StatusHub. In 15 minutes we were able to quickly set up our StatusHub account and get our Status page running. Next, we sent a tweet out to users telling them about the new page and how to sign up for updates. We also emailed users that had asked for this feature – so they knew we were being proactive.
Lastly, when we were scheduling downtime or an issue came up, we were able to quickly tell our users about it. Several users emailed to say they appreciated the added communication and our support staff appreciated that users were not flooding the support system when we needed to make a quick fix.
Now that issues are rare, we continue to use Status Hub for any maintenance issues. It has become a part of our monthly routine – scheduling site updates and making sure users know about the downtime ahead of schedule. Our users now rely on the page and we are thankful to have an easy system to communicate with customers.
Suzanne Cohen is the General Manager at FollowUp.cc, a simple email productivity system. She is a 20 year veteran of marketing, sales and technology. Connect with Suzanne at www.linkedin.com/in/sbsuz/
Choose from 9 new options. Nine!
These modern, customizable themes have all the same easy-to-use features as before, they’re just better looking.
Not Just a Pretty Status Page
It’s nice looking on every device–and that’s great for your business. Why? It’s easier and faster to communicate results to your customers.
To see all the new themes in action, log in to your account or have a look at our page! Give them a try–you can even pick your favourite hex colour.
Google announced massive price drops and changes today. It’s a fruitless exercise to start doing deep comparisons to AWS right now since there’s an AWS Summit tomorrow March 26th. Except when it comes to Sustained Discounts – that’s BIG.
So hold tight for a bit and don’t start migrating just yet! I bet we’ll see reactions from all the main providers over the next couple of weeks. Here’s a quick summary of what Google announced (more on their own post):
We’ve updated our Cloud Costs tool so now you can see Google Compute in one table – by region, currency and time frame (ie: see the full month cost), and with the new Sustained Discounts.
Sustained Discounts Explained (vs Reserved Instances)
This is where it gets interesting. Google now discounts based on usage – and they do it automatically. So if you run your instance 24×7 – you get a 30% discount with no upfront costs. The vast majority of normal workloads and apps require servers on all the time so this is applicable to a lot of deployments.
On AWS, you only get a reduced price if you BUY it – cash upfront – with a Reserved Instance – and you have to decide if you need it for 1 or 3 years and how much time you’ll need it each month. You could use the spot market – which is great, and can be very cost effective – but it’s unsuitable for long lasting instance requirements. This is very disruptive by Google, as it’s hard to see AWS being able to respond in kind – price drops are one thing, but new models where there are a legacy of pre-payments is a whole other issue.
Despite Google’s claim that they want to simplify cost – sustained discounts are not all that simple to calculate. They apply on the hours between % usage. So there’s no discount for anything under 25% (182.5 hours a month), and then from 25-50% (182.5 – 365 hours) you get a 20% discount off the base rate. And so on for 50-75% and 75-100%. While it’s not simple – you don’t have to do anything to get it – which is a big win.
It’s still not utility pricing.
On a final note – this is still not the utopia of utility pricing we were promised. It’s pay as you provision – deploy 10 instances, leave them on 24×7 and you’ll get discounts – but you still pay full price whether or not you actually utilize the instances (most people use less than 30% of the resources they deploy). The ultimate pay-as-you-go model is to charge for CPU, RAM and IO *used* NOT provisioned. Maybe containers (hat tip to our friends in Docker) will help progress this – as you can deploy a container with virtually no overhead, certainly compared to the overhead of running a VM with it’s own OS.
It used to be that to get any level of resilience you had to buy multiple physical servers and replicate them, same for network gear, and if you really cared (i.e. had budget) do that in multiple locations. Everyone started with the notion that they would do it ‘the right way’ but trade-offs swiftly came once costs mounted up.
Then virtualization became acceptable and ‘Cloud Platforms’ or a ‘ Managed Virtualized Environment’ could provide resilience, spread across a large shared resource, for a much reduced cost. This opened up high availability deployments to a much wider audience and was the beginning of what’s now IaaS. Thanks VMware!
And then Amazon Web Services came along and changed everything. On the plus side – you could build a high availability deployment quickly, spin up *and down* instances in minutes, all without a contract or access to dedicated resources. On the down side – instances (and their local storage) were not persistent and could die or become unresponsive anytime. The burden of architecting resilient deployments moved to the developer – away from the infrastructure provider.
Devops was born. ‘Infrastructure as Code’. We have accepted the shift in responsibility – Cloud providers give us the tools to apply as we see fit – it’s up to the app developer to ensure the correct architecture is deployed. Cross your fingers and hope you’ve done it right! It’s gotten so crazy that people take virtual pools of storage and create their own RAID arrays!
So Platform as a Service came along and these PaaS providers took the new burden of managing infrastructure upon themselves and presented an interface to deploy apps with ease. Some of these include Heroku, DotCloud, AppFog and Google App Engine.
The problem with PaaS is that at some point you either trade off the scaling capability of IaaS, or the flexibility to use any tools / frameworks / plugins you wish. This is why Docker is so interesting – you can build locally and push a Dockerfile to a container on any server that supports Docker – physical or virtual – and migrate painlessly later on. That’s why we built Stackdock – it’s the best of both worlds – power and flexibility (more on this another time).
Today Google launched Live Migration* and Managed VMs. Live migration is a big deal – when the underlying hardware experiences a problem – the VM will move with zero downtime! Now instead of accepting the default position that a VM might die anytime (and architecting around this), you can expect your Google Compute VM to persist past hardware failures (as it should – this is one of the promises of virtualization that has been ignored!). I’m not suggesting you don’t build resilience in anymore – I am saying that we’ve been educated by the current IaaS crop to accept that uptime is our responsibility. It shouldn’t be – certainly not ALL on our side.
Secondly, Managed VMs are an attempt at mitigating the limitations of a PaaS platform. Google App Engine is a fantastically scalable platform, but unless you write your app for it, in line with Google’s way of working, you can’t really use it. So if you build locally and then select a provider – GAE almost certainly won’t get a look in. Adding a hybrid option of bringing Compute Instances to App Engine is genius. It bridges the gap and widens the audience. PaaS + IaaS. Maybe you migrate to, or deploy on, Compute and then bit by bit use App Engine features; or vice versa – you start on App Engine and as you find limitations you plug them with Managed VMs.
However it’s a Google solution to a Google problem. I’m not sold on more lock-in. Using App Engine features, with my Compute powered app or with Compute assisting my App Engine app – effectively kills my ability to freely select an infrastructure provider. I have to make a choice and stick with it long-term. That’s already an issue with AWS – the more non-standard services I use, the less ability I have to migrate. Again – this is why Docker is important – and why in Copper we’ll happily support any infrastructure provider and we’d like customers to be able to mix and match the best set of tools to -cost effectively- get the job done.
*Live Migration has been part of GCE since December but today was the first time I’ve seen Google talk about it and give a demo.
Customer support can be the defining factor between a long-lasting positive customer experience and a PR nightmare. During the holidays the importance of providing bulletproof support is magnified when members of your team are away and you find your site hammered with loads of traffic.
We’re very serious about support here at Copper.io and we wanted to know how other teams handled support over the holidays. That’s why we went ahead and asked YOU (our wonderful users) how your company planned to manage their support over the holidays.
Here at Copper.io we’ve been stepping on the gas to bring our users new features to improve the way they use our products.
We knew StatusHub needed a scheduling feature for when you have to do that necessary downtime to make updates…that’s why we’re introducing Scheduled Maintenance, a sexy new way to communicate planned downtime to your users using StatusHub.
It’s a brand new year and we want YOU to come work at Copper.io!
That’s right! We’re hiring for a sh!t load of positions and we’re looking for the cream of the crop to come join our extremely good-looking (ok…we’re slightly above average) team!
Do you think you have what it takes? or maybe you’re thinking “why would I want to work at Copper.io?”
Well here, I’ll spell it out…
Oh…and did I mention…we love to have fun! Team culture is a top priority and here at Copper.io we know how to get it done!
So if you’re passionate about what you do and feel you would be a great fit for one of the positions listed below, hit us up with your info!
Yes, you with the computer in front of your face. It’s Christmas Day today and you just so happen to be browsing the interwebs and are lucky enough to end up on our blog.
Well this year you’re in for a holiday treat…