vmware-statsmonitor service times out on VCSA 6.7u2

In my homelab, I've made some changes, rolled back some changes, blown up a bunch of stuff, rebuilt servers, tried Terraform to see if I could make it work (I would call it a 58% success); tried Ansible (which I am MUCH more familiar with so it was a smashing success)... All of that to say I've been mean to my infrastructure, so I decided it was time to give it a fresh start.

I used the iDRAC (Integrated Dell Remote Access Console) to mount the vSphere install ISO and reloaded vSphere on all four nodes from scratch. I also re-initalized all of my  Once that completed, it was off to the races with vCenter and Update Manager.

This is probably a really old issue, but hopefully this helps someone :)

The VCSA I installed was older, so I backed it up to my Drobo and upgraded to 6.7u2. That's where the fun begins. Before that, though - if you're new to vSphere and vCenter, take my advice (especially if you're using a homelab to learn) and enable SSH when you install the VCSA. You'll thank me later.

On reboot, the PSC appeared to struggle (well, to be frank, it failed) to start all of the services. Most troubling was that the vapi-endpoint service continually failed upon start. Here's where SSH comes in handy. I connected to the appliance and checked the services status. You COULD do the same thing in the :5480 VCSA management console, but not nearly as quickly as with SSH.

Running "service-control --status" shows what is running and what is not. As you can see from the screenshot, many of the services were not running. The quickest way to restart is to use service-control.

This KB article is where I found help.

https://kb.vmware.com/s/article/68149

This describes a different problem, but it seems that the vmware-statsmonitor service was taking more than 60 seconds to load, which caused all kinds of downstream havoc. I changed the timeout values as suggested and rebooted. 3 days later (IM KIDDING), all services were running again and all is well.

Once I changed the .json mentioned in the article, everything seems to be ok. Now I can backup vCenter again and upgrade to 6.7.u3... stay tuned...

/finis

Rethink the possible - SAP HANA at home

The first thing I did with my new lab was connect it to my old lab. (yawn - and well, the power bill at some point becomes a problem)

CAUTION: This was an experiment. It involves mostly commercially supported configurations. I'm specifically "detail light" in this post because I don't want any assumptions being made about suitability or supportability for production workloads. Nothing about my homelab is suitable for production supported workloads.

I'm involved in a pretty cool project for work around SAP HANA virtualized on VMware vSphere. As a VMUG Advantage member, I'm loving the fact that I can get non-production licenses for just about anything I can think of when it comes to building out virtual datacenters. While I am not licensed for HANA at home, I did have 30 days to mess around with it, and mess around I did.

I wish I had taken screenshots, but here's the hot take. I connected my homelab with a 64GB HANA instance (and 3 application servers) to a 64GB HANA instance I built in Walldorf, Germany. This was a mostly functional landscape, with some bogus data I generated in my homelab - and used HANA System Replication to copy the data, and Dell EMC RecoverPoint for VMs for the application servers to Germany. This copy (with my exceptional cable modem service) took almost a week to complete, but just before I shut down my HANA landscape in my homelab, I was able to literally push all of the functions of my tiny little application instance over to Germany.

VMware vSphere as my virtualization engine provided stable, consistent infrastructure. I was using vSphere 6.7 in my homelab and 6.5u3 in the Germany VxRail cluster. Of course, consideration had to be made for a variety of configuration details (HW versions for the 6.7 VMs, etc). Let me tell you how incredibly simple VMware NSX virtual networking made this - especially since the test was across such great distances.

In the projects I'm on at work, this is a very similar scenario to what we're working on, but with much bigger landscapes. For me personally, provided a proof point as to how simple SAP HANA can be when it's built on top of intelligent virtualization. The great thing about this to me is, I proved several important concepts in my own mind that before this, I had only read about in whitepapers.

I'm a very pragmatic technologist, and the ability to perform a "cloud to on-premise and back" landscape migration / replication / copy is hard. Systems must be 100% perfect across potentially hundreds of them. Complex application integrations must remain established on either side of the landscapes. Data integrity is, of course, sacrosanct. Intelligent virtualization helps customers with a consistent view, regardless of the "iron underneath". There is no better than VMware vSphere, vSAN  and NSX - especially on VxRail.  My little experiment has given me a high degree of confidence that with the right tools, time and smart people, enormous projects at enormous scale can be accomplished with the right tools. A proof point in my own mind on the work I do every day.

Interested in learning more? Find out more about VMUG Advantage here. Learn about SAP infrastructure for free here.

/finis

Homelab: Update

I promised an update when the rework was complete, and here it is.

First, the rack and stack. This took a bit of time, and a bit of patience as I sourced the best deals on my favorite auction site. My patience paid off, and here's the finished product. From top down:

Ubiquiti UniFi USW-XG (16 port 10Gb ethernet)
AC Infinity sensor based intelligent fan
Ubiquiti UniFi USW-16 (18 port 1Gb ethernet)
Leviton commercial power conditioner
Dell EMC PowerEdge R620 x4
2014 Mac Mini (home media server)
Drobo 5c (connected to Mac) with 5x 1.5TB SSD
Drobo 5n (clients, vCenter backups) with 5x 8TB HDD

All of this is connected to my Ubiquiti UniFi based system. The only component of the network that is not UniFi is a SonicWall TZ350 just before my Comcast Business CPE.

This home lab is surprisingly quiet and consumes (again, surprisingly) much less power than I originally planned for or had available when I built it.

It's all virtualized using vSphere (of course), managed by vCenter and vRealize Log Insight (VMUG Advantage is awesome by the way), and I recently installed a TIG stack (Telegraf, InfluxDB and Grafana) to see what kind of metrics I could get out of it. Questions / comments welcome.

/finis

Homelab: connectivity

I've posted a little bit about my home lab, and have recently consolidated everything into a single rack. I'm still waiting on a few components for the rack to address recirculation and aesthetics, so I'll wait to publish pictures until that's complete.

I'm a big fan of Ubiquiti UniFi products, and they suit a lab's needs well. If you're looking for a managed solution of simple layer 2 switches, go check them out. I'll publish links to the products as I describe them.

My lab is connected to my home network via the default VLAN. That's the only way into the lab. Everything else is isolated within the lab networks. My home network consists of a pretty robust firewall, and everything behind it is Ubiquiti.

I have a 1Gb fiber connection between the switch that serves my home and the lab "core" switch. The lab core is a UniFi Switch 16 XG (link) that offers (12) 1/10 Gb/sec SFP+ capable ports, and (4) 1/10 Gb/sec RJ45 ports. It is connected to a UniFi Switch 16 (link) and a UniFi Switch 8 (link).

The VLAN configuration simplifies everything in the network. Rather than worry about port assignments, VLAN to port tagging, etc; I decided to create my distributed virtual switches with the VLAN tag in the Distributed Port Groups. This way, I can maintain flexibility and simplicity. The only exception in this scheme is in the connections to the NAS platform which is connected to the Default VLAN and is accessible from both the home network and the lab network.

The server connectivity is shown to the right.

I didn't have a 24 port switch, so I decided to separate management and provisioning. There's not really a need to do that for a small environment, but I could - so I did.

The vMotion and vSAN ports are separate, and the DVS' are using separate VLANs in the connections. I could have used a LACP connection on these ports but in the interest of simplicity, these connections are separate 10Gb/sec using SFP+ DACs.

Hopefully if you're building a server based home lab, you find this helpful. Comments / questions welcomed below.

/finis

Homelab: The quest for the circle of trust

NOTICE: This contains some advanced and potentially dangerous configuration steps. If you're at all uncertain on this, please don't do it. I cannot assume any responsibility for your system or information security. This worked for me, and may introduce serious risk to your own system. Know what you're doing, and how to undo it - or don't read this.

I would like to address an issue that has come up with Mac OS Catalina (10.15.x). Besides the rapid release of fixes, etc associated with iOS 13 and Catalina, one other issue has arisen that I found the workaround for. It truly is a workaround, and appears to affect ONLY Chrome on Catalina.

NET::ERR_CERT_REVOKED

SSL certificates are a pain by any measure, and self-signing isn't working anymore on Chrome / Catalina. SO, you can either get / create your own (a massive pain), or follow the steps below.

The NET:ERR_CERT_REVOKED message can't be bypassed like some SSL errors that Chrome reports. In the case where you're on the internet or looking into a system that you're not completely familiar with, this is a good thing. However, in the case where you KNOW the system (home labs are a perfect example), this is a royal pain.

So, upon connecting to my lab post-upgrade (to Mac OS Catalina), I received this message on all of my "home" systems. Connecting via Safari worked, as did connecting via Firefox - so I knew it was (1) a certificate issue, and (2) Chrome. Here's the workaround:

1. Open the URL in Safari ex: 192.168.1.200. You will receive the usual SSL message. 

Select "Show Details"

2. Here's a little known Mac OS trick. Once you view the details of the offending certificate in Safari, you can drag the certificate to your desktop by click / hold / drag the image. You'll then have your certificate on your desktop.

3. Once it's there, open "Keychain Access" and drag the certificate into your certificate store.  Once there, you need to expand the "Trust" section at the top and then select "Always Trust". This will then allow you to connect via Chrome. PLEASE NOTE: If you are at all unsure about what you're doing here, please do not do it. This bypasses a VERY significant security feature of Mac OS and Chrome. I am only doing this because I trust these systems.

I hope this works for you. I would also STRONGLY state that this process should NEVER be used on any SSL protected connection that you are not 100% responsible for, and definitely not for something outside of your own network and control.


/finis

PowerEdge and vSphere. My home lab upgrade

So I just finished installing my new Dell EMC PowerEdge servers in my home lab. The difference one generation of server makes is astounding. The new machines are pretty stout and will serve well in the experiments and learning I want / need to do.

Home labs get budget racks

4x Dell EMC PowerEdge R620 (Sandy Bridge EP)
- 2x Intel Xeon E5-2670 2.6GhZ eight core CPU
- 128GB RAM each
- 1x Dell 400GB SAS SSD (vSAN Cache tier)
- 2x Dell 1.2TB SAS 10k (vSAN capacity tier)
- 2x Dell 600GB SAS 10k (local datastore)
- 2x Samsung 16GB SD-Card (boot)

Ubiquiti UniFi 16 port 1Gb switch (+ 2 1Gb SFP)
Ubiquiti UniFi 16 port 10Gb switch
Ubiquiti UniFi 8 port 1Gb switch
Spanning Tree enabled
Uplinked to my "home network" but isolated from
it except for management (all workloads isolated but internet accessible)

The nodes are connected as follows:
- iDRAC is on a dedicated VLAN (16 port UniFi)
- eth4 is on VLAN 1 (16 port UniFi)
- eth3 is on a dedicated routed VLAN (8 port UniFi)
- eth5 is on a 10Gb SFP+ DAC for VMTN (closed VLAN)
- eth6 is on a 10Gb SFP+ DAC for vSAN (closed VLAN)

Configuring these machines was SO simple.

1. Since I bought them used, I connected to the iDRAC first and downloaded the Enterprise license key. I then reset the iDRAC. This took a few minutes - but trust me - it's worth it to not have to slog through troubleshooting only to find out some obscure setting was in your way.
2. Once that was finished, I connected a local keyboard and monitor to each server and set the static IP address, admin user, and a few other options. This can be done remotely, but it's kind of a pain to discover the iDRAC and have to reconnect. The 5 minutes it took was worth the "in person" visit to my basement.
3. I then used Virtual Media to mount the Dell EMC Remote Update ISO. If you're not already aware of this gift - get aware. It's an ISO image (so could be burned to DVD and run locally if you wanted to) that I mounted to the virtual CD and booted the server from. Think of this as a run-time out of band Lifecycle Management tool for all of the devices in your compute node. It updates everything it finds to the versions on the ISO and restarts the system.
   
   You can find the ISO for your system here.
4. I proceeded then to mount the vSphere (Dell EMC custom build ISO) image and installed vSphere to the SD-Card. 

Once all of that was finished, I configured my DVS' and vmKernel NIC's and was ready to start playing. 

But wait... there's more...

Backstory: Every Dell EMC PowerEdge contains a Lifecycle Management utility in its' pre-boot environment. This LCM process allows you to connect to Dell from any internet accessible network and - just like the ISO in step #3 it will analyze everything in your system and offer to update it. Since the ISO I downloaded in step #3 was from July, there were most certainly updates issued by Dell EMC since then.

Anyone want to buy some R610's and a NetApp 10Gb switch?

So, I configured everything - including vSAN and stuff is running beautifully. I then put Server #1 into Maintenance mode (vSAN is configured for FTT1) and proceeded to reboot into the LCM. Sure enough, it found several firmware items that were newer than what was installed, so I let it do its' thing.

vSAN is magic. Period. It has come SO far in so short a period of time - I'm a HUGE fanboy. The LCM process on Server #1 took about 45 minutes. Tons of time before vSAN rebuild starts. Except I'm an idiot. I got distracted - forgot the server was updating - and what do you know... 90 minutes or so after the LCM started, I realized it was finished and rebooted ESX.

Before ESX completely booted, vSAN stopped rebuilding and re-synchronized the node with the other 3 members. 

I'm really enjoying my time with VMware. I'm hoping (now that I have enough CPU and RAM) to start messing around with PKS and, later, OpenShift. I'll continue to update...

Proudly displayed on the wall in my "lab" because why not?

/finis

At long last...

Across two companies, what feels like an eternity (actually only 2 1/2 years), and many many iterations, my "pet project" is finally announced. I can tell you that our partners are excited, our teams are energized, and we can't get out to talk to all of the customers that want this fast enough.

Hybrid Cloud is nothing new, certainly not in the land of marketing and buzzword bingo, but Hybrid Cloud in an appliance form factor that focuses solely on "high value workloads" is certainly something that is elusive.

The preview announcement, made at SAP TechEd by Sven Denecken (SVP, SAP S/4 HANA) described an industry partnership to bring a fully managed hybrid experience to customers that run SAP workloads.

With the 2025 deadline approaching, customers migration journeys are under way to S/4 HANA, and with these journeys comes infrastructure questions and choices. The position that Dell Technologies and our partners are taking is that customers' consumption of these technologies shouldn't be a "cloud OR..." question; rather it's a "cloud AND..." question. This consumption model provides great flexibility as to where workloads are run, and enables workload mobility and management based on an SLA - not based on a location.

The Kinetic Hybrid Cloud for SAP is brought to you by Deloitte, Dell Technologies and Intel. This simple diagram shows the Unified Operations and workflow integration that Deloitte and Dell Technologies bring to SAP workloads across multiple datacenter instances.

Dell Boomi provides integration of data sources and applications outside of the SAP Application ecosystem; SAP has intelligent integration points within the SAP Application ecosystem; Deloitte brings Hybrid Cloud Management to the horizontal suite of deployment solutions; and Dell EMC brings complete infrastructure management for the on-premises infrastructure components.

All of this is managed under one SLA, one price, and a single engagement model through Dell Technologies and Deloitte.

I'm really excited about this combination of companies, technologies and people. This is only the beginning - and I'll share much more when able to.

/finis

Your own personal datacenter

About a year ago, I decided to build my own personal datacenter. I won't go into gory specifics, except to say that I tried to buy a VxRail cluster, and discovered that I am not a billionaire or a business with a capital budget.

SO off to my favorite auction site I went, and found a great assortment of gently used Dell EMC Poweredge servers. I chose 4 of them, bought a couple of Ubiquiti switches to add to my home network, and off I went.

Here's how things are currently cabled:

And here is what my home cloud is running:

It's all VMware based, but I'll be adding Red Hat OpenShift and Kabanero.io once the RAM I ordered arrives. Fun times ahead.

/finis

Back in the saddle

Well, I took a brief hiatus, and 4 years later I'm back. I'm going to attempt to keep this up to date with tips, tricks and general palaver...

Introduction:
I've never had a reason to run VMware vSphere from a professional perspective. Several years ago, I became very interested in it, and began running a small embedded vSphere lab in our company's lab. Aside from simply messing around, I learned slowly the how / what / why things work the way they do. Fast forward to today, and I'm running a full-on hyperconverged data center in my basement. It makes my wife very happy...

I have come to rely on a few extremely smart friends for advice, help, and so on - and they have been amazing with the amount of knowledge they're willing to share. One of them is zsoldier, a friend and colleague I'm blessed to know. Find him here: https://tech.zsoldier.com/ - and I'm very thankful for his wisdom and friendship.

Problem: vCenter Server failed with a disk capacity issue for its' database.

I had been away on business, and when I came back, I checked in on my vSphere cluster, and vCenter was up but not really. When I started digging in (https://vcenter.local:5480), I discovered that the database (seat) was out of space, and the vSphere Server couldn't start.

I started researching this, and found that this issue is pretty well documented (here: https://kb.vmware.com/s/article/2145603 and here: https://kb.vmware.com/s/article/2126276).

It literally took longer to restart services and back up vCenter than it did to fix the issue. I had considerable trouble identifying the exact volume to expand, because the default vCenter with embedded PSC installation process creates a bunch of 10GB volumes. Nothing is labeled, so seat could be on any of these volumes.

Here are the steps I took to fix the issue:

1. SSH to the vCenter VM and enabled the shell
2. Ran df -h to determine which mount point seat is on - completely useless except to see that it was, indeed, full - but helpful later
3. Opened the vSphere UI on the host I know vCenter and the embedded PSC are running on. I then edited every one of the 10GB vDisks as follows: 11GB, 12GB, 13GB, etc etc until they were all completely unique.
4. There is a shell script to autogrow the changed LUNs: "/usr/lib/applmgmt/support/scripts/autogrow.sh"
5. Ran df-h again to see which of the now unique 10GB LUNs are /dev/mapper/seat_vg-seat (it was 13GB)
6. Back at the vSphere node that is running the vCenter VM and increased the 13GB volume to 55GB (thin so who cares right?)
7. Ran the autogrow shell script again
8. Ran df -h again to confirm that seat did, in fact, grow to 55GB
9. reboot

Voila! Healthy again!

/finis

Uncomfortable truths

I follow an "insider's" blog pretty religiously. The person that writes this particular spot on the internet is usually very insightful and relevant. Today, however, I read a posting entitled "Uncomfortable Truths..." that narrowed my viewpoint quite a bit.

I am not one to comment on others' blogs, really at all. Heck - I am not even sure anyone reads this one - maybe I'm just writing to be therapeutic. Today, however, I was compelled to write a response to the Uncomfortable Truths writing. I did so on his blog, and I'll expand on it here. My point isn't to "blow up" my e-friend's premise, but I am quite afraid that the person I have come to trust, admire and read as often as he cares to post is quite wrong in his musing.

You see, my e-friend wrote about how he made a career change, and that his new company's offerings are so much better than the rest of the IT industry's. That's fine - it's good to be proud and feel like you made a good career move. However, the posting illustrated to me how out of touch with the real world he may actually be.

The posting stated that one particular segment of IT had a much greater advantage than all of the others, and this elevated that segment above all others in importance. The problem with that statement is it simply isn't true. Let me see if I can illustrate my point:

At its' most fundamental, any application that multiple users access at any given time require some sort of  component stack similar to what you see here.

The application requires multiple layers of services, many of which can be contained within one delivery vehicle (server), many of which have multiple discrete layers of services. Of all of the different layers shown here, none really work without the other.

The author of the discussion topic that prompted my writing stated that his new company caters to one specific segment of this layered services model, and that made the people that ran the layer much more important and relevant.

My argument is this:

In this model, there are none more important in this equation then the picture at the top. That is the consumer of the services this entire service stack was created for.

In the model shown above, there is no data without data storage. There is no data organization without databases. There is no presentation of the data within the databases without application services. There is no data or application security without, well, security. And the data cannot move logically within this simple diagram, nor can the end user access it without networks.

The premise of the Uncomfortable Truth posting referenced above is that the database administrators are much more relevant, since they have an unfettered view of the data they are managing. In the real world, however, the database administrators had better NOT have a view into the data at all. They must understand how the data is organized and presented, for sure - but they have no business knowing what my personally identifiable information is (as an example).

Here's the uncomfortable truth: The model shown above is necessary. Whether it's all running on your laptop or running in a complicated multi tier infrastructure stack, every application you and I use works fundamentally the same way. Each part is interdependent on the other. The uncomfortable truth here is without the entire stack, the data is useless. The value chain associated with applications relies on all of the application components being there.

/finis

Waterfalls and Agility

When I think of waterfalls, I think of tranquility, nature, peace, soothing sounds. Until I start thinking of waterfall in the context of information management.

For those not familiar with the term, waterfall is most commonly associated with a specific method of writing software. I, personally, also think of waterfall as a specific method of deploying and managing IT infrastructure.

But first...

Let me start by explaining what the waterfall concept is. Waterfall, by definition is a methodical, iterative process that takes progressive steps in the implementation or development of a thing that IT delivers. For example, if a new application needs to be deployed, the waterfall process  if followed correctly looks something like this:

1. Business says "I need / want something"
2. IT develops the response and negotiates with the business on their requirements
3. Analysis is done to determine how much work is required to do #1 and #2
4. IT starts to design the application environments and starts to build infrastructure (both software and hardware)
5. As IT prepares for implementation, the software and hardware solution(s) are rigorously tested 
6. Once testing is complete and accepted, the thing that the business wants is handed over to be operated.

Once the process is complete, it typically starts over with features or functionality that was kicked out during the negotiation process that happens throughout this extensive cycle. Waterfall has been a very widely accepted practice by companies and IT organizations for a very long time.

One thing to realize is that this process can apply to many implementations across a wide variety of initiatives. This does not necessarily limit itself to IT and software development. It's most commonly thought of int he IT world as a "software development" process, but variants of this are used in "off the shelf" software deployments, server and infrastructure replacement and refresh, etc.

Silly kids

In 2007, the world changed. A bunch of "kids in Cupertino" changed the world by bringing the smartphone to the masses. It wasn't long before the masses started realizing the utility in these devices, and started replacing their everyday computers with them. Apps became commonplace. Social media exploded. What that translates to is that the waterfall process started to encumber the agility of business. A different approach was needed. A different way to build software, servers, storage, networks, "the cloud". All of these different taxonomies converged to threaten the relevance of organizations whose very existence was to build and support stuff that the business needs.

Agile methods aren't really new, but they definitely require a new way to think about everything. The software development process embraced these methods first, and aggressively. Soon after software development became "agile", however, software teams began to realize that the infrastructure types weren't building stuff fast enough to deploy the software they were cranking out.

Fundamentally, midsets and deployment methods had to change. Organizations couldn't afford to wait  any longer for rigorous testing cycles to ensure that the data center equipment was ready. Redundancy and disaster tolerance / recovery took too long to build into infrastructure. 

Image: boxesandarrows.com

As new methods were adopted (commonly known as "Agile Processes" - again not universally the same way - but fundamentally the same concepts.

With an Agile process in place, infrastructure had to adapt and be faster. Software releases under waterfall processes used to happen  monthly in highly aggressive release environments. With Agile, software releases could come HOURLY. 

The infrastructure towers started giving way to cloud based services. With cloud based services, building an environment simply meant clicking a few buttons, and you had an environment complete with representative databases, application services, deployment services and the appearance of some level of resilience.

There became no room for "waterfall infrastructure" in this new world. There simply wasn't enough time. Agile infrastructure was essential to success. EMC, VMware and Cisco created the VCE company in 2009 to address the problem with rapid deployment of servers, storage and network infrastructure in a tested, consistent way. VCE created white-papers, reference architectures, and Converged Systems called VBLOCKS that greatly increased the amount of time and decreased the complexity of building and deploying systems to support these great new applications. Companies that have embraced VBLOCKS enjoy faster time to business solutions, greater uptime, and huge customer satisfaction with their infrastructure.

These systems have enabled companies to quickly deploy infrastructure and applications while greatly reducing the risk and time to do so. 

These systems underpin some of the largest Agile software development implementations in the world. These systems also are the foundation of some of the largest applications ever deployed, regardless of development method.

These systems have enabled EMC and our Federation Partners to deliver a completely tested, certified and supported "data center in a box" to you in just 30 days!

The Point

Consider your smart device (phone, tablet, even PC) and the way you receive applications (or for you kids - apps). How much different is it today then even 5 years ago? How often do your apps update themselves "magically" without you ever even knowing it happened? Probably more than you might think. What was the last time you used physical media to install anything?

The point is this dear reader: If you're in IT infrastructure, learn everything you can about Agile. Know what is driving this significant transformation in the business you support. Understand why the development teams need this capability. This will keep you off of the dust heap of technical irrelevance.

Get briefed on what VCE converged infrastructure can do for your organization - you'll be amazed at how liberating it is to not have to turn screwdrivers in your data centers for weeks. Think of all of the valuable skills you can apply by not having to "rack and stack". Consider how much easier it is to make one phone call for help with your infrastructure instead of 3 or 4.

Get smart on Agile infrastructure and methods. It will pay off. I promise. 

/finis

Transformation Tuesday

The pendulum may be one of the oldest technology metaphors that exists. The pendulum swings from left to right, and as long as the weights are set or there's power to move it, the pendulum never stops. Technology, it is said swings like a pendulum, consistently swinging from left - to right - back to left again.

Once upon a time, and to the FAR FAR left, there was a big giant computer in some big room with beefy armed guards making sure no one got in. Mysterious things happened in that room, and somehow that mystery made it to our terminals so that we could enter data. That data made the companies we worked for run somehow, but we never really gave it much thought.

Transformation happens
Then came Provo, Utah. And it begat Novell. Novell was pretty cool - you could take stuff that only ran on those huge, expensive mystery machines and run them on a PC. Clever folks even figured out how to create large groups of terminals and using a very simple diskette with a driver could connect to all kinds of magic.

Novell dominated the "server" market for quite a while until the desktop came to the server, and Windows NT was born. The pendulum swung HARD to the right. These desktop computers became industrialized and millions of them made their way into the room that once contained a single monolithic computer. Computers found their way to every desk in every office in every company around the world. People starting buying computers for home. Companies started sending software to consumers in the mail so they could join the online revolution. They started chatting to each other across great distances using telephones to connect to the "internets" (or some such fanciness).  You probably know the rest so I'll skip it, but that brings us to today.

Clouds on the horizon

The pendulum is swinging to the left again, only this time, instead of a single massive computer delivering terminal based services, we're all a part of the largest consolidation of compute services ever. This consolidation isn't just "a computer" - this consolidation is massive buildings full of computers, storage, network - all orchestrated to act as one huge pool of resources, serving many masters and many consumers. This is commonly called "cloud" computing.

The cloud, as an internet meme so cleverly describes it is "just someone else's computer". But truthfully, the advent of using someone else's computer to do work isn't new at all. It's been around since the mystery machines. We've been effectively using "someone else's computer" all along. We've all been using compute, storage, network capacity since the beginning of the modern computer age - and probably didn't know it. Think about this though: Cloud computing isn't a computer at all. Cloud is really a massive change in how we consume the huge compute capacity and new services that are enabled by these massive buildings full of carefully orchestrated "workload engines". When was the last time you thought about email? Not "read" email - but thought about what's behind your internet.com email address? It's someone else's computer, storage, network - all acting on your behalf (well - most of us but we'll leave the political commentary for someone else to tackle).

Swipe a credit card - someone else's computer. Deposit your paycheck - someone else's computer.
Turn your discarded coins into a coupon for cash - someone else's computer. Buy a lottery ticket - someone else's computer. Pay $243 for a cup of carefully brewed 5 shot grande latte with a light dusting of Madagascar fair-trade vanilla and a whisper of cinnamon poured over 1/2 skim, 1/2 whole milk steamed to a perfect 172 degrees - someone else's computer.

Get the point? Some of these things are so commonplace that we don't even consider them to be "computing" services. But these days, every facet of our lives is affected by a computer - someone else's computer.

The funny thing about pendulums. They never stop in the middle. If they do, they cease to perform the function they were put in place to perform.

The point
So, I'll get to the point. Transformation in the use of someone else's computer is happening at the speed of life. In fact, in some cases, it's happening faster. Did you know that 52% of the Fortune 500 company names from 2000 don't exist anymore? Still think transformation isn't happening?

Those who refuse to accept this transformation aren't doomed to the scrap heap of . They're already there - they just don't know it. 

My point is simple. Transformation means learning something you're not necessarily comfortable with. Transformation is a personal journey. That will expand beyond you to your peers, making it a workgroup journey. And so on... and so on... What you'll find is that transformation is contagious. Catch it - before you can't.

Isn't that the point of transformation?

Comments welcome.

/finis

Feedback on feedback

In my position at work, I'm constantly providing and receiving feedback. In fact, it's probably safe to say I am, like you, constantly in a feedback loop of some sort.

I recently attended a conference on leadership and one of the topics I found completely insightful was on feedback. The topic was presented in a way I had never even considered before.

In the context of leadership, feedback is omnipresent. It's everywhere. When an individual interacts with another, if you're paying attention, you'll both provide and receive feedback. We're creatures that leverage feedback in almost every aspect of life.

Think about a dog. If, while I'm writing this post, I blurt out "Do you want a treat?" Here's what will happen:

Meet Macie

That simple question will be met with ears up, tail going 800MPH, and ultimately a dog that will follow me to where the treats are - until one is delivered.

The dog doesn't know she's providing feedback. She doesn't know that in response to her feedback, people will comment on how incredibly cute she is and what an amazing little puppy she is. What she knows is that she heard the sound "treat" and her conditioned response to that sound is... physical feedback.

It's everywhere.

Feedback is everywhere, so I began thinking how I can apply the lessons I learned from this talk track in my life. The speaker had some really interesting points that I'll attempt to convey here:

1. Be aware when you're receiving feedback. 
2. In the feedback loop, it's the receiver of the feedback that's in charge. It's up the receiver to decide what he or she does with the feedback they've received. 
3. Be constructive. There is absolutely nothing whatsoever to be gained by feedback that is always critical. If critical feedback is warranted, offer a solution - don't just whine.
4. Here's an interesting one: If you, as the receiver of feedback ignore it, you've still acted on it. 
5. Last, but certainly not the least of these: Consider the feedback you've received (or are giving). Are you receiving (or giving) feedback to someone or about something someone did?

That last one is a big one. Think about the last time you provided feedback on a person. Was it to that person, or was it about that person to someone else? If it was the latter - be honest - was it gossip?

There are a lot of things in this post that I relate to directly. It's definitely a growth area for me, and I'm committed to it. It's already helped me - and I hope it helps you.

Feedback welcome.

/finis

A resurgence of sorts

I'll be resurrecting this blogging effort in an attempt to convey my thoughts on the world around me.
The frequency of my posts will be based on my ability and time. I won't post just to say something (or is that what this post is?) - or maybe I will :)

I'm also going to start tagging so that you, dear reader, can select those that interest you, and those that don't.

One more thing: I'm going to try and encourage interaction. I have a fairly diverse collection of friends, colleagues and acquaintances spread throughout the social-sphere (did I just create a term?) so I'll link to these various social outlets to try and encourage the conversation.

Let me know if you've read this. Or blogger analytics will - either way :)

Building Barriers

It's been said that the more man improves on the mousetrap, the better the mouse becomes. Or the better mouse gets built. Or something like that.

I read this morning a blog post that discusses the efforts that NYC is undertaking to protect itself from the next Sandy. It's a multi-billion dollar effort and it's admirable to be sure. They're building a 16 foot tall barrier in an effort to curb rising storm waters. Pretty cool stuff - unless - until -  there's a 17 foot storm surge. That'll never happen, right?

I've seen and heard plenty of people in IT take this same approach. Sure. For the 10 foot surge, everything is fine. It's that 17 footer that will get you - every time. 

Let's say there's an organizational leader named Joe. Joe's operating style is to manage up, and really not expose any strategic reasoning to his employees. This is ok for some, but for most of the advanced team members he's responsible for, they thrive on knowing that what they do on a daily basis matters and is contributing to some higher purpose than simply killing runaway processes or connecting new stuff to infrastructure.

Joe has built a mental 16 foot barrier, hoping to keep the noise from his organization quieter than the noise from other organizations - even within the same larger group. His motto is "Let's suck less than everyone else, and we'll be ok" or put another way "it's ok if someone else fails". I once worked with (notice not for - even though I reported to him) an extraordinary leader whose number one statement was "Never - EVER - let anyone else fail".  I've tried to adopt that philosophy in my life, and it really is easier than you might think.

Let's examine for a moment the results of Joe's leadership style:

1. This style will always lead to complacency. Contrary to a style of continuous improvement, this style encourages an attitude of "let's just keep the lights on" - and that's the most dangerous of all attitudes in IT.
2. Joe's attitude towards his peer organizations will ultimately breed resentment both within and without his group.
3. The best and brightest people within Joe's organization will soon grow weary of a stale and ordinary environment like this, and will leave.
4. Ultimately, this attitude will result in a failure to perform necessary ongoing maintenance, will lead to failures within infrastructure, and will actually work to have an inverse affect to what Joe was looking for in the first place.

It's my opinion (and opposing opinions are absolutely welcome) that employees are satisfied, even energized when their leader:

1. Provides a level of importance to even everyday menial tasks such that employees understand that they are contributing to something real. 
2. Helps them understand that there is a business impact to what they do. It really doesn't matter WHAT the function of an individual is - there is ALWAYS linkage between what they / you / we do and largest company goals.
3. Helps drive their organization to continuous improvement. When leaders adopt a "suck less" approach, employees will adopt that approach as well. When that happens, it's time to go home kids - it leads to ruin - every time.

Joe is a fictional character, but how many times within any kind of organizational leadership have you seen someone with this attitude? How do you overcome such a challenging leadership environment?

Joe isn't a real person - I'm not trying to single out anyone here, but Joe DOES exist. In every organization, there is a Joe. My challenge to anyone that leads people - don't be a Joe.