Kicking off our occasional series (introduced last week) on understanding the complete enterprise mobile application lifecycle, we want to take a look behind the proverbial curtain and discuss backend systems. This way of thinking can be a serious paradigm shift — mobile devices are obviously praised for their connectivity and portability, but those are precisely the same traits that are redefining our very perception of IT.
Unlike desktops or workstations, mobile devices are with their users essentially 24-7. We’re also perceiving a worldwide resonance that’s creating new user expectations. The ubiquity of mobile apps means that requests are coming in from all over the world, and at all hours of the day.
The fact that mobile apps have spread so quickly, that there installation and use has such low-threshold ease for users, means you have to plan for horizontal scalability. What does this mean for building the backend? Mobile apps are so tight, so specified in terms of functionality that they can be considered stateless.
To think of it from the more traditional side of the spectrum, if you login to Amazon, there’s essentially an expectation of session-style interaction — something based on a baked-in familiarity with you as a user that enriches your experience with that platform. Amazon or Soap.com knows it’s you — you’re filling your shopping cart, you’re browsing merchandise that has been served up for your quick perusal based on your shopping history, etc. You’re a returning user continuing what’s probably a long-term relationship.
Now consider a mobile app trying to create that type of hyper-familiar experience. Would a shopping cart live in memory on the server or the device? Is a session mentality even necessary? Perhaps we can extract that information or even forgo the need to hold it in memory altogether. Perhaps, and this is even more likely, there’s no need because user expectation for an app doesn’t demand that level of familiarity.
You have to think through that. Is the shopping cart going to live in memory on the server? The device? Maybe we don’t need to have a session; we can extract that and make it stateless. We don’t hold it in memory. We just move on. You’ll use up resources because of the ubiquity of these mobile devices.
Similarly, consider large, suite-style platforms such as Microsoft Office. This would be impractical if not impossible to translate into an app. There are, however, individual functions that can and do function well as apps — word processing, email, calendar, chat, etc. — the very abilities a mobile user needs to perform well while on the move or in the field.
The point is that optimizing the app is what drives the development innovation. Trying to replicate a desktop or workstation experience is cumbersome and weighs down the advantages mobility is supposed to deliver, so why bother trying to re-create that?
Don’t think in those old-fashioned, tethered terms. Don’t worry about throwing more hardware at the problem. Remember, this is a stateless scenario, which doesn’t transfer well horizontally. You’ll use up memory because there are just too many mobile devices, and you’ll spend far too much energy trying to transfer memory contents to other machines.
That costs you the ability to easily scale, so let’s not be encumbered by monolithic systems. Let’s think about accessing stateless resources on an as-needed basis — likely via the cloud — which makes perfect sense when it comes to mobility. That translates to how the backend is built. You can have a notion of a session on the app, but the integration should be very discrete, with the understanding that it will not be long-lived.
Build your backend with that in mind, and your enterprise mobile app stays lightweight. It’s fast, easy to consume without drawing heavy demand on resources. It’s off to a strong, stateless start.
