Dear Clouderti,

I have of late, but wherefore I know not,
lost all my mirth, forgone all custome of exercise;

and indeed, it goes so heavenly with my disposition;
that this goodly frame the Cloud, seemes to me a sterile promontory;
this most excellent Canopy the Cloud, look you:

this brave ore-hanging, this Magesticall Roof,
fretted with golden fire: why, it appeares no other thing
to me, then a foule and pestilent congregation of vapours.

What a piece of work is a Cloud?
How noble in Reason?
How infinite in faculties, in form and moving?
How express and admirable; In action how like an Angel!

In apprehension how like a god, the beauty of the
world, the paragon of animals. and yet to me, what is
this quintessence of dust?

Public Cloud delights not me; no,
nor Private Cloud neither; though by your smiling you seeme
to say so

—The Tragedy of Hamlet, Prince of Denmark (Act II, Scene ii, 285-300), [1]
- inspired by Withnail and I, movie

No related posts.

Quick post to share a little Ruby script that lets you send commands and get output from the Nexus 1000V VSM.

HTML: Basic Ruby interface to the Nexus 1000V

Public Clone URL: git://gist.github.com/1326436.git

Enjoy!

class NX1K
require 'net/ssh'

attr_writer :host, :user, :pwd

def send(xml)
  session = Net::SSH.start(@host, @user, :password => @pwd, :timeout => 10, :verbose => :debug) do |session|
    channel = session.open_channel do |channel|
      channel.subsystem("xmlagent") do |xmlagent, success|
        xmlagent.on_data do |xmlagent, data|
          puts "(xmlagent) ON_DATA: #{data.inspect}"
          xmlagent.close if data === "]]>]]>"
        end
        xmlagent.on_close do |xmlagent|
          puts "(xmlagent) ON_CLOSE"
        end
        xmlagent.on_eof do |xmlagent|
          puts "(xmlagent) ON_EOF"
        end
        xmlagent.send_data(IO.read('nx1k_hello.xml'))
        xmlagent.send_data(xml)
      end #xmlagent
    end #channel
  end #session
end #send

end #class

vsm = NX1K.new
vsm.host = '192.168.1.130'
vsm.user = 'admin'
vsm.pwd = 'VCEr0cks!'
vsm.send(IO.read('nx1k_show_int.xml'))

Related posts:

1. Easy access to the Cisco UCS API via the Ruby UCSAPI Module
2. VMware + Ubuntu + Ruby + REST + XML + Cisco UCS API

Say Cheers to Vblock

It’s nearly a year since I first published the VDI iceberg and 20-layer model: time for an update.

The original idea behind the iceberg/20-layer model was to inject some humour into a difficult subject, being: VDI is hard, really hard.  There are so many moving parts that it’s not IF but WHEN and WHAT problems you will have with your project.  The size and complexity of the problem seemed to fit an iceberg…

Above the surface is all the End User Computing stuff – the users, the apps, the OSs.

Under the surface is all the unglamorous stuff that is either too hard or too boring or too complex or Somebody Else’s Problem, but most likely all four.  There are multiple worlds colliding (end users, desktop admins, network guys, ITIL thingies, storage, server, virtualization, engineering, operations…).

What if some of that pain could melt away if you buy a Vblock for VDI?  What if the VDI End User Computing experts could rely on the underlying platform to such an extent they could focus on what they are really good at – ie. virtual desktops, the apps in them, and how to manage the Desktop as a Service (perhaps!)?

Here’s the updated iceberg, and I think you’ll agree it’s much less daunting to an EUC/VDI expert.  If you disagree, click here for the original!

VDI Iceberg with a Vblock

 

So if you bought a Vblock to run VDI, did your iceberg just became a few ice cubes?

1. one slightly submerged for managing the apps as desktop as a service, and
2. another one for the end user computing stuff (end points, user virtualization etc).
3. a solid foundation, called a Vblock, to run VDI in the datacenter that was application aware and made it easy to bolt on VDI technologies like firewalls, load balancers and accelerators?

Still want to roll your own backend infra for VDI?  Anyone who thinks that’s a one-time engineering effort is sadly mistaken, but not alone, but I’ll indulge that and STILL we see that VDI projects are sensitive to Time and Visibility…

• The VDI projects I’ve worked on all had a common thread in their business case: a compelling event that drove the VDI adoption.  Whether it was an office closure, or relocation, or new office without enough power: they all had short time limits:
  IT Exec “We aint got all the time nor all the money in the world to do this”.
  
• Under such pressure, with such visibility on end user computing, do you have time, say six-to-twelve months to evaluate, test, design, blueprint, procure, engineer, build, test again, go live, migrate, load up, support and operate a custom built infrastructure back end?
  IT Exec: “VDI is the biggest career limiting decision an IT exec can make”?

Now here’s a crazy thought:  what if VCE isn’t (just) about Vblocks.  What if a Vblock is not the end, but a means to the end?  What if VCE cares about Vblocks only because they let people and organizations focus on the consumption of IT, not the provisioning?  

In case you’re in any doubt, let me leave you with a statement of fact: Infrastructure only costs money, it doesn’t make it.

You know and I know that the business only benefits when those applications are up and running and performing within the SLA, hopefully protected from the entropy that will ensue when the “solution” is thrown over the wall from engineering to operations.

That three month evaluation period to compare This Array to That Array, the five hundred engineering hours spent comparing PowerPath to native ESX path sharing: Really?  Are these people serious?

Well?  Am I Right?  Am I Wrong?  Comments please  And whilst you’re noodling on it, why not read this from my personal sponsor, VCE

Check out VDI FastPath from VCE is the next evolution of converged infrastructure from putting Compute+Network+Storage in one configurable container that has known qualities (very helpful in the fight against IT Entropy – more on that later), to now making those containers application optimized.

Now your iceberg is really a new solid foundation to run VDI on top of, because with FastPath Vblock you get:

1. a converged infrastructure product, not a PDF/CVD/DIG document
2. modular growth
3. simplified scaling
4. trusted multi-tenancy
5. deployment anywhere in the world through VCE and partners
6. seamless support
7. rapid provisioning/decommissioning of desktops
8. resilient architecture due to engineering and QA

Related posts:

1. Microsoft Enterprise Application Iceberg
2. VDI iceberg and 20-layer model

This applies to all enterprise apps that need to run on highly-available, service-level-driven, on-premise infrastructure.

A picture paints a thousand words, but I’ll chuck in a few words just to make sure we’re all clear:

• Business demands focus on applications, how to generate revenue, how to increase margin, cut costs
• That drives focus away from “under the water” (ie. in the data center) infrastructure
• It also drives a focus on cheapest tin wins, which is like using spray-on cheese in a good restaurant.  Customers won’t come back.  If you have to ask why, you’re an idiot.
• If you think “under the water” is easy, you will hit the ice berg and be eaten by penguins.
• What you need is a way to do the “under the water” stuff in a repeatable, predictable, scalable, cost-effective way (VCE and Vblocks)

I’m picking Microsoft only because I’m presenting tomorrow at Microsoft, but all other vendor Enterprise Apps apply.

Now for the picture:

Enterprise Application Iceberg

Related posts:

1. Microsoft hearts Cisco UCS
2. VDI iceberg and 20-layer model
3. What if a VCE Vblock Platform turned the VDI iceberg into ice cubes?

I like it when it's stormy

Ever been on a British beach in winter?

Did you lean toward the on-shore gale, arms out-stretched as in a crucifix, with the wind whipping your hair and your eyes moistening with sea spray?  Ears hurting with the noise, the pressure, the cold?  Isn’t it FUN?!  I love it!

I’m nearing the end of my first quarter at VCE and has it been like body surfing in a storm.  I’m running a team of vArchitects in Europe that focus on service providers, and it is awesome.  I’m lucky to work with great people, there’s even a few ex-Loudclouders in here!  What are we doing at VCE?

Before VCE came along with their Vblock product, it was really hard, slow and expensive to deploy converged infrastructure: I know, because I’ve done several big ones and many small ones in my life at VMware and Cisco prior to VCE.  Why is it different at VCE?

Sit down with me and we can create a bill of materials from your requirements in less than 15 minutes.  If you press the Buy Now button then thirty days later it will be shipped to your datacenter loading bay on one or more pallets instead of hundreds of little boxes.

Then a VCE guy turns up in a taxi and in one day will have the whole thing running for you.  The day after that you can do your testing and launch your services and start making money.  Time to value and time to cash after making these kind of investments is what keeps the senior managers awake at night.

What goes on top of a Vblock though?  If you want a solution, VCE will take the lead and bring together some powerful functionalities and product sets so you don’t have to.  Watch this space for Trusted Multitenancy (TMT) including the market leading products from VMware, RSA, EMC, Cisco.  We just built this for a customer, from scratch, with no kit, to a fully functioning trusted multitennant Infrastructure-as-a-Service including VMmark2 (!) in less than four weeks.

And that, my friends, is why I work with Service Providers at VCE because you know what, it’s not really about a Vblock (we’ve solved that bit, let’s all move on now).  It’s about how you integrate it and run solutions on it to increase your margins and adopt new lines of revenue.  To quote one of my esteemed colleagues: It’s not about the hardware, it’s about the software.  We can only say that, though, because we have hundreds of engineers working thousands of hours to solve the hardware problem.  If you don’t do Vblock, you still have the hardware challenges to overcome.  Bon chance, mon ami.

What would the business prefer?  To be earning revenue from your new infrastructure in sixty days, or be still sitting in a room looking at a whiteboard and still doing the low level design and still working out which product firmware is compatible?  Been there, done that, now it’s up there with ITIL for me.  It is of value only to the professional services teams that charge customers for it.  It’s boring.  It’s dead, dead, dead.

I’ve been saying it since 2004 but I’ll say it again:  it’s not about provisioning, it’s about consumption.  If you spend 80% of your time talking about which SFP+ goes from here to there, then you are dead in the water.  VCE has done all that so you don’t have to.  We let you turn lots of knobs to get the performance and capacity you need, such as different RAID groups, but other than that we’d like to talk about something more interesting.

Like… how are you going to make money out of this thing?  And guess what?  VCE has some ideas to help you with that too.

I’ll be sharing these thoughts, such as In, With and On a Vblock, and topics like TMT and Service Creation over the coming weeks and months.

No related posts.

Quick note to remind you and highlight the key new features of the awesome 1.4 release.  Congrats to Cisco’s engineering team for getting this out!

The features this software release unlocks, and they are all awesome!

Update:  the docs are released, the code is on its way… I’ll update this post and my twitter feed when it’s all live!  It’s important the docs are released first so get reading and by the time you’re done, the code will be available

New Software Features in Release 1.4(1)

This release adds support for:

•Chassis and multi-chassis power capping for UCS B-Series < METER YOUR POWER DISTRIBUTION ACROSS 20 CHASSIS FROM ONE SCREEN!

–Power capping has been extended to cover chassis and groups of chassis and includes a policy based workflow using service profiles for setting it up.

•Software packaging with server bundles < FIRMWARE MANAGEMENT JUST STEPPED UP A GEAR, AWESOME!

–Support for server and adapter hardware can now be delivered independent of support for the infrastructure components. This allows customers to add support for new server types without having to upgrade their Fabric Interconnect or UCS Manager software.

Scalability

–UCS instances now scale to up to 20 UCS 5108 chassis  < THAT’S 160 BLADES WITH ONE UNIFIED FABRIC AND CONTROL POINT

Ethernet and Fibre Channel

•FabricSync < HIGH AVAILABILITY BUILT INTO THE UNIFIED FABRIC

–The UCS 6100 synchronizes their mac-addresses between them. It works along with FabricFailover feature to provide faster VNIC fail over for Bare metal and brings HA to Hyper-V virtual switch networks. It is always turned on.

•PVLAN support < SECURITY BUILT INTO THE UNIFIED FABRIC

–Layer 2 traffic segmentation within a subnet can now be achieved using PVLAN Isolated access in the UCSM. This allows customer to achieve vNIC level isolation which translates to VM level isolation using Cisco Virtual interface card in pass though mode.

•SPAN support on UCS 6100 < VISIBILITY IN TO THE UNIFIED FABRIC

–SPAN provides granular visibility in to the Ethernet and FibreChannel flows within UCSM for monitoring and troubleshooting

•Higher VLAN scalability (>1000) < SCALABILITY OF THE UNIFIED FABRIC

–Increased VLAN scalability from 512 in 1.3(1) to 1024 in 1.4(1)

•Direct connect Appliance < SIMPLICITY OF ADDING IP STORAGE

–Specialized IP Appliances such NAS filers and ISCSI storage can be connected directly to the UCS 6100 in End Host mode. This allows reduction in number of hops and latency for communication between server and IP storage.

•FC Trunking and port channel (in NPV mode) < INCREASE UTILIZATION OF FC JUST LIKE YOU CAN ETHERNET

–Allows trunking of multiple VSANs using a single FC link and FibreChannel link consolidation when using VSANs,

•Limited Direct Connect FC Storage < ADD STORAGE SCALABILITY WITHOUT INCREASING SAN COMPLEXITY

–FibreChannel storage can now be directly connected to the UCS 6100 with default zone policy (No zone configuration allowed in the 6100 but can be inherited from an upstream MDS switch).

Security

•KVM security enhancements < SECURITY IN OPERATIONS

–Multi-user KVM access has new controls that allow the first user to allow/deny or control the permissions of subsequent sessions.

•AAA – Active Directory group support < GRANULAR RBAC

–Groups defined in active directory can now be mapped into roles within UCS Manager.

•AAA – Multi-authentication support < FLEXIBLE RBAC

–UCS Manager now supports concurrent authentication using different authentication schemes such as Active Directory, TACACS+ or RADIUS. Concurrent authentication with multiple instances of the same scheme, such as multiple Active Directory domains, is also supported.

Monitoring

•SNMP GET support for all UCS components < EASIER INTEGRATION

–SNMP support has been extended to provide query (GET) support for all UCS components. The new MIB files can be accessed athttp://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml. Select UCS Manager under ‘Unified Computing’.

•UCS 6100 licensing enforcement/warnings < EASIER COMPLIANCE

–A new GUI based workflow for licensing management is available and licenses are enforced with warning messages.

•Syslog message classification enhancements < EASIER SYSTEMS MANAGEMENT

–New UCS labels allow easier filtering of syslog messages.

Stateless Computing

•Scheduling of service profile changes < OPERATIONAL FLEXIBILITY

–Through the use of maintenance policies, service profile deployments can be scheduled for a later time. In addition, the number of concurrent profiles that are being applied and the total number of profiles applied during a particular time window can be controlled.

•Impact analysis of configuration changes < HELPS CHANGE MANAGEMENT

–A simple “pre-flight check” compatibility check allows customers to recognize potential compatibility issues before applying a service profile to a particular server.

•CIMC IP address abstraction < MULTI-TENANCY AND OTHER USES

–In addition to the CIMC IP address for the CIMC on the server an optional management IP is available with the service profile that can move with the service profile when it is moved to a new server.

Usability

•User labels for managed objects < MAP SERVICE PROFILES TO WORKLOADS WITH SIMPLE LABELS

–Service profiles, servers and chassis have custom user labels that can be applied. These user labels can be displayed, sorted and filtered through the UCS Manager GUI.

•Direct upload of firmware image files from UCSM client < THIS IS ALL MY CHRISTMAS’S ROLLED INTO ONE!  THANK YOU ENGINEERING!

–The need for setting up SCP/SFTP for image file uploads is now optional since a direct upload from the laptop or other UCS Manager client to UCS Manager is now possible.

New Hardware Features in Release 1.4(1)

This release adds support for:

•UCS B230 server blade

–UCS Manager now supports the newest blade in the UCS B Series, the UCS B230 which is a 2 socket, 32 DIMM slot half width server with two optional SSDs.

•UCS Manager support for UCS C-Series

–The UCS C200, C210 and C250 servers can now be managed directly from UCS Manager. Integration details are available in the C-series server installation guides. Please contact your Cisco representative for additional information on connectivity and compatibility requirements.

•Fabric Extender Transceiver (FET-10G) between the fabric interconnect and fabric extender.

No related posts.

Why? And in relation to What?

After much research and consultation (ok, an hour of tweets), it has been agreed that the next time you hear/read about a “best practice” you have to think/respond “Why?  And in relation to What?”  Sound good to you?

“Who gives a damn!” I hear you shriek.  Well, best practice is big business (isn’t it, itSMF?).  On twitter there’s a constant stream of best practice tweets.  We get best practice shoved down our throats all the time (ITIL anyone?).  I would bet a rare Yorkshire quid that few of the people touting best practices can articulate both Why and In Relation to What.

If a best practice is defined as “superior to other practices”, then what are those other practices?  And why is one superior to the others?  It just might be that in my situation another practice might be best.   What’s best for you might not be best for me, right?  But you can’t know that, so we are still friends.

I’ll be honest: best practices appeal to my lazy self.  If someone else has done all the heavy lifting then why not leverage their hard work?  Aren’t best practices a form of altruism?  Well, that’s a bit of a trusting approach in an untrusting world.  What if the author is lazy too?  What if that auther just lifted their best practice from someone else, ad infinitum?  Now nobody knows why its a best practice, reason is lost in time, and we all go baa.

FWIW I give a damn because my lazy self really wants to use best practices but because of my irksome sense of self preservation I have to do a bit more homework before I reuse any existing best practices… and in fact, this attitude means I can’t take someone else’s short cuts and makes me into an ever more cynical person.

So, here’s three things I’m going to do from now on and I encourage you, Dear Reader, to do the same:

1. If you feel the words “best practice” bubbling from your brain to your mouth, make sure you can answer the Why and In Relation To What questions.
2. If you are writing a best practice then you must include text that answers the Why and In Relation To What questions.  Otherwise, you are just recommending a practice (ie. not best).
3. If your ears ever hear the words “best practice” from someones mouth or in see them in print, make sure you think Why and In Relation To What and unless you have at least one counterpoint, just downgrade it to a practice (i.e. remove the best).  Ask the author, Why?  and In relation to what?  They might have a superb answer that we can all learn from.

Up for it?  Let’s start now.  Personally I never recommend best practices I only recommend suitable practices to match the requirements but that’s another story…

No related posts.

Oo oo oo, I wanna be like you-oo-oo

Thought I’d share a snippet of something secret I’m working on.  I have a document template called, wait for it, template.odt.  It’s an OpenOffice document and I want to add text to that template from Ruby.  Perhaps I have a database of content that I want to inject into a nicely stylised document.  Sounds useful to me.

This example is all from the command line IRB to show you the actual output, but before I start here’s what I have already setup:

• I’m working in a directory called odt, but you could call it bananas if your name is King Louie.
• My template is a simple OpenOffice document called template.odt.
• I’m using Ruby 1.9.2 with the rubyzip.gem.
• My goal is to inject some text into template.odt.

Here’s the command line kung-fu:

14:30:57 ~/Documents/odt $ ls
template.odt
14:30:58 ~/Documents/odt $ irb
irb(main):001:0> require 'rexml/document'; include REXML
=> Object
irb(main):002:0> require 'zip/zipfilesystem'; include Zip
=> Object
irb(main):003:0> odt = ZipFile.open("template.odt")
=> template.odt
irb(main):004:0> doc = Document.new(odt.read("content.xml"))
=> ...
irb(main):005:0> root = doc.root
...
snipped output
...
irb(main):006:0> body = doc_root.elements[4]
=> ...
irb(main):007:0> text = doc_body.elements[1]
=> ...

irb(main):012:0> odt.replace("content.xml","myfile.xml")
=> content.xml
irb(main):013:0> myfile.close
=> true
irb(main):014:0> odt.close
=> true
irb(main):015:0> exit
14:39:46 ~/Documents/odt $ ls
myfile.xml oo_inject.rb template.odt


Now when I open the file template.odt in OpenOffice I can see…

Programmatically inserted text into an OpenOffice doc from Ruby

You can get a zip of my work here.

Related posts:

1. VMware + Ubuntu + Ruby + REST + XML + Cisco UCS API
2. Basic Ruby interface for the Nexus 1000v
3. Easy access to the Cisco UCS API via the Ruby UCSAPI Module

Quick update – there’s a new gem you can get at https://rubygems.org/gems/UCSAPI.

Important note:  I’m now using Ruby 1.9.2 so if you run this on 1.8.7 it might not work (for example, I have to do a ‘require_relative’ which is new in 1.9.2 I think).  I haven’t got time to test it against older 1.8.7 install (Yes!  I should be using rvm to test! and Yes! my code should be more robust!  but [fishes for excuse])

UCSAPI 0.0.9

This is still rough’n'ready code and you have to bear in mind that I’m learning and playing with Ruby as I go.

Headlines are:

• You get a UCS object and login to the api
• Then you can get fabrics, fabrics and slots, and all the attributes
• Next is to add fans and psus

This is taking quite a bit of time because (a) my wife is giving birth at the moment, and (b) I’m concentrating on making the code re-usable so the rest of the managed objects are a doddle to add.  I want this to be as usable as PowerShell, but with all the added goodness of Ruby.

One cosmetic thing I’m going to do next is add prettier “to string” methods so you get similar output to PowerShell.

Any comments…please add here.

Here’s an example of how to use (taken from the test case that’s in the gem – lib/tc_ucsapi.rb).  The output from the test case is here.

require 'UCSAPI'
@ucs = UCS.new(@options)
@ucs.login
puts "\nTEST: GET ALL FABRICS - @ucs.fabric"
puts @ucs.fabrics
puts "\nTEST: GET FABRIC A BY ID - @ucs.fabric(:id = 'A')"
puts @ucs.fabric(:id => 'A')
puts "\nTEST: GET FABRIC B BY DN - @ucs.fabric(:dn => 'sys/switch-B')"
puts @ucs.fabric(:dn => 'sys/switch-B')
puts "\nTEST: GET ALL FABRICS TOTAL MEMORY - @ucs.fabric.totalMemory"
puts @ucs.fabric.totalMemory
puts "\nTEST: NON-EXISTENT METHOD VIA FABRIC ARRAY PROXY - @ucs.fabric.noSuchMethod"
puts @ucs.fabric.noSuchMethod
puts "\nTEST: GET ALL FABRIC ATTRIBUTES - @ucs.fabric.attributes"
puts @ucs.fabric.attributes
puts "\nTEST: GET ALL FABRIC INSPECT - @ucs.fabric.each { |fabric| puts fabric.inspect }"
@ucs.fabric.each { |fabric| puts fabric.inspect }
puts "\nTEST: USE FABRICS PROXY METHOD - @ucs.fabrics(:id => 'A')"
puts @ucs.fabrics(:id => 'A')
puts "\nTEST: GET FABRIC A BOOTFLASH - @ucs.fabric(:id=>'A').bootflash"
puts @ucs.fabric(:id=>'A').bootflash
puts "\nTEST: GET ALL FABRICS BOOTFLASH - @ucs.fabric.bootflash"
puts @ucs.fabric.bootflash
puts "\nTEST: GET FABRIC A WORKSPACE - @ucs.fabric(:id=>'A').workspace"
puts @ucs.fabric(:id=>'A').workspace
puts "\nTEST: GET FABRIC A WORKSPACE SIZE - @ucs.fabric(:id=>'A').workspace.size"
puts @ucs.fabric(:id=>'A').workspace.size
puts "\nTEST: GET ALL FABRICS WORKSPACE - @ucs.fabric.workspace"
puts @ucs.fabric.workspace
puts "\nTEST: GET FABRIC A OPT - @ucs.fabric(:id=>'A').opt"
puts @ucs.fabric(:id=>'A').opt
puts "\nTEST: GET FABRIC A OPT SIZE - @ucs.fabric(:id=>'A').opt.size"
puts @ucs.fabric(:id=>'A').opt.size
puts "\nTEST: GET ALL FABRICS OPT - @ucs.fabric.opt"
puts @ucs.fabric.opt
puts "\nTEST: GET FABRIC A STATS - @ucs.fabric(:id=>'A').stats"
puts @ucs.fabric(:id=>'A').stats
puts "\nTEST: GET FABRIC A LOAD - @ucs.fabric(:id=>'A').stats.load"
puts @ucs.fabric(:id=>'A').stats.load
puts "\nTEST: GET ALL FABRICS STATS - @ucs.fabric.stats"
puts @ucs.fabric.stats
puts "\nTEST: GET FABRIC A SLOTS - @ucs.fabric(:id=>'A').slots"
puts @ucs.fabric(:id=>'A').slots
puts "\nTEST: GET FABRIC A SLOT 1 - @ucs.fabric(:id=>'A').slot(:id=>1)"
puts @ucs.fabric(:id=>'A').slot(:id=>1).to_s
puts "\nTEST: GET ALL FABRICS ALL SLOTS - @ucs.fabric.slots"
puts @ucs.fabrics.slots
puts "\nTEST: GET ALL SLOTS ALL ATTRIBUTES - @ucs.fabric.slots.attributes"
puts @ucs.fabrics.slots.attributes
puts "\nTEST: GET THE SERIAL NUMBER OF ALL SLOTS - @ucs.fabric.slots.serial"
puts @ucs.fabrics.slots.serial
puts "\nTEST: GET THE NUM PORTS OF FABRIC A SLOT 1 - @ucs.fabric( :id => 'A').slot( :id => 1 ).numPorts"
puts @ucs.fabric( :id => 'B').slot( :id => 1 ).numPorts
@ucs.logout

Related posts:

1. Easy access to the Cisco UCS API via the Ruby UCSAPI Module
2. Why does Cisco UCS memory stop at 384GB RAM?

Drills, Diggers and IT

Drills, diggers and IT. Each a means to an end not a means in themselves.  What the consumer really wants is not the tool but what these tools produce.  Holes, bigger holes and…well, what does IT produce?

If you’re reading this I will bet you a rare Yorkshire pound that you are involved in the IT business.  But what do you produce, Dear Reader?   And why?

I hope it’s none of the things in this document (ok, so I’m guilty of a few):

Lean IT: Enabling and Sustaining Your Lean Transformation Appendix C ?? Information Wastes To be published Fall 2010 by Productivity Press Copyright 2010 Steve Bell and Mike Orzen

In Eli Goldratt’s The Goal, each person and machine in the factory was focused on the same goal: increasing sales and revenue.  If what you are doing doesn’t help achieve the goal then don’t do it.  If you have a choice of two activities and one increases revenue more than another: do the one that increases more revenue.  If you are more focused on your individual performance at the expense of the goal: change!

What about the story about the janitor at NASA?  When asked what he did, he said “I send people to the moon!”  Hard to tie his “sweeping up bonus” to the success of the moon mission, but you see his point?

What about the IT guy/gal who’s working in a bank’s data center installing new Cisco UCS infrastructure to replace the old fashioned legacy stuff?  Their goal isn’t “install the infrastructure”, is it?  What is their goal?  When I say Their I don’t mean that single person, I mean The Bank.

FWIW, here’s what I think:

1. IT is no different to other industries, it’s just that while those industries build spaceships to reach the moon, we build unified infrastructure to help the 30,000 staff collaborate on the moon mission project – ie. we supply to those industries.  We might not fly the ship, but we do send people to the moon.
2. When we focus on the goal of sending people to the moon, and not our Visio’s of ITIL processes, then we are likely to do things that achieve the goal rather than … well, unnecessary activities that don’t reach the goal.
3. The top, number #1, can’t-live-without activity that will help send people to the moon is to make it really easy to consume the IT we produce.

The cloud projects, the unified infrastructure projects, the consolidation projects, the collaboration projects, and many more, they all have a goal and that goal is best served by creating the most easy to consume IT system.  Let me repeat that writ large:

The goal is best achieved by creating the most easy to consume IT system.

This is a universal ITism.  If you’re a vendor or a consumer, this helps you.  So, the next time you are working on an IT project think of the end goal hole and see if you’d do something different:

• During planning, think if the IT system could be used for something else to double up on value.  For example, if you’re building a Cisco UCS system of 32 blades you could easily get over a thousand VMs on there but it might only be logistically possible to get a few hundred desktops per month deployed: could you repurpose that initially-underused capacity some other way?  Overnight risk analysis calculations in a bank?  Yes the capacity will diminish, but not for months yet.  Think ROI.
• During architecture, think of how many pages of your blueprint are dedicated to helping people use the system.  Where’s the Service Catalogue?  Where are the tools and guidance to help operations keep the system up and reduce maintenance?  Spending six weeks (or more?  AGHAST!) on a design should be a crime punishable by spending a year on an IT Operations Bridge where you learn where the rubber meets the road and how adaptable designs are better than monolithic monstrosities.
• During deployment, are you involving the operations and applications people?  If you aren’t then you’re deploying a castle of infrastructure and for every week you don’t collaborate with them you are widening the moat around around it, making more work for later.  And in the world of cloud, crossing that moat might be too much effort.
• Looking at the handover, how easy is it for people to consume the compute, the network, the infrastructure?  This means changes, most likely in ways you can’t foresee.  Can your system be completely reconfigured at a logical level, or does it need rewiring in the data center?  It better be the former.
• Migrating information: How do you get data in and out of it?  Can I Vmotion VMs from legacy to your new infrastructure?  Can I cold migrate?  How?  Does someone else have to work that out later, or can we make it easier for them now?
• Marketing.  You have to sell your solution.  Data centers are cold and lonely places.  Build it and they won’t come unless you advertise, encourage, incentivise, adapt.

Take benchmarks: don’t we just love them in the IT industry?  But all they are is navel gazing for geeks.  There are much more important things to do to reach the goal but so many of us are addicted to them on both sides, vendor and consumer.  Some out there are focused on ROI which is a measure of the consumability of IT.  On this I have one thing to say:

Benchmarks are navel gazing for geek at best, bad science at worst, and don’t help you reach the goal at all.

Imagine being a restauranteur who only cares how fast his customers eat and not what they really want?  Perhaps some want to eat fast, but perhaps others want him to be open 24×7 and offer healthy food?  A successful restaurant has a goal of increasing revenue (not making meals!) and to do that they need to make meals (“meals to an end” ahahha) that satisfy customers’ needs.  Simple but important.

I ask you again, Dear Reader, what is it that you do?  And why?

No crack, dope or alcohol went into the production of this post.

No related posts.