Seeing the world clearly

This is one of a short series of self-reflective posts I wrote in January 2014.

One of my core principles is to continuously increase the clarity with which I see the world.

This is a top-level principle, and so I have a bunch of values and behaviours which flow from that. One is truth over harmony.

I have seen this value misused. A bitter person misused it to excuse counter-productive behaviour, and an idealist misappropriated it to disguise their unwillingness to accept reality as it is.

Another value I have is for clarity around facts and observations. Particularly I want:

  • people to be specific about the source and validity of a claim, and
  • observations to be described distinctly from conclusions about observation.

For example, “Apache crashed” is a conclusion and “http 80 is not responding” is the observation. Other causes could be security groups or internet connectivity.

In a cool way, these values overlap with my bias to action. So when solving a complex problem, if I find things going in circles, I will write a clear problem statement. How to think clearly about problems has been studied and codified by systems like Kepner Tregoe. I think all good services organisations should use a consistent problem solving method and be sure all staff are trained in it; you cannot assume a University degree will give a person this skill.

Problem statements can be quite simple, though. You can just include:

  • the observed issue
  • the desired behaviour
  • a list of possible solutions
Posted in solution sales | Leave a comment

Driven to achieve

This is one of a short series of self-reflective posts I wrote in January 2014.

I’m a fan of the Strengths model. On both of the times I have done the self-assessment, two of my top five strengths are:

  • Achiever
  • Focus

This is very true of me.
The ‘so what’ of the combination might not be immediately obvious unless you have those same two compulsions, or have a significant other with them, and have read about strengths psychology.

Basically I’m driven to achieve towards goals.
I need to achieve things. It gives me a single-mindedness which my wife says can be impersonal, and can appear selfish. So at home, I have to moderate myself :)

For example, right now I’m writing about my leadership style. I know I need to be clear in my own mind about how I operate as a leader, and as a manager, and be able to outline it in an interview next week.

I was just making my wife and I a cup of tea before coming back to the computer to keep thinking about my leadership style. Laura knew I was going to be thinking and writing all day. As I was making tea, she wanted to tell me about an interesting conversation she’d had with a lady about her religion and about her self-directed conversion to Islam at about age 17, whilst living in the Australian outback. Sounds interesting eh. I listened for a while before saying, “sorry hon, it’s distracting me from what’s on my mind right now”. That’s when she smiled and said “that’s one of your strengths”.

So here I am writing about it now, and will talk to her more later about her day with the kids.

The Focus strength is about goal-setting. Once I emotionally set a firm goal in my mind, it’s very hard for me to unwrench from it. In fact, I’ve learned to manage myself in this regard and only set goals when I’m sure I really want to achieve them. This means I tend not to idly discuss possible goals around my work or home life. I will either do them, or not. I think of Yoda: there is no try.

This is because somehow, the way my mind works, is that goals are deeply motivating. I like to-do lists too, to track more atomic goals, and I’m a completer-finisher in that I don’t like things dangling half-done.

The Achiever strength is about needing to get things done. A good example is that I find holidays a bit stressful if they go on for too long. I like to read a book or two, or spend time thinking about a goal I have for myself, or learning something new.

Also I am frustrated by fruitless or pointless tasks because they conflict with my need for achievement. Generally this is a good thing, and it might even trigger another one of my core behaviours around wanting to properly fix systems.

As a leader these strengths translate to wanting the organisation to be productive. For example:

  • I notice waste or inefficient processes and want them fixed.
  • I set sub-goals which are achievable, but not easily, and which are consistent with a greater goal.
  • I want people to be productive, to know what their job is, to have the tools to do it, and I will get things out of their way so they can achieve.
  • I want projects or changes completed properly so as to avoid creating re-work and to make a sustained difference.
Posted in solution sales | Leave a comment

Seeks root cause

This is one of a short series of self-reflective posts I wrote in January 2014.

Systems thinking

I don’t know whether I became a systems thinker because I read about it in the Fifth Discpline fifteen years ago, or whether I was already a systems thinker but didn’t know the label. Either way, I remember how it gave me a visual method to expose a system, and the diagnostic power of its archetypes.

I also remember in about 1994 being trained as an Apple technician, in the days when we did component-level repair within a Mac, and the trainer using sticky-tape to break a circuit to teach isolation-testing. Of course, he didn’t tell us that, we had to find the fault by reducing the problem scope and gradually isolating the cause of the video flicker. This is a linear form of problem, though, and not a system. Companies are complicated systems.

Whatever the genealogy, I’m a systems thinker and I seek root cause when dealing with problems. In systems thinking, root cause is not the proximate cause, but the deeper systemic issues which gave rise to the observed problem. This author uses the popular iceberg analogy to help explain systems thinking, and I wrote about it as a sales perspective a few years ago.

When effecting change in an organisation it is necessary to find points of leverage within the system that manifested the issue you want to change. This author describes that analysis process well. Doing this requires that you sufficiently understand the issue such that you can improve the situation with minimal unintended consequences, and is generally the opposite of a quick fix.

I like fixing things

One of my core behaviours is that I like to fix things, and to leave them sustainably fixed. Here’s an example of how it presents:

Recently RightScale developed a new vSphere integration technology and made it available in closed beta to our clients. I wanted sales people around the company to understand it and sell it, because I believed it hadsignificant potential. Because it was such new tech there was not any training material for sales people or client-facing content to explain it. I was also concerned about whether the developer-beta tester feedback process would ensure the product had capability which could easily fit into an enterprise’s technology and process environment.

So, I learned about how the RightScale appliance worked, which required learning more about how VMware worked first (and that included their pricing structure), and being able to explain how the vSphere API is different to a cloud API. I found a model to explain our product development cycle, and what lifecycle stage it was in, and put all this content onto an internal wiki page. I put together and delivered sales training which distilled the ‘so what’ of the innovation and explained how it fits in architecturally.

Across a few domains I wanted to be sure of a sustainable momentum:

  • developer-beta tester feedback,
  • sales force engagement into the client base,
  • internal knowledge sharing about the current and future state.

I knew that simply having a product would not translate to sales unless a number of systems were influenced, and that wasn’t being done, so I fixed it.

Posted in observations | Leave a comment

On leadership and the Ghost platform

I wanted to spend some time reflecting on my leadership behaviours and values.

I also wanted to try this new blogging platform called Ghost.

So I combined the two. Earlier today I spun up server, configured it (required vi, which I can never remember how to use), created a subdomain and pointed it to the server using CloudFlare (which is instant), and then got into writing!

The pieces are self-reflective to help clarify my thinking, but I tried to write them with an audience in mind, so hopefully you’ll find it thought-provoking too.

I like Ghost. It focuses on writing and helps put you in a state of flow. I also updated the theme to include the Disqus comment system using this instruction. Then made sure it was using Forever to stay up and did a restart.

Experiment successful, nearly a year later I decided to decommission the Ghost server and so I have merged its independent content back into this WordPress site.

Posted in observations | Leave a comment

How cloud-oriented is the app?

RightScale lets you easily deploy an application to a cloud provider like AWS or Rackspace. We do this by abstracting your server infrastructure design to a layer above that cloud provider. Consequently, I often have conversations about whether an existing application is a suitable candidate for the cloud. The less common question, but of great significance, is whether an application can really exploit the capabilities of the cloud.

I recently developed a little framework which helps to explain some of the dimensions which effect how well an application can go beyond a forklifted application towards one which is architected for the cloud.

What’s a cloud-oriented app?

It’s fairly well understood amongst web-based businesses who use the cloud, that you have to design for failure. You have to assume any element of your infrastructure or application stack could fail. Perhaps Netflix made this most famous with their chaos monkeys who deliberately destroy service elements, so Netflix could test what happened and make sure the system was resilient. At reInvent last year, it was thematic in key presentations from AWS. This is no secret.

Applications which are designed with a service-oriented architecture should gracefully degrade if a service on which it depends are no longer available. A simple example is if an application presents a menu choice, and that menu is derived from a database, but that database is not there any longer – it’s failed for whatever reason – the application needs to keep working anyhow.

In traditional enterprise data centres, the design assumption applications can make is that the hardware environment will be available 99.5% of the time or more. Core systems will expect 99.9%, and so on. The application at the top assumes all its layers underneath are working, and generally does not fail gracefully.

Cloud applications dismiss that availability assumption, and not because the cloud is necessarily less reliable, but because it makes for a more resilient and scalable application in any case, and because the cloud is a distributed system.

Cloud apps can scale horizontally (more servers), instead of vertically (CPU). Doing this requires the constituent parts are able to scale that way.

What are some non-cloudy ways?

So, some applications expect to find on a local file system, or store sessions in a low-throughput database. If the app is doing that, it’s not very cloud-oriented. That’s the “data location: actual server” column of this diagram.

I itemised a few technical elements which can be done in a cloudy way, or not:

  • user data,
  • session management,
  • infrastructure config and
  • application configuration.

Some web-based applications like Drupal, phpBB and Concrete CMS store their application configuration and user data in ways is not compatible with horizontal scalability. They need some adaption to use GlusterFS, for example, as a distributed file system, and do not have public reference architectures for putting them into a horizontally-scaling environment.

I’ve mapped out those elements against the continuum from least to the most cloud-oriented method (the solutions I’ve listed are not exhaustive).

how cloud oriented is the app?

For horizontal scaling, ideally the application needs to be installed unattended in a scripted fashion. (So, you can’t do the next/next wizard of phpBB, for example). This in turn means the configuration of the application needs to be defined and stored in a database or file which is accessible to the installer script, and then you have questions around version control and persistence of that configuration information.

People and process change management also needs to be considered: if the user edits a configuration on a local file, but doesn’t push that configuration back to the SVN, it will not persist when the server is rebuilt next time.

Some apps go easily to the cloud

Some applications will adapt well to a horizontally-scaling cloud environment, others will not.

Those which do not scale horizontally may still be suitable for deployment to cloud, but in a forklifted fashion. You’d retire the existing server and move the application to an equivalent cloud server, which is most likely cheaper. The application may not like to be turned off at night to save you money. If it can, though, then your financial savings increase markedly. Turning off servers is one key to unlocking cloud economics. Scaling horizontally is another key.

In either case, it’s a lot more intellectually fulfilling and interesting that staying with the status quo.

Posted in geek | 3 Comments

Two worlds of cloud

Increasingly it’s clear to me that there are two worlds of cloud users, the populations of which often do not realise they are world’s apart. The first is inhabited by traditional enterprise IT users. Extending the analogy, it has more terra firma than clouds.

The second has a population of cloud-first companies who use cloud-era technologies. They largely do not use Windows, SQL Server, WebSphere or similar packaged software, and instead their first choice is a SaaS or Open Source equivalent like Debian, MariaDB, Couchbase, django or a plethora of technologies and languages.

The world of enterprise IT has a density of applications, systems, hardware and processes which create a huge gravitational force towards status quo. Change is costly and risky. Interestingly, the perspective of enterprise IT folk actually distorts how clearly they can see what cloud is, and can offer. More on that later.

New cloud technologists are often fairly crap at risk management and change control until they’ve either hit some kind of scale (which brings the need for change control and rigour) or failed in some way. There’s often a religious rejection of anything that sounds like waterfall method (like planning), and a sprint to the next scrum instead.

I could have expressed this idea as a continuum with enterprise IT represented by banking at the most extreme on one end, and a seed-funded fledging internet startup with a few clients at the other end. One has great traceability and stability, the other has great spontaneity and agility.

James Staten from Forrester used a nice diagram which expressed how enterprise IT guys see cloud differently to cloud-era folk. The essential difference is that enterprise guys see cloud as the next logical evolution of virtualisation, whereas cloud developers see it as a programmable service. He comments on how this leads to private cloud implementations failing because the enterprise guys make it robust and highly change-controlled, whereas the developers just want an API that abstracts all those details away so they can launch a server in 5 minutes.

Google the paper “Rise of the new cloud admin” if you’re not a client, and read it. It’s absolutely spot-on awesome.

Result is, in the real world, that an enterprise decision maker will look at his sunk investment in a VBlock environment and ask me if we can make it into a cloud. Sure. But that question only gets you to first base.

You can run a private cloud on enterprise-grade hardware, but you don’t have to of course. Let’s assume you do though, because you want more HA on the private cloud, because that’s the norm. Then the usual first step is to make it easier for test and dev workloads — so your application teams can launch a base server really easily to test a new version of an application. Making that happen with a self-service portal isn’t hard either.

Here’s the catch though. Enterprise users are then putting traditional packaged applications into a private cloud, managed by ITIL, subject to change control and normal InfoSec policies. So you get a non-agile result in some dimensions. The dimension you have made cloudy is provisioning the hardware and operating system layers of the virtual machine, using a self-service portal.

Often, the installation of that enterprise application is not automated. If it is, it’s not multi-cloud portable, nor version-controlled so it can be elegantly moved through a lifecycle of test, staging and production.

The difference in the cloud world is that the application would have been defined and installed using configuration scripting. The application gets considered first, the hardware and operating system are almost assumed.

The interesting challenge for enterprises is to simultaneously:

  • look for enterprise applications they can move to the cloud,
  • identify applications they can migrate to cloud-era technologies, particularly considering NoSQL or graph databases, or cloud-friendly horizontally-scaling frameworks like django
  • identify applications or systems where configuration-based infrastructure definition is possible (RightScale uses Puppet or Chef), instead of virtual machine images which are managed under change control.
Posted in observations | Leave a comment

Notes from keynote at Cloud Inspire, Seoul

I’m delivering the keynote talk at SK Telecom’s Cloud Inspire event in Seoul, and in preparing my talk about hybrid clouds I reviewed many sources. For those wanting more detail, I have put together some notes below.

Research on cloud adoption, applications and cloud developers:

  • RightScale Cloud Survey also as of Jun-2012
  • Everest, “Enterprise Cloud Adoption Survey 2013” cited in Gigaom article
  • Forrsights Developer Survey, Q1 2013
  • Forrester Global Cloud Developer Online Survey, Q3 2012
  • Forrester, November 2012 “Don’t Move Your Apps To The Cloud”

Security and risk

User stories:

Hybrid cloud architecture:

Agility 

Reasons for hybrid:

 

Posted in observations | Leave a comment