About the author: Theo Schlossnagle is the founder and CEO of OmtiTI.
The Book:
This book aims to be a comprehensive, technology stack-agnostic compendium of strategies and guidelines to achieving scalability objectives for internet applications. It is quite thin (262 pages) and came out in 2007, when the DevOps meme was not around in its current form.
Why I like this book:
I like this book because it's oriented towards building a solid foundation on topics related to scaling. Compare this book with 'Web Operations: Keeping the Data on Time' (published in late 2010), and you'll find the book under discussion to be more grounded in fundamental principles, and the latter more oriented towards new trends. Now there's nothing wrong with the 'latest-trend' books, but it's better if one reads this kind first to get a good grounding.
Overview of Chapters:
The first three chapters cover basic principles, managing release cycles and operations teams.
A big part of chapter 4 is devoted to explaining the difference between high availability and load balancing. There's no coverage of Cloud based options here – this is for you if you manage your own datacenters. Also, cloud based options will invariably be tied to specific vendors. Different HA options are considered with almost academic rigour.
Chapter 5 examines load balancing options at different layers of the OSI network stack.
Chapter 6 is a mini-guide to building your own Content Delivery Network. From calculating your expected traffic, cost estimates, inter-node synchronization in a cluster to choosing the OS and having an HA network configuration – it's an interesting journey. It brings out the challenges which are invisible to most of us who push our static content to a third party CDN and forget about it. There's a section on DNS issues as well covering Anycast.
Chapter 7 covers five caching techniques. True to the general theme of the book, it does not talk about specific technologies but about theory that can be studied and applied to the problem at hand. An example of speeding up a news website is used to illustrate how to deploy and tune memcached (for that specific site's design).
In Chapter 8, we see an overview of distributed databases, including an overview of different database replication strategies. Managing, storing, aggregating and parsing logs is a challenge we all face – this is covered in Chapter 9. This chapter is dated now as there have been many advances on this topic.
Overall, a must-have for anybody who is interested or works in scaling internet facing applications.
Amazon US URL: http://www.amazon.com/Scalable-Internet-Architectures-Theo-Schlossnagle/dp/067232699X
Indian bookstores: http://isbn.net.in/9788131706114
Showing posts with label books. Show all posts
Showing posts with label books. Show all posts
Friday, 17 May 2013
Monday, 19 April 2010
How Not to do Customer Service
Anybody doing online business knows the importance of retaining and keeping their customers happy. How you do that depends on your specific business - but the starting point is always the same - Respond!
This post is about how not to do customer service - and I am going to take a recent bad experience with one of India's top online stores - http://www.indiaplaza.in. They sell books, among a lot of other things, and I have been buying from them since 2007.
I had ordered 4 books from them last month. 3 of them were shipped on time. When there was no news of the 4th one, I checked the Pending Orders page. It was not updated and stated that the book will be shipped by x - a date 4 days in the past. "Ok", I thought, "let's contact them".
I sent off a mail to their customer service ID - which I had been using earlier. An autoreply came back saying that they do not respond to queries anymore from that ID, and I have to fill out a form on their site. That would raise a support ticket.
Which I did. And the form's response promised that I would get a response within 24 hours.
Which did not happen. And their phone number is hidden in a small Contact Us link - I did not find it.
So I raised another ticket after waiting for a day.
Nothing happened.
At this point I had no visible working way of contacting them (apart from the phone number which I could not find. I attribute this to the fact that the most prominent "Help" link on their site is "Customer Support" - which points to the form mentioned above. That is what most people would click on).
So I went and posted my case on www.consumercourt.in - a site where consumers can go and post their grievances. Apparently that worked - for within 4 hours I got a call from Indiaplaza about the non-availability of the book. There was no apology, though. They promised to deliver it after 7 days. Now, this was extremely surprising. It indicated that their support team checks online complaint sites for issues with Indiaplaza, but do not check their own support system!
Anyways, nothing happened after 7 days - so I went through the same ticketing system again. This time there was a delayed response (thank goodness!) stating that the book was not available. "Fine", I said, "Just refund my money". They agreed to do it within 5 days.
Nothing happened (Do you see a pattern here?) . So I raised another ticket...and so on.
Four things they could have done better
The feeling that I have as a customer that I am being ignored, and especially after I have been billed, with prior experience not helping me to restore trust, is a damning indicator of what Indiaplaza lacks. They have just lost an old customer, and with the power of word of mouth these days, a lot of potential future customers as well.
Update: After raising another ticket, I finally got my refund. But I am not going back there :)
Respond - on time, with a clear actionable, and follow up.
This post is about how not to do customer service - and I am going to take a recent bad experience with one of India's top online stores - http://www.indiaplaza.in. They sell books, among a lot of other things, and I have been buying from them since 2007.
I had ordered 4 books from them last month. 3 of them were shipped on time. When there was no news of the 4th one, I checked the Pending Orders page. It was not updated and stated that the book will be shipped by x - a date 4 days in the past. "Ok", I thought, "let's contact them".
I sent off a mail to their customer service ID - which I had been using earlier. An autoreply came back saying that they do not respond to queries anymore from that ID, and I have to fill out a form on their site. That would raise a support ticket.
Which I did. And the form's response promised that I would get a response within 24 hours.
Which did not happen. And their phone number is hidden in a small Contact Us link - I did not find it.
So I raised another ticket after waiting for a day.
Nothing happened.
At this point I had no visible working way of contacting them (apart from the phone number which I could not find. I attribute this to the fact that the most prominent "Help" link on their site is "Customer Support" - which points to the form mentioned above. That is what most people would click on).
So I went and posted my case on www.consumercourt.in - a site where consumers can go and post their grievances. Apparently that worked - for within 4 hours I got a call from Indiaplaza about the non-availability of the book. There was no apology, though. They promised to deliver it after 7 days. Now, this was extremely surprising. It indicated that their support team checks online complaint sites for issues with Indiaplaza, but do not check their own support system!
Anyways, nothing happened after 7 days - so I went through the same ticketing system again. This time there was a delayed response (thank goodness!) stating that the book was not available. "Fine", I said, "Just refund my money". They agreed to do it within 5 days.
Nothing happened (Do you see a pattern here?) . So I raised another ticket...and so on.
Four things they could have done better
- The deployment of a well thought out customer support system, which is convenient to use and not just built out of considerations like it's easy to use for their support group or helps in cost cutting.
- Responding to my query on their ticketing system within the promised time.
- After not doing (2), followed by the incidents mentioned above, they could have taken extra care about this case. Once you piss off a customer, you have to do extra work to get him where he was before, and still more work to make him happy.
- Build a better online buying system where the status of the order is updated automatically.
The feeling that I have as a customer that I am being ignored, and especially after I have been billed, with prior experience not helping me to restore trust, is a damning indicator of what Indiaplaza lacks. They have just lost an old customer, and with the power of word of mouth these days, a lot of potential future customers as well.
Update: After raising another ticket, I finally got my refund. But I am not going back there :)
Monday, 1 March 2010
Dreaming in Code
I finished reading Dreaming in Code last week. It's Scott Rosenberg's account of a software development team's effort to build the ultimate Personal Information Manager (PIM). Led and funded by Mitch Kapor of Lotus 1-2-3 fame, the team goes through endless cycles of redesign, people issues and other upheavals.
Rosenberg follows the team very closely, participating in their meetings, interviewing them and filling the narrative with his own insights.
If a developer were to read this book, s/he would recognize the events in it this as standard stuff when developing a product, and s/he would also identify with the team itself, with the occasional shaking of the head :)
The software they set out to develop was based on Kapor's vision of a game-changing PIM. They called it Chandler, after one of Kapor's loved crossbred dogs.
This was the pre-Web 2.0 era, where most things, including product releases took longer to happen. The browser had not yet become the first medium for delivering any consumer facing application. Desktop applications for collaboration still looked as if they had potential.
Chandler's ultimate aim was to be a all-in-one tool where users could access their email, personal notes, calendar events and to do lists through one interface. Kapor visualized all these different data collections as isolated information silos. Chandler would break open and combine them. It would let you view and move around all these disparate things in a unified manner. You could tag a note with labels, and then put a date on it and make it a calendar event, or send it off as an email. Grand vision? Yes. It's something I would personally prefer to have around to manage things.
Due to numerous reasons, Chandler was late in delivering its promise. Gmail came in 2004, and opened the floodgates of what was possible using new Web technologies. Firefox arrived, and forced Microsoft to relook at IE (and make it better). Chandler was yet to release its 1.0 version. The browser was fast overtaking the desktop.
We have been spoilt by the seamless interconnectivity provided by the Internet - it's always there - home or office or a mountaintop - and with it, our data. Chandler did attempt a Web interface where you could access your data (which would be synced between your desktop and a central server), but it was too late.
The Chandler project is still on with many faithful developers. I tried out the latest version after finishing the book. My impressions? It still has a long way to go, going by the number of bugs I encountered, and assuming it can convince the Web 2.0 crowd to switch to a desktop application by the sheer force of its design and the things it is supposed to do.
The most interesting chapter in the book is "Methods" - where Rosenberg does a brief and very readable survey of the evolution of development methods over the years. This chapter can be read standalone even if you don't read the whole book.
Note: The Chandler logo image linked to here is used under a Creative Commons Attribution License 3.0.
Rosenberg follows the team very closely, participating in their meetings, interviewing them and filling the narrative with his own insights.
If a developer were to read this book, s/he would recognize the events in it this as standard stuff when developing a product, and s/he would also identify with the team itself, with the occasional shaking of the head :)
The software they set out to develop was based on Kapor's vision of a game-changing PIM. They called it Chandler, after one of Kapor's loved crossbred dogs.
This was the pre-Web 2.0 era, where most things, including product releases took longer to happen. The browser had not yet become the first medium for delivering any consumer facing application. Desktop applications for collaboration still looked as if they had potential.
Chandler's ultimate aim was to be a all-in-one tool where users could access their email, personal notes, calendar events and to do lists through one interface. Kapor visualized all these different data collections as isolated information silos. Chandler would break open and combine them. It would let you view and move around all these disparate things in a unified manner. You could tag a note with labels, and then put a date on it and make it a calendar event, or send it off as an email. Grand vision? Yes. It's something I would personally prefer to have around to manage things.
Due to numerous reasons, Chandler was late in delivering its promise. Gmail came in 2004, and opened the floodgates of what was possible using new Web technologies. Firefox arrived, and forced Microsoft to relook at IE (and make it better). Chandler was yet to release its 1.0 version. The browser was fast overtaking the desktop.
We have been spoilt by the seamless interconnectivity provided by the Internet - it's always there - home or office or a mountaintop - and with it, our data. Chandler did attempt a Web interface where you could access your data (which would be synced between your desktop and a central server), but it was too late.
The Chandler project is still on with many faithful developers. I tried out the latest version after finishing the book. My impressions? It still has a long way to go, going by the number of bugs I encountered, and assuming it can convince the Web 2.0 crowd to switch to a desktop application by the sheer force of its design and the things it is supposed to do.
The most interesting chapter in the book is "Methods" - where Rosenberg does a brief and very readable survey of the evolution of development methods over the years. This chapter can be read standalone even if you don't read the whole book.
Note: The Chandler logo image linked to here is used under a Creative Commons Attribution License 3.0.
Saturday, 26 December 2009
A Ruby script to search bookstores online
I started dabbling in Ruby some weeks back. The initial interest was sparked after reading "Treating Code as an Essay" (Yukihiro Matsumoto) - one of the chapters in Beautiful Code. So I started doing these bootstrapping exercises in Ruby. Some of the exercises are good - but nothing beats doing a small project to learn a new language.
I buy a lot of books, mostly online. There are a few good online bookstores in India, notably Flipkart.com, Infibeam.com and Indiaplaza.in (Sadly, Amazon does not have full-fledged shipping to India yet). The way I usually search for a book in online bookstores is (was, till now)
I wanted to collapse these steps into one - a simple script that would accept the name of the book and show results from all these bookstores, with comparative pricing. And the result was this
http://github.com/talonx/book-search
It's in Ruby, runs from the command line and writes the output to an HTML in the same directory called 'search.html'. Much needs to be done, like
To run the script, type this (you need Ruby 1.8.x, available from http://www.ruby-lang.org/en/downloads/ and the Hpricot HTML parser library, available from http://github.com/whymirror/hpricot)
I buy a lot of books, mostly online. There are a few good online bookstores in India, notably Flipkart.com, Infibeam.com and Indiaplaza.in (Sadly, Amazon does not have full-fledged shipping to India yet). The way I usually search for a book in online bookstores is (was, till now)
- Go to books.google.com and enter the book title
- Click on the best match
- Click on 'All Sellers' on the left of the page
- The Indian bookstores are usually listed towards the bottom. It does not include all stores, and sometimes the prices are not listed. I have to go to each individual site and check them out.
I wanted to collapse these steps into one - a simple script that would accept the name of the book and show results from all these bookstores, with comparative pricing. And the result was this
http://github.com/talonx/book-search
It's in Ruby, runs from the command line and writes the output to an HTML in the same directory called 'search.html'. Much needs to be done, like
- Price based listing with the lowest on top
- A web interface for the search
- Add more bookstores - it's only Flipkart.com, Infibeam.com, Indiaplaza and Bookadda.com right now.
To run the script, type this (you need Ruby 1.8.x, available from http://www.ruby-lang.org/en/downloads/ and the Hpricot HTML parser library, available from http://github.com/whymirror/hpricot)
ruby lib\book-search.rb "<book title (in quotes if it has spaces)>"
Subscribe to:
Posts (Atom)