What are modules and deployable architectures?

Creating secure, compliant, and scalable application infrastructure can be difficult to set up and costly to maintain. Instead of figuring out how to assemble a compliant infrastructure architecture on your own, you can take advantage of modules and deployable architectures. Modules and deployable architectures can help you to create a framework around how resources are deployed in your organization's accounts. By working with these reusable configurations, you can define the standard for deployment once and ensure that it is easily repeatable for each member of your organization.

For example, think about an architect who is building an apartment complex. These designs are typically executed in a modular way. There are patterns for standard one-bedroom, two, or three-bedroom apartments. The builder can combine the standard apartments, each functional in their own way, into a larger, more complex, but functional living arrangement. IBM applied this same analogy to deploying solutions on the cloud. Rather than your organization spending months figuring out how to get services and software to work together, you can use IBM Cloud's well-architected patterns. Each pattern is packaged as composable, automated building bocks known as modules and deployable architectures.

What is a module?

A module is a stand-alone unit of automation code that can be reused by developers and shared as part of a larger system. Similar to Node.js or Python packages, modules are a convenience to developers who are managing related resources. While it is possible to use modules alone, they're more powerful when you combine them to build a deployable architecture. Modules that are created by IBM Cloud are made available in the IBM Terraform modules public GitHub org. For example, the Red Hat® OpenShift® VPC cluster on IBM Cloud module installs and configures a Red Hat OpenShift cluster on IBM Cloud.

What is a deployable architecture?

A deployable architecture is cloud automation for deploying a common architectural pattern that combines one or more cloud resources. It is designed to provide simplified deployment by users, scalability, and modularity. A deployable architecture incorporates one or more modules. Deployable architectures are coded in Terraform, which you configure with input variables to achieve the behavior that you want. In the case of a deployable architecture stack, it incorporates one or more deployable architectures that are grouped without requiring Terraform code.

A deployable architecture, which contains modules — Figure 1. Deployable architecture that contains modules

For example, VPC landing zone is a deployable architecture that provisions several virtual private clouds in a hub-and-spoke networking pattern that is connected by a transit gateway. It includes a number of supporting services that are used for the monitoring and security of the workloads that run on the VPCs.

Deployable architectures that are built and maintained by experts at IBM Cloud are made available to you in the IBM Cloud catalog. If you choose to create your own version of those deployable architectures, or build one from scratch, you can onboard your deployable architecture to a private catalog and share your ready-to-deploy solution with your organization through the catalog.

A deployable architecture might include variations, have dependencies, or be stacked together to create more complex solutions.

Variations

A variation is a type of deployable architecture that applies differing capabilities or complexity to an existing deployable architecture. For example, there might be a Quick start variation to your deployable architecture that has basic capabilities for simple, low-cost deployment to test internally. And, you might have a Standard variation that is a bit more complex that is ready for use in production.

Dependencies

A deployable architecture is considered dependent upon another architecture when it has inputs that require the outputs from the other architecture to properly deploy.

A deployable architecture with a dependency on another deployable architecture — Figure 2. Deployable architecture with a dependency on another deployable architecture

Stacks Experimental

A deployable architecture stack links together multiple architectures to create an end-to-end solution. This linking is achieved by specifying references in the configuration of each architecture's inputs. You do not need to be an expert in Terraform, or have any Terraform coding skills, to create and deploy a stack.

Deployable architecture stacks are created with IBM Cloud Projects and can be shared with others through a private catalog. A stacked deployable architecture has independent configuration states for each of the architectures in the stack. This allows each component deployable architecture to be individually deployed, updated, or undeployed independently. The deployable architecture stack derives much of its cost, compliance, support, and quality assurances from its included deployable architectures. However, each stack is uniquely versioned and has its own descriptions and architecture diagram.

For an example, see the Retrieval Augmented Generation Pattern deployable architecture, which is assembled from separate deployable architectures. For more information, see stacking deployable architectures. The following diagram shows how a deployable architecture stack can be made of multiple deployable architectures to create a single deployable architecture.

What are projects and how do they work with deployable architectures?

An IBM Cloud project is a management tool that is designed to organize and provide visibility into a real-world project that exists in your organization. A project manages all of the configured instances of a deployable architecture and the resources that are related to the real-world reasons that they are deployed. Projects store versioned deployable architecture instances and organize the instances and resources into environments to help improve visibility into the development lifecycle. An environment is a group of related deployable architecture instances that share values for easier deployments. For example, development, test, or prod.

Projects are responsible for ensuring that only approved deployable architectures can be deployed. Additionally, they can help to ensure that the architectures and the resources that they created are up-to-date, compliant, and that drift does not occur over time. For example, you might have an account management application project. This project is designed to manage all of the resources that the account management application needs to deploy into a development, test, or production environment. Each environment has the same variables, such as a region or prefix, but has different values. When a deployable architecture is assigned to an environment through a project, their input values can automatically reference any of the environment's properties that have the same name. While IBM Cloud projects are easy to create and update, they are not templatized or optimized for replication or sharing.

How do I know which solution to create?

If you plan to create your own solution, the scope, coupling, whether it's deployable, and the purpose of your solution should all be taken into account. For guidance and use cases to help you decide what you plan to build, see Planning and researching for designing an architecture and How do I decide what kind of component to create.

The following table provides a high-level overview of why you might want to create the different components.

Table 1. Understanding for automated deployments use-cases
Purpose	Recommended component	Why?
Creating a library of sharable automation components	Module	Modules provide reusable, curated automation to speed up the process for those who are creating and configuring deployable architectures.
Ensuring that your organization's cloud environment is secure and compliant	Deployable architecture	Deployable architectures are packaged in a way that you can define a secure and compliant deployment once and ensure that all members of your organization are repeating the deployment in the same way.
Architecting your own solutions	Deployable architecture stack	By combining architectures, you can create a more complex end-to-end solution for your organization.