Cloud computing, Aaron Dumbrow Random Thoughts

In a conversation with a large customer recently we were discussions their enterprise architecture. A new CIO had come in and wants to move them to a converged infrastructure. I digging into what their environment was going to look like as they migrated, and why they wanted to make that move. It came down to a good enough design versus maximizing hardware efficiency. Rather than trying to squeeze every bit of efficiency out of the systems, they were looking at how could they deploy a standard, and get a high degree of efficiency but the focus was more on time to market with new features.

My first foray into enterprise architecture was early in my career at a casino. I moved from a DBA role to a storage engineer position vacated by my new manager. I spend most of my time designing for performance to resolve poorly coded applications. As applications improved, I started to push application teams and vendors to fix the code on their side. As I started to work on the virtualization infrastructure design for this and other companies, I took pride in driving CPU and memory as hard as I could. Getting as close to maxing out the systems while providing enough overhead for failover. We kept putting more and more virtual systems into fewer and fewer servers. In hindsight we spent far more time designing, deploying, and managing our individual snowflake hosts and guests that what we were saving in capital costs. We were masters of “straining the gnat to swallow the camel”.

Good enterprise design should always take advantage of new technologies. Enterprise architects must be looking at roadmaps to prevent obsolescence. With the increased rate of change, just think about unikernel vs containers vs virtual machines, we are moving faster than our hardware refresh cycles on all of our infrastructure.

This doesn’t mean that converged or hyper-converged infrastructure is better or worse, it is an option, but one that is restrictive since the vendor must certify your chosen hypervisor, management software, automation software, etc. with each part of the system they put together. On the other hand, building your own requires you do that.
The best solution is going to come with compromises. We cannot continue to look at virtual machines or services per physical host. Time to market for new or updated features are the new infrastructure metric. The application teams ability to deploy packaged or developed software is what matters. For those of us who grew up as infrastructure engineers and architects, we need to change our thinking, change our focus, and continue to add value by being partners to our development and application admin brethren. That is how we truly add business value.

Another question from someone I work with. “Can you explain the meaning of ‘Multi-Tenant’? Aren’t all virtualized servers and storage ‘Multi-Tenant’?”

The term Multi-Tenant is a little misleading. Technically, yes virtualized servers are multi-tenant in that there are multiple servers running on a single server. The term Multi-Tenant in the technology world however typically refers to a system where more than one company is using the same systems.

By way of example, we can look at a cloud hosting provider such as HP’s Cloud System Matrix (CSM). As a disclaimer, this not an official HP Blog, and I am not an expert on CSM, but I do have a solid understanding of it. So on CSM, you have multiple options. The most common and cost effective method is to simply purchase a virtual instance of a server. Essentially you get a virtual machine. Your virtual machine is on the same physical machine as several other peoples. In fact, it might get moved to other servers using vMotion without your knowledge. The concept is that you are simply renting or leasing a virtual machine, but you don’t care what the physical hardware is.

In the HP StoreServ, formerly 3Par, storage, arena, we have a similar concept of multi-tenancy. Consider the design of the 3Par array. Everything within the system is built first for redundancy, then for performance. It is the only truly tier 1 array that extends from the SMB through the global enterprise using the same architecture. The system was originally designed for hosting providers, thus everything had to remain functional no matter what. With this in mind, the system was created to be multi-tenant. It is literally possible to present the system as multiple virtual SAN’s without the users realizing it. This is perfect again if you want a granular control of your SAN, but you want to rent or lease it. A service provider might purchase a large system, and partition it off to many different companies. Since they all share the SAN, the system in multi-tenant. The HP StoreServ array is able to give a secure virtual san to each user.

So to wrap up, something which is virtualized but not multi-tenant would be most traditional virtualized systems. A company virtualizes their infrastructure within their own datacenter, or even at a colo. Since they are the only company on the system, that would be a single tenant system, or not-multi-tenant.