Brave For Free

Posts

Flying into the Clouds

A few days ago I gave sage commentary on leaving the cloud . Today, it's about going into the cloud instead. Image generated by MidJourney I’ve been living with my head in the clouds for a long time now. As a fledgling startup from before AWS, I could only look on in envy as a cohort of youngsters flashed a credit card and pulled in computing power I had to spend months and millions with IBM to get just a handful of years ago, This got me deeply into the cloud, and my next few startup-ish attempts made me no money, but did teach me a lot about how to ignore IBM. A History Lesson I’ve worked with companies that were not startups but benefited greatly from the move to the cloud in selected areas. The first was Indiainfoline, a decade ago India’s largest broker and struggling mightily with its hyper-growth. We put — not the core, but a very essential and troublesome service on the cloud — email. Remember, a decade ago email was the collaboration lifeblood of a company, and constant p

Leaving the Cloud

There’s much talk now about how the cloud is passé, and just an expensive way to send people into space really. A blog post by David Heinemeier Hansson posted some time ago about how he thinks the cloud is largely new coats of paint on old stuff and thus wants to leave it behind at once. As a practitioner who’s spent time on and off the cloud with companies large and small, these are my comments. (I got this image created by DALL-E-2 ) Now David is no lightweight. He’s the man behind of Basecamp that millions of people use. He’s also the man behind the widely used Ruby on Rails framework that tens of millions of people use. He’s a bestselling author. He’s even an actual, certified race car driver. I’ve never written a major open-source project, and only ride bicycles past racetracks so lets be clear — I’m sniping at giants. My only defence — I’ve done some of this stuff at all kinds of scale. I’ve been born once on the cloud, spent time purely on the ground and been back and forth a

Banana Peels and Getting Things Done

I am sure all of you must have experienced this. A team of smart driven people get together in a room, all focused on a project and eager to progress. Two months of meetings later, the project is still drifting along, not quite getting to closure. Have you wondered why this happens? Why seemingly smart people with the best of intentions slip on the banana peel just as they are about to raise the curtain? My theory is that one (or god help us, more) of the following syndromes is in play. 1. The HYTO or "Have you thought of..." syndrome. This is when, after a decision to act has been finalised, someone pipes up with "but have you thought about ". This of course leads to discussion about whether that has really been thought about, often causing action to be deferred till the thinking about is done. Of course, the next meeting to close has another "have you thought of..." moment and the cycle continues. With each round, the HYTO concerns get increasingly mo

Backing up is for Dumbos

Sunanda recently lost some photos that she'd clicked on her holiday, and I asked what I thought was the obvious: "where did you back them up"? A freezing glare followed. "Why", she asked me "should I have to back it up?". Putting my foot firmly in my mouth, I persisted "its dumb to not back up! Technology 101!!". "Pretty stupid technology, if you ask me" she said, marching out of the room. This exchange got me thinking. In all my life as a technology manager (not to mention high priest of family photographs), backup has been are core mantra, but also a colossal the pain in the neck. The process takes too long, is never as current as you want and is invariably missing for the very day that your most important data was being written. Storage did indeed seem more than a bit stupid if so much time and effort was required to protect it from losing data. Technology should be smart enough to do invisibly what is essentially a core

The Great Privacy Elephant

Privacy is all the rage now, and it struck me just recently that privacy protection has, in fact, changed worryingly without being noticed. Recently RBI insisted that all copies of all financial transaction data be stored inside the country, for reasons of " unfettered supervisory access ". Part of the justification for this extra-draconian measure is to protect the privacy of Indians, ensuring that no foreign power can snoop into such data. Many other data directives followed, all in the name of protecting data privacy. Today all of us are heated up about how Facebook and Google are compromising our privacy by knowing where we are and what we do. We insist on the right to be forgotten by these and other entities, convinced that they are stealing what really belongs to us. We insist that if they use information they learn about our habits, they should compensate us from their profits and not just by providing free services such as door-to-door directions and free email. S

Rethinking Disaster Recovery

Disaster Recovery has been on the minds of companies ever since the early days of commercially available computing. Today's world of DR revolves around four acronyms - BIA (business impact analysis), RPO (recovery point objective), RTO (recovery time objective) and BCP (business continuity plan). The acronyms appear in a disaster recovery plan in roughly in that order, the thinking being that you first analyse the impact to business of systems being down, then figure out how far back in the past are you willing to turn the dial back to recover from (last day, last hour, last millisecond). Next focus on how long you can afford to be down. Finally - buy a boatload of hardware, software and services to convert all this into action. Setting up a DR is a hugely expensive affair that takes a significant amount planning and effort, not to mention all those drills and tests every now and then. CTOs have followed this prescription since the late seventies (apparently the first hot site wa