Posted by: John H. Jones | February 12, 2011

DIY Cloud-in-a-Box, Part 2

by: John H. Jones, President – LabLynx, Inc.

In my last blog posting, DIY Cloud-in-a- Box, Part 1, I introduced you to the concept of the Private Cloud and the series of articles that will chronical my journey towards the development of a private cloud that can be installed within your own organization or can be hosted in an external datacenter.  Now we continue on with Part 2.

mobiuscloudlogoIn this episode I promised to provide an outline to the Quality Manual that would be used to govern the design of the Cloud-in-a-Box and to provide it with a name and a logo.  Let’s get the fun simple stuff out of the way.  The name:  MobiusCloud.net.  So why that name?  Well, most of you are probably familiar with the Mobius Strip.  It is a sort of 3D symbol for Infinity.  The thinking is that Cloud Computing should be a virtually infinite computing resource.  Of course we all know that in this mortal world nothing is really infinite for each of us as individuals.  However lets skip this philosophy and move on. 

The Cloud Computing resource should allow for virtually limitless computing, storage, networking and applications.  So this means that the fundamental design of the MobiusCloud should be modular without limits to the addition of modules.  Modules can be seen as additional computing resources or storage or IP addresses or bandwidth or applications.  The design should be a network design much like the Internet itself so that a failing node in the network does not bring the cloud down and thus essentially provide infinite uptime.  There, that covers why this is called MobiusCloud.net.  So now we need a slogan to go with the name.  Going with the theme of infinity, I came up with:  “cloud computing without limits”  Oh, one other thing, MobiusCloud.net was about the only descent domain name I could get.

Outline for MobiusCloud Quality Manual

Now that we have a name (MobiusCloud) for this Cloud-in-a-Box so that we can all discuss things by using a name and we now have an avatar (logo) for it, we all can have a picture in our mind as we move forward.  Keep this in mind for most anything you do.  If you are going to create something, start by figuring out what you want to call it and how you want it represented.  Further, in this Internet world, you had better find a domain name at the same time or you will find it hard to get your product launched.

The next step is to develop an outline for the MobiusCloud Quality Manual.  I feel this is the starting point for this new product/web service because without quality built into the very core of this product, cloud computing will be a joke at best and a disaster at worst.  If you are going to provide Cloud Computing services and products you had better make them “Utility Grade”.  In my mind, “Utility Grade” is just a notch below “Military Grade”.  Military Grade being the top of the line means that what you have can withstand the rigors of war and battle.  Well, I do not expect bombs to be thrown at MobiusCloud so I expect it to be up the level of Utility Grade.  Utility Grade is a level of quality like a power or telecommunications utility company (cable companies excluded) and the level that is below Utility Grade would be Enterprise Grade the next level down is Commercial Grade and the lowest level is Consumer Grade (cable companies fit here nicely).  The differences in these grades and definitions can vary wildly but I feel that the Utility Grade represents the practical best assuming no war.

Here is the outline to the first draft of the Quality Manual (QM) for MobiusCloud:

  • Develop MobiusCloud Quality Manual with Design / Installation / Operation / Maintenance Documents
    • Functional Requirements
      • Zero Downtime
      • Zero Data Loss
      • Zero Malware/Spyware/Viruses
      • Zero Network & Systems Security Breaches
      • Zero Physical Security Breaches
      • Zero Overallocation of hosting resources
      • Scalability without practical limits
        • Storage
        • Computing
        • Networking / Bandwidth
        • Power
      • Continuous Quality Improvement while reducing operations costs
      • Diversified product & service offerings
      • Compliance with Regulatory Requirements
        • HIPAA
        • CLIA
        • 21CFR part 11
        • SOX
        • HITECH
        • CAP
    • Logical Design
      • Network & Power Equipment
        • Wide Area Network (WAN) Switches
        • Local Area Network (LAN) Switches
        • Storage Area Network (SAN) Switches
        • High Availability Network (HAN) Switches
        • VoIP Area network (VAN) Switches
        • Power Distribution Units (PDU)
      • Firewall Servers
      • Storage Servers
      • Windows & Linux Application Servers
        • MobiusCloud Management Servers
          • Network Operations Center (NOC)
          • Cloud Administrator Control Panel
          • User Control Panel
          • Customer/User Portal
        • Application Servers
          • Customer Private Clouds
          • Bare Metal VMs
          • Application VMs
          • Shared Web Hosting Servers
          • VoIP Hosting Servers
    • Physical Design
      • Facilities
      • Network & Power Equipment
      • Firewalls
      • Storage
      • Computing Nodes
    • Installation, Operation & Maintenance Instructions for
      • Facilities
      • Network & Power Equipment
      • Firewalls / Antivirus / Antispam / Antispyware
      • Storage
      • Computing Nodes
      • Management Systems
        • NOC
        • Cloud Administrator Control Panel
        • User Control Panel
        • Customer / User Portal
    • Standard Operating Procedures
      • Facilities
      • Network Security
      • Data Security
      • Hardware Maintenance
      • Software Maintenance
      • Backups & Disaster Recovery
      • Auditing, Testing & Compliance Validation
      • Provisioning & Termination
        • Accounts
        • Resources
      • Change Control

     

    This is the first draft of the QM so I would like to hear any suggestions on how to improve the QM and most importantly to make sure that everything is included to ensure quality.

    At this point we are currently running experiments with a number of cloud technologies and hypervisor systems. I am not ready to say what Part 3 of this series will be until we complete some more experiments.  I am hoping that we start to get down to the good stuff (hardware and software installations and testing).  I must say that writing QM’s is not what I want to do.  In fact, I won’t do it.  I will have someone else do it while I spend time in the IT lab with these experiments.  That is much more fun and frankly, if we do not get it right on the technical front the QM won’t be worth the paper it is written on.

    Stay tuned for episode 3 in this continuing saga of the DIY, Cloud-in-a-Box.

  • The DIY, Cloud-in-a-Box Series:

    DIY, Cloud-in-a-Box, Part 1

    DIY, Cloud-in-a-Box, Part 2

    Advertisements

    Responses

    1. […] DIY, Cloud-in-a-Box, Part 2 […]


    Leave a Reply

    Fill in your details below or click an icon to log in:

    WordPress.com Logo

    You are commenting using your WordPress.com account. Log Out / Change )

    Twitter picture

    You are commenting using your Twitter account. Log Out / Change )

    Facebook photo

    You are commenting using your Facebook account. Log Out / Change )

    Google+ photo

    You are commenting using your Google+ account. Log Out / Change )

    Connecting to %s

    Categories

    %d bloggers like this: