Wednesday, July 29, 2015

Book Review: Zero to One: Notes on Startups, or How to Build the Future

Zero to One: Notes on Startups, or How to Build the FutureZero to One: Notes on Startups, or How to Build the Future by Peter Thiel
My rating: 3 of 5 stars

The book is good in patches. To start with, the book did not interest me. I somehow continued and then started finding portions which were really engaging. You see the occasional brilliance of Peter Thiel as a really experienced entrepreneur. He comes across with some really valuable insights. Unfortunately, he wavers easily too. I kept trying to guess who the target audience of this book is. Perhaps the author tries to put in something for everyone which obviously backfires. Because this book is not very engaging I wouldn't recommend it to someone who is not very enthusiastic about the topic but I really look forward to reading a masterpiece from Peter Thiel. And I wish the next book from him is better directed to a specific audience in mind.

View all my reviews

Wednesday, July 15, 2015

Amazon RDS use case: Disaster recovery and scalability

In the previous post in this series, we talked of the of native database usage versus Amazon RDS. We established some reasons as to why you could choose to go for Amazon RDS. In this post we will see what Amazon provides in terms of disaster recovery(DR) and scalability. Amazon RDS makes it so easy to set up both of these that you just click on a couple of things here and there and you are done. Lets look at each of these individually.

Disaster recovery is when you lose your data in the event of a disaster and want to have an option to fall back on. To achieve this you keep a copy of the data you have, being updated in real time along with the original copy. I recently stumbled across a senior project management in a conference who told me:
Chances of losing data in cloud is almost zero. We don't need disaster recovery at all. We have to do it only because our customers want to hear we have DR in place.
Living in the information age and a background in database replication that was hard for me to digest. Lets bank on the WhatsApp acquisition of Facebook. There are multiple interpretations of why Facebook paid the whooping amount and to me the most compelling one is the user base (aka the logical asset) of WhatsApp as a platform. That is how critical data can be. In the age of personalization, data in my opinion is soon going to be the single most precious thing to own. Needless to say being paranoid about your data is the way to go. Make sure your data is safe at any cost and that is where disaster recovery kicks in.

Getting back to the start up use case, disaster recovery is something that needs careful implementation. Automatic failover is ideal but there aren't many database providers offering automatic failover with zero downtime, and neither does Amazon offer zero downtime. Assuming you are a startup and your aim at the moment is disaster recovery, not necessarily with zero downtime, you can again fallback on Amazon's multi-AZ configuration.

Multi-AZ configuration is an architecture where you have a redundant copy of your data being replicated synchronously. When I say synchronously, do realize that in theory this should impact performance. For all practical purposes, the impact is negligible and I would expect this to be something you can simply ignore. Setting up multi-AZ configuration is super quick with Amazon RDS. A couple of clicks on their UI and you are done. A word of caution again from the start-up perspective is that multi-AZ is twice as costly as a single server deployment. Thats the only flip side of having a multi-AZ deployment as I see it.

Lets now turn to the second subtopic- scalability. The most obvious solution to scalability is adding a server (in the technical lingo, slave) that replicates asynchronously from your main server (master). In my experience, I generally see people worrying too much about asynchronous nature of replication fearing data inconsistency. Think hard about your use cases- asynchronous could just be enough. And if it is, Amazon RDS has again something called read-replicas to cater to this. So you will have an architecture like this:

The source here is the multi-AZ deployment that we discussed earlier and the sinks are the slave servers. Once you have this set-up you can scale on the go. Whenever you see the bottleneck on database end, buy one more Amazon RDS instance and attach it as a read replica. More the scalability needed, more the number of slaves- simple enough! Of course this is not the ultimate solution forever because managing tons of slaves isn't the easiest job out there. But as a startup if you have hit this problem you are really successful and should now be able to afford some DBAs to advice you anyway. We will look at the problems on this end and solutions to them in a separate post. For now its time to look back and pat yourself on the back for being quite successful as a start-up- successful enough to have so much data. Keep your data safe and have fun with it!

Sunday, July 12, 2015

Book Review: Direct From Dell

Direct From Dell: Strategies That Revolutionized an IndustryDirect From Dell: Strategies That Revolutionized an Industry by Michael Dell
My rating: 4 of 5 stars

This is an excellent book and I would recommend this to everyone who is starting a B2C company or holds (or aims to hold) a managing positions in such a space.

Michael Dell opens up about his life, how he started dell, what the differentiator for Dell as a company is and his obsession for the customer satisfaction. The book is divided into two parts: the first talks about dell as a younger company and the second focuses on managing the big organizers so you get both the perspectives. The examples quoted in the book, in the form of the experiences of Dell as a company shows how important a differentiating factor for a growing company is and why Dell prides itself on the support and customer feedback loop. The author talks at length about information versus inventory and highlights how important it is to hold as minimum inventory as possible. Alternatively focus on information flow. There is tons to learn from this book.

I am going to place this book in my "read again" section.

The reason I dropped a star (4/5) is that towards the end it fails to bind the reader. I got bored coming across customer obsession too many times and dropped the book just before it ended.

View all my reviews