It turns
out that other rules apply when creating a mobile application for 10-100K
users, and different when writing an application for several million users.
Many
companies dealing with mobile applications are good at projects for a small
number of users and face a severe problem when the number of users increases
significantly. When choosing technological solutions or a provider of such
solutions, you must consider what volume of users we plan to have in 1-2 years,
so as not to rewrite the entire application one year from the first release.
The small number of users
An
application for a small number of users does not require much. Most are code
written on a mobile device. For the application we have some CMS (bought or
written), a local user login system, some simple error tracking, and basic Analytics.
The back-end usually stands on only a few servers, which can be enlarged if
necessary. Sometimes, frameworks are used to create applications that allow you
to create a user interface faster. Sometimes, to solve the problem of writing
codes on two platforms simultaneously (IOS + Android), Xamarin-like
environments are used.
And it
works for small scale applications.
A large number of users
Writing the
application for more users, we find very painfully that:
1.
Errors
When a fatal error occurs in the mobile application, and we learn from
it through the opinions of users in the Google or Appstore store, it means
that:
- The error has been present for at least several days
- We have a significant number of users who are not satisfied with the application 1% of users with 10K population = 100 people
1% of users with 1M
population = 10K people - the chance for negative reviews in the Google store
or Appstore increases significantly.
Even if we immediately take action and fix our error - it will take 1-2
months for the new version to propagate to 80% of users' devices (time before
users upgrade the application) - in the best case, with a massive marketing
campaign, we'll go down to about a week. Even if the error has no financial
consequences and only reputation is the problem, it will decline significantly during
this period.
2. Performance
The mobile application, especially with a large number of users, often
becomes a powerful marketing tool that companies willingly use. While our
servers can handle the "average daily traffic" of users, triggering a
marketing campaign that causes the activity of many users at a given time, such
as promotions, can overload our servers. Standard databases (even on top
machines) may not be able to handle all the necessary requests in a short
period.
3. CMS - Content Management System:
After some time, we start to notice that some of our users behave
similarly. Therefore, we extract groups of users in several dimensions and
adjust the elements of the application to the expectations of these groups. The
more groups we separate, and the more we adapt our application, the more the
complexity of our CMS will grow.
We will quickly conclude that automation would be useful, and thus the connections
with other systems in our company. Then there will be a moment of truth of the
flexibility of our CMS system, which we chose earlier, and the costs associated
with new interfaces and expansion.
4. User Database
The decision on the user database architecture is usually made at the beginning
of work on the application. Often, at this stage, we decide to create a
separate database only for application users because it is a cheaper solution.
As the number of users increases, we naturally begin to see the benefit of
communicating with mobile application users also through other channels and also
in topics not related to the application itself.
Such a change of approach can, at this stage mean expensive adaptation
and unification of user database modules in several applications throughout the
company. Besides, we have a whole set of GDPR requirements to be met for more
than one system at a time, on different types of data.
5. Monitoring:
In addition to the critical errors that we face in the mobile
application, there will also be smaller errors that will make the use of
certain functionalities troublesome for users. Some of them will not be 100%
repeatable, difficult to reproduce, and thus, information about them will reach
us with a long delay. The problem here is not the size of the error but its
impact on users. An error that occurs only once in 1000 launches of some
functions in the application, with a population of 1M users can mean several
thousand dissatisfied users a day.
In this situation, it will turn out how important it is to accurately
and deeply track errors in the live application code. In these cases, even
error recording applications available on the market may not be sufficient.
6. OS Actualization
Manufacturers of mobile phones update the operating systems of their
devices several times a year.
Sometimes, however, it turns out that our application or library that
the application uses does not work 100% under the new version of the software
on a specific phone model. When this happens, we have very little time to react
because a well-functioning application may stop working correctly on thousands
of devices overnight.
The speed of reaction is decisive here. If we learn about the problem
from users, as in previous cases, it means that a significant part of them have
already encountered the issue. Simple application monitoring systems will also
not help much, because such problems rarely cause application crashes. Of
course, the time needed to resolve the error inside of the library used by our
application is correspondingly longer.
Without proper monitoring combined with appropriate application
architecture and automatic live tests, this type of problem can be severe.
7.
Different versions of one
functionality
The implementation of new features in the application used by a large number
of users means that each new feature is "tested" by many users. Our
internal tests must, therefore, be restrictive. However, when errors appear, we
must bear in mind the fact that the new version of the application will not
replace all the old ones in one day and for some time we will have several
versions running in parallel. If the bug fixes force changes on the server side
then for some time there will have to be 2 or more parallel interfaces that
need to be controlled and then deleted after some time.
8. Integrations
During the lifetime of the application, the number of servers necessary
for its proper functioning, as well as the number of external servers that
supply the application with data will increase significantly. Usually, such
external servers are created by different teams or different companies. So
every time a single server stops working, and the whole application will
suffer, the component suppliers may blame each other, claiming that the error
was not on their side and their SLA have been kept.
Of course, there are many other problems,
such as interruptions in WIFI, battery with GPS, map positions, other UX
behavior on IOS and Android, speed and availability of data transfer from
cellular networks, etc.
So what can we do to make our application deal
with a large number of users and increasing complexity?
Each of the
problems listed above can be addressed in several ways, depending on the
priorities.
The most
important are:
- Application should be written in a way that allows dynamic error tracking in a production application on the side of users at least five levels:
- Source code
- Application error monitoring
- Monitoring of source code errors (separately DEBUG separately RELEASE)
- Monitoring of connections between systems
- Monitoring of system versions and live automatic tests
This approach allows tracking the operation of the application in real-time without being surprised that something is not working properly and take corrective action as soon as the problem arises, and even before users manage to express their dissatisfaction.
- Server part should be prepared in a flexible and scalable way so that it is resistant to temporary increases in the number of users using it. If needed, our servers will be able to scale to the desired size.
- The application is modular, and we can control all modules separately, and our CMS allows a lot of flexibility to automate processes. Our UX can be easily changed.
- The user base is well thought out and works with other systems in the company.
Costs
- the
solution must also be cost-optimal. By creating a mobile application you can
easily fall into several traps from which the output to a larger scale can be a
bit expensive. So, each element needs to be addressed in such a way that our
monthly costs are not higher than necessary.
No comments:
Post a Comment