Sravish Sridhar is the co-founder of Kinvey, a mobile backend as a service (MBasS) that exemplifies the shift from web to mobile development. Sravish tells a story of how he came from India to Austin, Texas and worked on some of the earliest commercial providers to use distributed infrastructures to offer services that we now assoiciate with leading cloud providers.
Alex Williams: Tell me about yourself.
Sravish: I grew up in the Southern part of India, and I got my first computer when I was seven years old, and I started writing code using a cassette tape. I started getting better computers every year, and I had my first formal computer science class when I was 14. My mom was a geek, she still is. She has even more electronics in the house than I do. In first grade we had a VCR that wasn’t working well. I sat down with my mom and opened up the VCR and we meticulously cleaned the dust away, and she told me what was what. We moved from the VCR to computers. I could make it do things and it did it. Then I started formally learning how to write code. By 15-16 I was writing basic code in Pascal and C, and that’s when I knew this was the profession I wanted to pursue. Basic was the first formal language. Then the cool kids were learning Pascal, because that was better.
Where did you go to University?
Sravish: I was one of the oddballs. When I graduated from high school, it was one of the top five in all of India, and lots of my classmates went to the premier engineering colleges. I was a very good golfer, so part of me wanted to be a professional golfer, and part of me wanted to be an actor. I met a friend of my dad’s who studied in the US, and he asked what I liked to do — and I said I’m good at computers, and I like to golf and act. A week later he invited me to his house and showed me the Princeton Review and showed me the top 25 computer science programs in the US, and another sheet of paper that had the top 25 colleges for beautiful women, and the intersection of that list was the University of Texas in Austin. It was amazing to learn how to live on my own when I was 18. I moved to a foreign country, graduated debt free with no help from anyone. I wrote computer science programs for companies in Austin, I worked as an intern for multiple companies. I worked as a teaching assistant as an undergrad — it was fantastic doing it myself.
Where did you do after college? Who did you work with? What did you focus on?
Sravish: Right around my senior year in college I was working on a project called SETI@home doing distributive computing. It was a screensaver that would launch and run computations that analyzed data to determine extraterrestrial intelligence. It was very popular and about 750,000 people downloaded it. I met some guys in 2000 that wanted to start a company, and a company called United Devices was formed in Austin. They made it (SETI) into commercial software. We built good computing software, it was called Good Computing. In the mid-2000s Oracle 9G was created, G stood for great. It was the precursor to cloud. I wrote a piece of software that 3.5 million people downloaded. It was the largest virtual super-computer in the world. Grid.org was the project, and Grid MP was the software. I started writing code and then managed the team, then I became good with customers. I moved to Europe to grow our customer base, and I became a consultant, a product manager and a sales guy. In seven years I did everything in the company except marketing.
So you like being on the road and talking to people?
Sravish: Yes, I like to find out what people want. So many of us sit in our own bubbles and talk about products and features, and not enough time is spent with actual users. With Kinvey I spend two weeks a month on the road, talking to partners and customers. The George Clooney character in “Up in the Air”, I was that guy for four years. I really enjoyed it. Then United Devices got acquired in 2007 by Univa, and I stayed on for a year. Then I paused and took some time off. I lived in Europe, traveled the world, talked to customers, and I essentially created a category called Good Computing, which basically didn’t exist until that point.
Serendipitous influences on the road seemed to have changed your perspective.
Sravish: Absolutely, case in point: at United Devices we were focused for the first five years on delivering software for R&D departments. With the pharmaceutical industry we were helping people look for drugs, and in the oil and gas industry we were working with people trying to model oil wells. But during my travels I started meeting people from telcos, and we started talking about data centers and how to optimize infrastructure to run virtual machines on them. We created a product called Reliance that took the existing software we had but looked at it as a virtual machine provisioning use case. I joke around that was sort of Cloud 1.0, from an infrastructure standpoint, but we called it Virtual Private Grid, we weren’t smart enough to call it Cloud. It was the ability for telco to extend their data center as a virtualized computing asset for their customers. It all happened while I was on the road talking to people, trying to figure out what they were asking for. The same thing happens quite often for us here at Kinvey, as well.
Did you start thinking about how the resources are used and optimized for how backend as a service could influence application development, was that on your mind at the time?
Sravish: It wasn’t from a mobile standpoint. After United Devices got acquired I took a year off. I traveled around and found a young woman I fell madly in love with. I actually met her in India, I was living in London, and I found myself traveling back and forth between London and Bombay on a two week basis. Three months in she said, “I have some news.” And I said, what’s the news? And she said, I’m moving to Boston to start a PhD at Harvard, and I said, well I guess I’m moving, to Boston, too, at some point. And that’s how I started, instead of going from London to Bombay, I started going from London to Boston every two weeks. It was a much nicer trip. And at some point I said enough, I need to move to Boston for good. And then I moved to Boston and we got married, and we settled down in Cambridge.
When I was in Boston I was visiting a friend’s house, and I distinctly remember his wife came into the kitchen with bags of groceries, and their kids ran down to the kitchen and started rummaging through the groceries. The kids looked at mom and said where are my sticky notes? Where is my cookie dough? She pointed to a board on the refrigerator and said you guys didn’t write what you wanted on the board, so I didn’t buy it. And that was weird to me, because everyone had version 1 of the iPhone then, and I asked how come you guys aren’t using your phones? And that’s when the lightbulb went off for me, that a majority of the applications on the iPhone at the time were client-only applications, they weren’t connecting to any backend services. Notepad or notes was a purely client-only application, it was syncing with the cloud. Even Angry Birds, the popular game back then, was a client-only app. If I bought a new phone I’d have to start at level 0, there was no context of previous levels. And I said why aren’t mobile developers syncing or connecting with data stores or backend services, or letting me log in? Why is the bar this high for the hundreds of thousands of apps that were already in the store by then, for apps to connect to services?
And that’s when I really started getting into what the state of the art was in cloud, and I realized companies were only offering network storage and compute as a cloud service. But that’s not what a mobile developer wanted, and they wanted access to data and identity, engagement capabilities. And I said that’s the service I want to build, and we coined the term backend of the service to describe that concept in 2010.
In 2010, AWS was starting to take off. APIs were mainstream in developer discussions. What were you thinking about the market and how fast you had to move?
Sravish: Funnily enough, I didn’t know anybody in Boston, I moved here for love. I started talking to people, and they said why doesn’t AWS or Google just build this. This doesn’t seem like a good idea, because they could just build it. In hindsight it took them four years to build it. My thesis was none of the infrastructure service vendors had the interest or the capabilities to really go deep and offer the kind of service developers want, give you a full-featured stack. They did a great job giving you Lego bricks, but developers still have to put everything together on their own.
Our vision was: can you truly connect the world’s people, devices and data and enable what’s next? That’s the mantra here at Kinvey. To do that effectively, you really have to go deep to create those connections end to end, for the developer. And I didn’t really believe they could do that well, and so far I’m right.
How do you compare cloud computing now with virtual grids from back then?
Sravish: People have been thinking about it as a computing use case, how do I get access to a unit of computing that comprises CPU storage and network. We think of it as utility computing, we compare cloud computing to electricity — turn on a switch and have access to computing. But we live in a technology world that spans different devices and form factors (laptop, phone, iPad). Where the cloud goes to next is really understanding who a user is, and how they’re consuming the information they want, and provide that information in a very contextual and personal fashion on demand. Not just the when and where, but the how. What do I need to give you based on how you’re trying to access it.
Like Skype, I have on my desktop and phone, but if I use it on my desktop, I have to make sure the application isn’t running on my phone, because the intelligence isn’t there to sync and understand where I am and how I’m using it.
At WWDC, Apple gave a remarkable preview of the world we might be moving into, how you might be on a phone call, and your computer senses it and gives you the option to answer that on your PC. Or if you’re using an application on your tablet, then you come close to your PC, then it migrates into your Safari browser. We’re just scratching the surface of how these user experiences are going to transcend from one user environment to another.
What we talk about now is always much further ahead than the market understands. Now there’s an understanding that mobile devices work entirely differently than desktop computers. There’s different CPUs, memory allocation, the sensor component is different…we’re just starting to break the surface of that understanding. It seems there may be an opportunity there.
Sravish: I totally agree. In fact, in the last year-and-a-half, talking to the global 2000 enterprises, most of them have gotten their feet wet building applications for their businesses. Email, contact lists, enabling the sales force with information from a CRM… We’re now moving into a world where they’re asking the question, what does a fundamentally new business process look like in my enterprise? What are brand new ways for me to create new revenue channels or cut costs by leveraging a mobile tablet or iWatch or connective device? I see road-maps where they’re looking to build apps that are going to create these business processes. Some of the largest companies in the world are appreciating that mobile is different, and they’re asking the question, what can I do by leveraging this difference?
So you obviously have a fascination with backend services dating back to 2007. Today we’re looking at a different way of how things work, such as mobile. Other ways that backend affects applications and development: containers vs virtualization. What’s your take based on your perspective of backend services?
Sravish: In the grid computing world it was all client sites, so we were writing containers, take an app and run it on a PC or server, and have it number crunched on the data and have an answer. We had a highly distributive system of thousands of machines trying to complete a task by wrapping these apps into a container and distributing the container to all the tens of thousands of devices. I saw us moving from a client-site model to a VM model. The next phase of the virtual machine being the container, the application needed to be modified for consistency, but that was the sticking point, because these apps were delivered through ISVs and you don’t have access to the code, and you can’t modify the app. The world we’re moving into now is, how can I create a standard for an app when it’s wrapped in a container, can run on any cloud or any virtual infrastructure with an SLA? There are going to be cloud wars. People are going to ask what cloud should I run on? Enterprise wants the flexibility to not be locked in into a certain cloud provider. It makes sense for enterprise to say we want our apps to be certified on containers so we have the flexibility to move across different clouds.
Are you adapting your roadmap?
Sravish: We are. There’s an age-old debate (3 years old): PaaS vs BaaS [Platform as a Service vs Backend as a Service]. Some of the popular PaaS vendors like OpenShift and CloudFoundry are looking at mobile services on top of their PaaS offering. Companies like Kinvey now have a PaaS offering along with our BaaS offering, so you can run custom code and websites on our website and we manage it and can scale it for you. That entire platform, we wrote it on our own, but we’re now transitioning it to container based architecture, so when a customer wants to run a piece of custom code on our website, we provision that code on a container like Docker, and our PaaS is a set of containers we’re managing and scaling for them.
I’m looking at orchestration as a new theme for The New Stack to cover. If you’re moving clusters around, how is the app behaving on those clusters in these containers, and it’s really just application code. How do I get the PaaS ready to work properly and how do I work collaboratively because that’s how we work now. How is Kinvey adapting to that kind of an environment?
Sravish: To be honest, we cater to a different segment of the developer community. By being the company’s backend, we’re catering to the front end. The advantage we have is the developers we work with are not writing backend code or application servers, we’re doing that for them. When they send us custom code, they really don’t care what platform we run it on. However, in the PaaS world, when I’m writing backend code, I’m making assumptions on what OS is that backend going to run on. Docker doesn’t make it easy to run backend apps made on Ubuntu to run on an underlying PaaS made on RedHat Linux. There’s no compatibility across Linux distributions yet. It’s still in the early stages of being able to be cross compatible across OS distributions. We’re very far away to take an app written for Linux and run it on a Windows Cloud infrastructure. Docker needs to think about how to make PaaS offerings easy and cost comparable for apps written with the assumption that one OS works on another OS.
How does Beacon technology fit into your perspective?
Sravish: I’m a thinker, I’m constantly looking at things and how they’re working and what that might result in. The iPhone and Android phone changed business models: the touchscreen enabled many multi-billion dollar companies. It gives an end user a completely different way to interact with the application. That was genius. It was a new paradigm, created innovation. The next phase was getting geolocation on the phone correct. That created many multi-billion dollar companies. The third phase was getting the camera right. And that’s created many multi-billion dollar companies. With Apple and the Android hardware manufacturers making Beacon technology standard on the phone, it will enable the next wave of applications, but in this case, it will help the enterprise. When an enterprise can look at this proximity-detection via Beacon technologies hey can ask, how do I engage my customer? If I have Beacons in the hospital and on a patient’s wrist, I can track the lifecycle of a patient. A doctor can pre-populate that patient’s information on a tablet. For manufacturers who see a defect, they can open up an app, know where they’re at in the process and 90% of the metadata of where I am can be pre-populated. Beacon is embedded and automatic: it’s part of the hardware. It’s going to get better in the next year or two. The backend becomes the glue that provides the context to the application.
Will there be a new rise of embedded technologies?
Sravish: Absolutely. It’s going to create that rise across two channels: user-based experiences (the doctor in the hospital) and machine to machine experiences. These devices talking to each other and exchanging information. Now you’re bringing people, devices and data together, which is essentially the mission of our company.
What we don’t see yet are the scaling of passive applications yet. The iPhone is a piece of software, doing things without you thinking about it. You can take a picture by pressing a button, then Google Plus will upload the photo for you. They’re the first generation of passive generation. I looked at my Google Now page yesterday, and it talked about how much I’ve walked and biked in this month, and I’ve never set that up. But it knows where I am, and it’s monitoring me via my location, and that’s a passive application. That seems like the next generation — the passive application — and beacon gives rise to that.
Sravish: For example we have a client called SunSprite who’s developed a small little wearable to clip onto your bag, and it detects the amount of light you’re exposed to on a daily basis. Then it passively sends that info to your phone and your phone sends it to a backend. It tracks your light exposure and mashes it up with your mental state of mind. It uses research on how light exposure directly affects how happy you are. Apps like this are directly a function of the backend of the phone. The reason we’re not seeing more passive applications is the phone’s battery can get used up very, very quickly if the app isn’t written well.
Kinvey is a sponsor of The New Stack.
Judy Williams edited and contributed to this story.