Spotify Removes 5 Play Limit for Free Users in the UK...But Why?

Spotify has announced that they no longer limit free subscribers to five plays per song for users in the UK.  While I'm sure this is welcome news to Spotify customers who don't want to pay for the service, I don't see the wisdom of this business decision.  There have been a number of articles about Spotify's business model losing them a lot of money and being unsustainable.  I'm not privy to their internal financials but I would have to think that they make more from their paying subscriber's subscription revenue than from monitizing free subscribers through advertising.

I like Spotify's service a lot and have been a paying member since the day they launched in the US.  For less than the price of buying one album per month, I have access to most of the music I would want to listen to.  That's a great value proposition for me and the service is well executed so I would be very unhappy if anything were to happen to them.  I would rather see them cut loose the long term free users if it would put the company in a stronger financial position.  Of course they will always have to offer some type of free trial, as you really need to take this type of service for a test drive before buying.  Although, then again, for $10 per month maybe you don't.

Keeping Track of Sporadic Development Projects

I have been working on a personal project for about the last year, off and on.  It is written in Python using Django.  I started with Java and J2EE and JSF but I was spending a lot more time trying to figure out weird Java problems and not enough time getting things done, so I finally abandoned the Java code base and switched to Python.  The project itself is what I think is an interesting approach to knowledge management on the web, but that's a topic for another day.

The challenge I am running into is that I am the sole developer and it's something I pick up and work on furiously for a few weeks and then life gets busy and I don't look at the code for 2 months.  Unfortunately all the great ideas and state of mind that I had when I put the project down are long gone by the time I pick it up again.  So I needed to find a way to keep track of that state.

I started with a simple TODO.md file in my source tree, but that turned out not to be ideal.  I want to capture a lot more than just a simple TODO list.  I want to keep notes on things that I've tried, things that I want to try, technical approaches I'm thinking of, additional features I'd like to add, etc.  But I don't want an infinitely long text document that I have to parse every time I pick up the project.

Plus I want to keep track of temporality.  It's really useful to refer back to what I was thinking about six months ago, but I don't want that mixed in with the stuff from three months ago.  And I want to quickly look back at what I was thinking about the last time I picked up the project.  Which may be yesterday or a month ago.

So I have started a journal for the project in MacJournal.  I've been using MacJournal for some time for other purposes but I have not tried it as a "lab notebook".  So we'll see how that works out.  My initial thought was to use a blogging platform but I don't really want all my thoughts about this out in the ether (even if it were a private blog), since this is a personal project and not something I'm ready to share yet.  Hopefully a local MacJournal will give me the best of both worlds.  I've only written the inaugural entry so it's too soon to say if it is a good approach or not.  The one complaint I have so far is that MacJournal apparently does not support headings which is not something I've ever missed before but would be very handy for this usage.  For now I'm simply marking my headings bold, but it would be nice to actually have things stored semantically and with hierarchy.

If I find this to be wildly successful or a catastrophic failure I'll be sure to post a follow-up.

New Photography Page

This has nothing to do with my normal tech updates, so I have made a new Photography section on the site.  I've posted a few of my favorites to a portfolio page.  Hope you take a look and let me know what you think!

I might create a photography blog, but I don't know...it's not like I am so active at updating my tech one so...probably no point to that.

Really Impressed with SquareSpace

While this is not the most high traffic site on the Internet and a week or two of downtime would not really matter, I have been impressed with SquareSpace's ability to keep their infrastructure going during the Hurricane Sandy situation in New York.  SquareSpace has kept up a very transparent public blog on status.squarespace.com and while they originally expected to suffer a multi-day outage as a result of losing power and their colo building's basement being flooded, they have managed to keep everything online working closely with their data center provider Peer1.

It does warrant keeping in mind, as I wrote in my last update, that this is not actually highly available infrastructure.  If SquareSpace really wanted high availability they would need to have redundant systems in place provided by a data center in another geographic locale.  But that may be cost prohibitive for them to implement.  So definite bonus points for making the most of the resources they have!  And even more bonus points for the transparent and candid status updates.

"Cloud" infrastructure customers do still need to engineer availability

Today Amazon Web Services had another partial outage, impacting a number of their customer sites.  This has happened a few times and it is always met with declarations of the apocalypse by tech reporters.  I find that irresponsible and silly.  Overall AWS has a good availability record but any IT infrastructure can and will fail from time to time.  In the case of "cloud" providers like Amazon, these failures are amplified by the fact that they impact a significant number of independent companies relying on their services.

But that doesn't mean that companies shouldn't use cloud service providers.  It's still a fantastic value proposition, enabling small companies to compete with large incumbents without prohibitive capital requirements and larger companies to handle surge traffic without having to significantly overbuild their internal infrastructure.

Still, whether you are relying on your own infrastructure or someone else's, you have to engineer for availability if that's important to your business.  AllThingsD has an article on the outage with the incendiary title, "Amazon's Cloud Is Down Again, Taking Heroku With It".  But that's factually incorrect.  Amazon's "cloud" was not down.  There was a partial outage with EBS and several other services within the Northern Virginia Availability Zone.  Sites that are using the affected services within that availability zone are indeed impacted by the outage.  But an Amazon quote from the AllThingsD article states:

2:20 PM PDT We’ve now restored performance for about half of the volumes that experienced issues. Instances that were attached to these recovered volumes are recovering. We’re continuing to work on restoring availability and performance for the volumes that are still degraded.

We also want to add some detail around what customers using ELB may have experienced. Customers with ELBs running in only the affected Availability Zone may be experiencing elevated error rates and customers may not be able to create new ELBs in the affected Availability Zone. For customers with multi-AZ ELBs, traffic was shifted away from the affected Availability Zone early in this event and they should not be seeing impact at this time.

If Heroku was impacted by this outage it's a function of availability choices they made.  I have no experience with or relationship to Heroku so I don't know if their engineering choices were made based on cost, engineering complexity, or other factors, but the bottom line is that they are apparently choosing to host their service within a single AWS Availability Zone.  That is not a solution for high availability and it's unfair to blame the service provider when that provider offers solutions to mitigate these types of single Avaiability Zone failures.

Just because you're using someone else's infrastructure does not mean you don't need to make engineering choices to see maximum availability and it's irresponsible reporting to place all of the blame on the cloud provider.