Kubernetes, Docker, and microservices are just how new application software is created now. With new applications, there is usually a graph 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 Amazon bricks the Internet again... or someone else bricks AWS? 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 Sync Gateway.)
This isn’t just for mobile applications. Thick client applications (e.g., Java’s Swing or Microsoft’s WPF or UWP) can also use this technique. In the age of the web and mobile devices, thick clients still have their place. Think of your favorite pizza delivery chain. Each store clearly shouldn’t require a DBA on staff (though delivery driver/DBA has a certain appeal). Does Papa John’s or Pizza Hut really need an application server in every store just to run a web app?
However, some places can afford an app server at a remote location. Sometimes this might be a regional cloud zone even (though one could argue that the database should also be colocated and replicated). For various issues of latency, a cruise ship or remote lab might have an application server or even a database onboard. The same general principles apply, though you might use WAN replication instead of a sync gateway if there is a local database. You might also end up with batch jobs if phoning home to a cloud isn’t really an option.
Toward resilient server applications
It wasn’t too many years ago that I was a scalability and performance consultant. The first thing I would do is remove all of the remote calls to “localhost.” I did this slowly because when you’re billing $300 an hour it is important not to fix the problem in the first hour. The second thing was to switch any queries that hit a parent and lazy-loaded the children (n+1). The third thing was to fix the cache.
As architecture became more service-oriented and microservices-based, there came another class of problems—some services get utilized more unevenly than others. Quite often, the source of the thrashing is the database, though sometimes it is actually just the service by itself. Sometimes it is even an attack because when you build a beautiful and elaborate sandcastle on the beach, some kid always comes and kicks it over. Avoiding this requires a few layers of protection. Think of them as a fence, a moat, and some alligators. That’ll show the little —.
Another form of thrashing is the service version of the n+1 problem. If you’re doing lots of gets and puts against a service, it may result in a lot of individual, fine-grained calls. Somehow these need to be collected. While it is a good idea to make the client do that, it is a bad idea to depend on the client to do anything (like not accidentally kick over your sandcastle).
The first protection is to use a message-based, asynchronous, reactive programming style. Rather than making a REST call from one place to the next, you put the call on a queue and let other things “react” to the call. Essentially you’re passing state changes around. This is similar to the enterprise service bus approach of old.
The second protection is to use an API gateway (examples include Kong and Apigee). 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 service mesh (examples include Istio and Red Hat OpenShift Service Mesh). 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.
Edge devices 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 “cloudlets” or small-scale, regional data centers. Research has shown that edge computing improves the performance and scale of applications deployed in the cloud.
The advent of 5G networks holds the promise of supporting many more wireless devices on the network. Some see this as an opportunity for fog computing, 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 edgeless computing. 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 federated learning to distribute the training of shared machine learning models across smartphones. A future where not only the network is the computer but also the database may very well be upon us.