, , and are just how new application software is created now. With new applications, there is usually a between your front end and the request layer to the back end of a mobile application. However, after that, there is still a web circa-2007 request to the back end over a nice, fat, latent connection through several firewalls to some kind of application server and database.
What if … or ? If your mobile app or intranet is built in the classical way, you’re going down! Cue the 400 and 500 errors! If you’re just pushing spreadsheets around the office, then it doesn’t matter too much—take a load off. But if you’re a pharmacy serving a heart patient, say, or a pizza place delivering on Super Bowl Sunday, then a lot of people will care deeply.
Fortunately, some things are changing in the area of application resiliency and high availability, with new approaches available and new innovations on the horizon.
Toward resilient client applications
One approach to greater resiliency is to put an entire application server and database in every location (which many companies do). Another is to make the application and mobile application more resilient. This means it should be able to function—at least at a reduced service level—without the back-end database or application server.
For instance, pharmacy chains like CVS or Walgreens can detect drug interactions or overdose risks even if you purchase drugs at two different stores. If architected correctly, these in-store applications can run even if the network is down. In a “network down” situation, certain medications could not be dispensed but heart medication could be, though the pharmacist would be directed to give a more specific set of warnings regarding interactions and dosage.
This generally requires a localized database and some kind of edge sync gateway to the back-end database. You can’t just call remote APIs; you need to implement them on the front end as local proxies. To do this properly you should code in a “network broken” scenario first. This can be easier to do than you might think because you can write the mobile app without reference to the back end—at least initially. (Full disclosure: I work for Couchbase, which makes open source NoSQL database products including the .)
approach of old.
(examples include and ). An API gateway routes requests to the correct service and can even “compose” requests into one remote call. This also helps insulate the client from being exposed to your microservices.
The third protection is to use a (examples include and ). As services communicate with each other, failures can cascade. Moreover, duplicating the communication logic into each service is a waste. When a service mesh and API gateway are combined, and proper operations tools are deployed, it is easier to monitor, scale, and deploy services in large, complex, heavy-use applications.
Edge computing, edgeless computing, and fog computing
The most secure data is in your head. The second most secure, accessible, lowest latency data is encrypted in your palm. Today’s devices are a far cry from the DOS, Novell, Windows 3.11, Windows NT, Windows 2000, or Windows XP desktops you may or may not remember. Smartphones by default won’t take alien software that you downloaded from an unapproved source. Users are more likely to use a web app than install a desktop application. Many larger organizations make it difficult to install anything but their approved software. These aren’t dumb terminals, but they aren’t the user-managed chaos centers either.
and software allow your application to offload some of its data and computing requirements to a server that is geographically closer to your client or mobile application. Sometimes these use or small-scale, regional data centers. Research has shown that edge computing improves the performance and scale of applications deployed in the cloud.
holds the promise of supporting many more wireless devices on the network. Some see this as an opportunity for , a layer beyond the edge that provides compute, storage, and services to end users. Basically, rather than have some edge devices, you have a big regional cloud composed of smaller, distributed devices that are geographically closer.
Past this is the idea of . Our smartphones and other devices have become pretty capable themselves. Why not do something with all of that latent computing power distributed around the network? The technology isn’t there yet, and we still prefer centralized databases because they’re easier to manage. However, people see technologies such as blockchain and ask if we can’t securely distribute data, processing, and applications while finding a way to centrally manage them.
While not precisely the same thing, you can see early versions of this in how Apple and Google are using to distribute the training of shared machine learning models across smartphones. A future where not only but also the database may very well be upon us.
Copyright © 2020 IDG Communications, Inc.