The Evolution of Cybercrime: Ransomware and the need for an Isolated Recovery Solution

The Evolution of Cybercrime: Ransomware and the need for an Isolated Recovery Solution

Hope is not a strategy.


It takes some fortitude to begin a blog with such a well-worn cliché, but in this case it is more than fitting. With the emergence of ransomware and hacktivism as a rapidly growing new category of threats, all too often the response is hope.


Hope the hackers don’t attack us. Hope we can detect and shutdown and attack before it does too much damage.  Hope that by upgrading our perimeter defense and educating our employees that we will be a harder target.


Good luck with that.


The 2015 Data Breach Investigation report revealed that over 60% of companies could be compromised in six minutes or less. EMC has conducted two global data protection surveys in the past two years, and the resulting data is equally worrisome.  Approximately 1/3rd of all customers have experienced data loss due to a security breach, and the average cost of a single incident is $914,000, which in Dr. Evil terms is really, really close to “One Million Dollars!”


The statistics are out there for you to find if you want a greater dose of shock and horror. (Sometimes I wonder given all the travel I do why I watch the television show “Why Airplanes Crash”, but we are all drawn to the macabre and disturbing, right?)


But the reason I’m writing this isn’t just to put forth the disturbing data again. Instead, it’s to point out that many groups are looking in the wrong place for solutions.


While the threats are evolving, the Information Security community, vendors and IT professionals are all doubling down on more of the same. All of the emphasis is on incident prevention and very little attention is given to data protection and recovery.  The facts however lean very heavily toward the probability that any given business will be the subject of a successful cyber-attack in the foreseeable future.  In fact, most security experts agree that there are two kinds of companies:  those who have experienced a successful cyber-attack, and those who have experienced a successful cyber-attack and simply don’t know it yet.


As these threats have emerged, guidance in the form of Cyber Security Frameworks (CSFs) have been established. Most of these CSFs reference or borrow heavily from the NIST CSF, which has some very important fundamental information.  “Protect” and “Recover” are both pillars of the NIST CSF, as well as every other highly regarded framework.  In this context, “Protect” explicitly means to make secure, isolated protection copies of data.   “Recover” means that after detecting a threat a business needs a plan to suspend production, eliminate the threat, and recover data and systems necessary to resume operations.


EMC has a solution for customers who want to protect themselves from these modern and sophisticated threats called the “Isolated Recovery Solution”. Logically, this provides an “Air gap” between the production environment and the data that is critical for the survival of any business.  Here is a diagram demonstrating the key elements of the EMC Isolated Recovery Solution:


ransomware rc.jpg


Isolated Recovery is NOT Disaster Recovery. IR represents only the most critical data that a business needs to survive.  Most customers do not stand up an IR solution at the same size and scale as their primary backup or DR infrastructure.  Furthermore, IR usually lives in the same location as the production data.  This is essential for rapid recovery from an incident.  The mechanisms IR puts in place are both physical and logical.  For many enterprises this means creating a small locked cage within the data center and restricting access to the very few people who are responsible for the system.


There is a lot more to talk about when it comes to the IR solution, so I encourage you to reach out to one or more trusted advisors, prioritize what matters to you, and then dive into all the details.


But what about my earlier statements about not hanging all our hopes on prevention? Prevention is useful, but a successful defense requires a layered approach.  All of the parts of the solution need to fulfill a purpose within the CSF.  But how are you organized as a company?  When was the last time the Information Security team and the Backup team got together and built a joint solution?  My guess is probably never.  Traditional organizational structures simply aren’t aligned very well in order to solve this problem.  In order to defend against a threat that evolves rapidly, everyone needs to adapt.  Whether it is the backup guru talking to the firewall guru, or the CIO talking to the Board of Directors, someone needs to start having this conversation.  You are that someone.  You can’t just hope that somebody else will do it. Hope is not a strategy.


Rich Colbert

Cloud Native for The Enterprise

Cloud Native for The Enterprise

In Part I of this series, we explored how the Heroku architecture wires middleware software to their platform, allowing developers to focus on writing applications to drive their business. In this part, focusing on the enterprise use case, we’ll analyze the Heroku inspired PaaS system – Cloud Foundry.


Part II – Cloud Foundry – Cloud Native for the Masses


Cloud Foundry – The PaaS for the Enterprise


Cloud Foundry (CF) is considered by many to be the PaaS for the enterprise – and for good reasons. With mature APIs, built-in multi tenancy, authentication and monitoring it’s no wonder vendors like IBM, HP and GE built their platforms as certified CF distributions. Cloud Foundry can be thought of as a customizable implementation of the Heroku architecture. The main difference between Heroku and CF is the flexibility that allows CF to be installed anywhere. Like Heroku, CF adopted the strict distinction between the stateless 12-factor part of the App (“the application space”) and the stateful part of the App (“Services”). While the application space is very similar to the equivalent on Heroku, CF can’t depend on Heroku engineers to manage the services (e.g. databases/messaging). Instead, CF delegates this role to DevOps. As a result, enterprises can configure the platform to expose custom services that meet their unique needs. This sort of adaptability plays in favor of CF in the enterprise world.


Some of the major Cloud Foundry qualities that make it attractive in this space:


Avoid lock-in – With years of experience of being locked in by software and infrastructure stacks, enterprises seek freedom of choice. With the CPI abstraction (Cloud Provider Interface), Cloud Foundry (using BOSH) can be deployed on practically any infrastructure.


Mature on-premises use cases – The cloud is great! Enterprises are not passing up on that trend. However, reality has its own role in decision making, and many workloads are staying on premises. While security, regulations and IT culture are often cites, what keeps a large portion of the workloads on premises is the years and years of legacy systems holding the most important asset of any organization – its data. In order to move mission critical workloads to new architectures on a remote datacenter (e.g. cloud), organizations have to port all the proprietary non-portable data too. Translating for readers with cloud native mindsets: DB2 on mainframe is not yet “Dockerized”, one can’t simply push it around in a blink of an eye. J


Good Transition Story – CF can do more than run legacy workflows on premises. The big difference is that it provides a well-defined architectural transition story. The ability to move parts of the app or new modules to run as CF apps, while easily connecting to the legacy data systems as services (via service brokers), is powerful. This allows developers to experiment with the modern technology while accessing the core systems, giving them a real opportunity to experience the cloud native productivity boosts while keeping their feet firmly on the ground.


Compliance, Compliance and again Compliance – Many cloud native discussions leave out where data is being stored. We often hear that cloud native apps only use NoSQL or Big Data databases. While using modern databases makes sense in some use cases, in order to deliver compliant applications, organizations find it easy and safe to use mature database back-ends (e.g. Oracle/MS SQL) for serving their modern cloud native apps. With Cloud Foundry’s Service Brokers model, they are able to leverage the tools and processes they are already proficient with to protect their data, while modernizing their apps and workflows.


Vendor behind the platform – although Cloud Foundry is open source, Enterprises like having a throat to choke . Proprietary distributions like Pivotal Cloud Foundry support the transformation and can be engaged when customers encounter challenges.


While the motivation to modernize exists in almost every organization these days, not seeing a clear path for transformation can hold companies back. Many of the modern platforms (e.g. Kubernetes or Docker Datacenter) have an appealing vision for where the world of software needs to be, but it is not clear how to make a gradual transformation. By adopting CF, enterprises see an steady path that they can pursue and start getting results relatively quickly.


Cloud Foundry – Trouble in Paradise


Cloud Foundry is an exciting platform that can bring many benefits to organizations adopting it. However, there is always room to improve. CF’s flexibility in handling of stateful services via the “Service Brokers” abstraction and DevOps management is what made the “transition story” possible. However, as always, when making something more generic, there are tradeoffs. Since Heroku manages both stateful and stateless services, they can gain full control over the platform. Without that control, some pain points emerge.

cloud native 2 pic 1

Cloud Native New Silos


On one hand, the application space is modern and fully automated, while on the other hand the services space and its integration points with the app space have a quite a manual feel. It’s no surprise that the the platform shortcomings revolve around lack of control and lack of visibility caused by the new “DevOps Silo” the CF architecture enforces. For example:


Scale out – Cloud Foundry can do an impressive job scaling out the stateless services according to the load on the application. But sometimes, when the compute hassle has been resolved, the next bottleneck becomes the database. If the platform could control stateful services as well, it could scale the database resources as well. Today developers have to pick up the phone and call dev-ops, asking for specific services tuning.


Multi-Site HA – Production systems often run on more than a single site due to HA requirements and/or regulations. In order to support such deployment topologies, someone has to make the stateful services available on multiple sites when required. As the CF runtime ignores stateful services, there has to be an out-of-platform process of orchestrating stateful services. From the CF perspective, on every site you run a different application, and the coupling of those sites is not visible to CF. Seeing such deployment topologies in real life, I can testify that it is painful and error prone.


Portability – Great! CF is portable! Is it? Let’s say I run Facebook on my datacenter using CF. It would be effortless to point my CF client and AWS and push Facebook to a CF instance running on AWS. Job done. Or is it? If you are following so far you might have noticed that in my new Facebook production site on AWS, I’m going to be very lonely. In fact – I’m not going to have any friends! While the stateless services are portable, the stateful ones, that more than everything are the core value of any application, are certainly not portable.


Test & Dev – When new architectures emerge, they often focus on solving the primary use case of running in production. Only later, as the technology matures, do the toolsets and patterns for application maintenance come. To be fair, Cloud Foundry does have nice patterns for the application lifecycle, like blue-green deployments. However this is not enough especially in the enterprise. When maintaining an application, developers often need access to instances with fresh data from production. In the past, they had to speak with a DBA to extract and scrub the data for them, or even had a self-service way for doing this. In the modern world of micro-services, applications tend to use multiple smaller databases rather than one monolith. In addition, the new dev-ops silo means that there is one additional hop in the chain for doing this already complex operation. I’ll elaborate on the developer use case in the next post.


Data protection – While I have heard more than once that data protection is not required in cloud native, where the data services are replicating data across nodes, I’ve also witnessed organizations lose data due to human error (expiring full S3 buckets without backup) or malicious attacks (e.g. dropping entire schema). When crisis happens, organizations need the ability to respond quickly and restore their data. The CF platform hides the data services from us and creates yet another silo in the already disconnected world of data protection. Storage, backup admins, DBAs and now – DevOps.


Cost Visibility – When adopting modern platforms, more and more processes become automatic. This empowers developers to do more. However, with great power (should) come great responsibility. Companies complain that in large systems they lose visibility into the resources cost per application and use case. While with CF you can limit an application to consume some amount of compute resources, you get no control or visibility on stateful services cost (which in many cases is the most significant). For example, developers can run test-dev workloads attaching them to expensive stateful services while they could have used cheaper infrastructures for their test workloads. With Big Data Analytics services there is also lack of visibility in production. There is no ability to distinguish which app is utilizing what percent of the shared resource, and therefore the ability to prioritize and optimize.

Cloud native 2 pic 2

Native Application Data Distribution example


As the technology matures, and more organizations will take it to production and the community will start catching up with solutions. Some initiatives are already being thrown into the air (e.g. BOSH releases for stateful services) and offer some enhanced features (although always with trade-offs). I’ve recently seen a demo by Azure architects that runs Pivotal Cloud Foundry in Azure. Since they have full control of the stateful services, they could preconfigure Cloud Foundry marketplace to work seamlessly. Even more impressive, they stated they are working on supporting this configuration on premises using Azure virtualization software on customer hardware. With the tradeoff of being locked with Microsoft, having the ability to control and get visibility to the full spectrum of the application is certainly an attractive offering.



Cloud Foundry is bringing the Cloud Native environment to the enterprise ecosystem. By creating a more flexible model that depends on Dev Ops, it solves some of the challenges with bringing the Heroku model to the enterprise. Of course, there are new complexities that arise with the Cloud Foundry model. In particular, adding Dev Ops makes the stateful (i.e. persistent data) operations more challenging – especially for developers.


In the next article we’ll discuss the role of developers in the Cloud Native Enterprise. While cloud native applications empower developers to do more, in the enterprise world there are implications that create an interesting dissonance.


Amit Lieberman @shpandrak, Assaf Natanzon @ANatanzon, Udi Shemer @UdiShemer

Deduplicated Storage, Years after the Salesperson Leaves

Deduplicated Storage, Years after the Salesperson Leaves

Deduplicated Storage, Years after the Salesperson Leaves

So you are thinking about purchasing a deduplication storage system for your backups. Everyone tells you that, by removing redundancies, it will save storage space, and reduce costs, power, rack space, and network bandwidth requirements. Perhaps a vendor even did a quick analysis of your current data to estimate those savings. But, many months from now, what will your experience really be? We decided to investigate that question.

I was fortunate enough to collaborate with researchers studying long-term deduplication patterns, and our work was recently published at the Conference on Massive Storage Systems and Technology (MSST 2016)[1].

The Study

How do you perform a long-term study of deduplication patterns?

  • Step one: Create tools to gather data.
  • Step two: Gather data for years. And years. And years.
  • Step three: Analyze, analyze, analyze. Then upgrade your tools to analyze some more.

Our data collection tools were designed to process dozens of user home directories in a similar fashion as an actual deduplicated storage system. The tools ran daily from 2011 through today, with infrequent gaps due to weather-related power outages, hardware failures, etc. Every day, the tools would read all the files, break each file into chunks of various sizes (2KB – 128KB and full file), calculate a hash for each chunk, and record the file’s metadata.

In this paper, we analyzed a 21 month subset of the data covering 33 users, 4,100 daily snapshots, and a total of 456TB of data. If this isn’t the largest and longest running deduplication-oriented data set ever gathered, it is certainly among the top few. Analyzing the collected data was a gargantuan task involving sorting and merging algorithms that ran in phases, writing incremental progress to hard disk since the data was larger than memory.  For anyone that wants to perform their own data collection or wants to perform their own analysis of this immense data set, the tools and data set are publicly available.


The Results

What did we discover? Starting with general deduplication characteristics, we find that whole file deduplication works well for small files (<1 MB) but poorly for large files. Since large files consume most of the bytes in the storage system, this result supports the industry trend towards deduplicating chunks of files. We then looked at optimal deduplication chunk sizes based on the type of backup schedules.

  • Weekly full and daily incremental backups: optimal chunk size is 4-8KB
  • Daily full backups: optimal chunk size is 32KB

Deduplication ratios also varied by file type. Unsurprisingly, compressed files such as .gz, .zip, and .mp3 get little deduplication no matter the chunk size, while source code had the highest space savings because only small portions are modified between snapshots.  Interestingly, VMDK files took up the bulk of the space, highlighting that storage systems need to be VM-aware.

Looking at the snapshots for our 33 users, we found significant differences that are hidden by grouping all the users together. Per-user deduplication ratios varied widely from a low of 40X (meaning their data fits in 1/40th of the original space) to a high of 2,400X!  That outlier user had large and redundant data files that could be compacted dramatically through deduplication.

While much of the redundancy is related to the large number of user snapshots, increasing the number of preserved snapshots (e.g. the retention window) does not linearly increase the deduplication ratio because of metadata. For example, we saw the deduplication was as high as 5,000X for the outlier user before considering the impact of file recipes. A file recipe is internal metadata needed to represent and reconstruct the files in their deduplicated format. The recipe consumes a tiny percentage of the space compared to the actual file data. However, even when data isn’t changing, we still need a recipe for each file. This led to an interesting conclusion. We found that deduplication ratios tend to grow rapidly for the first few dozen snapshots and then grow more slowly because file recipes become a larger fraction of what is stored. There are even cases where deduplication ratios dropped because a user added novel content.

Finally we looked at grouping users together to see if there are advantages to deduplicating similar users together. We found that there are pairs of users that overlapped as much as 44%, which can directly turn into space savings by placing those users on the same deduplication system. Intelligent grouping and data placement can improve customers’ deduplication results.

These findings can provide guidance to storage designers as well as customers wondering how their system will respond to long-term deduplication patterns. Customers and designers should think about matching chunk sizes to backup policies, metadata management at scale, and grouping together similar users’ data. There are many more details in the paper, and researchers are welcome to use our tools and data set to perform their own analysis.

[1]Zhen Sun, Geoff Kuenning, Sonam Mandal, Philip Shilane, Vasily Tarasov, Nong Xiao, and Erez Zadok. “A Long-Term User-Centric Analysis of Deduplication Patterns.”  In the Proceedings of the 32nd International Conference on Massive Storage Systems and Technology (MSST 2016).


-Philip Shilane @philipshilane

The Robot Rock Cortex

The Robot Rock Cortex

Hurtling through the IT multiverse on leading edge of a ray of light this week Inside the Data Cortex:

  • Mark wants to replace everyone with a robot. Including The Rock.
  • Stephen rejects this and believes The Rock is the biggest movie star in the world. Both worry about Nick Nolte…and Ricky Martin?!?
  • Mark’s hero? Attila The Hun. Then he kills the vibe by deciding this week we’re talking about APIs. It is so disappointing.
  • Ransomware, Isolated Recovery Services, APIs for Services Providers, level based targeting, the stuff which will never be standardised, test automation and doubling your salary to slum it.
  • This time in books, Stephen wades further into the creation of the United States in “Revolutionary Summer” while in “The Great Crash, 1929” Mark discovers we are not stupid, just human. A Neal Stephenson recommendation, Asimov did it before you and in “The Price of Prosperity” the Emperor Augustus puts a tax on the childless.

Download this episode (right click and save)

Subscribe to this on iTunes

Follow us on Pocket Casts
Stephen Manley @makitadremel Mark Twomey @Storagezilla

C-D-M and Y-O-U: Excess copy data is a problem, but how do you solve it?

C-D-M and Y-O-U: Excess copy data is a problem, but how do you solve it?

If you’ve been following EMC’s latest announcements, one of the numbers you’ve seen repeated over and over… and over is $50 billion, the amount that the “copy data problem” is expected to cost customers globally over the next three years. Given such an outrageous number, it’s hard not to take a closer look at what’s causing this major cost overrun. I’ll save you the Google search and tell you right now: your numerous data copies are taking up valuable space on your storage, and the decentralized self-service methods of monitoring, managing, and protecting these copies are costing you a lot of time and money due to lack of oversight.


You can’t expect your DBAs and application owners to deviate from native copy creation processes, and you can’t get rid of every copy in your data center. Copies are vital to supporting nearly every task that shouldn’t be done with production data – operations, analytics, dev/test, data protection, and more. But how effective are you at managing those copies? Can you effectively mitigate the risk associated with self-service copy creation? Do you have the right number of copies on the right storage? Copy management solutions provide a central way to supervise copy creation and administration, which means you get to reclaim control of your copy data. With the right copy management solution, application owners and DBAs can continue to create copies while providing you with a way to oversee copy orchestration and ensure that copies are on the right storage to meet SLAs and mitigate risk.

Okay, so you get it – copy data management is relevant and important to enable self-service, ensure business compliance, and mitigate security and data protection risks. Now here’s the important question: which copy data management solution is best for you?

Traditional Copy Data Management

To date, most copy data management solutions have followed the same traditional approach and architecture. Basically, traditional copy data management consists of a server and storage. When installed, the CDM product is inserted into the copy data path and it copies your production database to the product’s own storage, creating a “gold” or “master” copy. The master copy is the copy for which all other copies are derived, and it is kept up to date with your production database through a scheduled synchronization process.

However, this architecture has some drawbacks:

  • Introduces a bottleneck in the copy data path
  • Requires reworking operational workflows and additional hardware
  • Copies are stored on a secondary storage device not designed for protection
  • Centralized copy management hardware creates a single point of failure

The limitations of the traditional copy data management offerings have prompted the conception of a new architecture.

Modern Copy Data Management

Modern copy data management, like EMC Enterprise Copy Data Management (eCDM), allows you to non-disruptively discover copies across both primary and protection storage in your data center. It embraces the decentralized ways of creating copies and the various underlying storage technologies that empower efficient copy creation, orchestration, and protection. The solution will non-disruptively discover those copies and monitor their lifecycle across the data center. Then, using the same solution, you can create customized service plans, automate SLO compliance, and make informed decisions about your copy data. Through this model, storage administrators, backup administrators, application owners, and DBAs can continue to create copies however they wish while still providing you with the global oversight needed to ensure compliance with various business or regulatory objectives.

Now that I’ve described the solutions, you can decide – copy data is a problem, but how will you solve it? To learn more about eCDM, check out

-Tyler Stone @tyler_stone_

The Portfolio Life

The Portfolio Life

EMC NetWorker 8 launched in June 2012. I’d just spent 5 hours recording a video for the launch. Customers were excited about the new architecture and the tighter integration with Data Domain. Sales were already hyped by the revenue growth started with NetWorker 7.6.2. The NetWorker 8 launch was going to be an “I’m Back” moment. Between the adrenaline and the caffeine, I was vibrating as I walked through the building. Then a NetWorker engineer sidled up to me and asked, “So, does this launch mean we’re killing NetWorker?”

This week’s question – “Are we killing XtremIO?”

Portfolio Companies – Nothing Ever Dies

Companies decide who they are going to be: consumer vs. business, product vs. services, profitable vs. unicorn. One of the biggest choices is whether to be single product vs. portfolio. At a single product company, there is little confusion about what product matters, but you can get constrained by the limits of that product. At a portfolio company, you can build/buy whatever you need, but there is complexity in having multiple products. And, of course, at a portfolio company, you have to answer the “are you killing Product X” question. As an old CEO said, “That’s the life we’ve chosen”.

Over the past few years, each product has had at least one customer question whether we’re killing it. My favorite was the customer who asked if Centera would kill Data Domain. (Yes, I did write that sentence in the proper order.) The truth is, it’s almost impossible to kill any product at EMC. Each product has at least one massive customer who has built a business-critical process around it; that customer, of course, will stop working with EMC if we don’t support that product. At a portfolio company, there are no “independent” product sales. That’s why we’re so careful about adding a new product – once you’ve put it in, it’s there forever.

The result – it’s almost unheard of to kill a product, much less a high-growth, high-revenue product.

All-Flash Storage is not One-Size-Fits-All

If you think of “All-Flash Storage” as a market, like “Purpose Built Backup Appliance” (think Data Domain), then it makes sense that you think you only need one product. If all that matters is the storage media, then the functionality, cost/performance, reliability, availability, and protocols are irrelevant. The applications will be so thrilled to have “All-Flash Storage” that they’ll re-architect to fit whatever limitations the storage system has. Not only does the universe revolve around storage, but it revolves around storage media. (Not surprisingly , narcissism is often an attribute of a single-product company). That’s the logical conclusion of the arguments I hear.

All-Flash Storage is not a new market. Flash storage is disrupting the storage media market, but not the storage market. All-Flash has become ubiquitous across both traditional and new arrays and vendors, so it’s important, but it’s not a separate market. All-Flash does drive architecture and product evolution, but we’re all still building storage arrays. If storage media changes really did create new markets, then I want more hype around Barium-Ferrite tape and shingled magnetic recording disk (SMR). (Note: I really don’t. On the other hand, the DNA storage is cool.)

What Makes Each All-Flash Product Special

Each of the all-flash primary storage products in the Core Technologies portfolio (VMAX, XtremIO, Unity) has features and architectures that make them unique. (Disclaimer: With the amount of engineering invested in each product, there are thousands of “favorite architectural choices”. These are mine. If you want to tout others, feel free to use the comments section or spray paint them on the side of my house; my HOA already hates me, anyway.)

VMAXCaching/Tiering. Everybody knows about the performance, reliability, availability, data protection (SRDF, SnapVX, ProtectPoint), protocols, etc. At the core, however, the FAST (Fully Automated Storage Tiering) algorithms fire me up. When everything is “All-Flash”, though, who needs caching/tiering? In the next couple of years, however, we’ll see persistent memory, flash, shingled disk, and cloud storage – understanding how to best store and serve data will matter more than ever. VMAX has the metadata analytics to be the storage media broker for core and critical applications.

XtremIOVersions (Copy Data Management). When people think of XtremIO, they think of speed and deduplication. Storage speed and space efficiency isn’t enough to survive in the modern metadata center, though. XtremIO’s dedupe is just the first way to expose the value of the block sharing architecture. The sustained value comes from creating and distributing lightweight copies for test & development, data protection, and analytics. Unlike many systems, I don’t need to worry about complex links to other copies (block sharing creates independence), the performance hit on the production copy (scale-out), or crushing the network (dedupe-aware data movement). XtremIO has the metadata management to be the system of choice for the DevOps and analytics world…

UnitySimplicity. Most storage systems are skewed toward simplifying enterprise data center challenges. That means scale-out, heterogeneous storage managed by dedicated IT teams. I love scale-out (see VMAX and XtremIO), but it complicates install and management of well-known consolidated workloads. Similarly, I love heterogeneous data protection, but sometimes replicating between two similar systems is better (especially if one is All-Flash and the other is Hybrid to reduce costs). I see the value in feature-rich dedicated storage management, but sometimes I want to just get a basic environment up and running in 15 minutes or less. As the metadata center shifts toward wanting simple, agile, application/VM-driven storage, Unity has the simplicity to deliver.


Each system has a design center that any “one-size-fits-all” product can’t deliver. Of course, there are many workloads that all of these systems (and many competitor’s products) could handle without a problem. There will always be a baseline of functionality (e.g. in CDM, caching/tiering, and simplicity) that we’ll deliver across the platforms, and even strive to drive the baseline higher. In virtually every environment, however, key applications will drive requirements to optimize in some direction. I believe that these 3 design centers will be the most critical in the storage space.


EMC is a portfolio company. The storage products in our portfolio will continue to evolve with the media transitions. Remember, All-Flash Storage isn’t a market – it’s a point in time for the type of media we’ll use in our systems. Soon enough, you’ll hear about All-Persistent-Memory Storage. Regardless of the media, our storage systems are differentiated by their software design center, and you’ll see us continue to extend our functionality in those areas. Each system will be part of the Modern Metadata Center.

In summary, when we talk all-flash: XtremIO is not dead. VMAX is not dead. Unity is not dead.

Oh, and in case anybody is wondering, NetWorker is alive and well, too.

Stephen Manley @makitadremel

Cloud Native for The Enterprise

Cloud Native for The Enterprise

The “Cloud Native” application architecture is disrupting the way organizations build software because it generates massive productivity boosts. The two major benefits are: 1) getting from idea to production faster and 2) scaling more easily. “Cloud native” helps remedy the biggest challenges of modern software. Cloud native patterns and practices, originally crafted by the likes of Google or Netflix, have found their way into the industry via popular open source projects. Developers from small startups all the way to huge corporations are adopting those technologies and practices and weaving them into the software fabric of their business.


In this series of articles, we’ll explore how cloud native practices are affecting companies, especially enterprises. We’ll look at this transformation through the eyes of a “typical enterprise” focusing on their unique needs. We’ll make some observations on their challenges, how they are addressing them, and what vendor opportunities lie ahead in this market.

“if you want to understand today, you have to search yesterday”

~ Pearl Buck

Part I – The Heroku Use Case

To understand the current state, we’ll first briefly review the history of what we call “Cloud Native for Masses”. Heroku was the first successful initiative popularizing cloud native for developers outside the software giant club. Until Heroku, organizations had to build an entire stack of middleware software to deliver cloud native microservices in production. The software giants have done exactly that – built or patched together a variety of tools to maintain their microservices. Netflix, Twitter, and Facebook all had similar, but proprietary, stacks for doing service discovery, configuration, monitoring, container orchestration etc. Heroku engineers were able to distill a key ingredient of cloud native as we know it today: the “platform” component aka PaaS.


cloud native 1.jpg

Heroku – Cloud Native for the masses

Heroku began by hosting small-to-medium scale web applications by cleanly separating between the platform’s responsibility and the application’s. Coining the term 12-factor apps, Heroku could run, configure and scale various types of web applications. This enabled their customers to focus on their business and applications, delegating maintenance of the platform to Heroku. We won’t go into a detailed description of the Heroku architecture and workflows, but we will describe one key aspect, since it is important for this analysis – how Heroku handles stateful services.


In order to orchestrate the application, Heroku had to create a clear line between the stateful and stateless parts of the application; in Heroku terminology it separated the application and Add-ons. The reason for the split is physics. Scaling, porting, and reconfiguring stateless processes is done seamlessly using modern container orchestration (Dyno – in Heroku). Doing the same operations for stateful processes requires moving physical bits between the processes and maintaining their consistency. To scale a stateless process, you run another instance. To scale a stateful service involves setting network intensive distributed state protocols that are different from system to system. Heroku’s way of solving the stateful needs is by focusing on popular stateful services and offering those as dependencies to the applications. Heroku added Postgres, Redis, RabbitMQ, email service, SMS – all as services in Heroku’s add-ons marketplace maintained by Heroku engineers (DBAs, IT).


cloud native 2

App space v.s. Stateful Marketplace

For “the Heroku use case”, this separation was elegant since it not only solved real world problems, but also was relatively easy to monetize. Developers could use variety of programming languages and stacks for their applications without requiring Heroku to support each stack (*to learn more, point google at “heroku buildpacks”). Focusing on web applications, Heroku’s experience allowed them to offer unique capabilities out of the box like powerful http caches, developer workflow tools etc. Another advantage of this approach is that it creates stickiness with Heroku because the data is managed by the service and porting the data won’t be a straight forward task. Over time, more vendors offered Add-ons on the Heroku marketplace and enabled 3rd parties to leverage the Heroku platform.


Seeing the potential in the Heroku architecture led to various initiatives trying to imitate it in a more generic and portable manner. In the next article we’ll focus on one of those initiatives – Cloud Foundry. We’ll observe the resulting implications and effects when applying the Heroku architecture on use cases other than the “Heroku hosting use case” it was designed for.


To summarize, we’ve seen that in order to deliver Cloud Native Applications, developers need a platform – Either they build it themselves, or they buy/lease one. In most organizations, having engineers with this skillset doesn’t make sense – hence there is room for consumable PaaS platforms. A common metaphor I heard from Pivotal puts this point nicely: “Some people are superman so they can fly around, but most of us need to board an airplane”.


Amit Lieberman @shpandrak, Assaf Natanzon @ANatanzon, Udi Shemer @UdiShemer

Copy Data Management – What About Unstructured Data?

Copy Data Management – What About Unstructured Data?

There’s a comfort in certainty. When you know where you’re going… when you know what’s going to happen… when you know you’re right… the future can’t come fast enough. For the past twenty years, I’ve felt that way. In the past six months, however, I’ve found out what it means to have questions that I can’t confidently answer. Since misery loves company, I’ll share my questions and internal debate.

This week: What does Copy Data Management mean for Unstructured Data?

What is Copy Data Management?

Copy Data Management (CDM) is the centralized management of the copies of data that an organization creates. These copies can be used for backup, disaster recovery, test & development, data analytics, and other custom uses.

Each CDM product has a unique target today. Some CDM products focus on reducing the number of copies. Others emphasize meeting SLAs and compliance regulations. Still others try to optimize specific workflows (e.g. test & development). The products also split on the layer of copy management: storage, VM, application, or cloud.

Despite the product diversity, they all have one thing in common: application focus. The products all try to streamline copy management for applications (whether physical, virtual, or cloud). The decision makes sense. Applications are valuable. Application developers create multiple data copies. Application developers are technically savvy enough to understand the value of CDM and pay for it.

Still, unstructured data continues to grow exponentially. Much of that data is business critical and a source of security and compliance concerns. Traditional backup and archive techniques have not scaled with unstructured data growth and use cases, so companies need new answers.

What should CDM products do about unstructured data (i.e. files and objects)?

Affirmative Side: CDM should Include Unstructured Data

Copy Data Management should include unstructured data because there is more commonality than difference.

First, the core use cases are common. Customers need to protect their unstructured data in accordance with SLAs and compliance regulations, just as they do their applications. While customers may not run test & development with most of their unstructured data (except for file-based applications), many are interested in running analytics against that data. With that much overlap in function, CDM should aggressively incorporate unstructured data.

Second, unstructured data is part of applications. While some applications are built with only containerized processes and a centralized database, many apps leverage unstructured data (file and object) to store information. Thus, the “application” vs. “unstructured data” dichotomy is an illusion.

Third, the data path will be common. Customers use files for their applications already, like running Oracle and VMware over NFS. Since CDM products are already managing files for their application data, why not extend to unstructured data?

Finally, today most customers use one tool to manage all of their copies – their backup application. CDM is an upstart compared to backup software. In a world where everybody is attempting to streamline operations and become more agile, why are we splitting one tool into two?

The use cases and data path are similar, CDM needs to support files no matter what, and customers don’t want multiple products. CDM must support unstructured data – case closed.

Negative Side: CDM should Include Unstructured Data

My adversary lives in a legacy, backup-centric world. (Yes, I often resort to ad hominem attacks when debating myself.) Copy Data Management and Unstructured Data Management are evolving into two very different things, and need to be handled separately. The use cases are already very distinct and the divergence is increasing. The underlying technical flows are also from different worlds.

First, the requirements for application vs. unstructured protection are as different as their target audiences. Application owners recover application data; end-users recover unstructured data. Application owners, a small and technically savvy group, want an application-integrated interface from which to browse and recover (usually by rolling back in time) their application. In contrast, end-users need a simple, secure interface to enable them to search for and recover lost or damaged files. Protection means very different things to these two very different audiences.

Second, the requirements for compliance also vary because of the audience. Since there are relatively few applications (even with today’s application sprawl), application compliance focuses on securing access, encrypting the data, and ensuring the application does not store/distribute private information. Unstructured data truly is the Wild West. Since users create it, there is little ability to oversee what is created, where it is shared, and what happens to it. As a result, companies use brute force mechanisms (e.g. backup) to copy all the data, store those copies for years, and then employ tools (or contractors) to try to find information in response to an event. When you have no control over what’s happening, it’s hard not to be reactive. With applications, you can be proactive.

Third, test and development is becoming as important as protection. The application world is moving to a dev ops model. Teams automate their testing and deployment, constantly update their applications, and roll forward (and back) through application versions faster than backup and recovery ever dreamed of. As a result, the test and development use cases will become more common and more critical than protection. Over time, they may even absorb much of what was considered “protection” in the past.

Finally, the data flows are very different. To support the application flows, the data needs to stay in its original, native format. You cannot run test and development against a tar image of an application. Fortunately, the application infrastructure has built data movement mechanisms (generally based on snapshots or filters) to enable that movement. Even better, since the application has already encapsulated the data, it becomes possible to just copy the LUN, VM, or container without needing to know what’s inside. In contrast, protecting unstructured data is messy. Backup software agents run on Windows, Linux, and Unix file servers to generate proprietary backup images. NAS servers generate their own proprietary NDMP backup streams, or replicate only to compatible NAS servers and generate no catalog information. There are few high-performance data movement mechanisms, and since each file system is unique, there is no elegant encapsulation. The data flows between application and unstructured data could not be more different.

Due to the differences in use cases, users, and underlying technology, it is unrealistic to design a single CDM product to effectively cover both use cases.

Verdict: Confusion

I don’t see an obvious answer. The use cases, workflows, and technology demonstrate that application data CDM is not the same as unstructured data CDM. Of course, the overlap in general needs (protection policies, support for file/object) combined with the preference/expectation for centralized support demonstrates that integrated CDM has significant value.

The question comes down to: Is the value of an integrated product greater than the compromises required to build an “all-in-one”? The market is moving toward infrastructure convergence, but is the same going to happen with data management software?

I don’t have the answer, yet. But just as Tyler Stone is sharing “how products are built”, I’ll take you behind the scenes on how strategic decisions are made. Just wait until you see the great coin flip algorithm we employ…

Stephen Manley @makitadremel

Unintellectual Thoughts

Unintellectual Thoughts

Emptying the dresser drawer of my mind.

  • When will all-flash protection storage become the “hot new thing”? To deal with the increased scale of primary storage capacity and more demanding customer SLAs, the industry is moving from traditional tar/dump backups to versioned replication. Thus, protection storage needs to support higher performance data ingest and instant access recovery. It seems plausible that protection storage will follow the primary storage path: from disk-only to caching/tiering with flash to all-flash (with a cloud-tier for long-term retention).
  • When will custom hardware come back? The industry has pivoted so hard to commodity components, it feels like the pendulum has to swing back. Will hyper-converged infrastructure drive that shift? After all, where better to go custom than inside a completely integrated end-to-end environment (as with the mainframe)?
  • Are job candidates the biggest winners in Open Source? Companies continue to struggle to make money in Open Source. Whether the monetization strategy is services, consulting, management & orchestration, or upsell, it’s been a tough road for Open Source companies. On the other hand, Open Source contributions are like an artist’s portfolio for an engineer– far more useful than a resume. Even better, if you can become influential in Open Source, you can raise your profile with prospective employers.
  • When will NAS evolve (or will it)? It’s been decades since NAS first made it easy for users to consolidate their files and collaborate with their peers in the same site. Since then, the world has evolved from being site-centric (LAN) to global-centric (WAN). Despite all the attempts – Wide-Area File Services (WAFS), WAN accelerators, sync and share – files still seem constrained by the LAN. Will NAS stay grounded or expand beyond the LAN? Or will object storage will simply be the evolution for unstructured data storage and collaboration?
  • What’s the future of IT management? Analytics. We’ve spent decades building element managers, aggregated managers, reporting tools, ticketing systems, processes, and layers of support organizations to diagnose and analyze problems. As infrastructure commoditizes, we should be able to standardize telemetry. From that telemetry, we can advise customers on what to do before anything goes wrong. If companies like EMC can make technology that reliably stores ExaBytes of storage around the world, we should be able to make technology to enable customers to not have to babysit those systems.
  • Will Non-Volatile Memory be the disruption that we thought Flash would be? Flash didn’t disrupt the storage industry; it was a media shift that the major platforms/vendors have navigated. (Flash did disrupt the disk drive industry.) The non-volatile memory technologies, however, could be more disruptive. The latency is so small that the overhead of communicating with a storage array exceeds that of the media. In other words, it will take longer to talk to the storage array than it will to extract data from the media. To optimize performance, applications may learn to write to local Non-Volatile Memory, shifting storage out of the primary I/O path. Maybe that will be the disruption we’ve all being talking about?
  • What happens when storage and storage services commoditize? The general consensus is that the commoditization of IT infrastructure is well under way. Most people feel the same about storage and storage services (e.g. replication, data protection, etc.) As commoditization happens, customers will choose products based on cost of purchase and management. As an infrastructure vendor, the question will be – how do we add value? One camp believes that the value will move to management and orchestration. I’m skeptical. Commoditization will lead to storage and services being embedded (e.g. converged/hyper-converged) and implicitly managed. Thus, I think there will be two paths to success. One path involves becoming a premier converged/hyperconverged player. The second revolves around helping customers understand and manage their data – on and off-premises. This means security, forensics, compliance, and helping users find what they need when they need it. Successful vendors will either deliver the end-to-end infrastructure or insight into the data. If you do both… then you’ve really got something. You can guess where I’d like Dell EMC to go.

I also wonder about whether software engineering jobs are following the path of manufacturing jobs, whether software-defined XYZ is a bunch of hooey, the future of networking, whether any of these big-data unicorns has a shot at success, and why people are so hysterical about containers. But we’ll save those incoherent thoughts for another time.

-Stephen Manley @makitadremel

Honoring EMC’s Core Technologies Technical Directors

Honoring EMC’s Core Technologies Technical Directors

How do you tell the story of a great organization like EMC? There are the big names – Egan, Marino, Ruettgers, Tucci. There are the outsized personalities – Scannell, Sakac, Burton, Dacier. There are the technical titans – Yanai, Gelsinger, Maritz. You can’t tell the EMC and EMC federation story without these epic players. But EMC isn’t about big names and glamor.


EMC’s culture is built on a principle best expressed by another technical genius – The Rock: ”Blood, Sweat, & Respect. The First Two You Give, Last One You Earn.”


I’m pleased to announce the latest EMC Core Technologies Technical Director award recipients. EMC Core Technologies recognizes technical leaders who have made a significant impact on the business through their contributions to products and solutions that help our customers.

TD 1

As you read through their contributions, you’ll see that Technical Director award recipients contributed to different products and solutions in very different ways. Despite the differences, they have one thing in common: when things needed to get done, they picked up a shovel and worked until things were right.


*NOTE: All TD recipients with a ’*’ earned the TD honor in previous cycles.


Scott Auchmoody – Scott, a founder of Avamar, has helped transform the backup industry. Prior to Avamar, the “state of the art” in backup was writing full backup images that backup storage deduplicated. Avamar created an end-to-end deduplication from client to backup storage. This architecture minimized server, production storage, network, and backup storage load, while also improving backup and recovery times. Subsequently, Scott played a central role in integrating Avamar and Data Domain. After that he, led the development EMC’s next-generation VMware backup and recovery solutions. Scott is a leading figure not just in delivering EMC’s backup solutions, but in advancing the state of the art of backup.


*Bhimsen Bhanjois – Bhim has led Data Domain replication, integration with backup software, and Data Domain Cloud Tier. Virtually every customer expects to replicate their protection data, and Data Domain’s network-optimized, flexible replication has become the standard of excellence. He also has helped Data Domain integrate with Avamar, NetWorker, RecoverPoint, and VMAX. Most recently, Bhim led the popular Data Domain Cloud Tier project. Bhim connects Data Domain to the rest of the ecosystem – from strategy to planning to execution.


Paul Bradley – Paul has been a leader in simplifying the management of VMAX systems. First, he was instrumental in streamlining the VMAX management tool stack. He led the implementation of Service-Level based management to the end-to-end process of: Planning, Provisioning, Performance Monitoring, and Protection. Second, as customers have struggled to manage large VMAX estates, Paul led the delivery of Unisphere 360 – the first data Center-wide VMAX Management and Monitoring tool. Moreover, Paul has created a new culture of simplicity of management in the Ireland Center of Excellence, so that VMAX continues to streamline its operations. The result – customers can deploy and manage VMAX for more uses at both smaller and greater scale.


Steve Bromling – Steve has been the architect and implementer for the anchor VPLEX infrastructure and functionality. Steve is responsible for the core data path of VPLEX and the distributed caching engine that deliver the active-active functionality of VPLEX. Steve has delivered changes in memory usage and layout that reduce response time variability, improve latency, and reduce hardware footprint. He also jointly created and architected MetroPoint – integrating data protection and availability – which has enabled customers to leverage the full data protection continuum. Steve has ensured that VPLEX meets our customers’ performance and functionality needs for their most business critical and valuable workloads.


*Ravi Chitloor – As one of the Chief Architects of Data Domain and an EMC Distinguished Engineer, Ravi has dramatically improved almost every part of the product. Ravi’s work in building the first system GUI enabled Data Domain to expand from NFS-based backups to being truly usable as a VTL Ravi then led Data Domain product mature into a Enterprise product in areas such as Security, RBAC, AAA, Licensing, SNMP and Reporting. By driving the creation of Data Domain Management Center, the largest customers were now able to manage multiple Data Domain systems at scale. Ravi’s leadership on mtrees and multi-tenancy APIs enabled Data Domain to expand into ITaaS/Service Providers markets and enabled Oracle admins to leverage Data Domain for direct backups. He has contributed significantly in developing Data Domain features/products such Data Domain Virtual Edition (DDVE), storage tiering, and Global Deduplication Array (GDA) as well as protection solutions like Avamar integrated with Data Domain and Protect Point (VMAX/XIO integrated with Data Domain. In his time at Data Domain, Ravi has also led supportability, quality, and testability initiatives. Today, he is part of the senior leadership team in defining the vision, strategy and roadmap of Data Domain. Ravi is responsible for the simple, reliable, secure Data Domain system that customers depend on worldwide.


Yaron Dar – Yaron has been the focal point for application intelligence in Symmetrix. Yaron’s work was the catalyst for the customer value and success of deploying Oracle databases on VMAX storage. From Oracle/VMAX data integrity validation, Oracle ASM space reclamation, integrating VMAX snapshots/clones with Oracle Enterprise Manager, and supporting SRDF Yaron has brought the best of VMAX to the Oracle environment. He has now been extending that expertise to cross-EMC solutions – e.g. ProtectPoint for VMAX with Oracle – tying together VMAX, Data Domain, and Oracle for industry leading data protection. Yaron also works directly with sales teams and customers to ensure that the engineering integration translates into customer value. The result of Yaron’s work is the exceptionally successful deployments of Oracle on VMAX across the globe.


*Rob Fair – Rob leads the protocols for Data Domain. Rob led the creation of Data Domain’s VTL interface. He worked on the SCSI target daemon that enabled Data Domain to connect to backup applications as a VTL and FC- BOOST device, and ultimately as a block-storage target for ProtectPoint. After that, Rob has been instrumental in Data Domain securely connecting to customers’ environments, especially focused on enhancing and supporting NFS. Rob has helped connect the value of Data Domain to our customers, regardless of their preferred environment and networking technology.


Mike Fishman – Mike, through development and acquisition, has helped EMC solve customers’ data protection and midrange storage challenges. As CTO of EMC’s Data Protection team, Mike was responsible for the extremely successful EMC Disk Backup Library VTL solutions. He was also instrumental to the creation of the EMC Data Protection portfolio – working on the acquisitions of Legato (now NetWorker), Avamar, and Data Domain. In the mid-range storage, Mike was part of the due diligence for Isilon and XtremIO. Mike’s development and M&A activity have enabled EMC to lead the industry in addressing customer’s data storage and protection challenges.


Terry Hahn – Terry is a systems management expert who has made it easy for customers to manage one, two, or dozens of Data Domain systems. The work began with laying the infrastructure for storing, processing, and reporting historical system data, so that we can help customers understand changes in their system’s behavior. Terry then applied that infrastructure to helping customers manage and address issues in their replication performance. To help customers manage at scale, Terry architected the original Data Domain Management Center. Recently, Terry has spearheaded the Data Domain Secure Multi-Tenancy work that is deployed across hundreds of customers and systems worldwide. Terry exemplifies both the increasing commitment and value in helping customers manage our systems.


*Mahesh Kamat – As one of the Chief Architects of Data Domain, Mahesh leads the Data Domain System Architecture and Design. Data Domain is the heart of our customers’ data protection solutions. Initially, Mahesh was a core member of the team that doubled Data Domain performance and capacity every year, while enhancing the Data Invulnerability Architecture. Scalable performance and reliable storage makes Data Domain the “storage of last resort” for so many backup customers. Today, Mahesh has led DDFS to improve support for random I/O, which has enabled support for Avamar backups, VM-image backups with disaster recovery, and ProtectPoint. He has been a catalyst for the delivery of Data Domain Virtual Edition, Data Domain Cloud Tier, and core Data Domain OS and system enhancements. Mahesh also mentors the senior engineering community so that Data Domain can continue to innovate and scale. Mahesh is responsible for Data Domain’s industry-leading performance, flexibility and reliability.


Anton Kucherov – Anton leads major initiatives that deliver strategic, innovative solutions for our XtremIO customers. With the importance of copy data management to our customers, it is critical that XtremIO can create and delete snapshots with minimal effects on the system. Anton led snapshot performance improvements that have helped some of our largest and most innovative customers. Anton is known for delivering simple, innovative solutions for complex system-wide problems. He’s also enabled XtremIO to expand its innovation and delivery capacity by growing and mentoring the team in the US. Anton is a technical leader, innovative engineer, and pragmatic problem solver who delivers critical value to our most strategic customers.


Brian Lake – Brian has been responsible for the core functionality, feature enhancements, and stability of VPLEX – a product that keeps thousands of customers’ systems online and available. Brian’s leadership on the VPLEX platform delivered a stable, reliable, high-performance system that customers deploy in front of mission-critical VMAX, XtremIO, and VNX systems. Brian’s performance work has delivered scale for all workloads – from small I/O to large, sequential I/O. Finally, his innovation on MetroPoint enabled EMC to deliver a unique and successful integration of data protection and availability. Brian’s work has helped VPLEX become a trusted solution for customers’ availability challenges across their entire environment.


Amit Lieberman – Amit has been a technical leader and innovation engine for Data Protection Adviser (DPA). Data protection customers depend on DPA to understand and monitor their end-to-end data protection environment. With DPA 6, Amit brought together the replication and backup architectures to provide an end-to-end view of their protection environment. Amit was also crucial in delivering high-performance, clustering, and real-time analytics in the DPA 6 line. He also worked on integrating DPA and ViPR-SRM. The result is that EMC delivers a more comprehensive, more reliable, more scalable, more flexible view of data protection for our customers.


Kobi Luz – Kobi a key leader of the XtremIO R&D Organization.  He’s been driving the core development of latest releases. Kobi led the XtremIO 4.0 release and helped deliver major technical with cross team integration. This includes adding non-disruptive cluster upgrade, native RecoverPoint support for DR, AppSync integration for Copy Data Management. Just as importantly, Kobi has helped expand the organization to enable XtremIO to continue its hypergrowth, while also being one of the core team members for resolving the most complex of technical challenges. Kobi both innovates and delivers for XtremIO’s customers.


John Madden – John’s technical leadership has been instrumental to some of EMC’s most dramatic transformations. John was a member of the “Open Symmetrix” team, that added SCSI and Fibre connectors to Symmetrix. This brought EMC from mainframe-only to open systems. John then led the team that enabled customers to manage their own Symmetrix. For example, the SRDF control scripts enabled customers to manage their own SRDF DR operations, instead of having to call EMC support to make changes for them. Most recently, John was a key influencer on further simplifying VMAX management with FAST-VP and SLO based provisioning. The unique longevity and success of the Symmetrix platform in the storage industry has been due to leaders like John Madden driving internal disruption.


Owen Martin – Owen has been at the heart of some of the most differentiated storage functionality in the industry. First, Owen led the radical shift in the provisioning and consumption of enterprise storage with the creation of Fully Automated Storage Tiering (FAST). The majority of VMAX customers use FAST to automatically place data in the most effective tier of storage. As the storage market continues to create differentiated tiers of storage – non-volatile memory, flash, disk, cloud – FAST will simplify and optimize customer environments. Owen was also critical to the SLO (Service Level Objective) based provisioning that streamlines the deployment and management of VMAX storage. Owen’s contributions have made VMAX a uniquely powerful, optimized, and simple-to-manage storage system.


*George Mathew – George’s work on the Data Domain File System has helped it solve even more customers’ protection challenges. As the lead for Directory Manager(DM) 2.0, George led the work on multi-threading DM and improving Garbage Collection enumeration. The result – Data Domain achieved the incredible goal of supporting 1 Billion files. This enables customers to use Data Domain for file archiving. George also led DDFS support for HA. George continues to evolve the Data Domain into a system that solves customers’ next generation protection challenges.


Steve Morley – Steve was a major driving force behind the MCx re-architecture delivered in VNX2 and carried forward into Unity.  Steve had significant development contributions in all three areas of MCx: DRAM Cache, SSD Cache, and RAID.  His systems thinking, development experience and internal knowledge of the entire IO stack helped identify bottlenecks and engineer multi-core improvements – including multi-core IO scheduling across the entire data path stack.  He also drove support for enhanced drive queuing and data path throttling mechanisms.  These improvements allowed VNX2 and Unity systems to scale performance at an impressive 96% linearity with CPU core count. MCx and Steve’s work on it are directly responsible for the multi-billion dollar success of VNX2.


Peter Puhov – Peter has delivered many significant contributions to Midrange products.  He architected and delivered the FBE infrastructure, a framework for building stackable system components, and leveraged it to deliver the multi-core infrastructure for the RAID component of MCx. This framework is now also being used in Unity to implement Mapped RAID. In addition, Peter helped architect and deliver Controller Based Encryption in VNX2.  He also pioneered work in predictive analytics of disk failures to improve data availability and system drive performance.  He has been a leader in development best practices, setting the bar for high-quality maintainable code.  As a result of Peter’s work, thousands of customers can depend on VNX and Unity for high-performance, scalable, reliable storage.


*Naveen Rastogi – Naveen is an expert when it comes to systems management and customer advocacy. He has made customers’ data protection simpler, both with his work on Data Domain and on ProtectPoint. Naveen delivered the core management infrastructure that still provides the basis for how all system management is done. Naveen was also instrumental in developing the Data Domain Global Deduplication Appliance, enabling customers to scale their Data Domain. More recently, Naveen spearheaded the Data Domain’s support for ProtectPoint – enabling industry-leading high-performance backups directly from VMAX to Data Domain. After that, Naveen led the entire ProtectPoint for XtremIO project. From simplifying daily management, to enabling customers to manage at scale, to reducing the complexity and overhead of backup, Naveen simplifies customers’ backup challenges. Today Naveen is driving Data Domain RESTful APIs as the vanguard of the “Simplification” movement.


Tony Rodriguez – Tony has consistently led EMC into new markets and technologies to solve new customer challenges. Tony was one of the original architects of EMC Atmos – our initial foray into object storage. The highly scalable and resilient architecture enabled Atmos to become an industry-leading product which still provides the foundations of some of largest customers’ global applications. Subsequently, Tony has led EMC’s efforts in critical acquisitions, next-generation interconnects, and the future of networking. Tony has helped create not only new products, but entirely new solutions and markets.


Zvi Schneider – Zvi is the Chief Architect for XtremIO R&D. He led the core development of the Data Path Module, which delivers industry-leading performance, efficiency, and copy data functionality. Furthermore, Zvi works across the organization to ensure that XtremIO delivers sound designs and solutions to ensure high performance, scalability,, and reliability that customers expect from EMC. Whenever there is a challenge in XtremIO, Zvi is the ”go-to” member who can solve the problems. Zvi is one of the key contributors for XtremIO’s continued technical leadership in the market.


*Udi Shemer – As Chief Architect for RecoverPoint, Udi continues to solve customers’ data protection and replication challenges. Initially, Udi worked on RecoverPoint splitters, which efficiently extract the data from sources, so that it can replicated for protection. Udi’s work on RecoverPoint for VMAX2 continues to provide protection for mission-critical applications around the world. More recently, his work on adding replication support for VPLEX enabled customers to realize the value of continuous availability with reliable, high-performance data protection. Furthermore, Udi’s leadership on RP4VM enables customers to protect all of their VMware VMs, regardless of the underlying storage. Udi has consistently delivered solutions that enable customers to focus on their business, knowing that their data is safe.


Ed Smith – Ed has been instrumental in improving the quality and velocity of EMC’s Midrange products – constantly executing on the goal of creating end-to-end analytic-driven automated testing. For the past four years, the team has benefited from the Continuous Integration Testing that Ed spearheaded. Furthermore, the Automated Results Triage Services simplifies and accelerates the process of filing and triaging system defects found during testing. Finally, Ed has been responsible for consolidating the test results which enables analytic analysis. The result is that over that time, we’ve executed more reliably and delivered ever-higher quality products for our VNX and Unity customers – helping the bottom line for both EMC and our customers.


Erik Smith – As the lead engineer for Connectrix, Erik delivers network technology that enables customers to connect their servers to storage. By leading the Connectrix Fibre Channel and TCP/IP qualifications and technical documentation, Erik ensures that server and storage can be reliably connected by Connectrix switches. Erik is also a leading Storage Connectivity evangelist. He works with the field and customers to help architect, configure, and manage their environments – with direct meetings, industry-leading “Brass Tacks” blog, and with his highly attended EMC World sessions. He is also an industry leader in the future of storage networking, including driving the definition and acceptance of Target Driven Zoning by T11. Erik’s work continues to enable thousands of customers to reliably, securely, and rapidly access their data.


Lei Wang – Lei has helped make the mid-range team’s goal of End-to-End Automation a reality with both his architectural abilities and leadership. As EMC’s customers increasingly adopt a DevOps model for running their IT infrastructure, Lei is applying those same principles to running our automation infrastructure. As a result of his work on creating a test harness for fully automating tests, the midrange team tests early and often – improving quality and agility. Furthermore, Lei has brought together the teams across the globe on a common approach to automated testing. Lei’s work has not only resulted in higher quality releases for our customers, but in developing a Quality Engineering organization that will continue to accelerate and improve the midrange systems that our customers rely upon.


Vince Westin – As a technical evangelist for the VMAX, Vince has synthesized customer input and technical trends into fundamental product changes. Vince has been a leader in driving VMAX to adopt flash. First, he showed both the technical feasibility and customer desire for higher degrees of flash in the hybrid VMAX systems. Second, he was a key contributor to product management, engineering, and performance engineering on the capabilities of VMAX All-Flash leveraging low-write per day flash storage. Finally, he pioneered what has become the VMAX sizer tool, enabling EMC to deliver the right system for our customers’ needs. There is no one at EMC that advocates more for both our customers and the potential of our technology.


William Whitney – Bill has been critical to integrating EMC’s VNX and Unity NAS functionality into customer environments. Since the creation of NAS systems, backup and recovery has been one of the industry’s biggest challenges. Bill was instrumental in delivering EMC’s support for NDMP, the NAS industry standard for backup. He also drove file-level deduplication, compression and tiering in our NAS stack. Most recently, Bill has been driving the use of VNX’s NAS stack for VMware environments through his significant contributions to the VNX VAAI provider, enablement of the new UFS64 file system for NFS datastores and most recently the VVOL implementation. For customers who prefer running VMware over NFS for simplicity, Bill’s efforts have helped EMC support these high-profile customers.


Andy Wierzbicki – Andy embodies the role of customer advocate for mainframe. With a background in both support and engineering, Andy understands that there is nothing more mission-critical than mainframe and ensures that we exceed our customers’ expectations. First, Andy worked cross-functionally to ensure that the VMAX3 platform would meet customer reliability, performance, and response time expectations. Second, if customers hit issues, Andy leads the way on reproducing the issue so that we can diagnose, understand, and resolve the customers’ issues as quickly as possible. Mainframe still runs the core of the largest organizations in the world – Andy makes sure that VMAX delivers the quality and reliability that those organizations need.


*Doug Wilson – Doug has delivered innovative, reliable platforms for Data Domain. Doug was the lead architect for the DD2200/2500, shepherding the success of the programs from the requirements to the release. During that project, Doug was instrumental in adopting battery-backed persistent RAM, instead of NVRAM; which gave the DD2200 significant cost advantages. Koala was also EMC’s first “gray box”, and Doug brought together Data Domain, GHE, and the ODM (Original Design Manufacturer) partner. Finally, Doug helped grow technical leads to take over the DD2500 and DD2200. Doug continues to work on delivering the next-generation platforms to help our customers protect their data. Doug delivers, innovates, brings together the organization, and helps others advance their career.


*NOTE: All TD recipients with a ’*’ earned the TD honor in previous cycles.


EMC has always prided itself on its scrappiness and work ethic. Those adjectives may seem odd for a company that became and continues to be an industry titan. On the other hand, that’s exactly how EMC became what it is – fighting every day to make better, faster, more reliable products to solve our customers’ problems. That’s the ethos that we need to continue to be successful as Dell EMC. Congratulations to these Technical Director recipients. Now get back to work.🙂


-Stephen Manley @makitadremel


Get every new post delivered to your Inbox.

Join 117 other followers