What is realtime data all about?

Joe: Hello and a very warm welcome to the fourth episode of the Digital Brew. I’m here today with Matt from Ably and we’ll be talking about realtime data delivery.

Matt thanks for your time today. You and I have obviously known each other for a few years but could you perhaps introduce yourself to those who don’t know you?

Matt: Sure, so I’m the CEO and sort of technical co-founder of Ably. I’ve been doing that for a few years now and prior to that I was a co-founder and CTO of e-Consultancy which we did a trade sell back in 2012.

Joe: Yes, there’s good heritage in there! *laughs*

Matt: Yes with your brother, brother involvement! *laughs*

Joe: Um I think one of the reasons I was keen to talk about realtime and Ably as a realtime data platform. As you and I both know, there’s a lot of buzzwords, lots of hype about stuff and, to be brutally frank, I don’t understand realtime enough and I think it would be quite interesting speak to you. You’ve got a good track record of backing the right horses, so you know, you understand it so I think perhaps what is an obvious starter, how would you define realtime?  I mean there’s obviously quite a wide appreciation of what that means, so what does it mean to you?

Matt: So I think it’s probably easier to start with – I suppose what we… some examples of how people are using us to deliver realtime and now I can maybe talk to you about from the initial point which is how the word realtime is maybe a bit overloaded and a bit of a buzzword.

Joe: Yeah.

Matt: So the types of experiences that customers, or people – everyone experiences day to day I think like Facebook Messenger where, you know, you’re getting a realtime message, delivered to you in realtime or using an Uber app and seeing the driver driving around that’s what we consider realtime, you know. It’s delivery of data to a device, to a server and it’s getting pushed to that device so you’re getting realtime updates. Now the word ‘realtime’ is very overloaded because I mean there’s a lot of… in the tech space you’ve got things like realtime databases and sometimes those just mean that they’re, you know, they’re consistent and up to date and you’ve got sort of realtime marketing platforms which are… again just means that they they’re up-to-date. So that’s –  for us, that’s not realtime I mean it’s not that that isn’t a version of realtime but that’s not what we mean by realtime.

And then you’ve got the sort of more extreme end of things which form an engineering perspective, if you’re designing a missile and you… you know, what you might need is a realtime operating system that guarantees that every CPU cycle a bit of code will runs so that you never have a situation where a hundred milliseconds may pass and a bit of code hasn’t run. Because you might need to guarantee every millisecond you have to analyse all the bits of information coming in and action something and do something.  So that’s kind of not where we operate either that that’s a very different way. It’s an engineering version of realtime where, the space we see realtime is… it’s really changing the paradigm of what we experience in the web which is you go to a web page you send a request and you get a response back and that’s kind of the sort of model and where realtime is really just turning that on its head where the device connects to us and then we push data to it as and when it happens.

Now there’s been some sort of studies around what humans perceive as realtime and and that’s what we do have, sort of when we‘re designing the platform, one of our goals has always been that everything needs to  happen within less than 100 milliseconds. 100 milliseconds is what you as a human can perceive, you know, to see two things happened separately; 500 milliseconds you’ll notice that one’s lagging behind the other one. It’s a bit like watching a movie hundred milliseconds, if the audio is synced with the video you wouldn’t notice that lag, beyond that you start to notice that things aren’t quite the same. And so, for us, it’s always been an aspiration or a goal that once we go beyond a hundred milliseconds we are moving to territory where people might perceive it as realtime.

Joe: Yeah.

Matt: But you know we focus a lot on that when we were coming up with Ably and that was one of our goals but interesting that really hasn’t been something that most developers care about. What they care about is the perception, the experience that things are happening in realtime and, you know, again like if you’re using an Uber app, that one’s always a great example with everyone sort of experiencing that. You know, even if it’s two seconds behind that doesn’t matter right? You still keep the car driving up the road and you see it on the map. That 100 milliseconds isn’t going to make a difference. So it only really matters when you have multiple interfaces and there’s only a few scenarios where that matters. So actually for us really the realtime bit is about us saying we’re pushing data to you rather than you pulling data from us.

Joe: Yeah, so that push – well that kind of request response model and I know in the years of old, having got involved in developing various apps that it’s always one of the biggest problems is how frequently can it be polled certainly because if you’ve got a lot of clients connected to that it, becomes a real headache.

It’s that – in simpleton terms – but is that kind of an easy way of thinking about the way you address that you’re removing the need to have the constant polling.

Matt: Yes I mean in short yes, it’s slightly more complicated, than that but yes.

I mean so realtime really – I suppose the first pioneers and I’m again, I’m talking about realtime web technologies and web technologies for me covers most mobile technologies and even increasingly kind of moving to the IOT space, you know. We’re still primarily using web technology so ACTP and stuff like that.

And so, you know, the sort of first pioneers really were Gmail and they sort of – we used to use Yahoo mail or Hotmail back in the day, which I’m sure you’ll remember. And you had to refresh your page to get the update and then Gmail came up with this trick data which was very clever – I’m not sure they were actually the first ones to do this trick – but it was this concept called ‘long polling’. So you’d send an ATP request normally and the server will do whatever it needs to do and respond. And a browser would accommodate a slow connection because you might see a really poor connection so you send your request. It might take 20 seconds to get you response but the browsers were designed to sort of cope with those conditions. So what Google did with Gmail was very clever as they they would send the request but instead of responding the server would just wait and wait until there would be something to be notified, and then it would send a notification. And there would be a limit , if you don’t have to say, you know 2 minutes, if don’t have time or there’s nothing to send in those two minutes, you would close the connection and the the browser would go to a new connection and would wait again.

And so that was a trick to sort of introduce realtime and that’s, for us, that was sort of one of those, I suppose, first milestones in terms of people starting to expect things to be done in realtime.

Joe: Interesting. Now I mean, Uber’s one which I think –  it’s very visual I mean you can see your car driving, what other examples have you seen recently which you think just wouldn’t work without realtime?

Matt: Yeah I mean to be honest, thing that our platform primarily is being used for right now is solving… there’s three different areas, The first one is server to device so that typically is something like a – you might want to send someone a notification when someone’s purchased an item or you’re doing eBay and someone’s bid on your item, so you’re get a realtime updates but the server, you know the customer needs… the business has some information they want to relay to a customer…

Joe: Yes.

Matt: … and that’s the service device model. And that’s arguably the most popular model right now and where our competitors have been operating in primarily because it was taking what Gmail was doing and offering it as a service.

Joe: Yes, is that device often mobile? Is it often a mobile thing or…

Matt: Increasingly so, I mean and that’s just the trend, increasingly so. I’d say right now for us it’s about 50% everything else and 50% mobile.

Joe: OK, well presumably you don’t really care what the end device is?

Matt: No, it doesn’t matter. And then you’ve got the device to server model which is less common because you know typically if a device needs to send a notification it would just send an ACP request so the old ACP model works very well. There’s a lot of reason why that’s not necessarily a good model because,  if you’re building let’s say a chat app you might want – you know if we were talking – you might want you to be able to receive that message immediately but also the server to receive a message and store it. And so that’s why people sort of use the device server and then you’ve got the device to device model which again goes back to chat. so in terms of like use cases, I mean it really varies immensely. We’ve  got e-learning platforms, we’ve got games, we’ve got a lot of logistics companies, obviously a lot of chat. So you know we actually quite a low level platform so we’re sort of more targeted at providing a quite low down in the tech stack so although we actually have a lot of chat driven through us, it tends to be developers who are building chat platforms will use us as sort of you know the lower level stuff.

Joe: Yes, I mean it’s probably worth talking about how you market yourselves to that, that audience is quite an interesting challenge. So chats run device to device, that strikes me as the most obvious thing but all businesses rely on data and there’s a constant appetite and thirst to speed things up and that’s why it’s interesting to speak to you as it sounds fairly obvious that this is needed.

Matt: Yeah well…no go on sorry…

Joe: No, I mean so you know what I guess what was the stimulus to start Ably  four years ago and what challenges have you had along the way?

Matt: So the thing that drove me – I’ve been an engineer my whole life and I was building app that needed to have a collaborative element so, sort of like the Google Docs type application and I looked at some open source solutions I looked at sort of building my own realtime element and then also look at the, you know, the main competitors out there at the time.

Joe: Yes.

Matt: And what I found mostly was that – kind of getting back to the Google Gmail thing – that the platforms that were built and, you know, rightly so at the time were trying to solve the problem of how you get notifications to your device but there was an element of well, if you lose a bit of data on the way that doesn’t really matter because it’s a notification. A bit like, again, going back to Uber is always a good example, if you miss a location on the driver you just get the next one so it doesn’t matter. And there’s a certain class of application where the order of the messages does matter and the fact that, you know, the bit of data that does get lost does matter and so that was the problem we aimed to solve.

So kind of going back to the certain Google Docs like problem there you can’t have a bit of data getting lost because everyone needs to have the same view at the same time. So it’s mission critical, and you can argue that a lot of applications are mission critical but our belief in the long term is that, you know, for realtime data – for people to be using these sorts of platforms – it needs to be as reliable as something like a TCP/IP sort of protocol. You don’t – no one questions if the internet, the underlying protocol works; it has a binary response it either works or doesn’t work. And that was the principle when we designed Ably was we wanted a platform the developers could use that says it either works or it doesn’t work, and if  doesn’t work it’s a bit like TCP/IP you might lose your internet connection, well that happens, but as long as you know that it’s happening you can deal with a situation. And there were a lot of sort of conveniences I suppose to make things easier for them, like mobile devices there are typically a lot of changing network conditions you might connect to Wi-Fi network and then as you leave the Wi-Fi network you go to 4G. Now what would happen with a lot of existing platforms is that your connection gets disconnected and then you re-establish a new connection. Now in that time that you disconnected and reconnected, stuff might have happened and we guarantee that you will replay what happens so as a developer you don’t care if the connection’s changed conditions. Or if you know maybe you’ve been disconnected for too long, then we would notify you and say ‘you’ve now lost messages because it’s been too long’. And so you now need to deal with that as a developer.

Joe: Yes, so is that probably your biggest challenge? Dealing with all eventualities and building walls to deal with that?

Matt: I think the biggest challenge for us is being… maybe setting our goal a bit high in that we wanted to achieve everything all at once.

Joe: Perfection? *laughs*

Matt: Yes! *laughs* And it’s a bit like with the databases, you have the sort of CAP theorem and the idea is you can’t have all three you’ve got to have two of the three principles and one of them you’ve got to sacrifice. And I suppose it’s a bit like Agile as well – fixed costs, fixed price, and fixed scope. Well, you can have two of the three things and it was a bit like that we sort of – we kind of set up… so we wanted a complete distribution system. We want to store your data in such a way that you can never lose data even if there’s crashes or network partitioning, and you want to provide continuity. And we wanted to provide all these guarantees yet we wanted a distributing system and distributing systems by their very nature have complexity and problems we can’t guarantee the two bits talking to each other.

And so, you know, it took us three years to build this platform because I think we bit off more we than we could chew, really. But we fought through, and we got there and we sort of stuck with our principles. And we wanted to sell this as a distributed in elastic scalable system and we did do that. But you know, what that now sort of allowing us to do is really move into a space where our competitors can’t move into, you know, if you’re a business and you want to share realtime data with another business again, you know, you need to say – you need to know that your data will be delivered and you need to know it will be in the right order. And there’s nothing missing. So, if you’re working with notifications, you could sort of work with the existing way things are done but now actually the space we’re working in with a lot of these customers, that qualities is all that really matters and that gives us a strong base.

Joe: You can’t really get it wrong. I mean there’s parallels with a client of ours in the States who use fax. Now fax you may think is archaic and dead, but it’s actually very secure because it’s true point to point connection –  but riddles with complexity with all different telcos getting in the way. It’s that ability to deal with every possible eventuality of things going wrong…

Matt: Exactly, I mean I’d say 95 – hang on that’s a bit of a random number – let’s, let’s say 80/20 rule! 80% is dealing with educators, 20% is dealing with the common stuff but the common stuff is the easy stuff to do and you know if we had to build – we’ve even talked about providing an open-source version of our service that just runs on a single server and that would just be quite a small task because you don’t have to deal with all these educators, but the educators are where we really spend all of our time and are the things that really differentiate us.

Joe: Yes, so the three years you were getting to point where you were ready to go to market, was that longer than planned?

Matt: Only two years longer! *laughs*

Joe: *laughs* Mild! So thinking about marketing Ably, your clients are actually other development agencies and other techies. That introduces some interesting challenges in terms of marketing to that audience. What have you found does work, what have you found more challenging and interesting about the experiences of getting the name out there?

Matt: I mean it’s quite handy that, you know, I am a developer myself and sort of understand… I’ve tended to be quite commercial as well so I feel like I can generally sit in both camps a bit but developers don’t… they don’t want to be sold to…

Joe: Yeah.

Matt: … they want to feel like they’re making all the decisions themselves. And they enjoy the discovery they enjoy learning new technologies and so you have to understand that. You can’t force something down their throat and you know there is an argument to say you could do the deal and a company might level and force it down you know sort of, I suppose, I imagine how you know bigger organisations buy in big CRM systems and stuff like that, it won’t just get sold you have to use it. I don’t think developers work like that there’s – you know, we find often we’ll talk to a CEO he’ll go, ‘this looks fantastic.’ The first thing they do is give it to one of the developers and say, ‘give it a go and tell us what you think’. And that person matters that – just the junior developer will come back and say ‘well, actually I preferred Ably because of these reasons and that really mattered’. So I think the old, sort of, forcing technology choices on your team is not going to gel anymore.

And so that has presented us with challenges because if we overtly advertise and try and you know approach these developers that has the opposite effect. They sort of see us as being too pushy. I’ve tried a few different approaches and I’ve had a few emails back, you know, pretty harsh emails going ‘well I was thinking of using you guys, but now you’ve done this approach I don’t want to work with you’. So I mean it’s been a nice educational experience so that, you know, the way we win them over is really around good content. They’re interested in reading about challenges you’ve done or how we’re solving things differently or the types of challenges we think they’ll have. And, you know, we’ve taken a slightly different view that you can go with tutorial content and – like a lot of developers, early developers will say I need to know how to build a counter, like a live counter app or build a little chat app. And that kind of was… at the beginning we thought we’d do that but actually now our thinking is really more that there’s a lot of solutions to do really simple realtime data. But when you try to do it to scale and you’re trying to worry about quality of service it really matters to your business, that’s kind of where we come into play. And so our content really now is around sort of more technically challenging problems and architectural discussion and stuff that is quite stimulating for…

Joe: … for the right people.

Matt: For the right people, exactly.

Joe: I guess it’s building trust in that you genuinely know what you’re talking about. You know, it’s not the day one tutorials, it’s the libraries of code it’s the confidence in…you know, it’s like taking down your trousers and saying ‘look, here it is use it, try it’ and that works for that audience.

Matt: Yeah I mean we have you know so now going back to what we’re saying that actually the CTO can be won over but actually he still won’t make the decision without the support of his developers, we’ve had to be very careful because someone can sign up with a Gmail account and then contact us on our chat. And you think, why are we spending time supporting someone… spending all this time we get after someone who may not even – because we’ve got a freemium model, right? So it might even just been a free customer. But we’ve often found that, you know, that person happens to work for a larger organisation…

Joe: Yes.

Matt: … and they’re doing a sort of experiment. So, it’s nice because it means every single person who visits the website counts.

Joe: Every person matters.

For us it’s about the developer experience so a good API, good set of code libraries, good documentation, nice tutorials, nice dashboard; just sort of everything, it’s the whole lot. And it’s not really digital marketing, it’s conversion optimization or along those lines, or customer experience.

Joe: Yeah, so you’ve got the freemium models and most people just as you say try it, get their head around it and see if it’s fit for purpose and then hopefully you know come to use it more and become more reliant on it…

Matt: Exactly that, and then we operate a sort of self-service model which I would argue is closer to – more akin to something like AWS: you sign up, you choose the resources you want, the number of devices and number of messages and then you just use it –  and that’s it. And then we’ve got more of an enterprise model which, we obviously want our customers to go down, but it really tends to be driven by the customer. The customer says, ‘I’m now integrating this and it’s now forming a really key part of my business I want to know that I can pick up the phone and talk to these guys I want to know there’s an engineer I can chat to if I’ve got a problem’. So it’s nice, it’s driven mainly by customers wanting to be an enterprise customer rather than us forcing that on them.

Joe: Yes, well I guess even those enterprise customers, even within the bigger organisations it’ll still be the tech team. So again they don’t need layers of fluff – the fluffy, nice offices and nice people they need genuine support. So if your promise is ‘this is good, it’s robust, it’s good for mission critical data transfers’ you can be trusted so that’s probably the most important thing for you.

Matt: I mean just to say, one of the things that has been challenging and also really sort of encouraging that, you know I think possibly 5% of our customers are in the UK.

Joe: Oh right, OK.

Matt: So our customers really are truly global we’ve got many customers in Asia quite a lot of traction Australia quite recently, obviously throughout Europe – Eastern Europe,  Western Europe – and then our biggest customers or most of our biggest customers are in the US. And developers are quite comfortable with that I mean, you know we don’t need to be in the same space same time zone we’re very… I mean I think there’s one customer we’ve gone to actually see.

Joe: Oh really, as small as that?

Matt: We do Skype calls occasionally, but that’s really a Skype call is just – they’ve already decided they want to work with us it’s really just reassurance helping them, a little assistance. So it’s a great business in that regard, it’s completely global. I mean it comes with its own challenges which is we have customers in every time zone who… their business period happens to be, you know, a time when we might be sleeping but we’re dealing with that; that is the challenge but that’s also fantastic.

Joe: So historically over the years you’ve had a pretty distributed team and during your development phase.

Matt: Yes.

Joe: I think it’s just modern times, businesses now operate that way and it works. It feels almost – asking about the future teams seems like a stupid question as  it seems like you almost are in the future now! Is there any sort of vision that you have that we could end on – sort of, not what’s next but where’s this going to go? You know, what’s the vision what’s the sort of ‘Matt’s Vision’?! *laughs*

Matt: *laughs* I think the thing that we’re banking on is… well there’s two principles we’re banking on. One is that, within the development community it’s – you know, developers love creating things and that’s you know, going back to the way we market to them – but equally developers realise that you don’t need to reinvent the wheel each time and, everything’s turned and people would rather buy in services than go and build something themselves. And so we’re riding that wave and that’s the thing that we’re saying, ‘you know you could do this realtime internally there’s plenty of open-source solutions, but it’s a problem you don’t want to worry about and it’s a problem we worry about all the time and do a very good job at.’

So we’re banking on that. But in terms of sort of the thing where we think the future is that consumers just expect real time experiences. And that’s just going to be – right now it’s an Uber app but it might be your banking you might just expect that as a transaction comes in it happens in realtime, you know? Even if you’ve just ordered a parcel you want to be able to see where it is – I think just generally consumers just – it’s going to be odd when you say ‘oh, that’s an hour behind’ or ‘oh no that’s not up to date’. I think that’s just going to be a bad thing so,  I think – it’s just going to be the expectation of consumers.

Joe: I agree.

Matt: And I think what then is going to follow from that is that there’s a whole bunch of secondary order problems to do with realtime which is, you know, how businesses share data in realtime.

So if you’re with Amazon, but you’re a logistics company and they’re actually using another company outsourcing, there’s going to be a supply chain for realtime data so that’s going to be a new problem that people have and the quality of service again and how they do that is paramount. And so, you know, right now we’re really operating in the sort of customers communicating with their customers’ devices. I think, you know, where things will change is people are going to start thinking well, how do we share data with each other in realtime? And so I feel like it’s just it’s a generic problem and they everybody’s just going to expect things to be done in realtime so I suppose we do often get compared to sort of being a content distribution network but a realtime content distribution network. But you know CDNs didn’t exist because they kind of weren’t needed but then people realised that why are we serving all our assets, you know, from our own service when we can distribute this work out?

And we believe it’s going to be a similar problem with people saying ‘well, why are we solving these real problems when there are platforms that will distribute work out for us so we don’t have to worry about that problem anymore?’ And so, I feel like that’s the direction things are going and there’s just going to be, you know, an increasing demand for realtime experiences.

Joe: Well we’re all very impatient. You know, well I’m going to track the drone as it brings my…

Matt: We do actually have a drone tracking company.

Joe: Oh really?

Matt: Yes, they do air traffic control systems and so they broadcast out all the locations of all the drones in realtime.

Joe: So you can literally track you basket from the drone delivery as and when it happens?

Matt: Well you know you would be but…yeah! *laughs* Yes!

Joe: That would be nice. Lovely Matt, really appreciate your time, and wish you the very best with Ably, we’ll be watching with interest. Thank you very much. Hope you enjoyed that, thanks for watching. There’s a few more episodes planned with digital transformation coming up but, as always, if you’re interested in taking part, please get in touch. Thank you.