Modernizing Automation for Data Center and Edge

Don

Thanks for joining me today. To kick us off, where are you today in your evaluation of Dell Automation Platform and automation in general?

Kip

We’re actively modernizing. Today we have a mix of manual processes and some homegrown automation—mostly scripts and a few tools tied into our ITSM platform. We’ve evaluated a couple of commercial automation products, but nothing has really covered both data center and edge for us. DAP is on our shortlist as we look for something more standardized and enterprise-grade.

Don

That's great! So when you think about deploying a platform like DAP, what deployment models are you open to—SaaS, on-prem, hybrid? And what would you see as the pros and cons of each in your environment?

Kip

SaaS is attractive from an operations standpoint—less to manage, faster updates—but some of our environments aren’t allowed to reach the internet. Um...on-prem gives us more control over data residency and integration with internal security tools, but then we own the care and feeding. A hybrid model is likely where we’ll land: central SaaS or data center control with on-prem components for our more sensitive or disconnected sites.

Don

That’s a good segue into topology. Can you describe your different site types—for example, connected, tightly controlled, and dark or air-gapped—and roughly how many of each you have?

Kip

Sure. We have three main categories. First, two large core data centers that are well connected and fairly flexible from a policy perspective. Second, around 30 regional sites—those are tightly controlled, behind strict firewalls, but still have limited internet access. And third, about a dozen truly dark or air-gapped sites, mostly in regulated or remote locations, where there’s no direct internet access and everything in and out is tightly governed.

Don

At each of those site types, what specific security or connectivity constraints—no outbound internet, strict proxy, data residency rules—would a DAP deployment need to respect?

Kip

In the data centers, we can accommodate outbound internet through our corporate proxies as long as we can whitelist destinations and keep traffic observable. At the regional sites, all egress goes through a regional proxy with additional inspection, so anything cloud-based has to be very predictable in terms of endpoints. For the air-gapped sites, there’s zero outbound connectivity. Everything has to be staged through controlled transfer processes, and data residency is strict; logs and inventory data can’t leave those environments without review.

Don

Let’s talk about installation options and prerequisites. What does your current virtualization and container landscape look like—primarily VMware, Kubernetes, or a mix?

Kip

It’s mostly VMware in the data centers today—vSphere across the board—with some Kubernetes clusters that our dev teams run on top. At the edge, it’s a mix of smaller VMware clusters and some bare-metal. We’re increasing our Kubernetes footprint over the next couple of years, but VMware will still be the dominant platform for at least the medium term.

Don

For an on-prem deployment, what infrastructure could you realistically dedicate to DAP—compute, storage, network—and what internal standards or prerequisites do you have for adding a new platform?

Kip

Typically, we carve out a small, highly available cluster for strategic platforms—think 3 to 4 nodes with shared storage. We’d expect DAP to fit into that model or leverage an existing management cluster. From a standards perspective, we require integration with our corporate identity provider, centralized logging, and our backup solution. There’s also a formal security review before any new platform is introduced.

Don

Switching to network dependencies, how is access to iDRAC and other out-of-band management handled today—centralized, per site, or restricted?

Kip

It’s mostly centralized within each region. We segment iDRAC and similar management interfaces onto dedicated management networks, and access is brokered through jump hosts and privileged access tools. In some of the smaller sites, access is more local, but we’re trying to standardize around centralized, role-based access wherever possible.

Don

Let's talk about the requirements that shape your architecture. How do your DNS and proxy architectures look? Are there any specific rules or zones a platform like DAP would have to work within?

Kip

DNS is split-horizon. Internally, we have regional DNS servers that handle local zones and forward out for anything else. From the proxy side, all H.T.T.P./H.T.T.P.S. egress goes through authenticated proxies with very tight ACLs. We often have to pre-register any new SaaS platform so its endpoints can be allowed. For DMZ or OT networks, we sometimes use separate DNS and don’t allow direct proxy access at all.

Don

Can you tell me about Day-2 operations? How frequently do proxy settings or network egress rules change, and how are those changes managed or communicated?

Kip

Proxy configs don’t change daily, but when we have security events or major policy updates, we can see significant changes a few times a year. Those are managed through our network and security teams and communicated via change management. The challenge is that tools that require hardcoded proxy details or fixed egress patterns can break when these changes roll out.

Don

Have you had prior issues with SaaS or management tools breaking after Day-2 network changes? And what would you need from DAP to feel confident that won’t happen again?

Kip

Yes, we’ve had tools lose connectivity because their outbound endpoints changed or weren’t properly documented. To be comfortable with DAP, we’d want a clear picture of what it needs to talk to, support for proxies and certificates, and good observability—health checks, alerts—so we see issues before they impact production automation.

Don

Let’s get into licensing, especially for connected vs. dark sites. How do you typically manage licensing today in partially connected or disconnected environments?

Kip

For connected sites, it’s pretty standard—license servers or online activation. For disconnected environments, we use offline license files or periodically sync via controlled transfers. We try to avoid any solution that requires constant call-home from dark sites.

Don

And around license validation and updates for dark or intermittently connected sites, what are your expectations or constraints?

Kip

We’d want a model where we can pre-stage licenses and have a generous grace period. Ideally, dark sites could run autonomously for months and only require occasional, planned updates. Anything that demands continuous connectivity or frequent online validation would be a non-starter.

Don

Related to that, let’s talk catalog and blueprint updates. How important is it for your air-gapped sites to receive frequent updates versus more periodic, controlled updates?

Kip

For those sites, stability is more important than having the absolute latest blueprint. We’d be fine with periodic, scheduled updates—quarterly, for example—as long as we can test everything in a non-production environment first. We definitely wouldn’t want surprise changes in those environments.

Don

Can you tell me about the mechanisms you currently use to move content into air-gapped environments—offline media, controlled file transfers, or something else?

Kip

We rely on controlled file transfers. That usually means a staging environment with virus scanning and manual approval, then copies onto encrypted media for physical transport, or a tightly controlled one-way connection. Everything is logged and audited.

Don

Let's talk about onboarding new hardware: what does your current provisioning process look like in your core data centers versus remote or lightly staffed sites?

Kip

In the data centers, we have established runbooks and some scripting. It’s semi-automated but still involves a fair bit of manual coordination. At remote sites, it’s much more manual—often a local technician racks and cables the gear, then our central team walks them through the rest over a call. That can be time-consuming and error-prone.

Don

Can you tell me where you feel zero-touch provisioning would deliver the most value for you, and where you are comfortable with more manual workflows?

Kip

Zero-touch would be huge for the remote and lightly staffed sites. If we could ship hardware, have someone plug it in, and then let DAP handle the rest, that would be ideal. In the core data centers, we’re okay with some manual steps as long as the repeatable parts are automated. We just want fewer tickets and less human error.

Don

If we were to create a readiness checklist for DAP, what internal teams, like the network, security, virtualization, and operations teams, would need to be involved on your side?

Kip

At a minimum, networking, security, and the virtualization team. We’d also involve our infrastructure operations team and probably someone from compliance, given our regulated environments. For the edge, OT or plant IT might need a seat at the table as well.

Don

Are there any standard checks or approvals—security reviews, change management windows—that we should factor into that checklist?

Kip

Yes, any new platform goes through a formal security assessment, followed by a change advisory board review for the actual deployment. There are also maintenance windows for production changes, especially at the larger sites. If DAP touches regulated environments, additional compliance sign-off is needed.

Don

Let’s talk edge cases and “gotchas.” Do you have any unusual network or platform designs—dual-homed systems, special ISO hosting patterns, custom DNS behaviors—that we should be aware of?

Kip

We do have some dual-homed servers sitting between IT and OT networks, and a few custom DNS behaviors where name resolution differs by segment. We also host OS images in a couple of non-standard ways at the edge due to bandwidth constraints. Those are the kinds of areas where tools can trip up.

Don

Have you run into any gotchas with other automation or management tools that you’d want us to avoid repeating with DAP?

Kip

The biggest ones have been assumptions about always-on connectivity, lack of proxy support, and rigid deployment models. We’ve also seen tools that were great in the lab but didn’t handle our scale or security requirements in production. We’d want DAP to be flexible in those areas and to have a clear path for supporting exceptions.

Don

How do you typically handle platform deployments overall—do you prefer to do them internally, work jointly with a vendor, or rely primarily on services?

Kip

We like a joint approach. Our teams want to learn and own the platform long-term, but we also value vendor expertise—especially for initial design and best practices. So we typically start with vendor-led or joint deployment and then transition to internal ownership.

Don

For DAP specifically, what scope of Dell Services involvement would be most helpful—design only, implementation, or ongoing operations?

Kip

Design and initial implementation would be ideal. We don’t necessarily need Dell to run it day-to-day, but having Dell help us set it up correctly, integrate with our environment, and get our teams trained would accelerate adoption and reduce risk.

Don

Thinking about scale, how many data centers and edge locations are in scope for DAP, and how interconnected are they from a network perspective?

Kip

We have two main data centers, those 30 or so regional sites, and the dozen dark sites I mentioned. The data centers and regional sites are fairly well interconnected over the network. The dark sites are more isolated, with constrained or no connectivity.

Don

Would you prefer a more centralized model—fewer orchestrators to manage—or a more distributed model with an orchestrator per site for resilience and autonomy? And why?

Kip

For the well-connected sites, a centralized model makes sense—we want fewer moving parts. For the more constrained or critical sites, a distributed model with local orchestration is appealing; it reduces latency, dependency on the Wide Area Network, and gives us autonomy if links go down. So we’re likely looking at a hybrid approach.

Don

Let’s touch on storage. What storage platforms are most critical in your environment today, and which ones would you expect DAP to be tightly integrated with versus simply compatible?

Kip

Our primary platforms are Dell PowerStore and PowerFlex in the data centers, and some PowerEdge-attached storage at the edge. We’d expect tight integration—full lifecycle automation, snapshots, maybe replication workflows—with our core Dell storage. For third-party or legacy storage, basic compatibility for provisioning would be enough.

Don

From your perspective, what capabilities define “integrated” storage behavior versus just “compatible”?

Kip

Integrated means deep, API-level awareness: creating volumes, attaching them to hosts, managing snapshots, handling performance profiles, maybe even driving replication or DR workflows. Compatible is more like “DAP can deploy a host and then call a script or an external tool to handle storage,” but it’s not deeply aware of the storage platform’s capabilities.

Don

Looking at HCI, which HCI platforms are you running today, and what are your timelines and drivers for migration or modernization?

Kip

We still have a fair amount of legacy HCI from a previous vendor, mostly in our regional sites. Over the next 18–24 months, we plan to standardize on Dell for both HCI and more traditional architectures, mainly for support consistency and better integration across the stack.

Don

Are you looking for DAP to orchestrate a one-time migration, ongoing workload mobility, or both? And what risk or rollback expectations would you have?

Kip

Both, ideally. We need structured, low-risk migrations off the old platforms, with clear rollback options. Long term, we’d like the ability to move workloads between clusters or sites more easily, especially for maintenance or DR. Any automation around that would need clear checkpoints and the ability to roll back safely if something goes wrong.

Don

To wrap up, if we use a Discover / Assess / Design / Deploy (D.A.D.D.) journey, where do you feel you are today with respect to DAP—mostly discovering, already assessing, or further along?

Kip

I’d say we’re between discover and assess. We understand the high-level value, and now we’re really trying to map DAP to our specific requirements—especially around connectivity, security, and edge use cases.

Don

And what would you see as the most valuable next steps with Dell: deeper technical workshops, a focused assessment, a reference architecture/design session, or a pilot/POC in a specific site?

Kip

A focused assessment followed by a reference architecture session would be the best sequence. From there, we’d like to move into a targeted POC at one of our regional sites to validate the deployment model and a couple of key use cases, including zero-touch provisioning and operations in a constrained network environment.

Don

That’s great input. Thanks for walking through all of that—this gives us a clear picture of where DAP can help and how we should shape the engagement.

Kip

Thanks, Don. We’re looking forward to seeing how DAP can fit into our roadmap and simplify operations across both the data center and the edge.