Part 2: MCP Is Interesting. Everpure Fusion Makes It Useful.
In Part 1, I tried to give MCP a proper “…splanation,” mostly because the first several times I heard people talking about Model Context Protocol, I had the same look Joey had in Friends when the salesman asked him if his friends ever had a conversation and he just nodded along without really knowing what they were talking about. That was me. MCP this. MCP server that. Agentic AI. Tool calling. Context windows. Protocols. Hosts. Clients. Servers. At some point, I realized I was nodding with the confidence of a man who had understood approximately 41% of the conversation and was hoping nobody asked a follow-up question. The simple version is this: MCP is a standard way for AI applications to connect to tools and data. It is not the AI model itself. It is not the magic brain. It is the plumbing that lets the AI reach into approved systems, ask better questions, retrieve useful context, and potentially take action through well-defined tools. That is important in the abstract. But for Everpure customers and prospects, it becomes much more interesting when we stop talking about MCP as a general AI concept and start talking about what it could mean for storage operations, data infrastructure, and Everpure Fusion. Because this is where the conversation moves from “AI is coming someday” to “your infrastructure may already need to be ready for how AI will interact with it.” Everpure recently published a blog with a sneak peek of the Everpure Fusion MCP Server, describing it as an open-source service that connects AI assistants to Everpure Fusion storage fleets through the Model Context Protocol. The important part is not simply that an AI assistant can talk to storage. That would be interesting, but it would also be easy to misunderstand. The important part is that the assistant can interact with the storage environment through the Fusion control plane, which already understands fleet-wide context across FlashArray and FlashBlade. That distinction matters. Without Fusion, many environments are still managed in a way that looks very familiar to anyone who has spent time supporting infrastructure. One array over here. Another array over there. Scripts in one folder. Notes in another. Naming standards that started strong and then apparently met reality. Screenshots in tickets. Tribal knowledge in the heads of a few people who somehow remember which workload lives where, which array is doing what, and why nobody should touch that one volume because “there was a reason,” even if nobody is entirely sure what the reason was anymore. That model may work, but it does not scale gracefully. More importantly, it is not especially friendly to automation, and it is definitely not ideal for AI-assisted operations. Most troubleshooting in mature environments is not hard because people lack tools. It is hard because the context is not immediately obvious. The storage admin has one view. The DBA has another view. The virtualization team has another view. The application owner has a completely different view, usually delivered through a ticket that says something deeply scientific like “the app feels slow.” Everyone may be looking at a valid piece of the puzzle, but the real work is in the correlation. Which volume maps to which workload? Which array is hosting it? What did latency look like during the reported window? Were IOPS elevated? Was bandwidth constrained? Did anything change recently? Are we looking at a storage issue, a database issue, an application issue, a noisy neighbor, a misconfigured VM, a bad query, or just another case of “the network is innocent until proven guilty, but still somehow looks suspicious standing there”? That is where Fusion and MCP together become compelling. The Everpure Fusion MCP example makes the idea real. Instead of forcing an administrator to manually build low-level REST API calls or jump between tools, the MCP-aware AI assistant can query Fusion through higher-level tools exposed by the MCP server. In the example Everpure blog described, a storage admin can ask about workloads and volumes supporting a production SQL environment, including arrays, IOPS, latency, and bandwidth over a recent time window. The assistant can then correlate that storage perspective with information from another MCP server, such as SQL Server context around database files, wait types, and query behavior. That does not mean the AI replaces the storage admin. It does not mean the AI replaces the DBA. It does not mean everyone goes to lunch while the robot fixes production. And this is where I need to bring in The Big Bang Theory again, because apparently this is who I am now. There is a scene in the show where Raj is very open to the idea of aliens and extraterrestrial life. At the planetarium, Raj can look at flashes of light in the sky and talk about how scientists cannot fully rule out the possibility of alien civilizations. It is funny because Raj is a scientist, but he is also Raj, so the line between rigorous possibility and “maybe the aliens are waving at us” gets wonderfully blurry. That is how some people talk about AI operations right now. A light flashes in the sky, and suddenly someone is ready to announce that the robots are here to run the data center. Let’s not do that. The point is not that the AI is an alien civilization arriving to take over infrastructure operations. The point is that the interface is changing. The way humans interact with infrastructure is starting to move from manual lookup, command execution, and tribal knowledge toward assisted reasoning, guided action, and cross-system correlation. That is much more practical than aliens. It is also much more useful. Fusion already gives customers a fleet-wide control plane. It gives you the ability to think above individual arrays, above one-off configuration, and above the old habit of managing infrastructure like every system is its own little island with its own weather pattern. MCP gives that control plane another interface, one designed for the way AI agents work. This is why Fusion adoption matters. If your environment is still managed mostly array by array, script by script, ticket by ticket, and screenshot by screenshot, then AI can only help so much. It may summarize the pain beautifully, but it is still summarizing pain. When you use Fusion to create a more consistent, policy-driven, fleet-aware operating model, you are not just modernizing storage management. You are making the environment more understandable to automation, to operations teams, and now to AI agents that need structured context in order to be useful. That is a very different conversation from “look, the AI can query storage.” The better conversation is this: if AI is going to become part of operational workflows, then your infrastructure needs to be ready to participate in those workflows. Fusion is one of the ways you prepare for that. Not someday. Now. And Fusion is not the only example of this direction. Another Everpure technical article shows how an MCP server can be built to integrate with FlashBlade, allowing an AI assistant to query system data and even take direct actions through a natural-language interface. That example is useful because it shows the bridge between the old world and the new one. In the old world, storage management often meant CLI commands, scripts, API calls, screenshots, and specialized knowledge living in the heads of a few very tired people. In the new world, those capabilities can be surfaced through an AI-assisted experience that understands the available tools and can help operators ask better questions in plain English. Again, that does not mean the AI should blindly run your infrastructure while everyone disappears. Please do not read this article and tell your change advisory board that “the blog guy said the robot can handle it.” That is not the point, and I would like to remain welcome in polite infrastructure society. The point is that the operational model is changing. For years, we have talked about automation in infrastructure, but a lot of what we called automation still required a human to know exactly what to automate, where to look, which command to run, which script was safe, which API endpoint mattered, and which piece of documentation had not quietly aged into fiction. AI-assisted operations changes the interaction pattern. Instead of always beginning with the operator knowing the exact command or API call, the operator can begin with the question. Why did this workload slow down? Which volumes support this application? What changed in the last four hours? Which arrays are carrying the highest latency? Which workloads are consuming the most bandwidth? Which policies are inconsistent across the fleet? Where do we have capacity pressure? Which storage objects are tied to this SQL environment? Those are the kinds of questions humans actually ask when something is happening. MCP gives AI assistants a standard way to ask approved systems for the data behind those questions. Fusion gives the storage estate a more consistent, policy-aware, fleet-level way to answer. That combination is where the opportunity lives. Now, because this is enterprise technology and not a children’s book, we also need to talk about the dangerous part. One of the readers posted this comment on Linked in yesterday: The moment an AI system can access tools and data, the conversation changes. A chatbot that gives a bad answer is annoying. An agent that takes the wrong action in a business system can become a real incident. If a model can read sensitive files, query databases, send messages, modify records, trigger workflows, or touch infrastructure, then security is not a feature. Security is the premise. This is where some of the MCP enthusiasm needs adult supervision. We have spent years telling users not to click strange links, not to approve unknown applications, not to reuse passwords, and not to download random files. Now we are building systems where an AI assistant might read strange content, call external tools, and act on behalf of the user. That can be incredibly powerful, but only if we are honest about the risk. In some ways, MCP may expose organizational problems faster. If your data is scattered, stale, contradictory, or politically curated, an AI agent connected to it will not magically produce truth. It may simply produce a more polished version of the confusion. If your workflows are unclear, connecting AI to them may help automate the ambiguity, which is not quite the same thing as progress. The model can gather information, call tools, and complete steps, but people still need to define what should happen, what should not happen, what requires approval, and what good looks like. For Everpure customers and prospects, the more important question is not whether MCP is interesting. It is whether your environment is ready for this kind of interaction. That is where I would encourage customers to take a serious look at Fusion. Not because Fusion is another checkbox on a feature list, and not because every new technology conversation needs to end with someone saying “platform” three times into a mirror. Fusion matters because it changes the operational model. It gives you a way to manage data infrastructure as a fleet, with policy, consistency, automation, and context. Those are exactly the things AI agents need if they are going to do more than produce nicely formatted guesses. If you already met all the prerequisites (Purity 6.8.+, LDAP enabled), use it. Explore it. Get comfortable with it. Stop thinking about Fusion as something reserved for a future automation project after everyone finally gets through the current list of fires, renewals, upgrades, and meetings that should have been emails. MCP may be the plumbing that helps AI connect to the enterprise. Fusion helps make the storage environment worth connecting to. And that is the real call to action. Fusion is how Everpure customers make sure their data infrastructure is ready for it. Appreciate you reading. Dmitry Gorbatov © 2025 Dmitry Gorbatov | #dmitrywashereMCP, Joey Tribbiani, and the Moment AI Needed Plumbing - Part 1
People close to me know that I have a very annoying habit of memorizing, remembering, and using movie and TV show lines in normal conversation. I wish I could tell you this is a carefully curated personality trait, but it is probably closer to a long-running defect in the #dmitrywashere operating system. Some people remember birthdays. Some people remember where they parked. I remember a line from a sitcom episode that aired before half the people reading this had a LinkedIn profile. My two favorite sources are Friends and The Big Bang Theory, which probably says something about me that I am not emotionally prepared to unpack in public. There is a scene from Friends that has lived rent-free in my head for years, mostly because it captures something deeply human and mildly embarrassing. A salesman is talking to Joey and asks him a question that is both funny and a little too accurate: “Let me ask you one question. Do your friends ever have a conversation and you just nod along even though you’re not really sure what they’re talking about?” Joey, of course, immediately zones out. Not metaphorically. Not politely. He disappears into that wonderful Joey place where the mouth stays closed, the face stays agreeable, and the brain has clearly left the building. That was me the first few times I started hearing people talk about MCP. Not once. Not twice. Everywhere. MCP this. MCP server that. MCP is the future of agents. MCP is the USB-C of AI. MCP is how models connect to tools. MCP is the protocol that will make agentic AI real. MCP is the standard. MCP is the integration layer. MCP is the thing everyone apparently understood already, except somehow nobody had bothered to send me the memo. So I did what any responsible technology professional does in that situation. I nodded thoughtfully. The next thing I did was call my son, who is a Data Scientist, and ask him what MCP actually was. After listening to his explanation, I had the uncomfortable realization that he knew more about it than I did, which, naturally, did not feel great. That was just my ego talking, of course. He is way smarter than me. Then I went away and tried to figure out whether MCP was actually important or whether it was just another acronym that had wandered into the AI conversation wearing a conference badge. And that brings me to the other sitcom line that kept popping into my head while I was trying to explain this to myself. In The Big Bang Theory, there is a scene where a very drunk Penny says, “I think I owe you …splanation,” clearly attempting to say ‘explanation’ while her brain and mouth are no longer managed by a ‘unified control plane.’ That is exactly how MCP felt to me at first. I did not need another acronym. I needed a …splanation. A real one. Preferably in English. Preferably without requiring a PhD in distributed systems, three browser tabs of developer documentation, and someone on YouTube drawing boxes and arrows while saying “obviously” before explaining the least obvious thing I had heard all week. So this article is my attempt at that …splanation. After spending time researching MCP, I think it is important. More importantly, I think it is important in a very practical way. It is not the kind of important that requires everyone to become an AI researcher, read white papers at midnight, or pretend that “agentic workflow orchestration” is something normal people say at dinner. MCP matters because AI is moving from something that talks to something that can actually do work, and doing real work requires access to real systems. That is the part worth slowing down for. Most people first experienced modern AI as an LLM chat bot window. You typed something in, and the model responded. Sometimes the answer was impressive. Sometimes it was useful. Sometimes it was wrong with the confidence of a man giving directions in a city he has never visited. But the basic pattern was easy to understand. You asked a question. The LLM answered. That was the product experience. The problem is that most real work does not happen inside a blank chat box. Real work lives in messy places. It lives in documents, calendars, databases, code repositories, CRM systems, ticketing tools, emails, Slack messages, service logs, storage platforms, cloud consoles, spreadsheets, procurement systems, and all the other places where business reality hides after the meeting ends. That is why the first wave of AI, as magical as it felt, was also strangely trapped. A model could write a beautiful summary of a business problem, but unless you gave it the actual business context, it was still guessing. An LLM is not programmed to say “Sorry, I don’t know.” So it makes stuff up with proper grammar and punctuation. It could explain how to troubleshoot an issue, but unless it could inspect the logs, check the configuration, or look at the environment, it was still operating from theory. It could tell you how to prepare for a customer meeting, but unless it could see the account history, the open opportunities, the support cases, the renewal status, and the meeting notes from last quarter, it was basically giving you a very articulate horoscope. MCP is one of the attempts to fix that. MCP stands for Model Context Protocol. The name sounds like it was assembled by people who are very good at distributed systems and very bad at naming things for humans, but the words are actually useful. “Model” refers to the AI model. “Context” refers to the information and tools the model needs in order to be useful. “Protocol” means a standard way for systems to communicate. In plain English, MCP is a standard way for AI applications to connect to external tools and data sources. That may sound boring, but boring is often where the real technology changes happen. Nobody gets a standing ovation for plumbing until the plumbing stops working. Nobody thinks about electrical standards when they plug in a night light. Nobody wants to understand every detail of networking just to open a website. Standards become invisible when they succeed, and that invisibility is exactly why they matter. The analogy people use is that MCP is like USB-C for AI. I know that analogy is already dangerously close to becoming a bumper sticker, but it works well enough if we do not abuse it. USB-C did not make your laptop smarter. It did not make your monitor more creative. It did not make your phone more emotionally available, although at this point I would appreciate it if mine at least tried. What USB-C did was standardize connection. Instead of every device requiring its own special cable, adapter, dongle, ritual, and small sacrifice to the drawer of dead electronics, USB-C created a common interface. MCP is trying to do something similar for AI. It gives AI applications a common way to connect to the tools and data they need. The model does not need to know the internal details of every application. The application does not need to build a completely different integration for every model. MCP creates a shared language in the middle. That middle layer is what matters. Without something like MCP, the AI world runs into what technical people call the N-by-M problem. Katie Baker wrote about it last year: NxM Problem If you have ten AI applications and ten systems they need to connect to, you do not want one hundred custom integrations. If you have fifty AI applications and two hundred systems, you definitely do not want ten thousand custom integrations, unless your business model is selling painkillers to integration teams. The better model is not N times M. It is closer to N plus M. Each AI application learns how to speak the protocol. Each tool or data source exposes itself through the protocol. Once both sides understand the same standard, the number of custom connections drops dramatically. This is the point where MCP starts to become more than an AI developer convenience. It starts to look like infrastructure. To understand how it works, you do not need to become a protocol engineer. You just need to understand three roles: the host, the client, and the server. The host is the AI application the user interacts with. That could be Claude Desktop, ChatGPT, Cursor, Visual Studio Code, or an internal enterprise assistant with a name like Atlas, Navigator, Compass, or whatever else the branding team selected after eliminating “Dave.” The host is where the experience lives. It is where the user types the request, where the model reasons, and where the answer or action comes back. The client lives inside the host and manages the connection to an MCP server. You can think of it as the part of the application that knows how to speak MCP on behalf of the model. It handles the conversation between the AI application and the external capability. The server is the wrapper around a data source. There might be an MCP server for GitHub, another for Slack, another for a database, another for a filesystem, another for a CRM, another for a cloud service, and eventually one for every system that vendors decide must now be described as “AI-ready” in a press release. The server’s job is to expose what it can provide in a way the AI application can understand. It might say, in effect, “Here are the documents I can make available. Here are the actions I support. Here is the format you need to use if you want to call one of those actions. Here are the permissions required. Here is the result you can expect back.” That is where the value appears. The AI application does not need to understand every internal detail of GitHub, Slack, Salesforce, Postgres, Kubernetes, or your company’s deeply loved but spiritually exhausted internal ServiceNOW ticketing system. It needs a standard way to discover and use the capabilities exposed by those systems. MCP gives it that standard way. The protocol itself is built around a few core ideas that are easier to understand than the terminology makes them sound. MCP servers can expose tools, resources, and prompts. Tools are actions the model can ask to perform. A tool might search a database, send a Slack message, create a support ticket, run a test, update a CRM record, query an API, or retrieve the status of a system. Tools are where the AI starts moving from “I can answer your question” to “I can help complete the task.” Resources are information the model can read. These could be files, documents, schemas, database records, logs, API responses, or other pieces of context. Resources matter because AI without context is mostly a very confident intern on the first day of work. It may be talented, it may be fast, and it may be enthusiastic, but it does not know where anything is. Prompts are reusable instructions or workflows. That sounds small, but it is not. In business, consistency matters. You may not want every user inventing their own version of “analyze this account,” “review this code,” “summarize this incident,” or “prepare this forecast update.” A prompt can define how a model should approach a task, what standards it should follow, what inputs it should consider, and what kind of output is expected. Tools let the model act. Resources give the model context. Prompts help shape the model’s behavior. That combination is what makes MCP useful. Let’s make this practical. Suppose you ask an AI assistant to help prepare you for a customer meeting. Without access to your systems, the assistant can give you a generic meeting prep template. It can tell you to understand the customer’s goals, review previous discussions, identify risks, prepare discovery questions, and align to business outcomes. None of that is wrong. It is also not especially magical. It is the kind of advice that sounds helpful until you realize it could apply to almost any meeting with almost any customer in almost any industry. Now imagine that same assistant has controlled access to the right systems through MCP servers. It can read the meeting notes from prior briefings, pull the current opportunity data, review support tickets, check the renewal timeline, inspect open technical issues, summarize the customer’s stated initiatives, and identify where the account team may be telling itself a story that is more optimistic than the facts support. It can then generate a briefing that is not generic at all. It is specific, grounded, and useful. That is the difference between AI as a writing assistant and AI as a work assistant. This is why MCP keeps showing up in conversations about agents. An agent is not just a chatbot with a better title. An agent is expected to reason through a goal, choose tools, gather information, take steps, observe results, and continue until the task is complete or until it needs human help. That requires a standard way to connect reasoning to action. MCP is one of the strongest candidates for that standard layer. This is also where the MCP conversation stops being abstract for anyone running Everpure Fusion. It is one thing to say that MCP allows AI agents to connect to enterprise systems. That sounds interesting, but it can still feel like one of those technology ideas that lives safely inside a product roadmap, an architecture diagram, or a conference session where the coffee is somehow both expensive and terrible. It becomes much more practical when you look at what Everpure is doing with the Everpure Fusion MCP Server. I can almost guarantee that you will not click the link below, so I read it for you. But that will be in Part 2. I already drafted it, but I want to be respectful of your time. Not all of my readers are Everpure customers (yet). So that is my MCP “…splanation,” at least the Part 1 version. MCP is not the robot, and it is not the magical brain that suddenly makes every workflow intelligent. It is the standard connection layer that helps AI move from “I can answer your question” to “I can interact with the systems where your work actually happens.” That may not sound glamorous, but neither does plumbing, electricity, networking, or storage until something important depends on it. And that is why MCP matters. Because the next phase of AI will not be defined only by which model sounds the smartest in a chat window. It will be defined by how safely, consistently, and usefully those models can connect to real tools, real data, and real workflows. In Part 2, I will bring this closer to home and look at what this means for Everpure Fusion, because once AI starts needing context from infrastructure, the way we manage that infrastructure starts to matter a lot more. Appreciate you reading. Dmitry Gorbatov © 2025 Dmitry Gorbatov | #dmitrywashere
Ask Us Everything: Everpure & Databases - From Firefighting to Forward Thinking
Databases aren’t going anywhere—in fact, they’re becoming more important than ever. In this Ask Us Everything session, Don Poorman sat down with Everpure database experts Anthony Nocentino and Ryan Arsenault to talk all things structured data. And while AI continues to dominate headlines, one theme came through clearly: AI doesn’t replace databases—it depends on them. If you’re running Oracle, SQL Server, SAP, or anything mission-critical, here’s what stood out.
Ask Us Everything: Pure Storage + Nutanix — What the Community Really Wanted to Know
The January Ask Us Everything (AUE) session tackled one of the hottest topics in infrastructure right now: what Pure Storage and Nutanix are doing together—and what that means for our customers. Judging by the volume and depth of questions, it’s clear that many of you are actively evaluating next-generation virtualization options and want real answers, not marketing slides. With Cody Hosterman (Sr Director Product Management, Pure Storage), Thomas Brown (Field CTO, Nutanix), myself - Joe Houghes (Field Solutions Architect, Pure Storage), and our host Don Poorman (Technical Evangelist, Pure Storage), the conversation went deep into architecture, migration realities, and the practical problems this joint solution is designed to solve. Here are the biggest takeaways from what attendees asked—and what they learned. This is joint engineering, not just “interoperability” One of the most important clarifications came early: this isn’t a case of “here’s a LUN, good luck.” Nutanix has natively integrated Pure Storage FlashArray APIs directly into the Nutanix stack. That means: No plugins to install No bolt-on frameworks to manage No separate operational silos In Prism, the Nutanix management plane, Pure Storage behaves like a first-class storage backend. Snapshots, protection, provisioning, and automation are driven from Nutanix, while Pure Storage delivers its strengths—performance, data reduction, SafeMode, and simplicity—under the covers. NVMe/TCP support is a deliberate, forward-looking choice Several attendees asked why Fibre Channel or legacy protocols weren’t the focus. The answer: this solution is built for where infrastructure is going, not where it’s been. By standardizing on NVMe/TCP over Ethernet, Pure and Nutanix: Avoid decades of SCSI and FC tech debt Enable massive bandwidth scalability (100G, 400G, and beyond) Lay the groundwork for modern security features like TLS and in-band authentication This is a design meant to still make sense 10 years from now. Object-style vDisks eliminate old datastore limits A recurring “aha” moment came when attendees learned how vDisks are implemented. Instead of traditional filesystem-based datastores (with all their historical limits), each virtual disk maps directly to a Pure Storage volume. What that unlocks: Petabyte-scale virtual disks (no more 64TB ceilings) No datastore gymnastics to scale performance No artificial limits inherited from legacy file systems This felt especially relevant for customers running large databases, analytics platforms, or fast-growing enterprise apps. HCI isn’t going away—this complements it A key question from the audience: Does this replace Nutanix HCI? The answer was a clear no. Nutanix HCI still makes perfect sense for many workloads. But when customers: Need to scale storage independently of compute Have performance-heavy or capacity-dense workloads Want an “apples-to-apples” replacement for traditional VMware + external storage …Pure Storage + Nutanix provides a clean alternative without forcing architectural compromises. Migration is real, and the hard parts were addressed honestly Migration questions dominated the session—and the tone was refreshingly pragmatic. Attendees learned: Nutanix Move is fully supported and preserves Purity’s data reduction–which makes this a zero-cost migration in terms of storage capacity VMware NSX rules can be translated into Nutanix Flow during migration Backup tools (Veeam, Rubrik, Commvault, Cohesity, etc.) continue to work without re-engineering or changes in backup operations Most migration risk doesn’t lie in the hypervisor—it’s overlooked third-party dependencies The guidance was consistent: plan carefully, take stock of any dependencies, and don’t rush a wholesale cutover just to meet an artificial deadline. No user ever wants to be forced to do that. Operational simplicity is a major design goal A subtle but powerful theme emerged: you don’t need to tune this solution. VMware users often ask about “nerd knobs” and the need to tweak things to get them working right. In this solution, they’re mostly gone—and intentionally so. Best practices for queue depths, multipathing, performance tuning and more are already baked into the platform by the joint engineering teams. Improvements are managed through upgrades, eliminating the need for manual scripting or implementing performance tweaks for a "snowflake" deployment. The result of this best-of-breed, jointly-engineered solution is consistency, predictability, and easier support—especially during migrations–so that you can focus on the work that makes your business run. The roadmap is active—and community feedback matters This solution was not positioned as “done and dusted.” The GA release is the foundation, not the finish line. Capabilities like Kubernetes support, deeper snapshot orchestration, VDI validation, and migration optimizations are all on the roadmap. And importantly: your use cases drive priorities. And the Pure Storage Community is a great place to drop your feedback for the teams! Keep the conversation going This partnership sparked a lot of interest for a reason: it’s not just about changing hypervisors—it’s about modernizing how infrastructure works. If you missed the live session—or want to dive deeper—join the ongoing discussion in the Pure Storage Community: 👉 https://purecommunity.purestorage.com/discussions/virtualization/ask-us-everything-about-pure-storage--nutanix/3634 You’ll find Pure Storage and Nutanix experts answering follow-ups, clarifying edge cases, and sharing lessons learned from real deployments. While you’re there, be sure to check out past Ask Us Everything events—they’re packed with practical, practitioner-level insights.OT: The Architecture of Interoperability
In previous post, we explored the fundamental divide between Information Technology (IT) and Operational Technology (OT). We established that while IT manages data and applications, OT controls the physical heartbeat of our world from factory floors to water treatment plants. In this post we are diving deeper into the bridge that connects them: Interoperability. As Industry 4.0 and the Internet of Things (IoT) accelerate, the "air gap" that once separated these domains is evolving. For modern enterprises, the goal isn't just to have IT and OT coexist, but to have them communicate seamlessly. Whether the use-cases are security, real time quality control, or predictive maintenance, to name a few, this is why interoperability becomes the critical engine for operational excellence. The Interoperability Architecture Interoperability is more than just connecting cables; it’s about creating a unified architecture where data flows securely between the shop floor and the “top floor”. In legacy environments, OT systems (like SCADA and PLCs) often run on isolated, proprietary networks that don’t speak the same language as IT’s cloud-based analytics platforms. To bridge this, a robust interoperability architecture is required. This architecture must support: Industrial Data Lake: A single storage platform that can handle block, file, and object data is essential for bridging the gap between IT and OT. This unified approach prevents data silos by allowing proprietary OT sensor data to coexist on the same high-performance storage as IT applications (such as ERP and CRM). The benefit is the creation of a high-performance Industrial Data Lake, where OT and IT data from various sources can be streamed directly, minimizing the need for data movement, a critical efficiency gain. Real Time Analytics: OT sensors continuously monitor machine conditions including: vibration, temperature, and other critical parameters, generating real-time telemetry data. An interoperable architecture built on high performance flash storage enables instant processing of this data stream. By integrating IT analytics platforms with predictive algorithms, the system identifies anomalies before they escalate, accelerating maintenance response, optimizing operations, and streamlining exception handling. This approach reduces downtime, lowers maintenance costs, and extends overall asset life. Standards Based Design: As outlined in recent cybersecurity research, modern OT environments require datasets that correlate physical process data with network traffic logs to detect anomalies effectively. An interoperable architecture facilitates this by centralizing data for analysis without compromising the security posture. Also, IT/OT convergence requires a platform capable of securely managing OT data, often through IT standards. An API-First Design allows the entire platform to be built on robust APIs, enabling IT to easily integrate storage provisioning, monitoring, and data protection into standard, policy-driven IT automation tools (e.g., Kubernetes, orchestration software). Pure Storage addresses these interoperability requirements with the Purity operating environment, which abstracts the complexity of underlying hardware and provides a seamless, multiprotocol experience (NFS, SMB, S3, FC, iSCSI). This ensures that whether data originates from a robotic arm or a CRM application, it is stored, protected, and accessible through a single, unified data plane. Real-World Application: A Large Regional Water District Consider a large regional water district, a major provider serving millions of residents. In an environment like this, maintaining water quality and service reliability is a 24/7 mission-critical OT function. Its infrastructure relies on complex SCADA systems to monitor variables like flow rates, tank levels, and chemical compositions across hundreds of miles of pipelines and treatment facilities. By adopting an interoperable architecture, an organization like this can break down the silos between its operational data and its IT capabilities. Instead of SCADA data remaining locked in a control room, it can be securely replicated to IT environments for long-term trending and capacity planning. For instance, historical flow data combined with predictive analytics can help forecast demand spikes or identify aging infrastructure before a leak occurs. This convergence transforms raw operational data into actionable business intelligence, ensuring reliability for the communities they serve. Why We Champion Compliance and Governance Opening up OT systems to IT networks can introduce new risks. In the world of OT, "move fast and break things" is not an option; reliability and safety are paramount. This is why Pure Storage wraps interoperability in a framework of compliance and governance, not limited to: FIPS 140-2 Certification & Common Criteria: We utilize FIPS 140-2 certified encryption modules and have achieved Common Criteria certification. Data Sovereignty: Our architecture includes built-in governance features like Always-On Encryption and rapid data locking to ensure compliance with domestic and international regulations, protecting sensitive data regardless of where it resides. Compliance: Pure Fusion delivers policy defined storage provisioning, automating the deployment with specified requirements for tags, protection, and replication. By embedding these standards directly into the storage array, Pure Storage allows organizations to innovate with interoperability while maintaining the security posture that critical OT infrastructure demands. Next in the series: We will explore further into IT/OT interoperability and processing of data at the edge. Stay tuned!Understanding Deduplication Ratios
It’s super important to understand where deduplication ratios, in relation to backup applications and data storage, come from. Deduplication prevents the same data from being stored again, lowering the data storage footprint. In terms of hosting virtual environments, like FlashArray//X™ and FlashArray//C™, you can see tremendous amounts of native deduplication due to the repetitive nature of these environments. Backup applications and targets have a different makeup. Even still, deduplication ratios have long been a talking point in the data storage industry and continue to be a decision point and factor in buying cycles. Data Domain pioneered this tactic to overstate its effectiveness, leaving customers thinking the vendor’s appliance must have a magic wand to reduce data by 40:1. I wanted to take the time to explain how deduplication ratios are derived in this industry and the variables to look for in figuring out exactly what to expect in terms of deduplication and data footprint. Let’s look at a simple example of a data protection scenario. Example: A company has 100TB of assorted data it wants to protect with its backup application. The necessary and configured agents go about doing the intelligent data collection and send the data to the target. Initially, and typically, the application will leverage both software compression and deduplication. Compression by itself will almost always yield a decent amount of data reduction. In this example, we’ll assume 2:1, which would mean the first data set goes from 100TB to 50TB. Deduplication doesn’t usually do much data reduction on the first baseline backup. Sometimes there are some efficiencies, like the repetitive data in virtual machines, but for the sake of this generic example scenario, we’ll leave it at 50TB total. So, full backup 1 (baseline): 50TB Now, there are scheduled incremental backups that occur daily from Monday to Friday. Let’s say these daily changes are 1% of the aforementioned data set. Each day, then, there would be 1TB of additional data stored. 5 days at 1TB = 5TB. Let’s add the compression in to reduce that 2:1, and you have an additional 2.5TB added. 50TB baseline plus 2.5TB of unique blocks means a total of 52.5TB of data stored. Let’s check the deduplication rate now. 105TB/52.5TB = 2x You may ask: “Wait, that 2:1 is really just the compression? Where is the deduplication?” Great question and the reason why I’m writing this blog. Deduplication prevents the same data from being stored again. With a single full backup and incremental backups, you wouldn’t see much more than just the compression. Where deduplication measures impact is in the assumption that you would be sending duplicate data to your target. This is usually discussed as data under management. Data under management is the logical data footprint of your backup data, as if you were regularly backing up the entire data set, not just changes, without deduplication or compression. For example, let’s say we didn’t schedule incremental backups but scheduled full backups every day instead. Without compression/deduplication, the data load would be 100TB for the initial baseline and then the same 100TB plus the daily growth. Day 0 (baseline): 100TB Day 1 (baseline+changes): 101TB Day 2 (baseline+changes): 102TB Day 3 (baseline+changes): 103TB Day 4 (baseline+changes): 104TB Day 5 (baseline+changes): 105TB Total, if no compression/deduplication: 615TB This 615TB total is data under management. Now, if we looked at our actual, post-compression/post-dedupe number from before (52.5TB), we can figure out the deduplication impact: 615/52.5 = 11.714x Looking at this over a 30-day period, you can see how the dedupe ratios can get really aggressive. For example: 100TB x 30 days = 3,000TB + (1TB x 30 days) = 3,030TB 3,030TB/65TB (actual data stored) = 46.62x dedupe ratio In summary: 100TB, 1% change rate, 1 week: Full backup + daily incremental backups = 52.5TB stored, and a 2x DRR Full daily backups = 52.5TB stored, and an 11.7x DRR That is how deduplication ratios really work—it’s a fictional function of “what if dedupe didn’t exist, but you stored everything on the disk anyway” scenarios. They’re a math exercise, not a reality exercise. Front-end data size, daily change rate, and retention are the biggest variables to look at when sizing or understanding the expected data footprint and the related data reduction/deduplication impact. In our scenario, we’re looking at one particular data set. Most companies will have multiple data types, and there can be even greater redundancy when accounting for full backups across those as well. So while it matters, consider that a bonus.Getting Started: 5 Steps to Get the Most Out of the Pure Customer Community
Welcome! You've taken the first step and created an account here. What to do next you ask? Here's five simple steps to take after registering to ensure you're getting the most out of this community. Fill out your Profile: Let the community know who you are! Click on your avatar in the top right corner of this window and select 'My Settings' from that dropdown. Fill in your name, location, and bio information. Plus select from one of several default avatars or upload your own image. Write an Introduction post: Head over to the Social Space and write your intro post. Tell us about yourself, your role at your company, and your goals for participating in this community. What have you been thinking about a lot lately at work? (And we won't shy away from pictures of your pets either!) Follow a couple of Forum areas: Find the products you use most and solution areas you're most focused on in our Forums and be sure to click the bell icon in the upper right of those forums to be sure you get notifications on the latest activity in those areas. If you work in Finance, Healthcare, Public Sector, or Telco there's groups dedicated to the unique needs of your industry areas too. And if you're an open source or automation fan, Cloud Native and Kubernetes devotee, or a Pure Partner, there's dedicated group you can join for each of those areas too. Join your local Pure User Group: Click on Groups in the top nav and select Pure User Groups. (fka FlashCrew) Select your region & find the group for your local area. Click on that group and then click 'Join Group'. This will ensure you hear about any Pure events happening in your local area, including when & where the next meetup is. Pick 3-5 tags to follow: This community makes heavy use of tags. As you browse a forum, you'll notice each thread has tags. That is because we require them for every post. Find the tags most relevant to your interest areas and click the bell icon on those pages so you can keep up to date with the latest posts in those categories, regardless of what forum or group the discussion happens in. Finally, feel free to ask questions! Your friendly admins (bmcdougall and Ludes) are here to answer any questions you have and take suggestions. And we have deputized experts across Pure Storage to be on hand to answer deep technical questions. So don't be shy, there's always someone around to help you out.Complexity Creeps. Let’s Audit It Before It Breaks You.
Complexity in IT isn’t built overnight—and it won’t be unwound that way either. This blog walks through a practical, no-fluff approach to auditing and simplifying your IT environment. From building a visibility map of your tools and integrations to prioritizing what to fix, executing cleanly, and proving the value with real metrics—this is about intentional, incremental change. Win big. Choose simplicity.Pure Storage Delivers Critical Cyber Outcomes
“We don’t have storage problems. We have outcome problems.” - Pure customer in a recent cyber briefing No matter what we are buying, what we are buying is a desired outcome. If you buy a car, you are buying some sort of outcome or multiple outcomes. Point A to Point B, comfort, dependability, seat heaters, or if you are like me, a real, live Florida Man, seat coolers! The same is true when solving for cyber outcomes, and often overlooked is a storage foundation to drive cyber resilience. A strong storage foundation improves data security, resilience and recovery. With these characteristics, organizations can recover in hours vs. days. Here are some top cyber resilience outcomes Pure Storage is delivering. Native, Layered Resilience Fast Analytics Rapid Restore Enhanced Visibility We will tackle all of these in this blog space (multi-part post alert!), but let’s start with the native, layered resilience Pure provides customers. Layered Resilience refers to a comprehensive approach to ensuring data protection and recovery through multiple layers of security and redundancy. This architecture is designed to provide robust protection against data loss, corruption, and cyber threats, ensuring business continuity and rapid recovery in the event of a disaster. Why is layered resilience important? Different data needs different protection. My photo collection, while important to me, doesn’t require the same level of protection as critical application data needed to keep the company running. Layered resilience indicates that there needs to be different layers of resilience and recovery. Super critical data needs super critical recovery. We are referring to the applications that are the life-blood of organizations, order processing, patient services or trading applications. These may only account for 5% of your data, but drive 95% of the revenue. Many organizations protect these with high availability which provides excellent resilience against disasters and system outages. But for malicious events, such as ransomware, protection is needed to ensure that recoverable data is available if an attack corrupts or destroys the production data. Scheduled snapshots can protect that data from the time the data is born. Little baby data. Protect the baby! Pure Snapshots are a critical feature, providing efficient, zero-footprint copies of data that can be quickly created and restored, ensuring data protection and business continuity. Pure snapshots are optimized for data reduction, ensuring minimal space consumption. This is achieved through global data reduction technologies that compress and deduplicate data, making snapshots space-efficient. They are designed to be simple and flexible, with zero performance overhead and the ability to create tens of thousands of snapshots instantly. They are also integrated with Pure1 (part of our Enhanced Visibility discussion) for enhanced visibility, management and security, reducing the need for complex orchestration and manual intervention. Snapshots can be used to create new volumes with full capabilities, allowing for mounting, reading, writing, and further snapshotting without dependencies on one another. This flexibility supports various use cases, including point-in-time restores and data recovery. In events that require clean recovery, and secure recovery at that, it would be much more desirable to leverage snapshots for recovery, where you could scan and determine cleanliness and safeness, often in parallel efforts and the reset time for going to an earlier period of time is a matter of seconds rather than days. But not even these amazing local snapshots are enough. What if your local site is rendered unavailable for some reason? Do you have control of your data to be able to recover in that scenario? Replicating those local snapshots to a second site could enable more flexibility in recovery. We have had customers leverage our High Availability solution (ActiveCluster) across sites and then engage snapshots and asynchronous replication to a third site as a part of their recovery plan. Data that requires extended retention and granularity is typically handled by a data control plane application that will stream a backup copy to a repository. This is usually a last line of defense in case of an event, as the recovery time objective is longer when considering a streaming recovery of 50%, 75%, or 100% of a data center. Still, this is a layer of resiliency that a comprehensive plan should account for. And if these repositories are on Pure Storage, these also can be protected by SafeMode methodologies and other security measures such as Object Lock API, Freeze Locked Objects, and WORM compliance. And most importantly, this last line of defense can be supercharged for recovery by the predictable, performant platform Pure provides. Some outcomes of this layer of resilience involves Isolated Recovery Environments to incorporate even security and create those Clean Rooms to isolate recovery to ensure you will not re-introduce the event origin back into production. In these solutions, the speed benefits that Pure provides is critical to making these designs a reality. Of course, the final frontier is the archive layer. This is a part of the plan that usually falls into compliance SLA, where data is required to be maintained for longer periods of time. Still, more and more, there are performance and warm data requirements for even these data sets, where AI and other queries can benefit from even the oldest of data. One never knows what layer of resilience is required for any single event. Having the best possible resilience enables any company to recover, and recover quickly, from an attack. But native resilience is just one of the outcomes we deliver. Come back to read how we are delivering fast analytics outcomes in an environment that seeks to discover anomalies as fast as possible. Exit Question: How resilient is your data today? Jason Walker is a technical strategy director for cyber related areas at Pure Storage and a real, live, Florida Man. No animals or humans were injured in the creation of this post.Why Are We Still Designing IT Like It's 2012?
Let’s talk about complexity in IT. Not the fun kind—like building a Raspberry Pi-powered coffee machine or arguing over whether Terraform should be capitalized. I mean the kind of complexity that slows teams down, bloats your stack, and makes security people question their career choices. You know the type: five backup platforms, three monitoring tools, two storage vendors “for resilience,” and a bunch of scripts someone wrote in 2019 that nobody’s brave enough to touch. We tell ourselves it’s “best-of-breed,” “cloud-first,” or my personal favorite—“strategic.” But let’s call it what it is: chaos without any direction. Enter Conway’s Law (aka the Mirror You’ve Been Avoiding) Melvin Conway dropped this gem in 1967: “Organizations design systems that mirror their own communication structures.” Still true. Still brutal. If your company has six teams that don’t talk to each other except through passive-aggressive Jira tickets, your architecture is going to reflect that—fragmented, redundant, over-engineered, and impossible to secure. Conway’s Law isn’t just a quirky observation. It’s a diagnostic tool. If your architecture feels like a group project gone off the rails, chances are it’s because your org works that way too. Cloud Chaos: Now with More Vendors! And just when you thought it couldn’t get worse—we bring in the cloud. Or clouds. Somewhere between “cloud-first” and “cloud-only,” we lost the plot. We started treating hyperscalers like interchangeable gas stations: need compute? Just pull over at the nearest one. We’ve seen it: Migrations from AWS to Azure to GCP like it’s some weird tech pilgrimage Applications lifted and shifted with zero refactoring Hybrid architectures that “just sort of happened” Look, the cloud’s not the problem. I like cloud and I believe it is here to stay. But designing 100% for the cloud without actually understanding your why? That’s Conway’s Law, just with bigger invoices. Even worse? Bouncing between cloud providers because someone read a Forrester report and got nervous about lock-in. That’s not strategy—that’s cloud-induced panic. The Two-Vendor Lie We Keep Telling Ourselves Ah yes, the old two-vendor strategy. Meant to be safe. Designed to reduce dependency. What it really does? Doubles your complexity and halves your team’s sanity. Two vendors = two playbooks, two consoles, two support teams blaming each other It’s not more resilient—it’s just more confusing Gartner even calls it out: more vendors = more risk, not less If you think managing multiple tools with overlapping functions is safer than consolidation, congrats—you’ve just invented the world’s most expensive “Oops” button. Manual ≠ Secure. It Just Feels That Way Let’s talk about the weird rituals we still do in the name of security: Manually copying data to “safe zones” Turning off network access like it’s a security blanket Spinning up siloed sandboxes to avoid risk It’s not protection. It’s procrastination. Manual controls introduce human error, waste time, and don’t scale. If your “strategy” depends on someone remembering to toggle a firewall rule every Thursday, you're not secure—you’re just lucky. And outsourcing that chaos to a vendor doesn’t make it better. Handing over management to a provider that’s Frankensteined a bunch of loosely integrated tech with bailing wire and hope isn’t a strategy—it’s just renting someone else’s mess. If there’s no real roadmap, no cohesion, no architectural vision—it’s not a partnership. It’s a future support ticket waiting to happen. Hybrid Cloud Needs Purpose, Not Permission Hybrid isn’t a backup plan. It’s a design decision. Too many shops end up hybrid by accident—because apps don’t refactor, budgets don’t stretch, or politics get in the way. The result is an environment that’s technically working but operationally exhausting. A good hybrid strategy is opinionated. You should know: What runs where (and why) How data moves What your north star architecture looks like If you don’t have answers to that? You’re not doing hybrid—you’re doing hope. So What Do We Do About It? We simplify. On purpose. Relentlessly. Design like a startup, not a committee. Keep the stack lean. Less is more when you have tools that actually integrate. Use Conway’s Law in reverse. Want systems that work together? Build teams that do too. Break silos before they become dependencies. Treat cloud like architecture, not an escape route. Cloud is amazing if you design for it. Otherwise, it’s just someone else’s complexity in your billing statement. Stop solving people problems with platform purchases. Most complexity isn’t technical—it’s cultural. No vendor can fix your org chart. Final Thought: Complexity Is a Tax. Stop Paying It. Every extra platform, every vendor “just in case,” every manual handoff is a tax. And it’s compounding interest on your ability to execute. If you want to move fast, secure your data, and stay sane—you’ve got to design with purpose. That means fewer tools, better alignment, and architectures that reflect how you want to operate, not how your politics force you to. You want resilience? Start with intention. But what I’m really curious about is your perspective: How are you dealing with complexity? Is hybrid working for you—or just holding you hostage? Have you successfully simplified your architecture without sacrificing flexibility? Let's make this a real convo—not another “cloud is the answer” thread. —Zane Allyn
