n-1 isn't necessarily the wisest choice

Ask any vendor & you will find that one of their greatest frustrations is when customers insist on implementing only the "n-1" release of a particular product. 

At almost every meeting, vendors are asked about the availability of new features, or new capabilities, or new supported configurations that will match what the customer is trying to achieve, and yet when these are finally made available after much development and testing, customers will wait, and stick with supposedly safer older versions.

The risk-management logic, of course, is that the latest release is untried, and may contain flaws and bugs. Unfortunately this misses the point that fixes to older flaws are made possible by deploying a new release. It also brings up the laughable scenario of customers asking for new features to be "back-ported" to the older, "safe" release. Pro-tip: if you back-port all of your new features to the older release, then you end up with the new release anyway!

There are also some times when you just can't take advantage of the latest technology unless you're up-to-date: for example getting the most benefit out of new CPU's requires the operating system software to be in-sync. As SUSE VP of engineering Olaf Kirch points out in this article from 2012, when new features are introduced, you can either back-port to old code (possibly introducing errors) or take the new code and harden it. 

Which brings me to the real point of this article - when we're  talking about open source, the rate of change can be extremely rapid. This means that by the time you get a hardened, tested,  enterprise version of software out of the door, it is already at least version "n-1" : the bleeding-edge stuff is happening at the forefront of the community project, where many eyes and many egos are working on improvements to correctness and performance as well as features. So there's really no reason to require an n-1 release of, say, enterprise Linux ... all you're doing in that case is hobbling your hardware, paying more for extended support, and missing out on access to improvements.

So when SUSE introduces a new kernel revision mid-way through a major release, as it is doing with SUSE Linux Enterprise 12 Service Pack 2 (SLE12SP2), don't fret about the risks: the bleeding edge has already moved forward, and what you're getting is just the best, hardened, QA'd, engineered version of Linux with the most functionality.

More on Scalability, Again

This week Intel announced its new Xeon E7 v4 processor, which takes x86_64 processor scale to another level: a single CPU socket now gives you 24 cores and access to 3TiB of RAM.  That means a medium-sized server of 8 sockets can now give you access to 192 cores and 24TiB RAM.  The upshot of this is that is you actually want to access all of that RAM with a supported operating system, SUSE Enterprise Linux is your only choice.

The new architecture also raises the limit for CPU sockets in a box to 64 – which means that you could max out this system in a standard kind of configuration at 1,536 cores. Again, SUSE Enterprise Linux is the only OS to support this degree of scalability for this kind of processor.

I wrote about this just a few weeks ago in the context of the HPE Integrity Superdome X,  which still only has published benchmarks running SUSE Linux Enterprise Server. It's interesting to see that all of the numbers have doubles (yet again) in such a short time.

Of course, SGI has been doing this degree of scaling with NUMA systems for a while, which is why SUSE Enterprise Linux is known to scale to 8,192 CPU cores and 64TiB RAM (they couldn't fit in any more memory): it's a little frightening to consider what they might end up doing with these new CPU's – at the very least 128TiB RAM will be near on the horizon.

So when the processor hardware manufacturers can still drop a doubling of capacity on us, it's worthwhile taking a note of whether your software can deal with it....

Deploying OpenStack is NOT Difficult

There are too many articles around at the moment claiming that OpenStack is difficult to set up, and too many vendors claiming the only answer is consulting.

Yes, consulting can be important to get the business side of your private cloud worked out, but setting up OpenStack doesn't need to be difficult, when you have a distribution that's main purpose is ease-of-deployment in enterprise environments.

Here are some factoids about SUSE OpenStack Cloud:

• It was the first enterprise OpenStack distro
• SUSE introduced the concept of "distro" for OpenStack
• It is actually a distro that can be set up by normal people - not just an invitation to a consulting engagement by a vendor
• It is the only distro to ever win Intel's "Rule the Stack" competition for ease-of-installation-and- management (3 times in a row, and sometimes when no-one else was able to complete the task)
• It is the only distro that supports KVM and Xen and VMware and HyperV and Docker and zVM – yes! you can even send workloads to mainframes!
• The deployment tool can deploy SUSE Linux Enterprise and HyperV/Windows Server as compute nodes.
• Installation of SUSE Enterprise Storage (powered by Ceph) is integrated into the deployment tool
• The deployment tool will communicate with your existing infrastructure if you want: plugins make it easy to include your favourite storage system or converged networking
• It is the distro used by some of the well-known OpenStack users
• HA deployment is included with a couple of extra clicks
• SUSE's fleet management tool, SUSE Manager, can be easily integrated into the cloud infrastructure so that new compute/storage/etc nodes automatically get patch/update/security/configuration management
• SUSE's template creation tool, SUSE Studio, can be used to set up the VM's to offer to end users & directly add them into the OpenStack image repository.

Given that ease-of-install has been the hallmark of SUSE OpenStack Cloud since day one, it seems a shame that everyone seems to think it's difficult when it doesn't have to be – it should be a piece of cake.

Some links:

FIS-ASP deploys in one day:  https://www.youtube.com/watch?v=aFdlUIdYwQU

BMW OpenStack + Ceph case study: https://www.susecon.com/doc/2015/sessions/CAS19964.pdf

SAP using SUSE including OpenStack: https://www.youtube.com/watch?v=mLkPzFB1m_w

More (including downloads) at: https://suse.com/cloud

Why SUSE Linux Is the Only Sensible Choice for HPE Superdome-X

Unlike other material herein, this is an unashamedly partisan post. It's here's to collect together mostly links, for reference.

In December 2014, HP (now HPE) announced the successor to its long line of proprietary enterprise class computer systems:  the Integrity Superdome X.

What was particularly interesting about this announcement is that the focus was not just on the Intel Xeon processor, or the scalability of the machine to 16 CPU's and 24 TB of RAM, but what Jeff Kyle, director of product management for mission-critical systems at HP said was most important: "It's all about the software," Kyle told eWEEK.

Superdome X was the first flagship system from HP to not ship with HPUX.  Instead its launch OS was Linux. SUSE Linux.

Why?  Well SUSE Linux was the launch OS for Superdome X. And yes, that article mentions our old friends from Raleigh, but the fact remains that at launch time, the only benchmarks provided by HP were those with SUSE Linux.

So how about now, 18 months later?   Well according to the SPEC website, as of today ALL of the SpecJBB and SpecCPU benchmarks published by HPE for Superdome X use SUSE Linux Enterprise Server:

http://www.spec.org/jbb2015/results/res2015q3/jbb2015-20150908-00012.html

http://www.spec.org/jbb2015/results/res2015q4/jbb2015-20151013-00025.html

http://www.spec.org/jbb2015/results/res2015q4/jbb2015-20151027-00029.html

https://www.spec.org/cpu2006/results/cpu2006.html

So there's a clear message here – when HPE is trying to get the best possible performance form their machines, they turn to SUSE Linux.

Why is this? well in terms of raw scalability, SUSE far exceeds RedHat linux:

	Max supported CPUs	Max supported RAM
SLES 12:	8192	1024 TB
RHEL 7.2:	288	12 TB

https://www.suse.com/products/server/technical-information/

https://access.redhat.com/articles/rhel-limits

At the very least, this means that to handle a fully-loaded Superdome X with 24TB of RAM you must use SUSE Linux or risk falling into the "experimental" or at best "unsupported" category.  And risk isn't really want you want when running a mission-critical system.

In particular, SUSE Enterprise Linux has actually tested scalability on other systems to 8192 CPU cores and 64TB RAM (no-one could supply a machine with more RAM;  the CPU count was qualified after that article was written). SUSE's numbers are therefore not theoretical when it comes to the demands of Superdome X: there is no risk that scaling will not follow the expected path.

This difference is likely to continue as well: both HPE and Intel spend a lot of effort developing code for the Linux to improve scalability, etc, and this is sent “upstream” to the latest kernel versions.  This means that you would normally expect the most recent kernel version would have the best performance, due to HPE & Intel contributions.  Typically SUSE leads its competitor in implementing the latest kernel features whilst maintaining application and kernel binary compatibility between major kernel releases (e.g. from SLES 11SP1 with 2.6 kernel to SLES 11 SP2 with 3.0 kernel).  Given this background it should not be surprising for SUSE to continue to make similar advances in its current SLES 12 major release. Historically Red Hat has not changed major kernel releases:  RHEL 5 & 6 were kernel level 2.6, with 3.10 introduced only in 2014 with RHEL 7.

In other words: as HPE continues to contribute performance & other features to Linux for all of its server platforms, these are most likely to appear (with full global enterprise-class support) on SUSE Enterprise Linux long before they are available on RHEL. 

https://wiki.microfocus.com/index.php/Kernel_versions

https://access.redhat.com/articles/3078

So it's no mistake that HP themselves chose SUSE Enterprise Linux when they migrated their internal systems from HP-UX.

Why is Open Source Important?

Recently I was asked by the IT manager of a customer, also a software development company, what my position was on open source. His developers were arguing in both directions: some characterised open source as being risky due to the potential for people to see the code & discover security vulnerabilities (which really isn't the case) ; other developers asserted that using closed source also had risks such as the vendor being acquired, going out of business, or dropping a particular product line.

My customer wanted to understand if had a "religion" about open vs closed, so I told a story about my perceptions on how closed source & closed systems came back to hurt the company that initiated it....

Microsoft defined the market in the late 1990's: most people couldn't see past the desktop paradigm. Certainly when I was at Sun Microsystems trying to tell people that "the Network is the Computer" I was mostly given blank stares or told I was living in a fool's paradise with the idea of continual network  access (now however,  some people even suffer from anxiety when they don't have network access).  Meanwhile, Microsoft, having been late to the start of the Internet revolution, quickly used its market power to inculcate Internet Explorer as the standard web browser for enterprise customers, so all software using a web interface had to confirm to its particular quirks, and in particular the quirks of Internet Explorer 6. Given this practical requirement, and the dominance of the Windows desktop concept, many software developers would not support their web interfaces with anything else, which in turn meant people had to buy into the Windows desktop world and so the vicious (or virtuous, depending on your point of view) circle continued.

When Microsoft tried to introduce new, better performing versions of Windows and Internet Explorer, however , they found that adoption was poor. Despite their best efforts and despite the end of support life for Windows XP (the last version of windows that supports internet explorer 6),  30% or more of Windows deployments are STILL of this older version, due in part to the huge dependance on the old, closed Microsoft ecosystem of the early 2000's.  In other words, Microsoft's own efforts to control the entire software stack actually ended up hurting them, with very poor adoption of Windows Vista, and initially slow adoptions of Windows 7 and 8.

A critical factor here is that these old systems do not work with today's dominant paradigm: mobile computing on phone or tablet.  Companies face a potentially huge transitional cost to get access to the way people now access data online. There are a lot of reasons why Microsoft hasn't been as dominant in the mobile space as they'd like to be, but certainly the way they set themselves up at the beginning of the 21st century didn't help.

So how does this fit into the question of open source?  Well by definition open source uses standards for data storage & transfer that are open to scrutiny and available for all to use. This means that getting to data and services can be possible from any device or system, not just from some tightly-coupled combination of software systems in a closed box owned by someone else.  Companies who developed with open standards in mind found it much easier (and faster) to move to the mobile world.

This is just one reason why open source is important: to provide tools, systems and protocols that can be continuously adapted & developed in compatible ways, rather than head down a one-way path towards a dead end.

A telling footnote to this story is that after many years of decrying open source, Microsoft is now embracing open source as a component of the way it operates, and actively collaborates with open source companies (such as SUSE) to improve interoperability and the effectiveness of their customers' IT environments.

Virtualization and Processor Capability

In the old days[1]  the big computer companies competed fiercely on processor performance: a few extra megahertz here & there could make the difference between winning that multimillion dollar sale & being relegated to the also-rans.  Applications and operating systems were monolithic, giant chunks of code that consumed vast quantities of the CPU's processing time, so the faster you could  run through that single-threaded code, the better.

These days, the "processor wars" are done & dusted. There's really nothing that the relatively low-volume-and-hence-high-price RISC processors found in the big UNIX systems from Sun, HP & IBM can do that the relatively high-volume-hence-low-price x86-64 processors can't. So unless you're looking for a specific niche solution (from Snoracle[2]) or especially clever I/O virtualisation (IBM Power), there's really not much reason to be putting your workloads on anything other than an x86-64  system.

In fact, processing capacity is so grotesquely huge these days (and has been for a while) that we chop that capacity up into little units & assign them to many operating systems at the same time. This is called "virtualisation" (stop me if I'm going too fast).   This leads to the question of whether we can get away with even less. Certainly in the dim dark ages of last century, we were able to run multiple web servers on a single cpu systems; even given the additional complexity of some web apps these days, there are many applications that don't warrant the full power possible even with virtualised x64, and certainly not the power & cooling requirements of those larger servers.

This is why people are interested in ARM and Atom processors - lower performance than the high-end x86-64, but with sufficient capacity to do the job, and much more attractive characteristics for power, cooling & price.

So the future of server selection could be much more about power consumption (& cooling costs) over its lifetime than raw performance.  In fact, it's almost certain.

1: Old days, for purposes of this article, are before about 2006. Bleh. I feel old.

2: Snoracle. Sun + Oracle. Also, possibly onomatopoeia .

IP Longevity Through Open Source

You never forget working for your first vendor.  I was reminded of this at the SUSEcon conference last November, when I met a young colleague who had recently started with the company and was overflowing with enthusiasm for the culture, workmates, and feel of the workplace compared to his previous experiences.  I saw the same degree of enthusiasm in former colleagues at NetApp, who had grown up with the company, and invested themselves completely in the company culture, even as it went through change.  My own experience with Sun Microsystems was also a match: there was something special about working in a place which, especially for a technologist, offered access to such great ideas, people, equipment & opportunities. For me, this was compunded by being there during the dotcom boom.

While I was at Sun, the place seemed to be brimming with innovation - we were proud of our brilliant ideas & cutting-edge execution. There were a few less-enthusiastic, or perhaps better said as "more realistic" people who didn't look through such rose-coloured glasses. These were the folk who had come to Sun from elsewhere - places like DEC (Digital Equipment Company), which had previously been one of the go-to places & hotbeds of innovation. They could see the good times wouldn't last, and in the end were proved correct.

It seems there has been a constant stream of "innovation" companies, each in turn attracting enthusiastic contributors, building great technology, and then folding or being consumed by some larger organisation that ultimately fails to capitalise on the innovations. The tragedy here is that as the smart people leave these companies, and the intellectual property gets buried under legal constraints, the innovations get lost, and the next generation effectively has to start from scratch. Sun's amazing technology & concepts of the late 1990's & early 2000's has only recently become part of the mainstream understanding (in 1997, no-one could understand what "the network is the computer" meant - modern smartphones demonstrate the concept completely), yet a lot of companies today are re-inventing the capabilities of the last generation of technology Sun developed before the decline & loss of personnel.

This is where free & open source is so interesting: once ideas expressed in open source are exposed, they are forever available, so the demise of a particular company doesn't bury the intellectual property (even if it does mean a lot of the workers on a project may not be able to spend as much time on it). Perhaps as more and more development moves into open source, we'll have less re-invention of the wheel (or even less out & out ignorance of what has come before).  

So long as we can work out a way to agree on licensing schemes....

Open Cloud?

History has shown us how damaging it can be to funnel ourselves down a single proprietary path, no matter how popular a particular platform is at a particular point in time.  

It can even damage organisations who originally benefit from the lock-in: one only needs to look at the trouble Microsoft is having getting people to move on from Windows XP. A lot of that is due to the general move away from desktops to mobile platforms,  but early on a great deal was due to organisations having bought or built internal applications on top of Internet Explorer 6 & that did not work with Internet Explorer 7 or later, so would not work on newer Windows platforms....

Keep things open - make a bigger pie, rather than just trying to take all of the pie for yourself...

Design Matters, Even (or Most Importantly) When It's Invisible

This may be old news, and I may be slow on the uptake, but look at this:

This is a screenshot from Apple iTunes showing the track listing of an album along with its cover. I was looking at this idly, waiting for another 2am concall, when it struck me that the colours used for the track info were a remarkable match for the album cover.  I looked at another album, and saw that its text also matched, yet clearly with a  different colour scheme:

Now, usually I listen to music on a separate iPod - not really paying much attention to what's on screen. This has floored me, though. Somewhere along the line, someone has decided that having nice fonts, cover art & whatnot is not enough - the entire visual effect related by the album's cover design should be used to cue the metadata associated with the music. Not only that, but that has been integrated with a reasonable clever programming effort to determine what the colour scheme of the album is, and how best to represent the text effectively.

Here's another example:

This whole thing is an example of concern about the complete design of an interface which seems, frankly, lost on a vast proportion of people. That isn't to say that people don't appreciate it - but rather that people don't even think about it, and may not have even consciously noticed the effect, although they may notice something "off" if it wasn't present, and may like the look of something without being able to explain why.   Architects (real ones - in the built environment) face this sort of thing all the time:  people often don't see the value in good design until they experience it for themselves.

Much as I love UNIX & Linux, in that world chances are the graphic design would go no further than placing the cover art in a bounded box, with the track info all in regular text with regular colours on a regular background.  Informative, maybe even reasonably attractive, but lacking the near-invisible design that makes this & many other Apple products such a satisfying user experience.

So maybe "invisible design" is something to aim for.

Going For Gold Isn't Enough

For many years, IT services within organisations have been advertised to business projects using a familiar set of names: usually “gold”, “silver” and “bronze”. There may be some noun associated with the service as well, such as “gold processing tier” or “silver storage tier”. The premise behind this kind of naming is that “everyone understands what this means”, and to some extent this is true from a relative point of view – gold is understood to be “better” than silver, which in turn is “better” than bronze. But what does “better” mean in the context of the services on offer? How can someone differentiate between the different services & decide which one to use? What happens when a new service is introduced that fits between the existing ones?

Most of the time the answer to these questions is “no-one knows”, which is less than ideal. The big problem with this precious-metal-related naming methodology (or any other arbitrary method such as colours, gemstones or suchlike), is that although they give a relative indication of “goodness”, they don't actually tell anyone what the service offers, and nor is there any consistency between what a name means from one organisation to the next (or even within a single organisation – they are arbitrary terms, after all). This usually results in a business project simply choosing what sounds like the “best” service (i.e. “gold”), even if the project's needs don't align with what the service is offering. Alternatively a cash-strapped project may choose the “least” option (i.e “bronze”) simply to save on costs, without understanding, for example, that running a database on bottom-tier infrastructure just won't work. This problem is compounded as IT organisations become more like service providers, and especially as automated orchestration is used more to provision and advertise services to business users through self-service portals and the like. It's this context which leads us to understand the way we should be designing and describing our IT services, which is to be as specific as possible.

The concept behind being a service provider (either internally to an organisation or externally), is to consolidate resources and then apportion them to different projects or customers on a per-use basis. The idea is that by offering a standard set of well-defined services, the provider can reduce waste, streamline processes, take advantage of infrastructure efficiencies like data deduplication and single-instance cloning, and save their organisation money (and/or make a margin). The key phrase here is “standard set of well-defined services”: in the service-provider context, customers (or projects) must choose from a menu, rather than being allowed to pick and choose how the ingredients will be combined. In turn, the service provider must be very clear on what is included in the services being offered, and also on what the price will be per unit.

In a NetApp storage context, this means that some understanding of potential workloads must exist in order to develop a service appropriate for each workload the provider wants to cater to, including all of the efficiencies and capabilities relevant to that workload. The goal is to then normalise the per-gigabyte pricing so that simple comparisons can be made on the effective usable space, rather than on the basic physical capacity. For example, likely de-duplication rates for Virtual Server (VSI) workloads in VMware are around 50%, which is greater than the de-duplication rates for simple file sharing at around 20%, so a provider can define different services with per-gigabyte rates for these two workloads that take these savings into account. For example, the “NFS datastore for VMware VSI” might be offered at $0.50/GB, while the “NFS datastore for general data” might be offered at $0.80/GB. This naming and pricing helps the customer or project understand what they are ordering, and helps the service provider direct the customer to the most appropriate service for a workload.

Once you start naming these services in a descriptive way, you can extend them to add additional capabilities. For example the “NFS datastore for VMware VSI” might be extended to a new service called “NFS datastore for VMware VSI with local backup”, which introduces NetApp SnapShots on a defined schedule, and includes an additional per-gigabyte price to cover to cost of capacity used for those backups (perhaps a 20% premium). Another example might be “NFS datastore for general data with Disaster Recovery”, which would include a SnapMirror copy of the data at a remote site, and would have an associated premium to cover both copies of the data, networking costs, and so on.

It's easy to see how infrastructure policies can be applied to basic services to build up a complete catalogue of services, and how the capabilities and efficiencies of the infrastructure can be used to set pricing so that customers or projects can select based on both functional requirements and budget, and service providers can direct customers to the most appropriate infrastructure. With a descriptive naming system, providers can easily introduce new or extended services as technologies become available, without worrying about having to squeeze between or around arbitrary names (is aluminium better or worse than bronze? What sits between silver & gold?). Furthermore, if a service is named according to the functionality it provides, then the underlying technology can be swapped out without necessarily having to re-name the service: for example, if a file sharing service moves from fibre-channel disk to SATA disk plus FlashCache, the customer's view of the functionality remains the same, even though the underlying technologies moved from what might once have been called “gold” storage to what might once have been called “silver”.

So consider making bland old “gold”, “silver” and “bronze” and thing of the past, and well-defined, descriptive services that incorporate infrastructure capabilities the way of the future. It will certainly make life less confusing for your projects & customers.

Stop Thinking About Storage as "Tiers" & Start Thinking About Workloads

In the olden days (which for purposes of this article means "the 1990's"), Gartner introduced - or at least popularised - the concept of "Storage Tiers". The idea was that with new & differentiated storage technologies becoming available, some decision had to be made as to which kind of storage you'd use for a particular kind of data. At the top tier ("Tier 1"), you stored mission-critical, frequently-accessed, latency-sensitive data like OLTP databases. In the middle (call it "Tier 2"), you stored less latency-sensitive data that was still business-critical and needed backup, DR and/or replication such as email systems, and at the bottom (call it "Tier 3"), you stored infrequently accessed or archive data.

Each of these tiers had assumed physical characteristics: Tier 1 was fast, high-performance (and most expensive) disk, usually connected to a fibre channel SAN and featuring high-availability, synchronous replication and so on; Tier 2 was lower-speed disk, with some degree of high availability; Tier 3 was the biggest, cheapest, highest-density disks, probably connected via file sharing networks, and less likely to have high availability features included. These physical characteristics in turn led to an association with specific disk technologies: Tier 1 became small-capacity 15,000rpm fibre channel drives, Tier 2 became large capacity fibre channel drives (maybe operating at 10,000rpm), and Tier 3 became large-capacity SATA drives.

This was fine, for a while: storage arrays frequently provided no additional performance considerations beyond spindle type, spindle size and spindle count; and application managers became used to the the idea that they really only had 3 flavours to choose from, and that Tier 3 was “the slowest”, and Tier 1 was “the best”, so they chose the latter.

Then someone invented solid state drives.

With a tiering system so firmly tied to particular drive technology and “Tier 1” as “the best” (meaning “the fastest”), the introduction a new, faster storage device type created a slight problem: what's better than 1? Fortunately computer scientists all know that you're actually supposed to start counting at zero, so the answer was clear: the new “best” was “Tier 0”, and the top-level descriptions were nuanced to place high-speed transactional data on this new tier.

Problem solved. Until someone invents something faster (like phase-change state drives, or something). At that point we'd have to call the new technology “Tier -1”, which finally clearly shows how ridiculous it is to tie a drive technology to an expected workload.

That's the point of this article – we should be thinking in terms of “workloads”, rather than “tiering”, since tiering is so closely tied to disk technologies, and since the physical drive characteristics are no longer the sole feature to consider. In a NetApp environment there are several features to take into account when designing the solution for a given workload: deduplication & compression, FlashCache, FlashPools, FlashAccel, and so on.

Once we understand what a workload is going to be, we can design a storage system to provide the best combination of features to handle that workload – which may mean that even high-performance workloads are deployed on lower-speed disks. A classic example of this is a typical Virtual Desktop Infrastructure (VDI) workload: many (hundreds or even thousands) of copies of essentially the same operating system and application binary data, with latency-sensitive access. The many copies of data can be deduplicated down to a few or even one instance of actual physically stored data. The first time this data is accessed by a VDI client, it is placed in the controller FlashCache. Subsequent requests for the data from any client are then served directly from the cache. What this means is that the actual disk performance is almost irrelevant, so lower-speed (and lower-cost) drives can be used, and fewer of them thanks to the deduplication effect. The solution becomes cheaper, more efficient, and more performant all at the same time.

This is just one example, and there are plenty more. The main point is that this combination of technologies (slow disk, deduplication, FlashCache) is suitable for that workload, and gives better performance than a traditional “Tier 1” storage infrastructure. It means that it is no longer appropriate to simply use storage tiering to decide the best infrastructure for a given workload. What solution designers need to do now is understand the characteristics of a workload, and then combine the available storage features to most effectively support it.

So from now on, think about workloads, not tiers. This is especially true when trying to develop Infrastructure-as-a-Service offerings. But more about that later.