The Service Model for Cloud/Automated Systems Architectures

Recap

Previous Article: Cloud/Automated Systems need an Architecture

In the last article we spent some time laying the foundation of an Architecture for Cloud and Automated Systems. In that article we discussed that our Architecture consisted of three Models that form our triangle:

Additionally, to provide context, we covered the following Architectural Truths:

• Enable a DevOps Methodology and Toolchain
• Lower or eliminate Domain Specific Knowledge
• Leverage Infrastructure-as-Code
• Don’t sacrifice Functionality to Automate
• Provide a Predictable Cost Model
• Enable delivery of YOUR innovation to the market

As we continue on our journey through this series of articles it's important to remember our Architectural Truths. These items are the unbreakable laws of our Architecture. As we develop our models we will take these Truths as base assumptions.

What's in a Model?

So, what are these models? We referenced them continually throughout the last article but now it's time to define them. Our Architecture consists of three models:

• Service Model: Maps business requirements to automatable technology use cases. In the case of F5 products the Service Model defines the Layer 4-7 services delivered by the F5 platform.

• Deployment Model: Implements Continuous Deployment of the Service and Operational Models into an Environment.

• Operational Model: Provides stable and predictable workflows for changes to production environments, data and telemetry gathering and troubleshooting.

Within these models we further define Truths and Attributes. Truths, as implied, should always be adhered to within a given Model. Attributes, however, are more flexible because the choice to implement an Attribute is made while implementing a specific Expression of the Model into an Environment. In the first article in this series we discussed how a Model evolves over time:

We can now expand on this idea to involve iteration:

As you can see in the image above, we implement Continuous Improvement on each Iteration of the Model. Generally, in each iteration we can implement new Attributes or improve on existing ones.

Service Model

Now that we understand the concept of a Model and how that Model fits into our larger Architecture, lets dive into the details of the Service Model. As discussed above, each Model has a set of Truths and Attributes. First, we'll cover our Truths, then the Attributes, and finally we will provide an F5 specific expression of each Attribute. This pattern will be used for all of our Models.

Service Model Truths

Lets take a look at the Truths for the Service Model:

• Provide Appropriately Abstracted Services
• Be Declarative, Composable and Mutable
• Be Consumable in an On-Demand manner
• Be Loosely Coupled to the Deployment and Operational Model

Provide Appropriately Abstracted Services

As discussed extensively, we must utilize abstraction to lower or eliminate the need for Domain Specific Knowledge and build Declarative Interfaces. To achieve this each business requirement should be mapped to a use case that a specific set of technology can deliver. After that mapping is identified it is essential that the perspective of the consumer of that service is used to establish the baseline requirements for deploying a Service.

For example, lets refer back to Jammin', our Jam sandwich restaurant. The Drive-Thru lane is a Declarative Interface, the Menu itself is a Service Model (or Service Catalog), and a Menu Item is a Service. When we establish the baseline Domain Specific Knowledge required to interact with our Service Model we assume that our Consumer knows how to use a Drive-Thru and also understands the basic differences between our Menu Items (strawberry vs. grape jam). From the perspective of the Consumer having two menu items for these types of sandwiches is the easiest interface. What happens to deliver the sandwiches is irrelevant to the Consumer. The only thing that matters is that they received the easiest possible interface.

Be Declarative, Composable and Mutable

We've already discussed what Declarative means so lets focus on the new items introduced here:

Composable: The ability to assemble features and use cases in different Service combinations that meet business requirements.

Mutable: The ability to change or Mutate service offerings as needed to meet business and operational requirements. Additionally, services themselves should cleary define how a specific Service can be mutated by the Operational Model.

Let's imagine that Jammin' is selling sandwiches left and right... Due to our massive success we've realized that we could delight even more customers by adding some more items to our menu. Because we implemented the F5 Architecture for Automated Systems we're able to do this easily.

The new menu includes the ability to choose Jelly instead of Jam (yes, they are different... look it up!) and a brand new sandwich innovation we are calling "Peanut Butter and Jammin'". Luckily, we thought ahead a little bit when designing our kitchen and included stations to store these new ingredients. This allows our service offerings to be Composable. We can combine ingredients in different ways to meet the needs of our consumers. All we need to do is add some steps in our Imperative Process to deliver these new products.

Now that we can make the sandwich, how do we let our customers know about our new offerings? This is where the Mutable aspect of service offerings comes in. When we built our restaurant we added digital menus to our Drive-Thru lanes. This allows Jammin' (the undisputed leader in jam based sandwich innovation) to quickly change (Mutate) their menus to include the newest offerings as soon as they are available.

The second type of Mutability, Service Mutability is not easily explained using our jam sandwich analogy. Instead we will be use an F5 specific example in this case. Clearly defining how a Service itself is changed is critical later on when we implement an Operational Model. An example is how a Service with a Layer 7 Web Application Firewall policy will apply changes to that policy.

Does the Service redeploy a standardized base policy?
Does it allow the policy to change after deployment and preserve those changes?

When working with L7 services it's important that Mutation of the L7 policy component is accounted for and the intended behavior is clearly defined by the Service.

Be Consumable in an On-Demand manner

We've discussed quite a bit about Declarative Interfaces, however, one aspect of that model has not been addressed yet; the ability to deliver a service on a as-needed or on-demand manner. This truth is usually bound within defined limits.The key idea here is that a Service definition should be deployable in a production state in an on-demand manner. To satisfy this requirement it is often required that other systems are orchestrated together (IPAM, DNS, Compute, etc.).

Be Loosely Coupled to the Deployment and Operational Model

Our final truth is critical to making sure a Service Model is portable between different environments. From a L4-7 service perspective we want to ensure that the Service definition does not change when the underlying L1-3 infrastrcuture is changed or replaced. While there is always a connection between L1-3 (packets gotta route) and L4-7 (ports gotta listen), the Service Model should always assume a very Loose Coupling between these layers.

Additionally, the Service Model should allow any number of Operational models to be implemented without changing. This allows us to address both the needs of new methodologies (DevOps, etc.), while still maintaining support for existing methodologies.

Service Model Attributes

Now that we've covered our truths lets take a look at our Attributes:

• Abstracted
• Declarative
• Composable
• Mutable
• Loosely Coupled

Abstracted

"The L4-7 service must be appropriately abstracted and leverage implicit configuration whenever possible"

We've discussed abstraction quite a bit already so lets focus on implicit configuration. Implicit Configuration means that a Service definition should derive as much of the metadata required to deploy the Service from the environment itself. The base assumption when defining services should be to require user/consumer input as a last resort.

Some examples of implicit configuration are:

• Integrate with IP Address Management (IPAM) systems for IP assignment
• Automatically enable functionality based on the service metadata
  • Enable X-Forwarded-For HTTP Header insertion if SNAT is configured
  • Configure base WAF policies that auto-detect common web frameworks
• Configure HTTP health monitors when using a HTTP well-known port

Declarative

"The Abstracted Service must be deployable in a single-call declarative manner"

Single-call is the key term here. If a Service has been appropriately abstracted it should be deployable with a single API call. One important nuance here is that the outcome of the deployment call may not always be a successful deployment. The impact of not implementing this Attribute is that it results in Imperative Process elements leaking into the Declarative Interface

Composable

"Appropriate abstraction enables inherently Composable services"

This attribute is really a reminder that Appropriate Abstraction and Composability go hand-in-hand.  However, the exposed Service Model can be as Constant (static) or Composable (dynamic) as required to meet business requirements.

Mutable

"The entirety of the Service must be implemented or not"

When deploying services it is critical that the toolchain used does not leave the underlying components in a half-configured state. Doing so can create situations that result in production outages because the state of the underlying components becomes inconsistent with the declared intent of the consumer.

"The Service Catalog must support inheritance and versioning"

To implement mutations of the service catalog it is critical that the catalog itself leverage inheritance and versioning. Inheritance is important so that service metadata defaults can be changed as needed. Versioning is important to ensure that the consumer understands exactly what service is being delivered at any point in time. Service deployments should be transitioned from one version of a service to the next as required.

Loosely Coupled

"The Service Model should not rely on the underlying expression of a Deployment and Operational Model"

One of the goals of the Architecture based approach is to provide a stable foundation for implementing Automated Systems. When we cover the Deployment and Operational Models you will see that the underlying components and methodologies of a system are extremely variable. In order to provide a Portable Service Model it's important to design services that minimize assumptions from Deployment and Operational Model attributes.

Service Model - F5 Expression

Ok, we've covered a lot. It's time to tie all of this together with some specific examples. This final slide shows an example of how to implement all the Attributes we've discussed 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

1 Model down, 2 to go! Next we'll cover the Deployment Model. Thanks for reading!

Next Article: The Deployment Model for Cloud/Automated Systems Architectures