Now that I've set the stage in the Financial Forum series of posts I'd like to conclude them by talking about how Hitachi is setting the pace in the market. To start, and so that this piece can stand on its own, you'll find in the summary of several trends included in picture to the left: the need for deployment speed, real scale, and an order of magnitude disparity in bus speeds versus LAN/MAN speeds. These trends are causing a shift in application and platform architectures from typical monolithic to something different. In fact this topic was discussed a bit in our Global Account and Global Systems Integrator Customer Community under the title "Bi-modal IT Architectures?" where we pointed out the shift away from the traditional to a revised model that is impacting how new applications are both written and deployed. Hitachi is indeed responding, yet I don't want to repeat the discussion in the Community. Therefore, I'll include another image illustrating three things we're doing that follow this architectural paradigm shift. Here Hitachi is fielding UCP (a programmatically controllable scale-up private cloud in a box), HCP-Anywhere (a desktop and mobile content access package with protection assurances), and our HUS-VM (a 7u thin 1M IOP All Flash Array without compromise). What I find most striking by all of this is that DAS and private networks are coming back with a vengeance. So after all of the years of working through consolidation and centralization we are set to enter an era, which isn't quite distributed and isn't quite centralized. It is something in between where the merits of each approach solve a portion of the emerging problem space. Some of this is due to the behind the scenes push towards exa-scale architectures, yet the majority comes an emerging era of super connected devices that exert pressures on network pipes. (For example if we're sensing, processing and predicting on trains or mining devices we need to respond locally to inform the operator on this platform. If we use a purely centralized IT model then notifying a train operator of a failure condition would potentially incur a round trip to a centralized system inserting delays in the decision making chain which is totally unacceptable when lives are on the line.) I want to diverge from the story for a moment and talk about flash + HUS-VM. There is a lot of "snake oil" being sold in the market now about flash, storage class memories, etc. even when there are data that points to the contrary. Let me get specific by reflecting on checking the box versus getting material benefit. I'm sure by now you've heard about our stellar SPEC SFS showing which has some great performance and overall response time numbers, yet they are not at the absolute top of the heap. Let's take a closer look -- thanks to El Reg for the pointers -- and what you'll find is that our 4 node 4100 cluster backed by the HUS-VM All Flash Array was 50% as fast as a 140 node Isilon 200x. The HUS-VM All Flash Array beat out a VNX5700 in aggregate performance with only 64 SSD-like FMDs versus 500 SSDs used in the VNX. In other words, we used 35x fewer nodes to achieve 50% the performance of Isilon and 10x fewer SSDs to achieve an IOP density greater than the VNX. Said another way, we've literally deduplicated both space and power consumption when compared the competition. So what does an all flash array with deduplication really give you? Shouldn't the overall story be about aggregate efficiencies, including deduplication, power consumption, densities, etc.? (Note: in the SPEC configurations we are able to supply deduplication as a feature so we can certainly check the box but that's not the point.)
Increasingly, we see that applications on the "edge" demand intelligent memory-based storage access as close as possible. For users with extreme latency requirements we can help them out today with an HUS-VM adjacent to their compute platforms, LPARs, VMs, OSes and Applications. However, deploying this architecture pervasively requires users to pay for a physical storage controller plus the memory media. As a consequence, most users have to deploy caching or semi-persistent solutions, like FusionIO, to achieve similar benefit at a reduced cost. In reality, many modern flash suppliers are creeping up the stack and discovering that managing this footprint like a stable storage system (and less like a cache) is really, really hard. This is one of the beauties of the common Storage OS we are deploying in our platforms today. We are proud to lead the industry with innovations on cache heavy stable storage systems yet the pernicious meme in the industry is that we only make hardware-based platforms. Our engineering abilities and skill sets span from hardware to high value software within the IT domain. This affords us many degrees of freedom because we can solve problems purely in the software domain, the hardware domain or a hybrid between the two. Remember that point on space reduplication and capacity deduplication versus when checking off that feature box. This isn't to say that we are immune to the development in the COTS space and we are of course carefully watching where our primary chip partner is going as we have been leveraging their intellectual property more and more as time goes on. But don’t take my word for it take a look at the picture to the left which supplies a high level view of how we've reduced the number of Hitachi specific microprocessors yet we still achieve a solid benefit for our users and customers. While I don't want to spill the beans, I can say that we are very deliberate about how we elevate the software content in our storage platforms. As an aside, we do have Software Defined Content in the form of shared nothing, scale-out object stores, edge based content sharing systems, file sync & share and more coming along the way. We believe the primary reason for offering scale-out object and associated services as “Software Defined Storage Content” is because the applications that exist in this problem domain are a better match to scale-out and distributed. Here's a simple way to look at things, and inversely, why moving to a pure software Block-OS is not exactly straight forward: Indeed probabilistic, embarrassingly parallel, and eventually consistent applications are emerging and scale-out architectures are a solid fit. However, in the event that you have processing with hard commitments, these architectures are not necessarily the best fit. After all, do we want an eventually consistent financial trade or do we want to be discussing the probability of a bank account balance? An obvious question is why on earth would Hitachi Data Systems be getting into engineered systems, compute platforms, advanced software like in-memory analytics, etc.? Of course there is the point of Hitachi's “Change the World” vision of Social Innovation, yet I want to put a bit more of a practical face on Social Innovation. Specifically, not only do we make Scanning Tunneling Electron Microscopes, MRI scanners, super big mining equipment, trains, power systems, people movers and water treatment plants… in some cases we also jointly operate with our users or operate them directly. This sets us up in a very unique place where we feel both the builder and the user pains. I would also argue that this very point puts us on the “Things” side of the “Internet of Things”, unlike many of our contemporaries in the market.
Top Hitachi executives and former HDS leaders, like Shinjiro Iwata & Hiroaki Nakanishi, are facilitating increased intimacy between Hitachi group companies and organizations. The backing of top Hitachi leadership has led us to one of the Systems Integration teams that supports the Financial Services sector in Japan, see the image on the left. What we found from this group is an ingenious in-memory application architecture that drives latencies out of the equation, allows for very flexible virtual machine based deployments and increases reliability all at the same time. Beyond the focus on driving inter process communication latencies out of the equation another key novelty for this latency sensitive application set is that all stages ran in VMware ESX. This in fact allowed the integration teams to repeatedly deploy an architecture, which was highly fault tolerant yet very flexible. As demand went up it was possible to add another stage to balance the load. If a new criteria or stage was required then it was merely a matter of adding another virtual stage and uploading the application logic. Visualization was required for better human interactions then adding a web based front end was merely about adding something like a LAMP stack that could provide the visual experience. This was all driven off of a fundamental assumption that for a future of Advanced Analytics or Social Innovation, many application and data types are required. It is therefore nearly impossible to forecast a precise institutionalized architecture until you've been through the experimentation process. So flexibility was key and VMware helped the team achieve that result. When we started to extrapolate where this would take us, we quickly realized that very stable archetypical containers will be required that align closely to application and user requirements. If we needed to add in a constraint programming engine for helping to eliminate the propagation of delays in a train network - no problem… add the content and start the VM. If we needed to add in a remote sensing and decision making platform to help forecast the running quality of train wheel stock - no problem, add the content and start the VM. In effect we recognized that the delivery of platforms like UCP, which are rugged and well ordered, is critical in this world of advanced and experimental analytics- and this is where the “ah ha” moment came from. The engagement with our sister companies allowed us to see these requirements and the emerging world of what I might call the “Internet of Life’, whereby we need to continuously experiment until the data tells us what's up. Once that happens, we can institutionalize the application's architecture yet we still don't have to compromise because (as our friends in the financial services area showed us) even for latency centric applications VM overheads are not really a barrier to deployment. So in a very real way learning about the “Internet of Life” from our sister companies allowed us to determine what our next steps would be from a platform perspective. This is indeed why we are getting into these adjacent spaces, why were upping the software content, why we're even seeing that we can (and should) bring memory control out to the edge, etc. (Note: In a very real sense we can answer the implicit why hidden in Chad's most excellent narrative of storage architecture archetypes but not explicitly articulated.) With the why answered, in several different dimensions, we're poised to contemplate what kinds of architectures, management software, analytics engines, etc. are required to achieve the change the world goal behind Social Innovation and the "Internet of Life."
Terms like experiment, data science, the "data tells us what's up" and so on point to something different in the traditional model of operations. Of course there is the ever-persistent point of IT organizations and business teams needing to become more intimate, yet I think that there is more to it than that. The DevOps movement is a reflection that the business teams want to both build their own applications, and ideally control the IT platform directly. Add in the usual pressures from the gold standard of public cloud services and there is a kind of perfect storm on the horizon. That storm on the horizon isn't all doom and gloom. Instead I think we can use the winds of change initiated by the storm to set sail on a new ocean of IT -- sounds fabulous doesn't it? In all seriousness, our thinking about this very problem has led us to believe that a kind of visual data flow based development environment that can talk to a data center orchestrator is likely the right way to go. The picture on the right is exactly a visual representation of that very point, and is a kind of generalization of the ideas we encountered from our SI brothers and sisters in Japan. I'll be the first to say that we are conducting research in these visionary areas and aren't sure how far it will go -- I suppose we are like Apple in that we keep pulling on these ideas to see where they will lead us. In the worst case we spend the time deeply understanding how a user will need to interact with the IT platform and what kinds of analytics engines will be required in an Analytics Palette and how they need to be orchestrated. In the best case … well I'll let you imagine that case, but the point is either way we win. A key assumption is that the pairing of an analytics data flow, with a set of well behaved analytics engines will require well ordered converged stacks. That is because if I want to get stable behaviors from a distributed, shared MongoDB, I cannot have ultimate flexibility in the hardware platform. Let's illustrate this with an example: if a business techie constructs a data flow with MongoDB and it gets deployed on a potpourri of hardware, how can I provide any guarantees of when the job will be done, if it will be error free, etc? However, if there is a kind of scale-out private cloud in a box then each node is uniform and it is much easier to make guarantees. Similar approaches and examples can be made for scale-up systems like our UCP. This very observation is fundamentally why we've gotten into the converged system space and why we're offering well ordered systems that are API controllable (I'll get into a deeper discussion on the Software Defined Data Center in a later post.) Something that is even more interesting in this thread of thinking is the notion of data flow experimentation is a micro example of a larger dynamic in the market: the tolerance for higher risk and faster innovation cycles in the form of open innovation. Perhaps because the markets have a new normal in uncertainty users want to develop new capabilities and services in partnership with Hitachi. In a very real sense, open innovation is a customer trend that cannot be underestimated and due to a great assets like strong relationships with our users, Hitachi Research, and thevaried capabilities in the overall Hitachi Group, we are well poised to help our customers achieve material benefit. Reaching Hitachi to engage in open innovation has never been easier from the Community to access to Hitachi Research labs around the world we love to engage, see the image to the left. In an effort to end short and sweet I won't belabor the point, other than to say that Hitachi is indeed poised to set the pace of the industry at large.