The Deployment Model for Cloud/Automated Systems Architectures
Recap
Previous Article: The Service Model for Cloud/Automated Systems Architectures
Last time, we covered our Service Model. We'll continue this week by covering the Deployment Model. Before we dive into the details lets take a look at a diagram so we can give more context to the reasons for having a loosely coupled Service and Deployment Model:
In the diagram above we differentiate between Layer 4-7 Stateful Services and Layer 2-4 Stateless Services. In our Architecture we can establish this mapping:
- L4-7 Stateful Services: Service Model
- L2-4 Stateless Services: Deployment Model
There is a nuance here when deploying L4-7 services. Following the Truths established by our Architecture and Service Models, we should deploy L4-7 Services with a Declarative Interface. This results in reduced Domain Specific Knowledge, which then forms the basis of the Loose Coupling of the Deployment and Service model.
Following the pattern from our previous article lets cover the Truths, Attributes and an F5 Expression of the Deployment Model.
Deployment Model
So, what does our Deployment Model accomplish? In the previous article we defined it as:
Implements Continuous Deployment of the Service and Operational Models into an Environment
So, first, what is an Environment? Simply put it is the underlying Networking, Compute and Storage infrastructure that we must interface with to provide instances that we can deploy Services from the Service Model on.
The Service Model, by nature, should be portable, with minimal change, between Environments. When implementing, or Expressing, the Deployment Model into an Environment we expect that each Expression will be specific to the underlying Environment. As we discuss our Truth and Attributes you will see that even though each Expression is unique, we abstract those Expressions to provide a consistent interface for the Service and Operational Models.
Very few Infrastructure Solutions implement a vendor-agnostic Declarative Interface for interfacing to the required Compute, Network and Storage systems required to deploy the underlying Instances needed by the Service Model. As a result we use the Deployment Model to interface with these systems while still providing a consistent interface for our other models.
Deployment Model Truths
Lets take a look at the Truths for the Deployment Model:
- Provide OR Consume an Source of Truth
- Express itself across Vendors and Solution Sets
- Implement Mutable Scalability
- Be Inherently Multi-Tenant
- Understand limits of the Deployment Environment
- Provide Safety Limits to Prevent Runaway
- Secure your Deployment Metadata & Secrets
- Provide Diverse Business Models for Consumption
Provide OR Consume an Source of Truth
In our first article we discussed the concept of a Source of Truth (SOT) and it's importance to Automated Systems. Because the underlying Environment can be inconsistent from system to system each expression must strictly define how a SOT is provided. If one is not provided then the expression must provide it. Said simply, there is no getting around the need for a Source of Truth.
Express itself across Vendors and Solution Sets
As discussed in the introduction to this section, the Deployment Model has to interface with many different systems. Our Model is designed to allow itself flexibility through Iteration, which allows you to leverage different underlying systems, while maintaining a loose coupling between the Service and Operational Models. A goal of the Deployment Model is to be abstracted enough to prevent a tight coupling to a specific Environment.
Implement Mutable Scalability
Scalability, especially Horizontal Scalability is a key feature at the core of most Automated Systems. Due to the differences in each Environment is it very hard to implement a portable Expression of 'Scalability'. Additionally, this Scalability should be Mutable (changeable) in an automated manner. As mentioned above, we want to make sure Mutable Scalability is implemented in a manner that is abstracted enough to prevent a tight coupling to a specific Environment.
Most Expressions of this feature rely on a concept called Pave & Nuke. This concept refers to two key operations required during most Scale Mutation operations performed at the Instance level. The Pave portion refers to he the set of operations required to instantiate (create) a new instance on the Environment. The Nuke portion refers to the destruction (delete) of an existing instance. It's important to Pave first, then Nuke once it's determined that it's safe to do so.
Be Inherently Multi-Tenant
This Truth is fairly straightforward. All expressions of a Deployment Model should be Inherently Multi-Tenant. It is much easier to implement multi-tenancy at the initial Iteration of our Model than to try add it in subsequent Iterations.
Understand limits of the Deployment Environment
Because each Environment implements different functionality it is important to understand the limits of that functionality and how it effects the Expression of our Model. For example, the underlying Network infrastructure may not provide access to Layer 2 networking such as ARP. Due to this, when implementing instance redundancy, we must rely on a non-ARP mechanism for redundancy and failover of an instance.
Provide Safety Limits to Prevent Runaway
One of the major panic-inducing aspects of Automated Systems is the runaway scenario. We can thank our friends in Hollywood for most of this... here are some examples:
- 2001: A Space Odyssey: HAL 9000
- Battlestar Galactica: Cylons
- The Terminator: Skynet
- I, Robot: VIKI
- The Matrix: Agent Smith
- The 100: A.L.I.E.
- Avengers: Age of Ultron
- Ex Machina: Ava
All of these examples result is some sort of destruction of the human race because no-one designed in Safety Limits. Most production issues that occur in Automated Systems happen during Mutation operations in the Deployment Model. As a result we should design in Safety Limits to operations such as Scale Mutations that clearly define high and low watermarks to prevent runaway scenarios.
Secure your Deployment Metadata & Secrets
As we move into Layer 4-7 services it's critical that Deployment Metadata and Secrets be handled in a secure fashion. Due to the variance in Source of Truth systems the specifics of this item can't be covered properly in our Architecture discussion. Instead, we clearly define that the Source of Truth needs to provide metadata security.
Provide Diverse Business Models for Consumption
So far we've discussed the technical aspects of Environments that the Deployment Model can support. It's important to understand the technical aspects are reliant upon flexible and diverse business models that naturally fit the Environment being utilized.
For example, in Public Cloud Environments F5 supports both Bring-Your-Own-License (BYOL) and Pay-As-You-Go (PAYGO) business models. This allows customers to use both on-demand/subscription and fixed-cost business models.
Now, in the case of Private Cloud Environments the ability to implement PAYGO may or may not exist depending on how Instance Metering is implemented. Public Cloud providers implement Instance Metering by default, however, this does not hold true in all Private Cloud environments. We can still simulate a PAYGO business model, however, it should be understood that this business model is not inherently provided by the Environment. Instead we implement it as part of our Deployment Model Attributes.
Deployment Model Attributes
Now that we've covered our truths lets take a look at our Attributes:
- Source of Truth
- Loosely Coupled
- Mutable Scalability
- Metadata Security
- Business Model
Source of Truth
We've discussed Source of Truth quite a bit. We include this item as an Attribute to reinforce the need for a well-defined Source of Truth.
Loosely Coupled
"Expression of the Deployment Model must retain all attributes regardless of the underlying Environment"
In order to maintain a Loose Coupling it's critical that each Expression retains or accounts for all of the Attributes of the Deployment Model. Not all attributes have to be implemented in the first Iteration of our Model; however, each attribute should eventually be implemented. Ignoring an attribute exposes the risk of creating a tight coupling to the Environment.
Mutable Scalability
"The Mutable Scalability attribute should defined within the bounds of, and consume the underlying Environment"
As discussed in our Truths, Mutable Scalability is heavily tied to the specific Environment we are Expressing the Model into. As a result this attribute should not exceed the technical capabilities of that Environment. Additionally, we should consume the native capabilities of the Environment whenever possible.
An example of this is utilizing DNS to implement Horizontal Scalability in a Public Cloud environment. When doing this it's important to understand that DNS responses can be cached by upstream systems. This must be accounted for in our Pave & Nuke operations so existing users are not disconnected due to a cached DNS response.
Metadata Security
"Security of the deployment metadata must be guaranteed"
It's simple. Secure your Source of Truth. Nobody wants Layer 7 metadata such as Encryption Keys, Polices or Source Code (iRule's) being exposed.
Business Model
"Decouple Deployment Consumption from the Business Model"
In our Truths we discussed an example using a Private Cloud Environment. When implementing this Attribute it's important to understand if the underlying Environment's business model (metering) can be leveraged. If not, we must implement the required model as part of this Attribute.
For example, in our Private Cloud scenario, if the Environment doesn't provide Metering, we can implement a PAYGO business model by using F5 License Pools and F5 BIG-IQ for Metering.
Deployment Model - F5 Expression
This final slide shows an example of how to implement all the Attributes of the Deployment Model using F5 technology. As we've discussed, it's not required to implement every attribute in the first iteration.
The slide references some F5 specific technology such as iApp's, iWorkflow (iWf), etc. For context here are links to more documentation for each tool:
- iApps: https://devcentral.f5.com/s/iapps
- iWorkflow: https://devcentral.f5.com/s/iworkflow
- App Services iApp: https://devcentral.f5.com/s/wiki/iapp.appsvcsiapp_index.ashx
Wrap up
Hang in there! 1 more model to go. The next article will cover the Operational Model and wrap everything together in our Conclusion.
Next Article: The Operational Model for Cloud/Automated Systems Architectures