Cloud-based software-as-a-service (SaaS) has emerged as the go-to delivery model for many enterprise applications, including integration software. SaaS applications are efficient and cost effective, taking much of the burden of maintenance, upgrades, and storage off the user. But without solid processes guiding the development of cloud-based apps, the code can quickly become overcomplicated and unwieldly, making the software difficult to scale, deploy, and maintain.
What is a 12 Factor App?
The 12 Factor App methodology was developed specifically for building SaaS applications. Created in 2011 by Adam Wiggins, it lays out 12 best practices for developers to follow when building native cloud applications so that they are reliable, predictable, and easily scaled and maintained.
As defined by Wiggins, the 12 factors are:
| I. Codebase One codebase tracked in revision control, many deploys. II. Dependencies Explicitly declare and isolate dependencies. III. Config Store config in the environment. IV. Backing services Treat backing services as attached resources. V. Build, release, run Strictly separate build and run stages. VI. Processes Execute the app as one or more stateless processes. | VII. Port binding Export services via port binding. VIII. Concurrency Scale out via the process model. IX. Disposability Maximize robustness with fast startup and graceful shutdown. X. Dev/prod parity Keep development, staging, and production as similar as possible. XI. Logs Treat logs as event streams. XII. Admin processes Run admin/management tasks as one-off processes. |
Source: 12factor.net
What are the benefits of the 12 Factor App approach?
The more you adhere to the 12 Factor App methodology, the more it will pay off in terms of efficiency and cost.
Benefits include:
- Optimized portability between execution environments.
- Reduced dependence on servers and systems administration.
- Ability to scale without significant changes to tooling, architecture, or development practices.
- Smooth onboarding for new developers, who can easily understand standardized processes and declarative formats.
When should the 12 Factor App methodology be used?
The 12 Factor App methodology can be applied to apps written in any programming language, and which use any combination of backing services (database, queue, memory cache, etc).
If you’re starting from scratch, following the 12 Factor App process is a no-brainer. But what about legacy software? The good news is that many of the 12 Factor App principles can be adopted over time. It’s not all or nothing, and any progress towards 100% compliance will result in a better developer experience and ultimately better software.
Is Avato a 12 Factor App?
Yes! Avato is a 12 Factor App which, in addition to its stand-alone support for DevOps, build, distribution and process management automation when run on virtual machines and physical hardware:
- can run on Docker and Kubernetes;
- can be configured and deployed using Helm charts, and;
- can run on Azure, Google or AWS cloud environments which are infrastructure-as-code defined in Terraform or CLI scripts.
How Avato Conforms
Avato conforms to the 12 Factor App principles in the following ways:
One codebase tracked in revision control, many deploys.
Avato is a declarative configurable application that utilizes a single codebase. Three streams are available for binary distribution from this single codebase: stable, latest and edge. Backwards compatibility is carefully maintained across releases, and any end-user customizations are additive to the core, so the core can be safely updated at any time to a newer version.
Explicitly declare and isolate dependencies.
Avato connectors, interfaces, and pages are built and distributed as packages, which explicitly declare their dependencies on static resources, database resources, java code and jar files. The Avato package manager reads a package manifest and enables the build command to build a distribution or container with a particular configuration and capabilities that will ensure all necessary components are included.
Store config in the environment.
Avato is a declarative application that provides highly-generic services that are configured over and over in a myriad of ways to solve complex business problems. The code itself does not contain any configuration, but defaults can be provided with packages that can be overridden by the end user using environment variables or properties files. Sensitive configuration information such as passwords can be loaded from keystores such as Azure Key Vault, and are encrypted when at rest on the system or in the container. Configuration can be overridden and stored in version control for each environment as properties files or as Helm values files. Containers, Helm charts and the build system all respect environment variables as a mechanism for communicating configuration information.
Treat backing services as attached resources.
All Avato services, including external services, are declared as URLs. Any of these can be swapped out, relocated or changed through simple configuration changes.
Strictly separate build and run stages.
Avato maintains strictly immutable build, release and run stages, all supported by platform-independent commands. All changes to sourcecode can only be distributed through a full DevOps pipeline, and version control is an option available to the platform for configuration changes as well.
Execute the app as one or more stateless processes.
Avato is generally stateless, and any request can be routed to any server at any time. No session affinity is required. One potential bending of 12 Factor App principles is identified here, however. For asynchronous messaging, Avato has identified persistent storage as a more-reliable data store for JMS messages. As such, StatefulSets are used to deploy the application on Kubernetes, which is a requirement of the underlying JEE container currently used to implement JMS (asynchronous) messaging. Outside of JMS / asynchronous messaging, Avato is fully stateless; all state is stored in the Avato database, although the system can be configured to leverage persistent storage for specific purposes such as file storage and transfer.
Export services via port binding.
The Avato platform can be configured to run on virtually any set of ports, and port mapping is facilitated in addition to this through Docker and Kubernetes.
Scale out via the process model.
When deployed on Kubernetes, Kubernetes manages the Avato process lifecycle, which is possible because Avato requests can be delivered to any Avato process. Additional instances can be easily declared and spun up, as part of the configuration or later at runtime.
Maximize robustness with fast startup and graceful shutdown.
Avato responds to health checks provided by a load balancer or by the Kubernetes environment itself, and can generally be terminated at any time without harmful consequences, with the following caveats: unless configured otherwise, long-running processes are immediately handed off to another node which restarts the work item, and if a node is terminated while processing a real-time message, a JMS queue must be used to re-attempt delivery, or the caller must resend the message if a message was being processed was interrupted by a shutdown. Note that in most cases, Avato attempts to complete any current transactions being executed before terminating, even if no JMS queue is leveraged. Startup times are minimized through the use of builder images in Docker (coming Q1 2023).
Keep development, staging, and production as similar as possible.
Although highly flexible in its ability to customize deployments for different environments, nothing in Avato prevents the observance of this principle. Internally, most customers leverage DevOps procedures that promote releases from Dev to QA to production with a simple approval process managed by a DevOps engineer.
Treat logs as event streams.
Avato streams all log output to STDOUT, although the platform can be configured to additionally write log files to persistent storage, an option often desirable when the log monitoring facilities in Kubernetes are inferior when compared to the built-in logfile analysis tools available from within the Avato platform itself.
Run admin/management tasks as one-off processes.
Avato provides a complete set of administrative tasks that can be executed on any platform. Furthermore, all Avato capabilities are exposed as web services that can be called by simple shell commands.
12 Factor App Benefits For Your Integration Project
The 12 Factor App methodology is designed to optimize the development of SaaS apps so that they can be deployed, scaled, and updated with maximum ease and minimum risk. By following the 12 Factor App best practices, developers can create better, faster code and gain a competitive advantage in the marketplace.
Avato is a well-behaved 12 Factor App that runs on multiple operating systems including Linux, MacOS, and Windows, and can be deployed in Docker and Kubernetes on various cloud platforms.
As a 12 Factor App, Avato completely realizes the vision of a hybrid integration platform that can run anywhere, under any operating system or network, so that all of your network applications can share data and functionality with one another without undue configuration, deployment or operational overhead.