Cloud Connected Apps (Part 1)

The architecture of software applications has evolved radically in the last 15 years.

From purchasing expensive hardware for every application that a business runs, costing tens of thousands of pounds, to running virtual machines on a hypervisor, like VMWare.

Today we have cloud platforms; AWS from Amazon, Microsoft Azure and, more recently, Google Cloud. The overriding benefit is that the cost of hosting and running applications and services in the Cloud is now much lower than before.

But this is not the whole story. There are a multitude of other benefits of being cloud connected, especially where mobile apps are concerned.

Why have Cloud Connected Apps?

A mobile app usually requires an API service to communicate with. This API is the part of the app that does a lot of the server-side heavy lifting, usually retrieving and manipulating data.

Most apps require a connection to the API in order for people to be able to use it. How many apps have you tried to use when you have poor connectivity? Usually you’ll receive a message along the lines of, “No Mobile Signal. Please try again later.” It’s incredibly annoying! 

There are also the potential security implications that come with making an API which can access sensitive information.

Wouldn’t it be great if you could still use app functionality, even when it’s offline, for example when you are in the middle of paying a credit card bill or downloading a newspaper article or video?

And wouldn’t it be great if it could be ultra-secure? You’ll be glad to know that this is the whole point of Cloud Connected Apps. If implemented correctly, this is what the Cloud allows you to do.

However, in order for things to work there need to be changes to the architecture of the app, as well as changes to your thinking.

If we go into Event Driven Programming, start by thinking of every possible event in your app. For example, a banking app could have events such as:

  • Pay Bill

  • Pay Credit Card

  • Request a balance

The user is raising events within your app.  But instead of communicating directly with an API, which retrieves data directly, the app does the following: 

  1. It communicates with an Edge API in the Public Cloud.
    This API forwards the request onto a Message Queue which is hosted in the Private Cloud and raises an event.

  2. Subscribers looking for specific events then process these events using a set of Micro Services.
    Ideally you should have a separate set of Micro Services for READS and WRITES.

  3. A notification is then sent back to the device stating that their request has been fulfilled.

 So, what are the advantages?

  1. Single API - You are communicating with a single API whose job it is to forward messages and raise events. Nothing else. Therefore, the app doesn’t need to worry about having to connect to multiple, disparate API contracts.

  2. Security - The APIs which have access to sensitive information are NOT available publicly. 

  3. Offline Capability - Azure Table Sync allows you to continue to use the app effectively, even if you don’t have a data connection. So, you would for example:
         + Open the app
         + Enter the amount and the bill you wish to pay
    The app will store the information locally on the device and once you have a stronger connection will upload the request to the API. Think of it as sending an email when you’re offline and it getting delivered when you are back online.

  4. Resilience - All messages delivered to the Queue will get processed eventually.

  5. Auto Scaling - If your app is raising more of one type of event than another, or is getting a concentration of requests to do the same thing, then auto scaling of hosting resources and computing power will help. If you have configured auto scaling, your cloud platform will automatically scale that particular service without any user intervention. It can also de-scale if a service has more resources than it is using, therefore reducing cost.

  6. Additional Cloud Services - These include services such as Machine Learning and 3 Factor Authentication. You can use these to detect anomalies in inbound messages. For example, you can pick up on requests coming from countries with sanctions, or unusually high volumes of transactions from one account.  The beauty of cloud services is you just have to turn them on. There are no additional servers or hardware required.

  7. Event Driven Programming – Every Event raised by the app can be stored in a database. This is great if you want to see how people are using your app.

  8. Multiple Event Subscribers - Other parts of your Domain can subscribe to events. So if you want to notify a team of transactions in excess of £10,000, a subscriber can be created which monitors for this event and reacts accordingly.

  9. Cross Platform - If a website or desktop application is used in conjunction with the app, it can use the same architecture and utilise the same Cloud Services.

 Microsoft Azure Service Fabric

One of the disadvantages of this type of architecture is that now, rather than having just one API, you have multiple services running in the cloud.

Azure Service Fabric is built for Micro Services and is the same technology that Microsoft uses to run Azure.

These are just some of the ways in which Azure Service Fabric allows you to build the architecture described above easily: 

  1. Stateful Services – It enables you to build Micro Services, which can manage state. Rather than a separate message queue with subscribers, the queue can be built into the service. Any data passed into the queue is persisted on Azure.

  2. Auto Scaling – Service Fabric can monitor your services and scale when the load becomes too high. It can also descale if a service not fully utilising the resources allocated to it, thus saving costs.

  3. Self-Healing – If a service goes down, Service Fabric will automatically redeploy the service to another node minimising downtime.

  4. Versioning – Unlike a website where users get the changes automatically, with an App you may have to support multiple versions of it.  Service Fabric allows you to version the entire backend services of an app easily. This means if you release a new version of the App, you can rapidly spin up a new version of the backend services and have multiple versions running, one for each supported version of the app.

Conclusion  

Why do people use Mobile apps rather than web applications? It’s generally because they provide a more convenient way to access to a service, without the need to find it in a web browser.

If you can’t use an app when you want to, chances are you won’t use it. So it’s better to give some functionality rather than none. Providing offline access ensures requests get processed, irrespective of issues with backend systems, and will go a long way towards encouraging use of the app.

Cloud Services offer a wealth of additional features in a commoditised, easy-to-use manner - from Machine Learning to 3 Factor Authentication for verification. Not only do you deliver a better app experience, there’s also value in the data gathered.

Chelsea Apps Factory helps businesses innovate fast, and gain sustainable value from cloud connected mobile apps. If you’d like a chat about your mobile challenges, why not drop in for a cup of tea? Or message us: contact@chelsea-apps.com