In San Jose (CA), we meet CTO & co-founder of KAAZING, John Fallows. He shares his story how he co-founded this startup and how the current business model works, as well as what the current plans for near future, and some advice for young entrepreneurs.

The transcription of the interview is uploaded below.


Martin: Hey today we are in San Jose with Kaazing and John. John, who are you and what do you do?

John: My name is John Fallows and I am the CTO and co-founder here at Kaazing.

Martin: Great. What did you do before you started this company?

John: Well, prior to Kaazing I was working at Oracle Corporation. I was one of the architects that were responsible for webifying many of Oracle’s applications in their E-business, so during that time our whole team became very familiar with the challenges of building modern web application software at the time. That was around the time that Ajax was incredibly popular and we were responsible for building technologies that made it easier for application developers to take advantage of Ajax without getting caught up in all the technical challenges that that presented.

Martin: And how did you make the move from being an employee at Oracle to start your own company? And how did you find your team members?

John: So at the time my colleague and I, Jonas Jacobi who later became my co-founder, we had written a book about the technology that I had been working on. And so by writing this book, we were able to travel the globe, talking at many different developer conferences about technology and so we built up a fairly strong personal brand, the two of us. Being well renowned in the industry for things related to Ajax and other technologies, at the time called Comet that we were responsible for pushing information towards the browser, almost sending information in the wrong direction. So gaining personal brand was very helpful in transitioning to the next phase of creating a corporate brand. So when Jonas and I founded Kaazing, we continued down this path of attending developer conferences and continued to talk about the challenges that were still present in web architecture and many of the solutions that we were able to bring to the table with Kaazing. And the personal brand that we had already build up, pretty much just translated over into Kaazing directly. And this is also a great mechanism to reach the community at large and find people who were interested in joining our mission.

Martin: Did you find this idea of Kaazing while you were working at Oracle or, I mean, part time? Or did it just happen when you left Oracle and then said, ‘This is some interesting problem that we should work on’.

John: Yeah so actually, we took a little bit of a break in between working in Oracle and starting Kaazing, even spend another brief time at another company in between, both of us. So, this is something that was stemming from this idea of pushing information almost in the wrong direction into browsers and at the time we were getting such a compelling response to attending the various talks that we were providing in these conferences that we felt that the market was having some demand. We even had on several occasions, someone come up to us after our presentation where we would do demos and they would say, ‘I would like to buy your demo’ and of course it’s just demo so you don’t really want to sell it, but it gives you an indication of how compelling this was and how interesting it was to other people.

Martin: Did you bootstrapp until some specific point or did you raise external funding for the building the company?

John: We raised money from angel investors in the early days to help us get started. And then we used that to continue to fund the company, to build up product line and then to segway into institutional funding afterwards. So now, NEA is a investor in the company, CNTP is an investor in the company and we get a lot of guidance from them from the board membership that they have and helping us steer the company forward.


Martin: John, let’s talk about the business model. So can you give us a brief overview in terms of what customers are you serving, what type of value proposition, and what is the pricing structure behind it?

John: Certainly. So fundamentally, when we started the company we were about making the web much more interactive, much more—we’d say real time back then, real time web fully interactive. And so various different markets have different needs in that space. The market that we got interested in tapping early on was the financial services industry. So, they have a requirement to build training applications and so they needed a better latency over the web, they needed the centralized deployment so they needed to use web technology and they were able to use our solution to achieve that. Now, financial services companies, banks and so forth are especially back then, very keen on the perpetual license. And here we were we were a new company, we were providing revolutionary technology and we knew that we wanted to do the subscription model approach but we found it very challenging to break into the financial services with subscription. So in the early days we actually moved to change our approach, our original thinking and we moved to perpetual for the early days and that allowed us to land us some fairly sizable accounts in financial accounts in financial services but it was perpetual license with maintenance and upgrades and yearly maintenance after that. So if you fast forward a little bit to more recent times, we found it easier to transition into the subscription model which is incredibly valuable to our company health, corporate health. And it also allows people to try and not necessarily—they can try things out and see how much they want to buy into and automatically scale up, pay more instantly, things like that. So our subscription model still applies to own premise, it also applies to the cloud like Amazon where elastic scalability is so important for our demand scaling. We have also found that it’s important from an investment thesis standpoint, valuation of a company is deemed more valuable, the more recurring revenue you have that you don’t have to spend more money to get the same amount of return the following years, so that’s valuable as well.

Martin: So you started with a financial industry and then you added other verticals…

John: Yeah, so we found that beyond financial services who—they have a large volume and rate of information to deal with – we’ve certainly being highly relevant to other spaces that are parallel to that such as: online gaming or online betting is very popular in Europe; and also transportation and logistics for information that is highly relevant in the moment, whether it’s gate changes or whether it’s tracking assets like trucks delivering packages, knowing where the trucks are and knowing where the packages are, rerouting the trucks, things like that. These are all recurring style used cases that we found many customers want to use.

Martin: And what does your software really do? Imagine, I am logistic company and you come to me, pitch and tell me what is your software solving?

John: So, the simplest way to put it I would say is, we’re getting the web out of the way. So if you look back, and I mentioned early where we came from in terms of the architecture strategies that are in place, we are making the web feel more interactive, feel more real time. A lot of energy typically gets put into building prototypes for web applications and whenever the prototypes are finished there are necessary additional steps to go beyond the prototype to get to high availability, disaster recovery, scaling out across the globe for example. With traditional style architecture as you go from one step to the other, you typically are invalidating some design choices that you made in the previous step, so it becomes increasingly more complicated. So what we are really doing is we’re taking advantage of all the pain that we’ve already felt and understood and we’ve moved a lot of the complexities involved kind of underneath the line. So when you finish developing your prototype, the incremental effort to go all the way to high availability, disaster recovery, and global scale out, these are all very large benefit’s but small steps in terms of effort because of where you started, so it becomes much easier in terms of value proposition. And what we what found is that that’s all very easy to do and the reason why people want to do it is because what they end up with is simpler more cost-effective architectures that can do more than what they can do before. So we see that, applications that people are building, you hear a lot about things like internet of things, internet of everything, but what it really comes down to is that we are living in a much more connected world. And just as in real life, we are reacting to one another with stimulus, just as you are asking me a question, I am providing you an answer and this is continuing, this is how the applications are evolving. So applications in general, they are becoming more closely modeled to real life because they are interacting with us more and more and the information that they provide that allows us to make good decisions or interact with the world we live in, needs to be done in a more timely way. And there are no rules about what direction the information needs to go in so the concept of a client or a server is very blurred. This concept of only getting a response when you make a request is a little updated now to be able to satisfy the need of that. So, we make all of this interaction very possible. And the other part about these architecture is that they are spread out over the web at large. So they are very geographically distributed, the pieces of the architecture are spread out; the people are spread out; the things are spread out, the data centers, the services inside the data services, they are all spread out from one another. So typically, the web is in the way for some number of these connections that are present in the logical flow of information. So what we are really doing then is we’re getting the web out of the way so that it’s just as easy to architect those kinds of solution as it would be if you are running every inside of your own data center whether there is no web in line.

Martin: Imagine, I am a developer of a website or a specific mobile program. I totally understand that once I have developed this and used this service that I can scale more easily without changing very much on the code that I have written. Is there anything else? Because this is something like a server company who is providing some kind of addition backend structure which helps me scale.

John: Well, a lot of times people are building applications that when it’s time to scale and the solution is just more hardware added. What we are really talking about is getting more out of the underlying hardware. So, we are eliminating parts of the architecture where people would write application code to glue two of the layers together. Those are the places where the scalability is challenged typically, so we are addressing that eliminating the need for the glue code and creating a fabric that permeate everywhere. That allows us to optimize all the pieces where the is no need to have true application code as they used to and just have the services on the edges and the application user experience on the edges and everything is interacting in a very efficient way. So, if I am building new application then I need to think about it in a different way, I can’t just think about it as a go make a request and I get a response. That type of thinking comes from the days in which the web was born. The web was born as a way to share research papers between university professors and there were much slower networks back then and so there was a heavy emphasis of caching to not waste the network and make it unbearably slow and the rate of change of that information is quite slow, so compared to today’s standard. So as you fast forward and continue to try to use that same tool for the job it has it’s very strong strengths related to being able to fetch documents and cache them effectively but it may not as be as well suited for these new styles of interaction pattern that we need.


Martin: Let’s talk about corporate strategy. What do you perceive Kaazing’s competitive advantage?

John: As we compare ourselves in the market place, the way we think about solving these technical challenges is that we tend to divide the product up into layers. So just like good engineering we use the right tool for the job, we put the solution in the right layer of the architecture, having this all layered out nicely gives us unexpected benefits whenever we find that we can out these layers together in new and interesting way. And so I think our competitive advantage on the product line is, we have a high emphasis on performance and scalability and security, starting out in financial services that is not the easiest market to break into. We had a real value to real pain point that they needed a solution for but being successful in there really forces you to have a very strong performance scalability, have a very strong security story. And so, starting in that market was difficult but coming from there and coming into other markets we are very naturally strong by definition of where we came from. So, that’s a good competitive edge for us in the market place. The way we think about this stuff, making it possible to put in layers together in different way is also very powerful. For example, we have a feature that we call enterprise shield and that lets us shut down all the firewall ports between the DMZ and the internal trusted network so that no inbound communication is permitted. Now, there are many ways you could try to approach that technically but what we’ve done is we’ve really just changed what’s happening in the lower most layer where connectivity is being established and everything on top is blissfully unaware that that has happened underneath. So this is what I mean by, we are solving it in a layered way but we don’t require, this reaching in across the layers to solve these problems in an efficient manner, we have isolated it to the right layers. That’s from a product standpoint. But I also think that from a philosophical standpoint, the way that we approach things is that we, we tend to not rush into the simplest shortest term win. We tend to want to always understand where our compass is pointing to know where we will likely end up base on what we know now. And so whenever we make a step forward, we generally do that with the intention of aiming it towards a goal that may be 5 or 6 steps farther ahead. Now at the same time, as you make these steps you don’t know what you are going to learn until you’ve try them. And so, whenever we’re moving forward we are also very keen to iterate on learning on what we’ve done and see if it affects where we want to end up. So it’s based on what we’ve learnt and the sum of all of our knowledge so far which is including the experience on the journey towards where we had planned to go. So that’s baked into the DNA of Kaazing and also I would say that within the organization, whenever we talk about things, we don’t come out of a perspective that it’s right or wrong because of who says it. It is very much a way of thinking about things out loud, it’s a safe environment to disagree but it is very important that when you disagree you are able to articulate why. And that gives the conversation an opportunity to spiral upwards towards a common solution that everyone can get behind and not only that but it’s justified and so now we have a very clear understanding of where we are going and why and now it’s clearer how to take the first step and why.

Martin: So rational decision-making.

John: Yeah, absolutely.

Martin: Like we learned it at the university…

John: Absolutely, absolutely. I applied it in the business context and you know I’ve been in other situations where that doesn’t get applied because you can take the logic all the way up to the finish line and say, ‘Well actually we’re going to do something else based on other criteria’. And I think it’s very valuable to sort of fold that into the decision-making process and then trust the outcome.


Martin: When you think about the market development, related to what you call glue, so it’s something that has some kind of scalability but it’s not directly connected to the server and what trends can you identify? Can you give us some sort of overview of how the market works, in terms of growth and size as well?

John: Well I think, there is these reports about 60 billion connected devices by 2020 and that is talking about the internet of things. But the thing that will make internet of things a reality are the applications that can be built to connect all of those pieces together and so if developers want to move quickly and they want to be able to create these new breeds of applications, they need stuff that’s not going to get in their way when they are trying to tie it all together. So that’s why we think that this concept of glue code is really something that really needs to go away and naturally falls away. It’s good to be able to think of architecture in a simpler way. When we talk about those kind of applications, there’s also more modern trends about how to describe the nature of those applications so we tend to think about these applications now as what we call reactive applications, there’s even a reactive manifesto that’s out there.

Martin: What’s that?

John: It’s trying to describe the context in which an application is running; trying to describe the characteristics of an application that is reacting to stimulus and made up of many disparate pieces; it’s likely message-driven so that it’s responding to stimulus and producing stimulus; and this is all distributed, elastically scalable, and so forth. So this is an interesting way of thinking about application design and application architecture so that you can evolve these applications over time without being able to turn the whole thing off and switch it on again. You need the ability to evolve the pieces independent of the whole. So this all makes a lot of sense but it hasn’t been how web application development have been thought of historically. So we obviously see a lot of value in this direction and we anticipate that it will continue, to be honest it feels a lot like the early days of Ajax at the moment with reactive applications.

Martin: Okay, great.


Martin: John, imagine if a friend comes to you and asks you, ‘John, what should and shouldn’t I do when I start a company?’. What would you recommend to him?

John: I think the first thing I would say is—I think it was Guy Kawasaki said this, ‘Scratch your own itch’. So the whole concept of finding something that is a problem for you personally that you really want to solve, so solve for yourself. So in our case, we had been going at these web architectures and constantly fighting against the challenges and the constraints in which success was defined based on those available choices. And we finally said, ‘Let’s challenge the own concept and turn it on it’s head and introduce the new standard that we needed up helping to create called web socket; let’s create full duplex by directional communication over the web; lets use it as a foundational layer to service all the layer above; and really stop adding all these work arounds where we are trying to retrafit old techniques to new problem and space.’ So I think that would be the first thing as to what to do.

What not to do, I think it’s important to have a balanced approach so in the sense that technical innovation is important, your go to market strategy is also important. Some companies may heavily emphasize on one or the other. I think, I would recommend not over extending either one and having a much more balanced approach to knowing how customers are actually going to achieve value from what you are doing. So clearly, there can be technical optimizations in any solution. It is possible to market something very successfully and then possibly not be defensible technically. So I think it’s very important to have a good balance of both of those.

Martin: What mistakes have you made over the last 3 ro 4 years and what have you learnt?

John: Oh, That could take a long time. Let’s see, I would say early on we did it the hard way. So many companies whenever they approach these opportunities they my create an open source project and they might create a lot of market awareness through that. I think that’s an excellent way to achieve a lot of people being familiar with your approach to things. I also think, we went the route of defining a new standard which has been successful in terms of being picked up by all the major browser vendors; they all have websocket in there now. And so we are very honored to being a part of that process to help create the websocket standard, but that takes a while. So that takes a while in terms of business, in terms of a young company, sustaining themselves while that’s playing out, to put themselves in a strong position for being so highly relevant as that plays out. So there maybe other better ways to do that more efficiently and in a more timely manner. But I think that having come through it and now being on the other side of it obviously, it’s a great place to be now, it just takes some time.

Martin: Okay. John, thank you very much for your time. And next time you want to start a company try to resolve your biggest pain because I am pretty sure thousands of other people will have the same problem and might be willing to pay for it. Thank you very much. Thank you, John.

John: You’re welcome.

Comments are closed.