Home > Blogs > vCloud Architecture Toolkit (vCAT) Blog


vCAT 3.0 Implementation Examples Changes

Now that vCAT 3.0 has been released, it is worthwhile to discuss the obvious as well as the more subtle changes that are a part of this release and specifically the Implementation Examples document.  One of the key guidelines that we adhered to while writing vCAT was to be careful not to operate in a bubble. In other words, the authors tried to always be cognizant of why they were writing these documents.  One of the primary reasons behind writing these documents is simply to make the jobs of cloud architects and engineers a little easier.  In order to do this we listened to feedback from the field that would ultimately be consuming these documents. Three pieces of feedback based on previous versions of vCAT that were directly incorporated into the Implementation Examples document were:

  1. The document has a lot of information and readers are not always sure where to go for a specific task they need to accomplish.
  2. The document is a large monolithic representation of one very specific design example, which reduces its value to those without the same exact business requirements or constraints.
  3. While the document has very specific guidance and information about vCloud Director, what about other complimentary products in what is now the VMware vCloud Suite. Readers wanted more information on the integration and coexistence of VMware products such as vCenter Chargeback Manager, vCenter Operations Management Suite, vCenter Orchestrator or vFabric Application Director with Cloud.

I am very happy with what the team has been able to accomplish in this release. Both from a content perspective but also for the structural changes that were made that will pave the way for more interesting and relevant user stories to be seamlessly integrated in subsequent releases.

To address the first two pieces of feedback we changed the structure to be more modular in nature so each work product represented a specific feature, technology, or configuration.  These work products are then organized into design areas such as storage, networking, security or monitoring.   Each work product stands on its own and is provided in the context of a specific deployment model such as private, public, or hybrid.  In order to maintain consistency, each example or work product within the document contains the following information.

  • Deployment Models – Deployment models for this technology example (Private, Public, Hybrid).
  • Example Components – The required software components and versions. For example: vSphere 5.1, vCloud Director 5.1.
  • Background – Background and overview for the specific technology example.
  • Example – The actual example implementation of the technology or feature in the context of a specific use case.
  • Design Implications – Information to consider when using the technology or feature.

Aside from the fact that our readers should be able to quickly and efficiently find the information they are looking for, the new format should enable two other things:

  1. Because each work product stands alone, we can document different ways of implementing a feature or technology and our readers can decide which way works best for them.  For instance, we include different methods for providing network isolation for network pools such as VCDNI, VLANs, or VXLAN.
  2. Our readers can mix and match the design elements to help build a VMware Cloud that meets their specific needs.

To address the third piece of feedback, this release incorporates sections that involve integration, orchestration, security, and monitoring using multiple products in the VMware vCloud Suite. This only makes sense as Cloud computing is a way of providing and consuming services and will almost always involve customization and integration with other products both inside and outside of the VMware portfolio.

 

 

 

 

 

2 thoughts on “vCAT 3.0 Implementation Examples Changes

  1. Nigel Hardy

    One of the new features of vCloud Director 5.1 is the ability to use multiple storage profiles from a single Provider VDC, thus providing the option to supply different storage tiers without having to tie each of them to a separate Provider vDC. This gives a single Provider VDC tiered storage capability.

    However, page 39 of “Architecting a VMware vCloud” in the vCAT 3.0 says:
    Storage tiering is not possible within a provider virtual datacenter. Instead, supply tiered pools of storage through multiple provider virtual datacenters

    Is this an out-dated comment related to vCloud Director 1.5.1 rather than 5.1?

  2. Thomas Kraus Post author

    You are correct, we can in fact provide differentiated tiers of storage within a single virtual datacenter in vCloud Director 5.1. I will have someone take a look at this and if there is a problem we will address it in a point release.

Comments are closed.