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 blocks 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. To create a more complex deployable architecture, you can stack deployable architectures together without editing Terraform code to do so.
An example deployable architecture is Cloud automation for Secrets Manager. This deployable architecture provisions an IBM Cloud Secrets Manager instance as a modular solution. You can use this architecture to securely manage secrets with your IBM Cloud account. Cloud automation for Secrets Manager has a narrow scope. It only deploys a Secrets Manager instance, though the deployable architecture can also optionally create an IBM Key Protect key ring and key to encrypt data if one does not exist.
Deployable architectures can be broader in scope, like VPC landing zone. VPC landing zone 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.
What does it mean to stack deployable architectures?
Experimental
For a more complex use case, you can stack architectures together to form a complete, end-to-end solution for deploying a complex application or infrastructure. Unlike individual modules or deployable architectures, which provide specific functionality, stacking combines multiple deployable architectures to form a comprehensive solution that can be easily deployed and managed. Just as modules can be combined to create a deployable architecture, deployable architectures can be stacked to create a more extensive solution. Stacking includes linking the architectures together to create a complex deployable architecture. This linking is achieved by specifying references in each deployable architecture's inputs by using a reference notation. You do not need to be an expert in Terraform, or have any Terraform coding skills, to stack architectures together and deploy them.
As an example, consider Cloud automation for Secrets Manager. That deployable architecture includes the Secrets Manager module, which creates a Secrets Manager instance. If you only require an instance of Secrets Manager, that deployable architecture is a suitable choice. However, securely managing secrets is only one piece of maintaining security in the cloud. What about running compliance scans so you always know the posture of your resources? Or receiving notifications for critical events in your IBM Cloud account? IBM Cloud Essential Security and Observability Services deployable architecture leverages the full range of security services from IBM Cloud. It was created by stacking Cloud automation for Secrets Manager along with deployable architectures that provision other IBM Cloud services, like Security and Compliance Center and Event Notifications. That deployable architecture provides a more comprehensive security solution that Secrets Manager can't provide on its own.
You can stack deployable architectures in an IBM Cloud project and publish them together to a catalog without many extra validation steps. Or, you can stack architectures as you onboard a solution to a private catalog. From there, you can share it with others to save them the time of rebuilding it on their own.
This complex solution derives much of its cost, compliance, support, and quality assurances from its included deployable architectures. However, that complex solution has a unique version, description, and architecture diagram. If an update is made to a deployable architecture that's stacked with others in a catalog, the entire solution must be updated by the onboarder to use the latest version of that component deployable architecture. Updating the entire solution to a new version helps ensure that the latest update to a single architecture functions correctly within the broader solution.
However, each deployable architecture has independent configuration states, allowing each one to be deployed, updated, or undeployed independently. For example, you already know that the IBM Cloud Essential Security and Observability Services deployable architecture includes the Cloud automation for Secrets Manager deployable architecture, among others. If Cloud automation for Secrets Manager is updated, then IBM Cloud Essential Security and Observability Services needs to be updated to use the latest version of Secrets Manager. However, every architecture that's included in IBM Cloud Essential Security and Observability Services doesn't need to be redeployed by the user consuming that solution. When the user updates their project to use the latest version, only Secrets Manager needs to be redeployed.
What's included in a deployable architecture?
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.
- Required architectures
-
A deployable architecture can contain inputs that require the outputs from other deployable architectures to successfully deploy. This relationship between a deployable architecture and another architecture it requires is commonly referred to as a dependency. You can meet dependencies in two ways: by stacking deployable architectures or by onboarding a deployable architecture to a private catalog and extending it to include other architectures.
Deployable architecture with a dependency on another deployable architecture - Optional architectures
-
Deployable architectures are designed to be flexible, so you can easily stack architectures together to build a more complete solution. However, a generally useful deployable architecture may not include the specific options that you need to meet a complex use case. For example, which database goes with your Java application? Do you need event notifications, a message queue, or some other optional service that’s not included by default? Optional deployable architectures can be stacked along with required deployable architectures to solve this customization problem for users.
- Swappable architectures
-
Whether an architecture is required to satisfy a dependency, or it’s included as an optional extension of an architecture, users might require more flexibility. You might know your Java application works with an optional database - but which database do your users require? Specifying swappable architectures for users helps them customize the end-to-end solution to meet their specific needs. After you stack any optional or required architectures together, you can group architectures as swappable with one another. The consuming user can then select which required architecture they want to use to satisfy a dependency, or select an optional architecture if they want to extend their use case.
Optional and swappable architectures can be added as you onboard a deployable architecture to a private catalog. Currently, stacking deployable architectures in a project does not support optional or swappable architectures.
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.
| Purpose | Recommended method | Why? |
|---|---|---|
| Creating a library of sharable automation components | Create a 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 | Create a 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 | Stack deployable architectures together | By combining architectures, you can create a more complex end-to-end solution for your organization. |