by Paul Butterworth

April 9, 2019

Revised July 25, 2022

Revision: 0.30

Introduction

We have made a distinction between deployed applications
that are operational and deployed applications that are production. In this
paper we offer some best practices that can be applied to bring an application
into compliance with the production application criteria enumerated in the
document: Deployed Applications: Operational and Production.

Practices for Producing Production Applications

Development and operations staff can apply the following criteria
and methods to bring the quality of an operational application up to the
standard of a production application. Certainly, all of these methods can be
applied but it is also reasonable to be more selective and only apply those
methods required to bring the specific application of interest up to production
standards.

Criteria and methods:

·
Quality hygiene

o
Application produces no errors (aka exceptional conditions)
during normal operation. If a normal run of the application produces errors in
the error log the application is not ready for production. Note that this does
not apply to user errors that are properly handled and reported to the user; it
only applies to errors that are not handled by the application.

o
All diagnostic logging is disabled. An application may produce a
small number of log entries during normal operation but if it is writing
debugging and diagnostic information at more than one record every few seconds,
the application is not suitable for production. Remember there are 86,400
seconds in a day implying that an application that writes 10 log entries a
second will produce nearly a million log records a day. That adds up and you
will quickly exceed your disk quotas.

o
A set of documented tests are available that confirm the proper
operation of the application. It is most useful to have automated regression
tests where practical since these can then be run on demand when changes are
made to the application for bug fixes or enhancements. The tests can also be
run when new versions of the platform are introduced to confirm there is no
impact on the correctness of the application.

·
Scaling hygiene

o
The application does not produce errors when run at scale.
Typically, the additional errors that occur at scale are quota violations
caused by the fact the application is using more resources than it is authorized
to use. The error logs can be scanned to detect such errors. If scaling tests
are producing errors the application is definitely not ready for production.

o
The application has been tested at scale. This does not
necessarily mean it has been tested at full scale – although that is a good
idea – but has been tested with enough of a load that you are confident the
production workload will be serviced properly.

§
A by-product of scale testing is you should know what resources
are required to execute a unit of work within the application. Resources are
normally measured as events ingested or produced and DBMS actions taken. These
measures are proxies for the overall resource consumption of the application.
This information can be used for capacity planning and to estimate the cost of
running the application at greater scale. See the document: Scalable
Application Architectures for additional details.

·
Code management in place

o
A general rule for all software development is that it has to be
possible to re-create the application from its source representation. In VANTIQ
the source representation is the set of resources that comprise the
application. All such resources should be exported and placed under the control
of a version management system such as Git or Team Foundation Services. Note
that any other resources required to reconstitute the complete application
should also be placed under the control of the version management system. For
example, any configuration files, help files, etc. Essentially, everything
needed to recreate the application from scratch should be controlled.

o
Along with application resources, the procedure to deploy the
application should be documented and placed under version control. If you are
using the VANTIQ deployment manager, exporting the configurations, deployments
and environments used to implement the deployment will satisfy this need. If
you are using external procedures and scripts to deploy the application, they
must all be collected and placed under version control along with the
instructions for executing the deployment process.

·
Namespace and Nodes provisioned

o
The application will run in one or more namespaces within the
production installation. The namespaces must be set up in anticipation of
deploying the application. Nodes can be defined as part of the deployment
process and the node definitions must also be placed under source management.

·
User management in place

o
The application is likely to have a user community unless it is a
totally automated system. The users must be provisioned into the production
installation. Note that even if users are provisioned into the development
installation, they must be provisioned again in the production installation.
The normal procedure for provisioning users is to invite them to be authorized
users within the namespace in which the application executes.

o
Profiles that contain appropriate privileges for each user role
are constructed and assigned to the appropriate users.

·
Note that namespace and user provisioning for production
applications is described in detail in:  Migration to API.
This document describes a number of additional best practices for bringing
applications to production quality.