A Tale of Two Architecture Models

When designing clouds for customers and partners, Canonical Consultants and Architects follow a standard process that creates designs based upon use-cases and requirements. Over the years working with many thousands of customers and partners, we have zeroed in on two Cloud Architecture Models that serve as the base for many of our designs.

The Hyperconverged Model is the default model used in our Canonical Cloud Reference Architecture and is what all technical sales conversations are started with.

But, as we delve deeper into those discussions, either through pre-sales activities or via paid consulting engagements, it may be determined that another model, the Disaggregated Model should be used.

The primary difference between the two, as you will see in the diagrams below, is service placement on physical hardware. Other key differences abound and are also important to help drive the final outcome of design workshops with customers.

While both models have pros and cons, the use-case & requirements we gather while working with customers ultimately decides which model we will go forward with.

Hyperconverged Model

Hyperconvergence is a type of infrastructure  with a software-based architecture that tightly integrates compute, storage, networking and virtualization resources and other technologies on commodity hardware.

Typical Use Cases of the Hypercoverged Model

The primary use cases for the Hyper-Converged design model are Public Cloud, General Purpose or starter clouds on premises.  The cost savings in management and operations costs alone can make it a great choice for many reasons or uses:

• Public Clouds
• General Purpose Clouds
• Proof of Concepts
• Development Labs
• Non-specific workloads
• Customers who want to test vast amounts of different services and technology
• Customers who expect large services growth rates and need to scale out quickly
• Customers unsure or undecided of application stack

This model is generally more efficient requiring fewer physical servers to provide the required capacity, however, it can carry additional cost as it’s not optimized for any particular type of workload.  For clouds where the diversity of workload is very low, alternate architectures may offer greater potential for performance tuning.

Disaggregated Model

Disaggregation takes cloud architecture a step further and targets the processing, memory, networking, and storage subsystems which make up every system. Disaggregation is really attractive among hyperscale providers which see disaggregation is a way to achieve more flexible systems and fewer underutilized resources.

Typical Use Cases of the Disaggregated Model

The use cases for the Disaggregated Model is customers who know what workloads will be deployed and understand how to tune the environment for those applications.  A customer may have one workload that is CPU bound while another demands low latency networking or high-performance storage.  When choosing between the Disaggregated Model and the Hyper-converged model, the latter is less efficient to grow the cloud that is optimized for these workloads, especially if they grow at different rates.

Use Cases where the Disaggregated Model work best are:

• NFVi Clouds
• Storage Clouds
• HPC
• Other Specialized Workloads

The Disaggregated Model gives the customer flexibility to grow the cloud in a more optimized way based on a specific workload. It requires more detailed knowledge of workload and takes more thought to scale out.  The payoff of knowing these two is going to be a more efficient cloud for the price.

When to choose which model?

The flexibility of cloud workloads, in general, makes the hyper-converged model a great starting point.  For clouds where the diversity of workload is very low and more specialized, the disaggregated architecture model may offer greater potential for performance tuning.

NFVi cloud architecture designs, for example, are best served by the disaggregated model. In the case of NFVi,  many vendors of VNFs require the cloud infrastructure to be specialized and tuned to give the highest performance and to attempt to reach as close to line rate speeds as possible. Some machines may be tuned and/or built for VNFS that would require SR-IOV and DPDK while others may be used for VNF management backplane and be less powerful. Again,  it all will depend on the use-case and requirements of the customer.

Changing Models on the Fly

But what if my use-case or requirements change? How do I reuse hardware that I have already purchased? I do not want to go out and spend hundreds of thousands of dollars on another purpose-built cloud.  Juju and MAAS to the rescue!

If you haven’t heard about Juju, it is Canonical’s tool for modeling, deploying, and operating Big Software.  One such Big Software Stack is Canonical OpenStack(OpenStack,Ceph, Swift, etc.). It has the innate ability to re-deploy a cloud architecture at any time. In parallel, MAAS has a complete picture of my physical infrastructure that allows me to redeploy operating systems, reconfigure networks, and do other cool stuff that I would otherwise have to manually do.

We find Juju and MAAS extremely useful when we are testing and validating designs as we are working with customers.  Our labs only contain a limited set amount of hardware with a very generic hardware configuration. Juju and MAAS combined give me the ability to repurpose that hardware, redeploying either model quickly and efficiently.

It’s as simple as

juju deploy customerdesign_hyperconverged_version.yaml

or

juju deploy customerdesign_disaggregated_version.yaml

whereas the YAML file will have a complete description of how services should be placed, configured, and deployed on our lab hardware. This means I can redeploy without having to run through a large amount of steps to repurpose that hardware or have two sets of hardware laying around for testing.

Conclusion

Simply put, cloud designs and deployments can be boiled down to two discrete models. Hyperconverged for general purpose computing where workloads are generic and forgiving or Disaggregated where workloads are more specialized requiring higher levels of performance.

Using a use-case, requirements-driven approach to design has simplified and shortened delivery of clouds to our customers. Ultimately, it has allowed us to streamline and reduce our architectures down to two models which drive designs that match customers vision and business case more closely.

Special  Thanks

This blog post was co-authored with Chris DeYoung who is one of my co-workers and team members on the Canonical Consulting Architect Team that I lead.  A very special thanks to Chris for his contributions to this post and for his help with creating the cleaner diagrams.  He, along with other members of my team, are some of the best High Touch Domain Architects in the world. Check him out here:  https://www.linkedin.com/in/christiandeyoung