Private Cloud Architecture

Since I started my journey with Virtualization in 2005, I knew this technology would initiate a long-term transformation journey in IT. Server virtualization has proven to be a versatile tool from its early days, serving a multitude of use cases beyond the well-known consolidation function.

Server Consolidation was the first use case for virtualization in the data center because it was easy to understand: fewer servers = less maintenance, less capital investments, etc.

However, the actual use cases came from harnessing virtualization's power to previously manual and complex tasks.

The first example I encountered was Disaster Recovery.

Until the age of virtualization, Disaster recovery was a complicated task. Syncing the OS State with the running applications was unreliable, causing data loss and an inability to validate data reliability in the DR site.

Virtualization, in its simplest form, as an ESX server with a couple of simple scripts, allowed customers to move a complete VM (OS and APP) in a specific state to a DR site and validate its reliability in the DR site to 100% guarantee.

After a while, new tools and methodologies came along, making it an automated and distributed service for IT.

This opened my eyes to the fact that virtualization can be used for many other purposes in the IT environment.

This notion of use case fulfillment continued with the introduction of the Virtual Data Center (ESX+VC) and the Software-Defined Data Center (Compute, Storage, Network virtualization); with each framework, future, and solution, we fulfilled more and more use cases in our Customers Data Centers.

However, something still needed to be added; it felt like a bottleneck that prevented our customers from getting the most out of the SDDC framework. It took me a while to figure out, but the hype about moving everything to the public cloud a couple of years ago showed me what was missing.

Back then, most customers who started using public clouds had one of these three initiatives.

• Shadow IT – giving developers their funds to use public cloud resources.
• A dedicated team within IT – Yet another SILO that was developing its tools and methodologies to use public cloud services.
• An outsourced or external team – particularly when the use case was developing an app in the public cloud that had nothing to do with the local IT team.

In all of these cases, the local IT team was left out of the decision-making and, most of the time, described as an “Obsolete” or “Legacy” with an expiration date.

What was the difference between these “Public Cloud” teams and the local IT? From my perspective, it was the Operating Model. These “Public Cloud” teams had no option but to embrace the cloud operating model, act as service consumers, and sometimes act as service providers in different circumstances.

So, it became clear that a service provider operating model needed to be included between our SDDC framework, which enabled Private Cloud for our customers long before we even talked about it, and the Siloed IT Approach, which still exists within most customers.

Changing an Operating model is changing how IT works, thinks, develops, and deploys its services. It’s a massive change for a customer that involves time, spending, and dealing with local policy and politics.

But there is no other option. A Cloud, whether private, public, or hybrid, is not a place, a product, or a framework; a Cloud is an Operating model.

Considering that enlightenment, I started to think about how we can help our customer’s IT departments become Cloud Providers.

So, the first thing we need to do is concentrate on a private cloud approach. Why? First, this is where most of the customer’s intellectual property lies. Second, if we can transform our local data centers into private clouds, embracing hybrid and public resources will be much easier and more transparent. Third, there is no other way. The world of IT is moving fast into cloud consumption models. A customer not embracing this new operating model will soon find itself outside the mainstream for apps and data management.

Right after we embraced the Private Cloud Approach as the way to go, we needed to start thinking like a service provider.

?

A service provider has two main sides: the provider and the consumer. The provider creates and maintains services according to business needs and publishes them for consumers. The consumers can then use the services available to them without caring about resources, maintenance, security, or the complexity of the implementation.

?

More Services = a more mature cloud that serves more business initiatives and fulfills more use cases.

VMware Cloud Foundation is our framework for enabling the Private Cloud. In a private cloud, there can be provider and consumer services.

Provider Services: these are services used mainly by the provider side to maintain, upgrade, patch, increase/decrease capacity, and assign policies.

Consumer Services: These are services deployed and used by specific consumption groups to fulfill a specific use case. They can be anything from deploying an app to a complete platform like K8S or a data source; they can also be a day operation, such as increasing capacity or changing the configuration of an app or platform.

In VCF, most provider services come right out of the box. Provisioning/increasing/decreasing consumption, setting policy for compute storage or network usability, creating stretch clusters, and DR scenarios are all part of the product and can be implemented as Provider Services on day 1 with minimum effort.

Provider Services are essential to make our private cloud agile and have capacity whenever our consumers demand it.

Implementing provider services is the first stage in which we must consider transforming to a private cloud operating model.

The Silo Approach of having Compute, Network, and Data separately managed does not work here anymore.

Instead, we now have “capsules” of all components in virtual data centers that can be used as Workload Domains for our consumer’s apps and platforms.

Each workload domain is a subset of Compute, network, and data storage and needs to be maintained as one logical unit by the service provider.

This means that the Compute, network, and storage departments need to slowly become transparent to each other and work together to ensure that the logical workload domain maintenance meets the defined SLA.

We can start by having a small team of architects from each department work together to create and document the new operating model and slowly add more people.

Once we have a stable Provider Platform that can be maintained, we can start identifying the consumer services. To do that, we have developed the Future State Discovery framework, which helps our account teams and customers identify business cases, use cases, services, operating models, and their relationships. Whiting the Future State Discovery, we use discovery methodologies, definitions, and the Intention Map to Discover, Sort, and validate the service landscape.

?

?

After Drawing and validating the intention map, we can select a “leaf” from it and create a Future State Architecture. The Future State Architecture is a forward-looking statement and has five stages:

1. Mapping the current state - Capture existing processes, challenges, and relevant roles to the designated project.
2. Problem Statement - Identify the main issue that the customer defines as a problem and the risks it poses.
3. Mapping the Future State: Outline your desired outcomes and vision, setting the stage for your aspirations.
4. Conceptual Design - Compare the current and future states to identify gaps, opportunities for improvement, or areas requiring additional resources. Articulate the solution in a conceptual solution architecture
5. Review & Optimize - Review your offering with key stakeholders to optimize and identify gaps.

Creating a Future State Architecture helps us to pinpoint the specific use case we are trying to fulfill by specifying how to develop, publish, and maintain the service or set of services that satisfy it.

Both the Future State Discovery and Future State Architecture frameworks help us define the objectives, priorities, and actions toward a healthy Cloud Operating model, transforming IT into a service provider; it has been proven successful with many types of customers and is being practiced by most Broadcom field engineers. After many years of trying to outsource IT and relocate it to the public cloud, many organizations today realize that the Private Cloud is the most cost-effective, accessible, and fastest-to-market cloud approach.

However, with that, IT organizations need to embrace the private cloud operating model by prioritizing the transition to a cloud provider approach. This transition has many aspects that Broadcom field architects can help you with, regardless of your size or stage.