Today’s world is inextricably linked with mobile applications. These can be smartphone based, but increasingly smartwatch based! This opens up a world of new customer interaction that revolves around the timely communication of relevant information. This could be driven by context, by location, by timeframe—a multitude of factors.
How do you ensure you can provide a reliable, scalable and powerful notification service across all mobile devices with minimum effort? This week Pivotal Labs’ Matt Smith is a guest on the podcast to discuss the PCF Mobile Push Service that helps with just that!
PLAY EPISODE
SHOW NOTES
- Subscribe to the feed
- Feedback: podcast@pivotal.io
- Links Referred to in the Show:
TRANSCRIPT
Speaker 1:
Welcome to the Pivotal Perspectives Podcast, the podcast at the intersection of Agile, Cloud, and Big Data. Stay tuned for new updates, technical deep dives, architecture discussions, and interviews. Now let’s join Pivotal’s Australian and New Zealand CTO, Simon Elisha for the Pivotal Perspectives Podcast.
Simon Elisha:
Hello everyone and welcome back to the podcast, fantastic to have you back, as always. Interview session this time, because we spoke a few episodes back with Farhan who looks after our mobile products and offerings on the Pivotal Cloud Foundry platform, and it sparked some thought process and some more detail around the various different components of those mobile offerings. So we’re very fortunate today to be joined by Matt Smith, who’s a product manager at Pivotal, and he’s going to help us talk about some of the push notification capabilities of the mobile services. Welcome to the podcast, Matt.
Matt Smith:
Thanks.
Simon Elisha:
Matt is over in Toronto today, so what’s happening in Toronto?
Matt Smith:
It’s a big office here, it’s really nice weather this time of year, long days, sun’s pretty good.
Simon Elisha:
Very nice, very nice indeed. It’s lovely working in an international context, because you get to see who’s doing what where, and what different parts of the world are like. I think something that’s certainly common to most parts of the world, is the increasing use of mobile devices of all kinds, be their phones and watches, and new and wonderful things that haven’t even been thought of yet. Matt, you look after the push notification service. I thought we’d start with some basics of why would a customer want to use a service on Pivotal Cloud Foundry rather than just building their own? I’ve played with API’s myself, they’re out there, the various different technologies on different platforms. Why would a customer want to build their own?
Matt Smith:
Building your own is something that used to happen more in the past, if you don’t want to use cloud service you would want to build your own, so we’re kind of unique in offering this, but when you build your own, there are a lot of downsides as well, you need to actually use the libraries to connect to the different services, like Apple’s APNS service or Google’s GCM service. There are a lot of ins and outs, things you need to take time to ramp up on, and you basically are reinventing things.
If you’re creating a multi-platform app, you have the exact same app, and you just want it to work the same way on iOS and Android and people to get the same notifications, you end up creating different back-end implementations to sort of talk to each one of those. That’s also a big problem.
Then you need to own the code. Once you’ve done it once, these things keep changing, the push notifications with the new Apple Watch support requires a change, for instance. For interactive notifications there’s more changes. It’s a really hot topic with wearables, it’s continuously changing so you have to try to keep up to date with all those changes.
Simon Elisha:
For sure, for sure. It can be challenging, we sort of think of push notifications as one thing, if you’re sitting there trying to write for Android, trying to write for iOS, trying to write for Windows, trying to write for Blackberry, suddenly you’ve multiplied your problem domain significantly. You need a whole bunch of expertise, and then you need to keep a cross all the changes, it’s kind of hard. Can you give us an indication, how long does it take to add push notifications to a mobile app at a high level? What are people doing to do that?
Matt Smith:
There’s a couple stages. The first thing is, for any given service you want to connect to, whether it’s Apple’s APNS or Google’s GCM, or Microsoft service, you need to get the right credentials to be able to actually push to those services. It takes a different amount of time for each vendor, you have to have your own developer account or sort of thing like that. Once you get all your credentials, with our service, for instance, we actually run a workshop where we train people in office how to do it. They set up an app from scratch, completely, and within the hour-long workshop they’re able to send and receive push notifications to their phone on the app that they just built. That’s all in one hour.
Simon Elisha:
Wow.
Matt Smith:
Getting the certificates and stuff, that varies per vendor. That’s one thing that’s really nice. Part of the ease of doing this is because we actually have multiple components, we don’t just have this backend cloud service, we also have SDK’s that you put on device. We have SDK’s for Android and iOS to make the process a lot smoother.
Simon Elisha:
SDK’s always speed things up. Let’s think about this in terms of some other services that people are familiar with, probably Urban Airship is the most well-known one, relatively speaking in the marketplace, but there are many. What does this service offer that you’re not going to get with an Urban Airship or other type of offer?
Matt Smith:
With Urban Airship, one of the differences is they’re a true SaaS offering, it’s one service, you have no idea where it’s run or how it’s run, whereas what we make, you put in your PCF environment, and it’s your own service. It’s kind of like having your own Urban Airship that you control. It gives you a few advantages, you actually own all the data, you can look at all the logs, you can control everything that’s happening, you can scale it up and down, you can make sure that you’re the number one priority and that you’re not having a noisy neighbor syndrome. Also, all of your apps can talk directly to your servers, so that’s all easy in the backend.
Simon Elisha:
That’s a lot more control and really managing that in-user experience in a more granular way than relying on someone else’s service.
Matt Smith:
Yeah. We’ve also had clients move to us because when they talk directly to Apple and Google they can send the notification a lot quicker, as well. That could be important. Where you use another service, they have a lot of other customers, and if it’s a live event, or something just happened, if there’s lots of people to send notifications about this same event, then you’re competing against them.
Simon Elisha:
For sure, for sure. What are the components of the push notification service? How’s it built, how’s it put together, what does it bring to the table?
Matt Smith:
The way we designed it, is there’s a few different components. There’s a backend component, and this has the API’s actually send and administer the notifications, and it scales up and down. Then we have administrative dashboards, you have a nice user interface to set up and configure all of your apps, be able to send notifications, fill out forms. Then we have a scheduler so that you can pre-schedule notifications and have them send out later. Then we also have an analytic server and that’s how we can actually see how many notifications were sent. We expose those analytics on the dashboard as well.
Simon Elisha:
Fantastic. Customers can see what’s happening to their notification as well as just knowing that they’re getting delivered.
Matt Smith:
Yeah.
Simon Elisha:
In terms of the platform, this runs on the Pivotal CF platform, that’s important from a scalability perspective I’m guessing. Tell me a little bit more about some of the nuances about running something like this on top of a platform like Cloud Foundry
Matt Smith:
We really get to leverage all the benefits of Cloud Foundry, so we want to make sure that our apps are up and running, we don’t have to go and design anything special for that. We know that we’re pushing CF apps, they’re going to stay up, if one dies it’s going to be restarted, that kind of thing. That’s part of the reason why we went and deployed microservices, so we can actually decouple the different things. With our backend server that actually handles the sending of large volumes of pushes very quickly, all we have to do is a simple scale trend to Pivotal Cloud Foundry, and then all of a sudden we can send a lot more.
Simon Elisha:
You’ve mentioned the magic word there, I’m waiting for an alarm or a ding-ding to go off, because at the moment, microservices is the magic code word, really is relevant in this case where you’re talking massively scalable and spiking activity that needs this kind of architecture. As much as you can tell us obviously, what were some of the decisions you’ve made in terms of where to draw the line of those particular marker services, which components were divided into their own domain?
Matt Smith:
There’s a few different things that we were considering. For instance, our different components some of them were developed at different times, so when we wanted to add a new piece of functionality and it didn’t relate to something that we already had, we were free to build it on separately. For instance, our scheduler is a Ruby server, and it can be done in a different language, really small, all on it’s own, using some nice things that are already available, so then we can set something up quickly, have it all self-contained, have a nice API with how it communicates with the rest of the overall service. Other things we considered, the backend server really needed to scale to handle the performance load, the pipeline for sending the pushes was really able to handle a lot of volume, whereas the dashboard, we wouldn’t want to mix that with the UI for managing it, because we’re only expecting maybe one person at a time to be managing and building information for an app, so we’re actually delaying a push notification.
Simon Elisha: Excellent. So a lot of real thought went into that, and I guess the fact that you could rely upon the platform to look out for some of the heavy lifting meant that it was easy to just focus on the code development.
Matt Smith:
Oh yeah, and it also really helped us on how we, in turn, depend on other services. For instance we use our—our scheduler depends on our Redis service, so inside of Cloud Foundry it was very simple to provision and then bind to the service, and then it’s up and running and we know we can rely on that to be available to our services, and different of our microservices have different dependencies, a couple each.
Simon Elisha:
For sure. And obviously one of the highly touted benefits to the microservices architecture is the ability to do continuous deployment and move very quickly. How often are you guys able to release on your team?
Matt Smith:
On our team we actually target quarterly releases for features, we’re actually planning a 1.3 release later this month, so it will be our fourth quarterly release. In between we’ve had patch updates and some compatibility updates, so for instance a new version of Cloud Foundry’s available, we make sure we’re compatible with all the latest versions. So you have some dot releases, but every quarter we’ve been able to release new features. Being agile enough to do this, we do fixed timeline and variable scope. We might cut a little out of a feature to make it simpler, but it allows us to still be more agile and keep iterating, getting more customer feedback.
Simon Elisha:
For sure. So you like having that regular cadence, that customers can expect, and then really it’s the features and benefits that may vary slightly depending on how much work got done, eh?
Matt Smith:
Yes, and it also allows us to stay up-to-date with the latest. So for instance in this latest release, the interface for Apple, allowing to send notifications to Apple watches have been introduced. Since we’re releasing regularly, we know that we can catch these things within the quarter.
Simon Elisha:
Fantastic. And that’s really important in the lifecycle of mobile, which moves an order of magnitude faster than the server world, and really the web app world. It’s hard to keep up-to-date, so having something that evolves very quickly is important. You mentioned the Apple watch feature, what are some of the other recent features that have been added that would be of interest to people listening?
Matt Smith:
The really big feature in this next release is the availability of pushing based on location. You can actually target users in a certain geographical region, or you can have a bunch of preset locations and then have notifications trigger when they enter into those areas.
Simon Elisha:
That’s really interesting. How do you think customers are going to take advantage of this, because this adds a whole new dimension to the personalization of notifications, doesn’t it?
Matt Smith:
Yeah, we’ve seen clients of [Pivotal] Labs, previously when they’ve built these things, if it’s something in a retail customer base, they can send notifications that are in the vicinity of each of their retail outlets. Sometimes you might want to target high-value customers, and if they’re in the vicinity of the store you want to entice them to come in and maybe offer them a discount. If you have a show, you can send a notification to try to fill those last few seats. You can actually send to a much larger region and target at a country, or a province, something large like that, you don’t actually have to ask the users what country they’re from, or where they are, and you can still send them information that’s relevant to them.
Simon Elisha:
That’s fantastic. So really you’re adjusting that experience to the customer, we talk about that often. With modern applications, we want to help tune the experience to the customer and give them the right amount of information that’s relevant to them, and also not bother them. It’s that fine line where if you send information to a customer that’s not relevant, that’s frustrating, but if you don’t send them information when it could have been relevant they get frustrated because they missed out, so we’re trying to find a happy middle ground.
Matt Smith:
That’s a very difficult thing to achieve.
Simon Elisha:
For sure, for sure. Obviously in your role you are always looking to the future, looking at what’s coming next. Can you give us a little sneak peak on what’s coming up on the road now?
Matt Smith:
One of the things in the immediate horizon is doing support for multi-tenancy, like when you have—like I said this was having your own Urban Airship installed on your own PCF environment; right now it’s like that but for one client. So if you’re a large organization and want to have lots of different teams that don’t have to know each other’s business, or different kind of client-based apps instead of internal apps, we’re going to allow you to be able to separate them out. Also we’re constantly looking at what is the latest thing, and with Apple watch here, although we have support for it in this release, we’re looking for how to enrich that, and enrich connections with your other [backend] services. Basically, trying to solve, trying to take a stab at getting closer to solve that problem. You want to be able to send them just the information they’re looking for, that would be hopefully coming from different things in your system, so connections, your backend, and then targeting just when they need it, so that’s on the watch, small messages really.
Simon Elisha:
Fantastic. Some really important steps there, and if you’re a PCF user, then it would be worth going and grabbing the push notification service to see, to fix your environment, have a look at it, because that can make mobile development really easy.
Hey, Matt, thanks so much for joining us today, really great to have you talking to us from Toronto.
Matt Smith:
Thanks as well, it’s been great. Thank you.
Simon Elisha:
Awesome. So thanks everyone for listening, and look forward to speaking with you again soon. And until then, of course, keep on building.
Speaker 1:
Thanks for listening to the Pivotal Perspectives Podcast with Simon Elisha. We trust you’ve enjoyed it, and ask that you share it with other people who may also be interested. We’d love to hear your feedback, so please send in any comments or suggestions to podcast@pivotal.io. We look forward to having you join us next time on the Pivotal Perspectives Podcast.
About the Author
