And the first statistic that I'll show is this number, 51%. Some research has found that 51% of developers, as of the end of 2016, fall– and this is mobile developers– fall below what was termed the poverty line, where the poverty line is that their app makes $500 or less per month. So 51% of developers are falling into that bucket, and that's a lot of developers, and that's a lot of apps. And once upon a time, there felt like there was a gold rush for building mobile apps, that you could build anything, you could put it in the App Store, you could put it in the Play Store, and you could do really, really well. But as of 2016, the majority, 51%, are not doing so well. 29% of developers are above the successful line, the highly successful line, of making– excuse me– making $5,000 or more per month off of their applications. So that's a pretty good number, 29%. I know I'd rather be in that bucket than in the 51%. So what we've been doing is we've been doing a lot of research into what makes a successful application, what allows an application to be– what allows an application developer to be successful, and what are some of the habits that they have.
So breaking down those numbers a little bit further gives this bar chart. Now earlier, I mentioned 51% are below the poverty line. But the vast majority of them, that big bar on the left, are way below the poverty line. They're making less than $100 per month. So it's about 39% are on that. About 12% are between $100 to $500. But then, there's this small bar over on the right. And these are the folks who are making $25k or more per month off of their applications. Now, what do they do that I don't do? What do they do that the rest of the folks here don't do? What are some of their habits? You know, one of them that we took a look at is that 88%– whoops– 88% of them are targeting three platforms. They're targeting Android, iOS, and mobile web. So the vast majority of the ones who are extremely successful are going beyond a single platform. So like, it would be point of advice number one that, if you're building something, don't focus on a single platform.
88% of the folks on the right-hand side of this diagram did not. They focused on Android, iOS, and the web. And as a result, they're in the $25k-plus club. There's a lot of other things that they do. So first of all, for example, outsourcing– a lot of the logic that you would normally have to build and roll for yourself, for example, authentication– it's really, really difficult to build a secure authentication system. It's even more difficult for you to maintain that, because it's a constantly moving target. There are new vulnerabilities being found all the time. And if you build something and roll it yourself, you are beholden to your developers and your SREs to be able to maintain that while it's under attack, whereas the highly successful folks have moved more into a federated identity. So you've probably seen, most apps nowadays allow you to sign in with Facebook, or sign in with Google, or sign in with Twitter, GitHub, and other providers. So having that ability to be able to offload all of the work of building and maintaining a security infrastructure is something that would then allow them– if you were at the keynote yesterday, one of the most poignant things that I remember hearing was when Eric Schmidt was talking about, you know, the most difficult thing to do is to find the developers to do the job and to get your developers focused on doing a job.
But then also, one of the habits of the highly successful developers that we saw was that they had a programmatic, systematic way of growing their application. They didn't just build something, throw it into the App Store, do a marketing spend, and then sit back and wait. So being able to grow your application and have technologies in place– and I'll talk about them a little bit– that you can have to grow your application is very, very important. And that's the second of the pillars of Firebase. The third of the pillars of Firebase, of course, is being able to earn. There's two ways that you typically earn from an app. Number one is you charge for it, or number two is you put advertising in it. And as a result, in Firebase, we've brought the mobile advertising APIs from Google into Firebase to make it really, really, super easy for you to be able to build these apps, for you to be able to grow these apps, and for you to be able to earn money from your apps and sites.
And then finally, we bring that all together with Analytics. The other habit of the highly successful developers was they know what their users are doing. They're not just throwing apps into a store and hoping for the best. They know what their users are doing. They're adapting to what their users' requirements are and the users' needs are on the fly. And all of that can be driven off of Analytics. So importantly, and one of the things that we're announcing at Cloud Next, is that we're trying to bring the ease of use of Firebase together with the full range of Google Platform, Google Cloud Platform, services. So if you're building mobile applications, we really think Firebase is a great offering for you to get started, for you to be able to maybe build everything that you need. But if you start needing the backend scalability of the Google Cloud Platform, then there is a path for you to get there. And a small side note is that scalability is something, to me, that's very important, because it's often miscommunicated.
Because when you say the word "scalability," you think being able to go big and being able to go big really quickly. And that's only half of the truth. The real power of the Google Cloud Platform is not just being able to scale up very quickly, it's also being able to scale back down very quickly and only pay for the compute capacity that you're using. And there's one example of this that I like to share. It was a project that I worked on when I first joined Google. And it was for a boy band, OK? And anybody heard of the boy band "One Direction?" Aah! And what they did was they put together this online event on YouTube for the release of a new album. And it was, like, a seven-hour livestream. And during this seven-hour livestream, every 10 minutes, the band would ask somebody to go over to an app, to a second screen application, and answer a question so that they could have the best– they could find out who were the best and who were the most knowledgeable "One Direction" fans.
So think about that in terms of scalability, right? You have a boy band with millions of fans and millions of people watching a stream and nobody looking at the app. And then the band says, go to the app. What happens? Millions of people go to the app. And your traffic goes from nothing to massive spike. And then the people answer the question. And what do they do? They close the app. So your traffic goes back down again. And if you think about this in terms of scalability and capacity planning, you know, typically, you would build something that maybe could handle this capacity and hope that the spike doesn't penetrate it. But you have nothing. You have a spike. You go down. You have nothing. You have a spike. You go down. But you're paying for all of this space below the capacity when you're not using it. And one of the really neat things about the Google Cloud Platform and about App Engine, which this was built on, was that the number of virtual machines that were used to manage the site followed this curve precisely.
So when we ended up finally shipping this thing and running it, it was massively used, had a huge amount of traffic. And I'm not allowed to share how much it costs to actually run the App Engine instances for this. But a few of us went out and had a couple of drinks afterwards. And I don't even drink, and the drinks bill was higher than the cloud bill. So if you manage scalability, and you scale up, and you scaled back down effectively– and that kind of scale that the Google Cloud Platform gives you is a very, very powerful tool. So coming back to Firebase, what we're doing is we're really bringing these two services together. We're bringing the ease of development and the ease of use of Firebase. But it's not a silo in between the two of these. You have a glide path from A to B if you need to get that backend logic and you need to build that kind of scale. So this is how we typically look at Firebase. And here's how we like to talk about it, the three pillars that I mentioned.
So there are services to help you develop your application– a realtime database, authentication, cloud messaging, storage, hosting, test lab, crash reporting, and functions. I'm going to talk about each of these in this talk in detail. And then there are the other pillars that we're not going to go into in a lot of detail in this talk. But if you have any questions about them, come see me afterwards. And that's notifications for growing your application through re-engaging your users. There's a remote configuration, which is a personal favorite of mine. And that's a way that you can store values, global values, for your application on a server and have them driven off of– have them driven off of Analytics. There's app indexing where users using the Google Search app on their phone, if they're searching for content that's in your app, they should be able to find your app. Because they've already made the choice to download and install your app instead of randomly discovering it at some point again in the future.
Dynamic links are really smart links that will allow user A to share content with user B. And even the content context can be taken through an install session. Now, that's a bit of a mouthful. So if I were to explain that, it's like– so for example, I really like to eat, and my wife really likes to cook. It's a great arrangement. And if she discovers some really interesting recipes online and she wants to send me these recipes– and then she'll find, OK, here's a recipe for X. And it's in this application. Why don't you take a look at it and see if it's something that you would like– well, what happens then? She would probably send me the recipe. And then I would go onto the Play Store on my phone. And then I search. You know, it's in Frank Puff's cooking application, so I start searching in Frank's cooking application. Frank's here in the front row, so I'm giving him a hard time. So I'd search Frank's cooking application. And then I find it.
And then I install it. And then that takes a few minutes. And then it finishes installing. And then I open it up. And what was the recipe again? So that's the idea of the dynamic links was that if you had sent me a dynamic link, then the context of that recipe would be maintained through my install session. So again, as an app developer, that's really useful for me, because it will help my app grow. Because when person A shares something with person B, person B gets the context throughout that entire session. And it makes for a better experience. App Invites is another one of these. It's like where friends help friends discover great apps. I have an awesome 16-year-old son. And what my awesome 16-year-old son spends way too much time doing is cruising the Play Store looking for great free games. And then when he finds the good free games, we will send them to me. And because he's kind of already curated them for me, I know they're going to be great. And if an app developer had built these games using App Invites, as soon as he hits the Share button, I'm going to be at the top of the list.
Because the intelligence behind this says that, hey, when you share, this guy, your dad, will take the game, and will install it, and will usually enjoy it. And of course, his mom's going to be at the bottom of the list, because she will always say stop playing games, stop playing too many games. And so all of these are tied together by Analytics, and you can earn off of them. But I want to focus on the left-hand side, the develop technologies. And so Analytics first– the idea behind Analytics is– I used to be a development manager. And I don't know if many of you have probably sat in one of these meetings where you've built an app, and you want to ship the application. And then your marketing people say, well, we want this set of analytics to see if our campaigns are working. And then the salespeople say, well, we want this set of analytics to see if, you know, we're meeting our goals, if we're hitting our commissions, if the right people are buying it. And the engineering people are saying, well, we want this set of analytics, because we want to see the performance of the application.
And we want to see if we've optimized everything that we need to optimize for the best user experience. And the CEO is probably saying, well, I want this set of analytics, because this part of the app was my pet project, and I want everybody to see this part of the app, and all of these things. And then you usually sit. And you have to compromise. And what's the usual compromise? You've got to do everything, right? And how many times have– have any of you ever sat in one of those meetings? Yeah, I see a few hands. And then you end up saying, hey, look, if I need to ship everything, we're not going to be able to ship the application on time. You know, I can't put all of these analytics in there, or we're not going to be able to ship. And it becomes ugly. And there's compromises and all those kinds of thing. So one of the nice things with Firebase Analytics is that all of the common event- and user-centric things that can happen in your application are collected for you behind the scenes for free– not just monetary free, but you don't write any code.
You link in the Analytics libraries. And all the possible things you could imagine, like opening this activity, closing that activity, those types of things– in-app purchases, all that type of stuff– is collected for you for free. So that's number one advantage. Number two advantage then, of course, is that you can use the analytics that you're gathering about your users to drive behavior in some of the other functions of Firebase. And I'll talk through that in just a moment. So here's an example that, last year, for Google I/O, a Googler built this Bingo Blast game. And he put the analytics into that. And we just collected a whole bunch of analytics from that without writing any code. And these are some of the things that we were able to tell from it. So I just grabbed this screenshot from it. So for example, the one that I always find much amusement from is the amount of in-app purchases there you can see. And so in this case, his Android application had 22,700 monthly actives.
And they spend $2,000. And his iOS users, he only had 5,000 of them, and they spent $3,000, all right? So there's the old urban legend that, you know, the iOS users spend more money. But well, here you go. Here was our analytics to prove this. And he was able to gather this kind of intel without spending a lot of time coding. Now, I mentioned there's a lot of– common events will be captured for you for free. You don't write any code for that. You're probably thinking, well, what about a thing that my app does that only my app does. Maybe I'm building a game, and I see that everybody quits the game after level 3 because the boss is too difficult to beat. So that's at least a feedback that I've gotten from my users. So you could build a custom analytic for that. And unfortunately, that does require writing a little bit of code. We can't predict all of that ahead of time for you. But we've made the APIs very, very easy so that you can write that code and build those kinds of analytics into it.
So on to the develop here. First of all is the realtime database. Now, the realtime database is a cloud-hosted NoSQL database. It's a very, very smart type of database so that you've got synchronization and conflict resolution. So if you think about it, we live in a multi-device world. Many of us have a phone, a tablet, maybe a smartwatch, a robot– you know, these kind of things that are going to be able to access our data. Now, if we are building an application that requires access to the data, or maybe on my phone, I'm going to change something, and I need to see that updated on my tablet, that's the idea of how the synchronization works and how the conflict resolution works within Firebase. This is all done for you behind the scenes. It's an event-driven database. So when something happens, if I make a change to a set of data, an event will fire. The application running on my other device will receive that event. And then it can synchronize its state to the data based on receiving that.
And most importantly, and sometimes overlooked, is that you access it directly from your app. So a lot of time, if you're writing an app or if you're building something, you generally have to build a back end. And you have to write a lot of code on the back end. And more often than not, you're simple CRUD, simple CRUD operations where you're reading, writing, updating, deleting data. And so you need to maintain a back end for that. And you need to build a back end for that. And you need a totally different set of skills for building a back end. And one of the nice things about the Firebase remote database– or the realtime database– is that this is just code that's running in your app. So you have the same code base. And the Backend as a Service of the Firebase realtime database manages all of that for you. So you've got that single code base, that single set of skills to make your life easier. Now earlier, I mentioned, of course, Firebase is working very closely with Cloud.
And if you do want to build a back end in Cloud and you want to get the scalability of that, or if you want to get the logic, the programming logic that, sometimes, you only do want to put on a back end, then of course, there are technologies to make them work together. And we'll be talking about them a little bit later in this presentation. But a clear use case for that that I always see is– and I used to work in the financial analytics, not to be confused with the analytics I spoke about earlier on. And a lot of financial companies, they have a set of analytics for a particular company that they can use to measure and get a temperature for that company. And that's their crown jewels. They're not going to distribute that in an application. They want to keep that on a back end. They want to keep that for themselves so that nobody else can see those analytics. And you know, that's a great use case for where you may want to put code on a back end, and not in Firebase, and not on the front end.
So you've got the option to be able to do both. But when you're building with the Firebase realtime database, you can do that from within your client app without needing that back end at all. And here's how synchronization works that I spoke about earlier on. You've got multiple devices. You've got one database. And the synchronization fans out between them because of how the database is built to be event-driven. And another really neat one is the fact that it has offline access. So if you are building an application and you are using Firebase, but you don't have connectivity at this moment in time, but you're writing to that Firebase, it will get cached. And then the next time you come online and you reconnect, then the data can be synchronized between them. So I was doing a talk earlier on today about geolocation. And I used this little guy to demo geolocation. And one of the questions that I always get, if you doing geolocation and you're storing it in Firebase, what happens when you go into a tunnel, right?
And then you can't dial home. And you can't store your location. And you can't get these details. And that's where something like Firebase is a really good solution for that. Because you're getting your geolocation information. You're storing it. You're not connected. You come out of the tunnel. You get reconnected. And the data can get re-synchronized. So then, there's authentication. User management and authentication, of course, is really important. If you want any kind of custom experience in your app for your end user, even if it's just a high score table in a game or something along those lines, you need to be able to identify your user. And your user wants to know that their identity details are secure. They don't want to be able to give tons of information to you that you may not need. I mean, do they need your social security number enable to generate a high score table? Probably not. And so– maybe they do. There might be hash in there.
I don't know. So the idea is that, with authentication, we offer, in Firebase Auth, a number of different federated identity providers– Facebook, Twitter, GitHub, and of course, Google. And so if you want your user to be able to sign in with them, then you can almost effortlessly implement that in your application. The user signs in, for example, with their Twitter account. Twitter sends back a token saying that, yes, this is the user Bob Smith or whatever. So then you can customize your application to them. And then you, as a business, are not gathering any information from that user, which is very user-friendly. Because how many times do you want to fill out a form saying, this is my name, this is my password, this is my address, as an end user, when you already have a Twitter account, or a Facebook account, or a Google account, or something like that– so again, to make it very, very user-friendly. But of course, if you want to be able to identify users yourself and not federate out to them, then there's the email and password authentication built in to the Firebase Auth where you would gather their username and their password that they want to use to sign in to your application.
And then Firebase stores that. And then they can sign in with Firebase. But there's also a really neat thing called– we have an open source library for Firebase Auth for handling user flows. Because if you think about it, it can get really, really complex. You open up an application, and you want to sign in to the application. What happens next? Maybe you want to sign in with a Google account. Well, there are many of you who have more than one Google account. Which one are you going to sign in with, right? And so, OK– or maybe you want to– you don't have a Google account, and you need to sign up for a Google account in order to be able to sign in with the application. So how do you handle all of that, or the same for Twitter and others like that? So there's all of these very complex flows that a user needs to go through to be able to sign in to your application or sign up for your application. So we've open-sourced the library where we've put years of research into optimizing these, particularly for Google IDs.
And there's an open source library for Firebase Auth– it's on GitHub– that you'll be able to do. And you can drop that into your application. And then all of those potential have been implemented for you. And again, thinking of the habits of the highly successful developers that you're not writing all of this code for yourself. You're being able to take upon what we've done, the work that we've done and that we've open-sourced, to make life a whole lot easier for your uses. Cloud Storage for Firebase– if you're building an application that needs to store files, then Cloud Storage is really handy for you. Maybe it's a social media application, and you need to store user pictures, or videos, of those kind of things. Instead of building your own infrastructure for hosting files and then thinking of all the complex use cases, edge caching for people around the world, or what happens if you're storing a large file, and then the person's downloading it, and their connection breaks, as can happen with mobile, as you walk between access points and access point, all of these kind of things– all of this kind of logic was built.
I think, Eric, again, yesterday, in the keynote, said, hey, we spent $30 billion on building this infrastructure. Why should you build it for yourself? And this is one of the benefits of that Cloud infrastructure is that the Cloud Storage for Firebase is built upon that. So one of the benefits of that is like, you get disconnected– what happens? So 2 gigabyte file, you get disconnected after 1.9 gigabytes– do you want to start downloading again? No. So there are APIs for that. There are Cloud APIs for that. So you could have that kind of file management built in your Firebase applications, built in for you. One of my personal favorites– and I geek out over this one a lot– is Firebase Cloud Messaging. So as of– I think it was– November last year, we announced that we send over 1 trillion messages using Firebase Cloud Messaging every week. And the vast majority of those messages are received by connected devices in less than 500 milliseconds. So there's a massive infrastructure there that you can use to send realtime or near realtime messages for your users, and it doesn't cost a dime.
It's completely free of charge. It works cross-platform. So it works on iOS. It works on the web. It works on Android. And this is something that you can use to drive user interaction. Like, one partner that we spoke with, it's a company that does notifications for people that use public transport. And so this is kind of handy where, like if you live in a city, and you rely on public transport, and there are delays in the public transport, then you can get notified by this application that such and such a line is closed down today or such and such a line is on a half hour delay. But if you don't live in that city and you still use the app, you don't want to receive those notifications. So there's intelligence in the messaging platform. So notifications can be sent for things such as topics. So for example, if I live in London and I'm interested in the London Underground, or if I live in New York and I'm interested in the New York subway, I should only be receiving notifications about London if I live in London and only receive notifications about New York if I live there.
So there's that versatile messaging– sorry, that versatile way of targeting your messages so that the right users get the message. And like I said, for connected applications, it's usually less than 500 milliseconds. And it's getting bigger, and bigger, and bigger all the time. And it's pretty cool. And it's totally free of charge. Remote Config I spoke a little bit about earlier on. I find it really cool, because it's server-side variables that you can modify without redeploying your application. And they're integrated with Analytics. Let me give an example. Say you build an application that's an e-commerce application. And as part of this, you provide a standard discount to all of your users. So for the majority of your users, the standard discount might be 0%. But some people– like, maybe you want to grow the application in Canada. So you say, hey, for people in Canada, we're going to give a discount of 10%. And then, say you realize that people who make three purchases in the app tend to make a lot more after their third one.
So people who have made three purchases in the app, we're going to give them a 15% discount. And then, let's just say, OK, women tend to shop more in this app than men do. So let's give women a 20% discount in this app. Now, think of all that logic. Think of all that if this, then that, if this, then that. And then you suddenly realize that you don't want to give the Canadians that discount anymore. You want to change it, all right? So what do you do? Do you ship a new app, and you do all the if this, then that, and you do all the testing? You could do that, but that's a lot of work. With something like Remote Config tied with Analytics, then each of those conditions that I spoke about can generate an audience. And then for that audience, you can set the value to be a certain amount. For the Canadians, it could be 10%, for women, 20%, those kind of things. And then when your app reads the variable off of Remote Config, because it's driven by Analytics, your app can just get that variable and then can execute on that right away.
And if you need to change that variable, you change it in one place on the server without reshipping your application. So it opens up really, really cool, really interesting scenarios, particularly when it's tied to Analytics, for some good, fun stuff that you can do with your applications. Another one, Test Lab for Android, is– OK, I'll do a quick survey. How many people here have a Pixel XL? Oh wow, three? OK. I usually ask that, and there's none. OK, so for those of you who don't have a Pixel XL, how do you test your applications if you're building them for a Pixel XL, right? The vast majority of the– maybe 200 people in the room. So 97% and a– 98.5% of us don't have a Pixel XL. How do we test for that? Or what if you live in a country where the Pixel XL isn't available or particular devices aren't available? Like maybe you live in– maybe you build– you're a Chinese developer, but you're building for the American market, and you don't have access to American phones, or vice versa.
What if they aren't available to you? What do you do? Do you create this huge farm of devices so you can test them? So again, one of the habits of the highly successful developers is being able to test on a variety of devices. But it's really difficult to send people on a plane to other parts of the world to buy devices that aren't available to you. So Test Lab for Android is where we have created a suite of both virtual and physical machines so that you, as an Android developer, can upload your APK of your application. And you can have it tested by a suite of robo-tests that we've designed. Or you can design the actual test that you want to have done on it. And we'll send you back a report on how it performed. And we'll send you back screenshots and those kind of things. And there's one really fun, innovative use of this that I heard about that– has anybody here heard of Udacity? They're a training company. Yeah, cool– so quite a few of you. So for one of Udacity's certifications, they have an exam that they do for you to pass the certification.
And what they do is they give you an incomplete Android application. And you have to fix the bugs in the application. And you have to finish the application off. So when you do that, you upload the APK to them. They actually run it through Test Lab. So they've written a suite of robo-tests. So instead of a human looking at this application to say that Frank actually finished this activity, and he did it correctly, and this button works– you know, those kind of things– that they actually have a robo-test to do that for them. And to me, it a scenario that– I don't think we thought of that when we were building Test Lab, right? And it's just how people have innovated on it. I just find it's really fun, and it's really cool. Another one, Crash Reporting– the number one reason why you get bad reviews in an App Store or a Play Store is your app crashes, all right? App crashing is a bad thing. But how do you fix it? I have this scenario where there's an app that I was working on for a show in Korea last summer.
And before I went to Korea, I sent it to some people in Korea to test it. And it didn't work. And I'm like, OK, what does "it didn't work" mean? And they were like, it didn't work. So how can I fix that? I mean, what's the developer's usual answer? Works on my computer, you know? So it's like, how do I fix that? So with Crash Reporting, thankfully, when I migrated the application over to Firebase and used Firebase Crash Reporting, then I was able to basically get a detailed stack trace back every time it failed. And from the detailed stack trace, I was able to figure out why it was failing in Korea and it wasn't failing on my machine. And I was able to fix it before I went there. So when I was doing the demo, I was able to spend my time preparing for the demo instead of trying to fix a bug– you know, so those kind of things. And of course– and as you'll see, these three words, "integrated with Analytics," is built into almost anything.
So I wanted to come up with a gratuitous demo that shows, maybe this is an interesting thing that you can do with a static site. So if we can switch to my demo machine. OK, so as a hobby, I'm a CG artist. And I'm a writer. And for one of my books, when trying to sell it to a publisher, they asked me to say, hey, can you send us some visualizations of the characters, and maybe what the characters look like so we can get a feel for the scenario, we can get a feel for some of the things that are going on in the story. So I've been doing that, and I've been working with CG. So I thought, hmm, Firebase Hosting– maybe I can do something interesting. So the biggest possible image I can render was a 10,000 by 10,000 image. So that's 100 million pixels, all right? So those 100 million pixels, I stored them on Firebase Storage– sorry, on a Firebase Hosting site. And then the Firebase Hosting site is at this URL, seadragontestsfd 06e.firebaseapp.com. And I'm on the conference Wi-Fi.
I used a tool in Linux to slice this image. So my 100-megapixel image got sliced into about 8,000 tiles. With Firebase tools, I upload all those tiles in one shot. And I have a website to do something like this. So there's lots of really, really cool stuff that you can do with Firebase Hosting even though it's just still static hosting. Don't overlook it. I think it's really cool, the kind of things that you can do. All right, so can we switch back to the slides please? So today, we then announced Cloud Functions for Firebase. And anybody excited about Cloud Functions? Show of hands. Whoo. So we've been working really, really hard on this for a long time. And it's been, in many ways, the number one request. I mean, it's all very nice that we can store data in Firebase. But can we do something with it? Can we do analytics on it? If, then, an event changes– sorry, if a data item changes– from A to B, can we run some code in response to that? Can we send a message from Google Cloud Messaging when value reaches a certain amount?
All of these questions, that's what Cloud Functions are all about. So you'll be hearing a lot more about Cloud Functions today and later today. And I believe we have a code lab downstairs for it. Is that right, Frank? OK. We have a code lab for it in the code labs area. So you can go and play with it, and you can test with it. We've been so excited by this, but we've been holding our tongue for this event so that we can– you know, so you guys can go and you can really play with this. And to me. It's one of the things that really brings your ability to build with Firebase to the next level. When you start looking into these, it's pretty cool stuff. So that's like the quick whistlestop tour of what's available in Firebase. But like I've mentioned, it's really, really important to think about Firebase as part of Cloud overall. You know, Firebase is our platform for building mobile applications that work with Cloud. There are some other sessions here about Cloud that you might be interested in if you want to be a Cloud developer.
But talking about Cloud, some of the functions that are within Cloud, some of the aspects of Cloud that are available to you as a developer that, should you want to migrate to the next step beyond Firebase– one of those is Cloud Functions. Does it sound familiar? All right? So it's very similar to the Cloud Functions for Firebase. But this is Cloud Functions, which are lightweight, event-based microservices. Again, they're completely serverless. So if you are building stuff that runs in the cloud on the back end, if you're building stuff in App Engine, if you're building stuff that uses Pub/Sub, if you're building stuff that uses the Google virtual machines and Google Compute Engine, then you've got microservices that are event-based that you can start using to orchestrate these things to do interesting scenarios. And it's up to you to decide the scenarios for your application. But one of the nice things about them is automatic scaling. Remember, earlier on, when I mentioned the "One Direction" example, that that was really, really cool where you can scale up quickly.
And again, that has the automatic scaling. So you think about it as microinstances of VMs that don't have the capability of a full virtual machine and operating system, but they're programmable, which is what makes them microinstances. And as a result, you can create them quickly, and you can destroy them quickly. And then you get all the infrastructure benefits– Eric Schmidt $30 billion comment– you know, the infrastructure benefits like load balancing, health checking if you're running them constantly, being able to log their behavior. In the "One Direction" example, logging really, really helped us early on. Because we couldn't figure out why some of the things we were doing when we were testing were going wrong. And it turned out that we had some fans who were such superfans of the band that they figured out the URL of the site that we were hosting the quiz on. And they were trying to get in early. And they were breaking some of our tests and stuff like that.
And maybe we should have used the fourth bullet point for them, and that's security. Because your instances, your App Engine instances, are always secured. And of course, there's great developer support, like I said. There's a multitude of languages that it runs on. And they're pretty easy to develop for and build for. Compute Engine, then, is your ability to create a virtual machine and run that in the cloud. And then you can scale it out accordingly. One of the things I really enjoy doing is– you saw, my demo earlier on– is doing CG development. And sometimes if I'm going to render an image– like, that one wasn't photoreal. But sometimes when I want to render an image, a photoreal image, it can take 30 or 40 hours to render a big image. But if I spin up a virtual machine, upload my stuff to that, get that to start rendering, then I'm not tying up my home machines. And the machine that I usually use at home to render it on runs an operating system that's not on this silver machine.
And it tends to crash a lot. So I won't say its name. So I like to upload them to the cloud. And as a result, I can fire and forget. I can put them up there, render them, get an image back. So Compute Engine's really handy for things like that. You can have Windows in the cloud. You can have Linux in the cloud, those kind of things. As Urs mentioned this morning, how it charges, its minute-level. So you're not paying excessive money for capacity that you're not using. And as a result, it's very flexible. Container Engine– so I'll personally admit that I don't use containers a lot– or I didn't until recently. And one of the really nice things about Container is that if you're using full operating systems and you're running applications on full operating systems, you can have a lot of dependencies. And then, so if you try to build an application that runs on one machine, it doesn't necessarily run on another machine. So this little guy, this robot, he runs on a Raspberry Pi backplane.
And so there's some Python scripts on him that I use to turn him into an autonomous robot, and to do geolocation, and all that kind of stuff. But I have a Linux machine at home that I use for developing this stuff. And his Raspberry Pi board uses Linux. So I spent a lot of time writing code, testing code, doing geolocation, make sure things were working fine. And then I deployed it to the Linux on that guy, and it didn't work, OK? Because there's a thing in Linux called AWK. And the AWK flavor of the Linux that the Raspberry Pi runs was very different from AWK flavor on my desktop machine that I was using to develop. And I didn't know this. So I ended up having to rewrite half of my code to get it to work on this guy. And that's one of the things containers are really handy for. Like for me, it was, I have a development machine, and I have a single robot. But what if you have a cluster farm of a thousand servers, and then it turns out that those thousand servers, there's version drift between them?
There's different versions of, maybe, operating systems, or patches, and all that kind of stuff. And that's the goal behind containers, where the idea of a container is you can create a script for what an operating system's supposed to look like. And then you can spin up operating systems from that. You can spin up virtual machines with those operating systems. And then you can have that consistent set. For me, it was just a case of a single one. But I can't imagine what it would be like if I had had to make changes to handle with thousands of them. And that's what Container Engine's all about. It allows you to quickly set up these clusters. You can manage them declaratively. And that flexibility, if you need to make a change, you could maybe make a change to the entire cluster to bring in a new dependency that you didn't realize that you had previously needed. So these are some of the services that are available on Cloud. And you, as a mobile developer, can take advantage of all of these.
And the thing that ties them all together from the Cloud perspective is Cloud Endpoints. So Cloud Endpoints allow you to build an API that wraps your cloud services and then make that API accessible to your mobile applications. So if you're running stuff on App Engine, if you're running stuff on containers, if– you know, the Kubernetes engine, GKE, is what we use for managing containers. If you're running your stuff in that, then the idea is you can wrap them with an API that's callable from a mobile back end– or from a mobile application, sorry– so that then, these become your back end. So if you're not using Firebase for things like functions, but you're using Cloud for functions, or you're building logic that runs on App Engine, and you need to easily be able to call that from a mobile application, Cloud Endpoints are your friend. They're a choose your own framework kind of thing. So if you want to build in Java for Android, or if you're building in Objective-C or Swift for iOS, then you can call these guys.
And like they say, they provide that wrapping service for you to be able to build your mobile applications. So that's a quick tour of the things that you need to consider when building mobile applications, what we believe are the habits of highly successful mobile developers, why we've built Firebase the way that we've built it with the services that we have done so, and also, hopefully to show you that, if you're going down Firebase and you're going down the Firebase route, but you want to be able to move to something bigger and scalable and have logic on your back end, Cloud is available to you. And as an application developer in Firebase, you are also able to use that. So thank you very much. [APPLAUSE] And if we have any questions, we can take them at the mics. AUDIENCE: Hello, I have one question. Do you have any plans on expanding Firebase to over-the-top solutions? LAURENCE MORONEY: When you say over-the-top solutions– AUDIENCE: Apple TV, or Android TV, or Roku.
LAURENCE MORONEY: I mean, I can't comment on any specific plans. But Firebase, of course, has web-based interfaces. So with a web call, you can read and write to the database. Not all of the functions that I showed you have web. Like remote config doesn't yet have a web interface. But on the whole, you could make API calls in that way with web interfaces. AUDIENCE: All right. LAURENCE MORONEY: All right. AUDIENCE: Thanks LAURENCE MORONEY: Thanks AUDIENCE: Hi. You mentioned the Firebase Cloud Storage. LAURENCE MORONEY: Yep. AUDIENCE: Could you go into a little more detail on where those files actually live and what scopes are involved to access those? LAURENCE MORONEY: Sure. So to the best of my knowledge– I don't really dive down deep in them. But we have Google Cloud Storage. And Google Cloud Storage has data centers around the world and edge caches around the world. And they're stored there. AUDIENCE: OK. LAURENCE MORONEY: So when you're asking about scopes to access them, my understanding would be that the scope that you allow your user as a Firebase user is what would give them the permission token to be able to access them on the Cloud back end also.
So if you've got a million users of your application and you want all million users of your application to see one set of files, but a individual user only to see a different set of files, that's done using the Firebase Auth. And it works with the Cloud back end to be able to manage that. And I see Frank nodding, so I think I got it right. AUDIENCE: Great, thank you. LAURENCE MORONEY: He's my test. Over here. AUDIENCE: So currently, on Firebase, I see there is a small restriction, which is you can only log up to 500 events and only up to 25 user properties. And they are not even deletable. So do you have any plans to remove those restrictions? LAURENCE MORONEY: Sorry, which restrictions, specifically? I didn't hear. AUDIENCE: So for Analytics, you can log only up to 500 events. And for remote config– and for user properties, sorry– you can only have up to 25 of them. LAURENCE MORONEY: OK. AUDIENCE: So are there any plans to remove those? Because I feel like it's easy to hit those limits.
And especially with the user properties, you can't delete them as of now. LAURENCE MORONEY: Right. We're not allowed to speculate on future stuff, but we understand that that's a requirement. And it's one of the requirements that we're working on. And obviously, we have Google I/O coming up in a couple of months. And we're working on some new stuff for Firebase for that. So there may be some new announcements then, but I can't really speculate on a specific one. But understand that's it's a big requirement that we've received. And we're taking it seriously. AUDIENCE: Thanks. LAURENCE MORONEY: Thank you. AUDIENCE: Hey. I just wanted to ask you if Firebase has any plans of incorporating A/B testing. LAURENCE MORONEY: A/B testing? Absolutely, via remote config. So the remote config that I spoke about is perfect for A/B testing. So again, thinking about, it's a server-side variable that's driven by Analytics. So you could say, OK, let's set the variable to– I don't know– for the background color of the main activity.
That's going to be red for people in Canada and blue for people in the US. And then you can perform an A/B test like that. And then, using Analytics, you can also measure how people have interacted with it. AUDIENCE: How would we know which particular cohort– I mean, which particular, let's say, conversion corresponds to which particular cohort that's been set in remote config? LAURENCE MORONEY: So– I'm trying to think. So if you define an audience in Analytics and you specify that, again, just using the flippant example of the background color of an activity as an example, then you know that audience A has red and audience B has green. So then, when you are– you can set another analytic on the application that says, people who have a red background, are they doing favorable activity like spending time in the application, or doing in-app purchases on the application, or something like that. And then measure that. And you could correlate the two against each other. It's the only way I could think of right now to do something like that.
AUDIENCE: Yeah, I just wanted to figure out a way to connect both the things, so you know. LAURENCE MORONEY: You could connect it off of the remote config variable. Because you know that audience A has remote config variable red, and audience B has blue. So then you could say, OK, when I got red, who spent time in the application on red, or who did an in-app purchase on red. And then you could create a custom analytic for that and then measure that. So it's almost like the remote config variable is the integration point between the two audiences. AUDIENCE: OK, thank you. LAURENCE MORONEY: Thanks. Hi. AUDIENCE: Does the Test Lab– what testing does that do? I was looking for something that does application response time or performance testing. Does that test that as well? LAURENCE MORONEY: I'm not sure if it measures actual performance. I think, like for common things like the initial open, and initial close, and quit, I think it reports back the time to open and that kind of thing.
But then, in-app performance like moving from activity A to activity B, I don't think it does that out of the box. But you might be able to create a robo-test for that. AUDIENCE: OK. LAURENCE MORONEY: My recommendation would be– in the ask the experts area downstairs, there's a guy called Doug. And he's our Test Lab guru. He's the expert. And he's been spending a lot of time– guy with a little goatee beard. You can't miss him. And he'll probably be best able to answer that question. AUDIENCE: OK, thank you. LAURENCE MORONEY: All right, thanks. Time for one more? Nope, we're good? OK, so check out the code labs. Have a play with Firebase. And if you have any questions, come see me. Thank you. [APPLAUSE] [MUSIC PLAYING]
Building applications for mobile devices flips a number of traditional developer assumptions on their heads. In this video, Laurence Moroney explores the key considerations when building for mobile, and how the latest offerings from Firebase and Google Cloud Platform (GCP) can help you meet new challenges. He gets hands on with the tools you can use today to address topics like poor connectivity, serverless computing, data validation, and access control.
Missed the conference? Watch all the talks here: https://goo.gl/c1Vs3h
Watch more talks about Application Development here: https://goo.gl/YFgZpl