In case you missed (or didn’t read) the post on Sunday about choosing web app pricing through testing, we announced a price reduction for all paid Server Density accounts.
Instead of £10 GBP (~$15) per server per month, the price is now £7 GBP (~$10 USD) per server per month. This excludes VAT for UK/EEC customers.
This change will be applied to your next invoice. You can see how much your next bill will be from the “Account” tab in Server Density. Let us know if you have any questions.
This is the 3rd post in a 3 part series which has previously looked at our work and the metrics behind improvements to features (part 1) and the conversion funnel (part 2).
It seems that one of the more difficult questions facing startup founders is how to choose a price. Without a physical product that has a fixed unit cost, it can be hard to decide how much you should charge, especially at the beginning. There has been a fair amount of discussion and various blog posts (and a free eBook) on the topic but it often ends up as an educated guess – what you would pay for it.
When we first launched our server monitoring service, Server Density, we were in the same position and so decided to base our pricing on FogBugz On Demand. This is a hosted version of Fog Creek’s well known bug tracking service which is charged at $25 USD per user per month. That’s about £16 GBP and so we decided to go for a nice round number, £10 per server per month. During our beta users indicated this would be a fair price when we asked them about it. And that’s what it’s been ever since…until now.
Competing with free
We built Server Density out of our own frustration with existing tools. Sure, they are very flexible and are free (open source) to use, but the real cost comes with the complexity of setting things up and ongoing maintenance. As a small company (or even a medium sized company), that is overkill. So we positioned Server Density as a very easy way to quickly get server performance monitoring and alerting set up.
The problem is you’re competing with free products and regardless of what time/cost savings are involved, there’s always the perception of “well I could just download it for free”. This isn’t the place for a discussion of free (open source) vs commercial but we had to try and differentiate the product in ways other than “ease of use”. Our customers get that once they’ve signed up, the hurdle is getting that signup in the first place.
Too expensive?
That there are free alternatives is important because it makes a difference to what your pricing is. When we surved our customers, one of the biggest complaints was the price. People loved the service but thought it was too expensive. Since then we’ve made improvements to try and reach the “must have” status but also thought we’d try a pricing experiment.
A/B testing pricing
Unlike at the beginning, we now know how much each customer costs us and how much revenue they generate per month on average. Using this data, we were able to pick 2 new (lower) price points to test based on the assumption that £10 per server per month was too expensive. So from the 19th Dec 2009 we started a test on our website to randomly assign a price to each user as they landed on the site and measure both signups and then conversions.
This was very simple multi-variate testing executed using Google Website Optimizer picking from 3 price options:
- £10 GBP per server per month (original)
- £7 GBP per server per month (combination 1)
- £5 GBP per server per month (combination 2)
The results – signups
We need to run the test for at least a month so we could go through an entire signup/free trial cycle. Our free trials last for 30 days but we ended up running it for over 2 months – 19th Dec to 3rd Mar. We had a pretty good idea what the right choice was near the end but it was interesting to see the data come up and run through several trial cycles.
Based on signups, the best price was £7 showing 13.1% more signups than £10, performing better than £5. This is interesting because £5, is obviously cheaper. This showed an 11.7% improvement so it was very close. The chart below shows the number of signups and demonstrates the variations over the experiment.
The results – conversions
Signups are important because as mentioned above, we have found that once users get into using the app they find it extremely useful and are more likely to put their pricing objections aside. However, even more important are the conversion figures because they translate directly to revenue.
As expected, the lower pricing points showed more conversions but that does not necessarily mean higher revenues. Our average customer monitors more than 1 server so the real test was whether the lower price point resulted in an increase in the number of servers monitored.
It did. We did not see an increase in conversions but a decrease in revenue because of the lower price – we in fact saw an increase in conversions, an increase in the number of servers monitored and an increase in the revenue.
- At the £7 price point compared to the £10 price point we had 20% more conversions and a 78% increase in the number of servers. This translated to a 25% increase in revenue.
- At the £5 price point compared to the £10 price point we had a 70% increase in conversions and 161% increase in the number of servers. This translated to a 30% increase in revenue.
So the clear winner is £5 right? Not necessarily. It is clear that lowering our pricing is the right move but the revenue difference between £7 and £5 is only 5%. Given the tiny difference in signups (even with more conversions), it makes little difference choosing £5 over £7. Further, setting a lower list price means we have to adjust our reseller pricing which is where our largest revenues come from. Decreasing the price from £10 to £7 makes the most sense right now because it gives us both the revenue increase from direct signups but also provides flexibility when negotiating reseller deals.
Impact to existing customers
We have, from today, reduced our pricing to £7 GBP (~$10 USD) for all customers. The figures make sense for new signups but if you do this, you have to be careful with existing revenues because they will be affected too (unless you’re evil and don’t make the change for existing customers). I ran our numbers through our forecasting spreadsheet to ensure this wouldn’t cause any cashflow problems and the change made almost no real difference. I’m hoping to see some of our existing customers add a few more servers now their monthly bills will be lower.
What about complaints during the experiment?
I thought we might have existing customers complain if they went to our website and saw a different price from the one they signed up with. That was not the case – none of our existing customers noticed! We had a couple of e-mails from new visitors who had colleagues showing different prices from them when they were evaluating but that did not affect sales in any way we can measure. Google Website Optimizer is pretty clever about how it remembers the pricing – it’s not just cookie based.
Conclusions
Choosing a price at the beginning is hard but once you have data you can quickly use it to make decisions about what the best price will be. In our case we were able to reduce the price to achieve a revenue increase. We no longer have an arbitrary price – it is based on our costs and clear statistics showing the effectiveness of each price point. Having real data also allows you to show you’re not reducing prices as a panicked reaction to slow signups. We are now confident we have the right pricing for direct signups and room to work with resellers.
One feature in our server monitoring application, Server Density, and indeed the one I had quite a bit of fun developing, is our cloud provider support. To clarify, we deem any ad hoc VPS, slice, or server supplier a “cloud provider” for the purposes of Server Density.
libcloud
We use a modified version of libcloud to perform API calls to the various cloud server providers. libcloud is an open source, Apache-incubated project, started by the folks over at Cloudkick.
Use within Server Density
There are several places within Server Density where libcloud is used. The most apparent is on the add cloud server screen. On this screen, you’re asked to supply your cloud provider type and corresponding credentials.
When you click the update button, a few things happen. A document is saved to one of our RabbitMQ queues, which is then processed by one of the consumer daemons for that queue. The consumer is written in Python and so fully utilises libcloud. The appropriate cloud provider driver is then created, on which list_nodes is called; the subsequent list of running nodes is stored in a MongoDB collection and populated for the user via a periodic AJAX call.
Two other daemons also use libcloud; the auto-removal and CloudWatch daemons. These both make periodic calls to libcloud drivers either to automatically remove a server from Server Density when it no longer exists, or to pull in metrics from CloudWatch.
Enabling vCloud support
There is a vCloud driver in libcloud, however it is disabled by default. You can enable vCloud support by modifying the providers.py file and adding its driver to the end of the DRIVERS dictionary.
DRIVERS = {
Provider.DUMMY:
('libcloud.drivers.dummy', 'DummyNodeDriver'),
Provider.EC2_US_EAST:
('libcloud.drivers.ec2', 'EC2NodeDriver'),
Provider.EC2_EU_WEST:
('libcloud.drivers.ec2', 'EC2EUNodeDriver'),
Provider.EC2_US_WEST:
('libcloud.drivers.ec2', 'EC2USWestNodeDriver'),
Provider.GOGRID:
('libcloud.drivers.gogrid', 'GoGridNodeDriver'),
Provider.RACKSPACE:
('libcloud.drivers.rackspace', 'RackspaceNodeDriver'),
Provider.SLICEHOST:
('libcloud.drivers.slicehost', 'SlicehostNodeDriver'),
Provider.VPSNET:
('libcloud.drivers.vpsnet', 'VPSNetNodeDriver'),
Provider.LINODE:
('libcloud.drivers.linode', 'LinodeNodeDriver'),
Provider.RIMUHOSTING:
('libcloud.drivers.rimuhosting', 'RimuHostingNodeDriver'),
Provider.VOXEL:
('libcloud.drivers.voxel', 'VoxelNodeDriver'),
Provider.SOFTLAYER:
('libcloud.drivers.softlayer', 'SoftLayerNodeDriver'),
Provider.VCLOUD:
('libcloud.drivers.vcloud', 'VCloudNodeDriver')
}
vCloud works slightly differently than other cloud providers, because it is a VMware product that can be offered as a service by multiple vendors. Because of this, you have to provide a host parameter to your instance of the driver.
from libcloud.types import Provider
from libcloud.providers import get_driver
vCloud = get_driver(Provider.VCLOUD)
driver = vCloud('username', 'key')
driver.connection.host = 'services.vcloudexpress.terremark.com'
Terremark’s vCloud Express is one such vCloud provider, but you can use any host.
Enabling Amazon CloudWatch
Amazon EC2 is also supported very well by libcloud, however, we needed the ability to pull in CloudWatch metrics whenever possible which is currently not supported by libcloud. Fortunately, since libcloud is open source, we forked the project on Github and added the ability to pull in CloudWatch metrics. You can view the changeset here.
Back in July last year I wrote about our migration from MySQL to MongoDB. We have been running MongoDB in production for our server monitoring service, Server Density, since then – 8 months – and have learnt quite a few things about it. These are the kind of things that you only experience once you reach a certain level of usage and it is surprising how few issues we’ve had. Where a problem or bug has cropped up, it has been quickly resolved/fixed by the MongoDB dev team; so we’re very happy.
A few stats
Taken from our MongoDB instances as of Fri 26th Feb:
- Collections (tables): 17,810
- Indexes: 43,175
- Documents (rows): 664,158,090
We currently have a manual failover setup with a single master and slave. The master has 72GB RAM and the slave is in a different DC. Given disk space limits, we are in the final stages of migrating to using automated replica pairs with manual sharding across 4 database servers (x2 masters, x2 slaves in different DCs). There were some delays deploying our new servers but we’re expecting all data to finish synching this coming week so we can switch over. This is a classic move from initial hardware (vertical) scaling to adding more servers (horizontal) as we grow. Although manually sharded for now, we’re planning to switch to the auto-sharding coming in MongoDB soon.
Namespace limits
We split our customers across (currently) 3 MongoDB databases because there is a namespace limit of 24,000 per database. This is essentially the number of collections + number of indexes.
You can check the total number of namespaces in use for a particular DB by using the command db.system.namespaces.count() from the MongoDB console. You can also increase this limit by using the –nssize paramter but there are tradeoffs and limits for this. See the MongoDB docs for details.
Durability
There is no full single server durability in MongoDB. This has been highlighted by the MongoDB developers themselves but essentially means you must run multiple servers in replication. If you suffer a power loss and/or MongoDB exits uncleanly then you will need to repair your database. If it’s small this is a simple process from the console, but it involves MongoDB going through every single document and rebuilding it. When you have databases at the size of ours, this would take hours.
You can use master/slave replication (ideally with the slave server in a different data centre) but if there’s a failure on the master you need to failover manually. Instead, you can use replica pairs which handle deciding which is the master between them, and in the event of a switchover will become eventually consistent when they both come back online.
Initial sync/replication of large databases
Our databases are very large and it takes about 48-72 hours to fully sync all our current data onto a new slave in a different DC (via a site-to-site VPN for security). During this time you’re at risk because the slave is not up to date.
Further, you need to ensure that your op log is large enough to hold all actions since the sync begins. MongoDB takes a snapshot from the time you start the sync and then when it’s done, uses the op log to catch up with actions since.
We found we needed a 75GB op log, which can be specified with the –oplogSize command line parameter. However, these files are allocated before MongoDB starts accepting connections. You therefore have to wait whilst the OS creates ~37 2GB files for the logs. On our fast 15k SAS disks this takes between 2-7 seconds per file – 5 mins – but on some of our older test boxes it took up to 30 seconds (~20 mins). During this time your database will be unavailable.
This is particularly a problem if you’re restarting an existing single server in replication mode, or are setting up a replica pair – the restart will take time as the files are allocated.
To avoid this problem, you can create the files yourself and MongoDB will then not have to do it. Run the following from the console, as soon as you hit return after “done” it’ll start making the files:
for i in {0..40}
do
echo $i
head -c 2146435072 /dev/zero > local.$i
done
Stop MongoDB, make sure any existing local.* files are removed and then move these new ones into your data directory, and restart MongoDB.
This will work for –oplogSize=75000. Note that creating the files will hog the filesystem I/O and slow everything down, but it won’t take your database offline. If you prefer, make the files on another system then transfer them over the network.
Initial sync “slows” things
When doing a fresh sync from a master to a slave, we have observed a “slowdown” in our application response times. We’ve not looked into this in detail because it’s still within acceptable response time ranges but it seems to be caused by a slightly higher wait time when our application is connecting and querying MongoDB. This causes http processes to hang around a little longer for each request and so CPU load increases.
My theory is that because the slave is reading all data from every collection in every database, the cache is being invalidated often and so reads can’t take advantage of it as well. But I’m not sure – it’s not been reported to MongoDB as it’s not really a problem. It would, however, be a problem, if your server was unable to handle the load from the Apache processes. It’s quite an edge case though.
Running MongoDB as a daemon/forked process + logging
Back in the olden days we ran MongoDB in a screen session but you can now just specify the –fork parameter and MongoDB will start as a forked process. If you do this, be sure to specify –logpath so you can check for any errors. We also use the –quiet option otherwise too much gets logged and rapidly fills up the file. There is no inbuilt log rotation.
OS tweaks
We came across a problem with too many open files which was caused by the default OS file descriptor limit. This is set at 1024 which can be too low. MongoDB now has documentation about this but you can set your limit higher on Red Hat systems by editing the /etc/security/limits.conf file. You also need to set UsePAM to yes in /etc/ssh/sshd_config to have it take effect when you log in as your user.
We also disabled atime on our database servers so that the filesystem isn’t caught up updating timestamps every time MongoDB reads from all its files.
Index creation blocks
We create all our indexes at the very beginning so the initial index process is pretty much instantaneous. However, if you have an existing collection and create a new index on it then that process will block the database until the index is created.
This is resolved in the development version of MongoDB (1.3) which introduces background indexing as an option.
Efficiency of reclaiming diskspace
The nature of our server monitoring application means we collect a lot of data, but it is deleted after a set retention period. We have found that there is a massive discrepancy between a master and a freshly copied slave. Obviously the slave is copying the data and storing as optimally as possible (no gaps between sectors where stuff has been deleted) so the very first sync will use less disk space than the master. However, we have seen a master using almost 900GB where a fresh slave uses only 350GB.
We have an open issue with MongoDB commercial support about this.
Support is excellent
Even before 10gen (the company behind MongoDB) got their $1.5m venture funding, their support was excellent. And it still is. We use their gold commercial support service and it has proved useful when we encountered many of the issues above. Opening tickets is easy and we get extremely fast responses from developers. I can also call and speak to them 24/7 in emergencies.
And if you don’t want / need to pay then their open mailing list is still very good. We need the ability to get support very quickly 24/7 but I’ve always had very fast replies from the mailing list.
Conclusion – was it the right move?
Yes. MongoDB has been an excellent choice. Administration of massive databases is easy, it scales extremely well and support is top notch. The only thing I’m missing and waiting for now is auto sharding. We’re doing manual sharding but having it handled by MongoDB is going to be very cool!
We’re in the process of deploying a new set of servers behind a new firewall. The servers can only be accessed via our IPSec VPN provided through the Cisco hardware firewalls and whilst this works “out of the box” with the provided Cisco client, it’s so horrible (Java) that it’s worth taking some time to configure the firewall so it can be used with the iPhone and OS X 10.6 Cisco VPN clients.
The first time we encountered the issue, it took a lot of time and research from us and our provider, Rackspace, to get the right configuration – the default options won’t let your iPhone / OS X connect.
Changes to the firewall
Minimum requirements:
- You must run the firewall firmware v7 or above to get VPN support for the iPhone client (Cisco docs).
- The entry level Cisco Pix 506 firewall provided by Rackspace as standard cannot be updated to v7. You must use a PIX 515/515E, PIX 525, PIX 535, ASA5510, 5520, 5540 or 5550 (Cisco docs).
The configuration of the firewall itself requires enabling extended authentication for the tunnel group with a shared secret. The tunnel group needs to be tied to a group policy that defines the tunnel protocol and split tunneling settings. This is a case of removing the “isakmp ikev1-user-authentication none” IPSec attribute and creating one or more users in the local user database.
Here is our configuration (from an ASA5505) with passwords removed:
group-policy iphone internal group-policy iphone attributes vpn-tunnel-protocol IPSec split-tunnel-policy tunnelspecified split-tunnel-network-list value 202 username david password PASSWORDHERE encrypted tunnel-group iphone type remote-access tunnel-group iphone general-attributes address-pool ippool default-group-policy iphone tunnel-group iphone ipsec-attributes pre-shared-key SHAREDKEYHERE
The client
You can connect to the Cisco IPSec VPN through OS X 10.6’s inbuilt client. This is in System Preferences > Network > Add > VPN > Cisco IPSec. You’ll be asked to provide a username, server name and password. You also have to click on the authentication settings and enter your shared secret and group name as configured on your firewall.
Unfortunately there is a bug in OS X which means it will not remember the password. This is very annoying as it means you’ll have to enter the password every single time you connect to the VPN. It’s reported to Apple under bug ID #7573884 and is compounded by another bug which prevents copy/pasting the password, also known by Apple under bug ID #5296712.
If you get errors that look like the below then you probably haven’t configured the firewall as described above. You’ll find these logged in /var/log/system.log on OS X.
Feb 24 18:06:58 Panama racoon[20256]: Connecting.
Feb 24 18:06:59 Panama racoon[20256]: IKE Packet: transmit success. (Initiator, Aggressive-Mode message 1).
Feb 24 18:06:59 Panama racoon[20256]: IKEv1 Phase1 AUTH: failed. (Initiator, Aggressive-Mode Message 2).
Feb 24 18:06:59 Panama racoon[20256]: IKE Packet: transmit success. (Information message).
Feb 24 18:06:59 Panama racoon[20256]: IKEv1 Information-Notice: transmit success. (ISAKMP-SA).
Feb 24 18:06:59 Panama racoon[20256]: IKE Packet: receive failed. (Initiator, Aggressive-Mode Message 2).
Feb 24 18:06:59 Panama racoon[20256]: Disconnecting. (Connection tried to negotiate for, 1.054018 seconds).
Feb 24 18:06:59 Panama racoon[20256]: IKE Packets Receive Failure-Rate Statistic. (Failure-Rate = 100.000).
Feb 24 18:06:59 Panama racoon[20256]: IKE Phase1 Authentication Failure-Rate Statistic. (Failure-Rate = 100.000).
The buzzword is bootstrapped. This means using your own funds to start a company spending as little as possible, either until you generate revenue from customers and/or you raise outside capital. One year ago I started playing with some Python code to create our server monitoring tool, Server Density, and formed the company in April 2009 (on the 6th, specifically to coincide with the day the tax year starts), but how much did it actually cost me?
The beginnings are always unsure – I was trying out an idea that I thought would be fun to do, but could also be a good product. Funding everything from my own bank account, I wanted to spend as little as possible to get to the stage where people were willing to pay me. At that point I could decide whether to continue, or withdraw.
The dates run from April 2009 – June 2009 (I backdated some expenses from the previous months), so using the power of our awesome accounting system, Xero, let’s have a look at where the costs were.
April 2009
Total: £862.13 GBP + $65.03 USD = £902.78 GBP
- Advertising – Google AdWords – £76.58
- Business cards – Moo – £11.48
- Domain names – £34.00
- Events – Geek’n'rolla – £81.03
- Legal (company incorporation) – £144.95
- Mobile internet – T-Mobile – £39.35
- Monitoring – Pingdom – £31.74
- Phone (calling beta testers) – Skype – £11.50
- SMS credits – Clickatell – £15.93
- Source code hosting – GitHub – $7.00 USD
- Testing – Amazon Web Services – $0.76 USD
- Travel – Hotels – £306.02
- Travel – Trains – £109.55
- Web hosting – Slicehost – $57.27 USD
May 2009
Total: £235.11 GBP + $517.04 USD = £558.30 GBP (at current exchange rate)
- Accounting – Xero – £21.85
- Advertising – Google AdWords – £40.13
- Advertising – ServerFault.com – $160.43
- Book – High performance MySQL (updated edition from the one I already have) – £25.03
- Events – OpenSoho – £5.50
- Phone answering service – Answer.co.uk – £23.00
- Phone headset – Plantronics Voyager – £35.67
- Phone (calling beta testers) – Skype – £14.83
- Postage & packaging (sending contracts for payment processor) – £8.85
- Source code hosting – GitHub – $7.00 USD
- SSL certificates (wildcard and domain) – GoDaddy – $244.93 USD
- Testing – Amazon Web Services – $0.02 USD
- Travel – Trains – £60.25
- Software – WordPress.com (custom domain) – $15.00 USD
- Web hosting – Slicehost – $89.66 USD
June 2009
Total: £262.87 GBP + $144.89 USD = £353.44 GBP (at current exchange rate)
- Accounting – Xero – £21.85
- Advertising – Campaign Monitor – $11.39 USD
- Apple Developer Program – £59.00
- Clothes (serverdensity.com t-shirts) – Spreadshirt – £15.10
- Insurance (legally required employee liability insurance) – Hiscox – £14.72
- Payment processing – NetBanx – £23.00
- Payment processing – Streamline (setup fee) – £57.50
- Phone (calling beta testers) – Skype – £14.89
- Postage & packaging (sending contracts for payment processor) – £5.51
- Software – 37signals (Highrise) $2.00 USD
- Source code hosting – GitHub – $7.00 USD
- Testing – Rackspace Cloud – $9.17 USD
- Travel – Trains – £51.30
- Web hosting – Slicehost – $115.33 USD
Total startup cost to get to revenue
£1,814.52 GBP / $2,902.87
What’s missing?
The biggest cost is paying employees. That isn’t on the above figures because I didn’t pay myself or my co-founder a salary (only expenses, as above). Although a few of the items above could’ve been left out as unnecessary, they’re really only minor costs compared to the amount you have to pay real people. This is fine if you have lots of money (savings or external funding) but the best way to bootstrap is to have technical co-founders who can do everything you need (programming, design, graphics, etc) for equity and promise of an awesome future.
The cost of people cannot be underestimated. It is significant and not paying yourself/your co-founders only works for a short period of time. Eventually you run out of money so you need to be generating revenue by then.
What if you can’t find co-founders with these skills? Look again. I think everything should be done in house wherever possible (with a few exceptions like legal, accounting, etc).
Ongoing costs
That’ll be the subject of a future post, as getting to revenue is only the first hurdle. Our costs are now quite different but we have the funding available to cover them.
Status blog
This post will be the last notice on our main blog about any service problems or planned maintenance. We have created a new blog at status.boxedice.com that you can subscribe to be notified of upcoming maintenance. We will also keep it up to date when we experience any service affecting issues.
Server Density Maintenance
On Saturday 13th Feb 2010 and 12:00 GMT, we will be taking the service offline to switch over to a new database configuration.
This outage will last a few minutes at most and will affect all monitoring services provided by Server Density.
Once the service resumes we will pause alerts for a few minutes to prevent any false “no data” alerts – all servers should report in within 60 seconds of coming back online.
Until the unveiling of Apple’s iPad, Amazon had an effective monopoly as a large ebook retailer with the Kindle tied to their online Store. This has allowed them to exert control over pricing because the publishers had no alternative options. However, that dominant position has now been challenged.
Apple is expected to recommend pricing at around $12.99 – $14.99 but publishers will have the final say on that. This is a different pricing model from the one currently operated by Amazon which involves a set price.
As a result of Apple entering the equation, a dispute arose concerning one of the big 6 US publishers, Macmillon, who wanted Amazon to provide the same variable pricing structure. This is interesting because Macmillon were getting their fee regardless – it was amazon that was taking the hit:
Amazon prices all its Kindle e-books at $9.99 or less. This becomes a selling point for Kindle, as new hardback books can cost up to $27. In some cases, Amazon is actually paying the publisher more than $9.99 per copy sold, and losing money. But Amazon has stacks of cash, and it’s a way to sell more Kindles and gain market share. – Amazon v Macmillan: free market fail, Guardian
Books already have pricing ranges. A new hardcover release is usually more expensive before the paperback comes out later at a lower price. So currently the big advantage of the ebook format is consumers can access the latest releases at a lower price than the hardcover. This is not only a lower price but means they can read it right now when they might otherwise have waited for the paperback. The new pricing introduces more pricing variability on a per title basis but probably more consistency across platforms.
Amazon attempted to fight back by removing Macmillon’s books from its entire site. The problem is that because this is essentially 1/6th of all books and consumers can just buy elsewhere, Amazon quickly gave in to the demands. Had this gone on, the other publishers may have become involved too. This is an interesting example of increased competition affecting the market, even where the competing product is not yet available.
This pricing structure is similar to how iPhone apps are priced with developers deciding how much to charge and Apple taking a 30% cut. Such a model provides more flexibility for publishers but removes the ability for the retailer to provide a competitive edge through pricing alone. However, there are a huge number of iPhone developers and they therefore have no individual power.
In adopting the Apple model, the balance of power would shift at least partly back to publishers, which regain control of pricing,” the report said. “In setting higher prices, they could provide a level playing field for all e-book retailers. The potential for publishers is that the device may generate greater volume for e-book sales.”
One publish executive surmised that book companies will be left with a choice to embrace Apple’s device and hope it attracts more people to e-books, or stick with Amazon’s model which offers greater revenue. – AppleInsider on WSJ report
The effect of this is that ebook manufacturers (namely Amazon and Apple, but also other companies who may enter the market this year) can no longer compete on price. Instead, they will need to look at other options. The Amazon Kindle is very much a single purpose device – reading – and it is said to do it very well. However, the iPad not only does ebooks but is a multi-purpose device – email, web browsing and all the apps currently available on the App Store.
Amazon knows that it needs to expand the abilities of the Kindle – it has recently announced the availability of a Kindle SDK. We have seen the iPod touch replace the general iPod range as a multi-purpose device and it seems that Apple are now looking to do the same with the iPad. People do not want to be carrying several devices, although there is an argument for carrying a couple of devices if each one is heavily optimised for its purpose.
Amazon still have a few advantages, namely the worldwide wireless access. It’s very convenient to be able to purchase and access content anywhere in the world for free (there is a small fee depending on your country of origin and the content you’re accessing), a convenience that the iPad does not have. It will be a pain if you’re required to have data subscriptions for each country you want to take the iPad to.
Aside from functionality, like other Apple products, the competitive advantage is in the experience. Anyone who uses the iPhone, iPod (and to a lesser extent OS X) knows how great the user experience is. This is because Apple control the whole system and spend a huge amount of time on the UI. The iPad will likely be the same when it comes to buying books – from the store to the reader application.
User experience is a competitive advantage. So many devices, software applications and websites have poor user experience and it really does matter. This is not something that can be outsourced and requires a deep focus on usability from the beginning. Everyone involved has to have great design and experience as the first consideration, not something that is added as an afterthought. It’s difficult to get right, particularly because users often don’t notice when things are done properly! But statistics show that improvements in usability have a real impact on important metrics.
We have yet to hear how good the iPad is for prolonged reading. The Kindle’s eInk display makes it much more like reading a physical book than reading from a screen, but that presents limitations in what can be achieved visually. If the war is going to be won based on visual experience then this will pose a big problem.
When book titles are priced the same, cost ceases to be a factor in choosing which device to purchase. This is especially so when the pricing differences between the two devices are minimal but one has superior aesthetics and functionality. It’s certainly going to be interesting to see how things develop and what Amazon does in the coming months.
Feedback from the users of our server monitoring service, Server Density, indicate that user experience plays a big role in decision making when it comes to choosing one product over competitors. Whether it is ease of use, a great looking UI or a tight shopping experience, user functionality and user experience are now the most important things, not price.
It is now possible to get alerts when specific processes are no longer running on your servers using our server monitoring service, Server Density.
Available for all users (free, trial and paid), you can now choose “Process not running” as an alert check type when adding an alert, enter the name of the process, and Server Density will then notify you when that process no longer appears on the process list. Just enter the exact process name as displayed on the process list in the server snapshot (click on any point on the graphs to view the snapshot for that timestamp).
This feature is useful so you can find out when your regular jobs stop running, or important system processes like MySQL, Apache or Nginx fail.
Let us know if you need any help, or have any questions.
Yesterday we experienced an outage of our server monitoring service, Server Density, lasting approximately 45 minutes. The problem was resolved and we are now in the process of implementing a number of changes to prevent a re-occurrence.
Technical Details
We are currently investigating what appears to be a bug within MongoDB that causes indexes to become corrupt on a single collection within a database. This is only on the collection storing the process list and means we are unable to delete items from it. End-user impact is therefore nil, but it affects our backend processes such as data retention. The MongoDB developers are trying to reproduce but the interim fix is to drop the indexes and recreate them.
Yesterday, this was done on a single, but large collection. The expected impact was a short period of blocking (affecting a small percentage of users due to our split database structure) as the indexes were rebuilt. This completed as expected but immediately afterwards, the entire MongoDB instance started throwing “too many files open” errors. This caused the instance to do down.
We have experienced this error before and it resolved itself after a few minutes. However, this time it persisted long enough for us to decide to failover to our off-site replicated slave. Unfortunately this was further delayed because we were waiting for the primary MongoDB instance to quit, but a bug in the network layer prevented this from happening. Further, once failed over, our checks picked up some inconsistencies with the replicated database which meant that data for the previous 24-48 hours was unavailable for some users.
In the meantime, working with the MongoDB emergency support team, we resolved the problem on the database master and so decided to bring that back online instead of remaining with the problematic failover.
Subsequent actions
We have submitted a full incident report to the MongoDB team but a number of changes will be implemented immediately:
- Previously, our failover mechanism was entirely manual. This has been replaced with the MongoDB replica pair system. Our servers in multiple datacentres now continually communicate so that in the event of an issue, failover will occur immediately and automatically. This was not implemented sooner because it requires a period of downtime, so this outage presented a good opportunity to set it up.
- Non-blocking index building is now available in the latest MongoDB development code and we will be deploying this once it is released in the stable branch.
- The bug affecting closing the network layer has been fixed and will also be deployed once it is released as stable.
- Investigation will continue into the index corruption issue.
- We are also in the process of planning a new server architecture to incorporate more automated failover.
I’d like to apologise for this outage. If you have any questions then please get in touch.
