My assessment is based more on more of a specific scenario in where a company or corporation has presented their business units the options of utilizing a shared infrastructure as well as the options of utilizing the option of a public clouds that are readily available in the technology marketplace.
Will containers change the shoe size of the physical servers in the datacenter? When having a conversation with some of my peers about containers in general, the discussion started to move in a direction of what containers can bring to the environment and as such what steps or changes would be needed to be implemented to make the environment to be able to bring about the greatest success when offering containers as an option to the customers. To truly understand the change in thinking about the physical server’s footprint size I first need to make sure that we have a basic understanding of what the difference is between virtualization as a general term and container virtualization.
Have you heard about Uninkernels? Uninkernels or Cloud Operating Systems as it has also been called is a specialized lightweight operating system which is intended to be used within a virtual machine. These Unikernels have the potential to become the core of a new form of cloud computing where a single hypervisor instance can support hundreds or even thousands of virtual machines. Uninkernels can accomplish this potential by rethinking how we populate the cloud infrastructure by utilizing specialized, single-address-space virtual machine images constructed by using a virtual library operating system.
In my last post, Priorities of Uninterrupted Data Access, I got the chance to present the results of the IDG survey that reported a sizeable difference between the 50% of executives and the close to 90% of managers’ and the directors’ concerns of the priorities of uninterrupted access to the company data. This “spread” between the percentages has left me really wondering and speculating what might be behind the different attitudes and concerns.
For those of you that know me, know that Disaster Recovery is a topic near and dear to my heart. For those of you who I have not had the pleasure of meeting, I have spent most of my professional career working in Florida so I hope that helps give a little insight into my special interest in Disaster Recovery.
In my last post I started the discussion on the tools of the trade for automation and orchestration. The post mainly focused on Microsoft PowerShell as one of the primary tools of the trade when working within Microsoft, VMware and Citrix virtualization and orchestration solutions. One of the main reasons that I focused on Microsoft PowerShell. So why PowerShell? Quite simply it is a very powerful platform that has a very strong community to help support it and companies outside of Microsoft have invested a great deal of time and development to use this technology as one of the main administration and management platforms for working with VMware vSphere and Citrix Xen. For the sake of this discussion, I am going to refer to PowerShell as one side of the automation coin and now concentrate on the flip side of the automation coin.