We live in an increasingly mobile world. Many of us spend an inordinate amount of time looking at our smartphones, posting updates, consuming content—and occasionally making phone calls!
As businesses work to compete in new domains and on new fronts—the mobile world has proven to be a key battleground. Banks work to out-do one another with capability and feature, established businesses seek to re-engage with their customers in the digital realm, and disruptive startups take a “mobile first” approach to their market.
Whilst a lot of focus is correctly placed on the look and feel of these mobile applications—thought must be given to the back-end supporting systems behind many of these applications. Most significant mobile applications have a need to connect to a back-end “system of record” of some kind, store data of some kind and provide live notifications to their users.
In many cases there are multiple systems to be accessed and multiple notification platforms to support (e.g., iOS, Android, Windows Phone, etc.)
This week Simon talks about the new Pivotal CF Mobile Services, how they work and what benefits they can provide organisations stepping into the mobile world.
PLAY EPISODE #6
RESOURCES:
- Subscribe to this feed
- Find more episodes of All Things Pivotal podcast
- Feedback: podcast@pivotal.io
- Links Referred to in the Show:
- Check out Pivotal’s advise on how to win in mobile app development quickly
- Learn more about Pivotal’s Mobile API Gateway and how it could help your development in this blog post
Transcript
Speaker 1:
Welcome to the All Things Pivotal podcast. The podcast at the intersection of agile, cloud and big data. Stay tuned for regular updates, technical deep dives, architecture discussions and interviews. Please share your feedback with us by e-mailing podcast@pivotal.io.
Simon Elisha:
Hello and welcome back to the All Things Pivotal podcast. Fantastic to have you back. This is episode number 6 and my name is Simon Elisha. I’m CTO and Senior Manager of Field Engineering here at Pivotal Australia and New Zealand. Coming to you this week from beautiful Melbourne, Australia, my hometown. Lots to talk about this week. We’re going to be focusing on mobile and the mobile experience and in particular a specific capability that we have within the portfolio that addresses that space. Let’s contextualize a little bit. Let’s talk about mobile.
It seems that most of us spend a lot of time looking at these little glowing rectangles in our hand, the windows to the internet, windows to the world, windows to our friends, etc., full of photos, updates, e-mails and occasionally we do make a phone call with them from time to time although it’s interesting, I have a few younger relatives and they spend an increasingly reduced amount of time, actually, using the phone as a phone. They like to use the apps instead which is really, really interesting.
There are over a billion smartphones out there and most people have them within arms reach. They typically have changed their own behavior and their consumption behavior to use various applications and methods of accessing services and products that they consume in daily life. A very common one is the banking use case. Clearly a lot of people have moved to doing, firstly, banking online and now banking in the mobile sense and the mobile experience is very different to that of the web experience. What we find is that people expect an even more immediate response. They expect a beautiful design, they expect a smooth experience because they can choose between a variety of different application providers from the application marketplace and they have expectations about what they think is good or the right approach. They want this very rich experience, they want a clean interface, they want it to be fast, they want it to move well.
What also comes into play here is the back end of all these systems. I could build a beautiful, functional, exquisite front end native application running in iOS or Android, etc., but if the system’s record that it needs to talk to in the back end, the systems that actually power and provide the information for the application, are inaccessible or not accessible correctly or not up to task then my overall experience will fail. One of the challenges is that a lot of those internal systems have not been built with mobile in mind. If you look at the behavior change of customers, a good example is a banking customer that said, ‘When it’s payday for certain members of their customer base people will check their account balance something like thirty times a day to see is the money in there yet, is my account updated, etc.’
Whereas you can imagine those systems were originally designed at a time where if you wanted to check your balance you may go into your branch and ask, ‘What’s my balance?’ You’d be told and you probably wouldn’t come back five minutes later and ask, ‘Hey, what’s my balance now?’ It would be a much slower process. The behavior mechanism and the way that we interact with systems is changing significantly. How do we go about addressing this? One of the areas to look at is the back end part of it. Again, often the unglamorous and unsexy part of mobile development. There’s no cool widgets, there’s no funky animations, etc. It kind of makes things work.
We recently released the Pivotal CF Mobile Suite. This is a suite of components that cover a lot of the back end capability you would need for your mobile app development. Predominantly, push notifications, an API gateway and data sync capability. Let’s dive into each one of those and see how they fit. Probably the most well understood or accessible one is the concept of push notifications. One of the amazingly useful features of most mobile applications is the ability to provide real-time push of messages and updates. This could be a notification specifically for you as the user, it could be a more generic notification that suits a pool of users or a set of users, etc. It’s a method by which people from an application do and a lot of prospective can communicate with the user base directly.
Again, common use cases, things like in banking. I may want to notify you if a withdrawal has happened on your account above a certain amount so that you can know, ‘Well, did I do that? Did somebody in my family do that? Was that some sort of nefarious activity?’ Logistics companies often use this to update their drivers on what’s going on in the environment, is there an accident they need to avoid, do they need to change their routing for example, is there a change to a delivery notification, etc. There are lots and lots of examples of how they can do this.
The challenge with notifications is really two-fold. One is that of volume, the need to scale up appropriately. The second one is the thing IT. Of course we can’t just have one standard. Oh no, we need multiple methods and multiple standards when it comes to delivering notifications to different platforms because if we just did one way that would be far too easy so we don’t want to do that. Let’s talk about scale. When you’re talking about mobile you’re talking about potentially very, very large numbers of messages required. For example, we have a customer for whom delivering twenty million notifications a minute is normal for them. You can imagine that’s a really large number of messages to be sent, there needs to be infrastructure to send that it needs to work effectively. Getting messages out there in an efficient and effective way that you can control becomes very important. You don’t want to be affected by noisy neighbors, you don’t want to be affected by constraints of resource, etc.
The push notification service runs on Pivotal CF. What this means is you get all the capability of Pivotal CF in terms of scalability, portability, the ability to run it within your own infrastructure if you’d like for that particular service so you can build and scale as appropriate when you need that push capacity. The other nice thing is it connects and manages the interface to things like Apple push notification service, Google Cloud messaging, the Microsoft push notification service and the Blackberry push service. We can address this diverse range of end points that we have to deal with for our native applications. We can be pushing from one location using one set of infrastructure to do massive message push to all the different application types and all the different services whilst lowering the amount of maintenance and management we need to do to make that happen.
Again, kind of like the heartbeat of how many of these mobile apps work is revolving around their mobile experience and that live notification service. Now I mentioned that one of the key things about a good mobile app is that it usually talks to other systems and many of those other systems live behind firewalls, they may be previous generation systems, they may be built in a different way, they may support different protocols, they may not be web enabled, they may not be scalable in a particular way. How do we protect against that? The API gateway is a capability that allows us to really shield and obstruct away those back end systems. It means we can have a very clean and efficient interface to those back end systems from our application, from our portable application and mobile application and then extract away some of the complexity of those back end systems.
Let’s talk about what this would like. I’ve actually got this layout that you can communicate to from your mobile application. Now, by talking to the API gateway you’re now talking to a location where you can implement centralized authentication. You may want to expose an API key style with interaction or other approaches to make sure people who are using the API are using it correctly and are validated. You can also reduce checkiness in terms of the communication required. If you’re making a call that may require data from multiple systems wouldn’t it be great if the API layout could make those calls on your behalf, mash all the information together and send it back in a reduced format? You’re sending less data every time, you’re making less calls.
For example, your application may need to talk to a customer management system and some sort of inventory system. You could have your application make one call to the customer management system and then one call to the inventory system and now respond, or you could say the application makes one API call that in turn makes those two calls in parallel and returns the information back to you. It becomes a very efficient design patent and reduces the checkiness of the connection so there’s less data going back and forth. You may also need to be converting existing applications and systems to new formats. You may have services that are risk based, but they may be soap based, they may be more generic than that, they may be using an enterprise service bus, a whole variety of things you might want to do. Using the gateway you can convert them all into that nice clean risk based interface that we’re very familiar with using in the web these days.
Now the element that we often forget is once we start to present APIs out to the general world and our application user base people can overuse them. I talked about people checking their account balance very regularly just before. Limiting becomes really, really important. You may want to limit the number of requests a client can make to a service in a sequential fashion so that you can avoid possible distributor denial of service or texts and you can also control access to any services that may be incurred or billed. Maybe you’re using a third party service, you’re abstracting, but every call that’s made costs you a small amount of money, you may want to gate how many times a call can be made.
How’s this all put together? The API gateway is a really great mechanism because it basically provides a Java 8 platform, including nashorn and a number of other components including things like SpringBoot, Tomcat, JD, etc. and the ability to write your conversion applications in Java Script. You basically code your transformation so that you’re integrating the front end and the back end in a really lightweight and simple way. I’ll actually link in the show, it’s a really great article that walks you through how you can write some of these applications and some of these transformations. It’s actually not very complicated. It makes it pretty straightforward.
Think of this layer as that extraction layer, the ability to take what you have behind the firewall essentially, or those traditional applications, wrapping them in a modern, effective API gateway and presenting that to the mobile applications that then consume those. Again, this all runs on Pivotal CF so you get the scalability, the portability and the power of that platform. The third and last component that we’ll talk about today is that of data sync. Again, we live in this Cloud based world and this mobile world. We have all our data flying around everywhere, but typically on most devices, even though they’re getting bigger these days in terms of the internal storage, typically we want to store data externally. That’s often the case when we’re using cross device type applications, say something works on my tablet and my phone and other platforms as well. We need the ability to store components or blobs of data somewhere.
This is where the data sync service comes into play. It allows you to provide Cloud based storage for your mobile data with authenticated access. This means you can easily authenticate access to the particular data set and store it resiliently and reliably. The back end effect uses MySQL and Redis for its configuration data and its data storage and there’s also an authentication and authorization layer that’s an implementation of the Open ID Connect protocol. What this allows you to do is to create a really neat location upon which the mobile application can easily connect using a risk based API. You define what those API end points are, you define how they look and you define how they can be consumed by mobile devices to store or retrieve data.
What this means is you have control over where the data resides. You can choose which particular Cloud it may reside on or if it’s in your own data centers, etc. You have complete control over accessing it, where it’s located, how it’s secured and where it resides which gives you immense control over what is often sensitive data sets. You’ll see many times people talk about these mobile apps that are collecting quite sensitive data or information that shouldn’t be released to other people, there may be privacy considerations, etc. Having control over this back end storage you have a greater degree of control that helps you meet security compliance and other regulatory requirements that may exist in your environment.
You can choose where information is stored, who has access to it and how they may get to it. That’s a bit of a summary of what’s going on in the mobile space from a back end perspective. Again, I want to emphasize, I’m talking about back end tools. These are things that are often behind the scenes, not thought about until the last minute. ‘Oh my God, how are we going to do all this notification to twenty million users?’ These are the components that may be less eye candy related components that are very important in building an application. Take a look at the Pivotal CF Mobile Suite, think about those components in your architecture that need to be accounted for when you’re building a mobile application, particularly a mobile application that will be used at scale.
I hope you’ve enjoyed this episode. Again, please get in touch with us. We’re getting some fantastic feedback from listeners. I’ve got a whole lot of really cool interviews coming up, as well as other interesting topics of conversation that people have wanted to ask. You can always reach us, podcast@pivotal.io. Please do tell others about the podcast, the new podcasts. We like to get the word out there as well. Until then, thank you very much for listening and keep on building.
Speaker 1:
Thanks for listening to the All Things Pivotal podcast. If you enjoyed it please share it with others. We love hearing your feedback so please send any comments or suggestions to podcast@pivotal.io.
About the Author
