Skip to main content

CodeNOW conceptual model

How to concretely implement an application with CodeNOW? Development teams should first identify the functional requirements, non-functional requirements, and constraints of the application. Those three pieces help define a target architecture. That architecture is then turned into a CodeNOW design that leverages the entities exposed by CodeNOW's conceptual model (e.g., cluster, application, components, environments, managed services, libraries):

Example of CodeNOW design

Functional requirements​

Functional requirements are primarily addressed through code written by developer teams. The necessity of having teams working independently on a set of functional requirements can be addressed by independent software modules. To that purpose, use CodeNOW components and managed services.

Managed services help implement functional requirements that most applications commonly need (e.g., persistent storage, distributed communication). Managed services are tied to a cluster and share its resources.

CodeNOW components are generally stateless modules that are developed by a single team/developer. Managed services are generally stateful services. CodeNOW components can be connected to managed services in order to implement stateful microservices.

CodeNOW components can reuse CodeNOW libraries, which gather a cohesive set of functional requirements in a single package. CodeNOW libraries are meant to be used by components and are not deployable.

Non-functional requirements​

Use CodeNOW applications to address the necessity of having independent units of deployment with distinct non-functional requirements such as availability, performance, or scalability. To that purpose, each application deployment must provide runtime deployment configuration parameters (e.g., number of replicas, memory quota, CPU limit). As applications run in a cluster, the resources that can be dedicated to a given application are limited to those available to the cluster.

Note that managed services, like applications, are tied to a cluster and share its resources. Managed services can also be configured individually to implement non-functional requirements (e.g., for PostgreSQL: storage size, number of nodes, RAM per node, vCPU per node, backup).

CodeNOW clusters provide a high degree of infrastructure isolation by running on independent, dedicated pieces of infrastructure (e.g., compute nodes, managed computing units, cloud provider). CodeNOW applications in different clusters do not share infrastructure resources. Applications are deployed to environments (e.g., dev, staging, prod) that are tied to a cluster. By deploying to different environments, development teams can deploy to different clusters.

Summary​

  • CodeNOW components are independent units of development.
  • Managed services are (generally stateful) services that can be used by components. Managed services are tied to a cluster and share its resources.
  • CodeNOW applications are independent units of deployment that share the resources of the cluster associated to their deployment environment.
  • CodeNOW clusters are independent units of infrastructure. A development team may have one cluster on Azure and another one on AWS.
  • As architects identify the non-functional requirements of their applications, they can use the different levels of independence (development, deployment, infrastructure) and configuration (runtime configuration, cloud provider) offered by CodeNOW entities (e.g., components, managed services, applications, environments) to implement their architecture.