© Giri Fox for Giri Fox, 2013. | Permalink

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

• AWS CloudHSM for security
• Security monitoring in the cloud
• Cloud risk decision framework

User stories:

• Trader Media Group (UK car and vehicle sales)
• Coupa (procurement management)
• Intercontinental Hotel Group
• Zynga zCloud and article

Hybrid cloud architecture:

• Cloud bursting challenges including hybrid
• Keep your options open by John Rhoton

Agility 

• On agile approach for enterprise
• On software bringing agility

Reasons for hybrid:

• On abandonment of video
• www.cedexis.com
• Data centres worldwide infographic

© Giri Fox for Giri Fox, 2013. | Permalink

RedMonk recently wrote an article surveying the various data points which go to this issue, including a few I’ll call out:

• Rackspace are joining Open Compute, the new standard for servers needing cloud-scale economics
• Quanta will one day sell directly to enterprises, say for for private cloud

The Open Compute standard drives down manufacturing costs by removing vanity and wasteful items like logos, flashy lights, DVD drives and serial ports. Manufacturers like Quanta (based in Taiwan) then build to your specification.

The standard also considers operational effectiveness, such as cooling and space saving, for example, the Open Rack width lets you fit more 3.5″ HDD side by side than the traditional rack.

It’s clever because it’s so obvious, and it’s so disruptive.

So how about the software layers?

At one layer of the software stack, we have open source hypervisors KVM and Xen which compete with VMware’s ESX.

Technically I could say there’s competition at the cloud orchestration layer with OpenStack and CloudStack, but in the context of disrupting existing markets, I think it’s more useful to consider them as platforms which allow the creation of alternative ecosystems to that of AWS. Fascinating, really.

Recently IBM and earlier VMware throwing their weight in the ring with OpenStack will help bolster the engineering depth in OpenStack, along with the hundreds of existing contributors. RightScale is also a corporate sponsor.

I don’t believe any single cloud infrastructure provider will monopolise, but that we will see a future of multiple clouds interoperating. Since there is no singular interchange standard, this is going to be an interesting process.

Thanks to RedMonk, here’s the RedMonk article.

© Giri Fox for Giri Fox, 2013. | Permalink

Noisy Neighbours is the current term to describe an age-old phenomena when many users share a medium, in this case with cloud computing it’s sharing CPU, storage and networking. In IP networking, one solution is Quality of Service (QoS) which helps prioritise network traffic so the most important packets get through whilst others get shaped. The shaped packets could describe the bossy packets as being noisy neighbours.

Other methods to solve this contest for shared network resources include Weighted Random Early Detection and Weighted Fair Queuing.

Operating systems for mainframes had to solve it too, with various methods to divide the monolith between its various hosted applications.

In cloud computing and virtualisation in a traditional data centres too, noisy neighbours are a problem that effect the consistency of disk and network throughput and CPU performance that an application will see. Applications will still work, but for example if they need to finish a batch job within a certain time window it may be hard to predict how many hours it will take, or users of a web-based application may observe varied response times.

In cloud computing, the noisy neighbour issues get addressed by the provider at various technical layers (hypervisor for example), but also at commercial layers with some cloud providers offering opt-in paid services for those users who require higher throughput or greater consistency on disk performance, for example AWS Provisioned IOPS.

It also gets addressed by the user, who can deploy the granular nature of cloud computing as a workaround to itself. For batch workloads with dozens of servers, some users buy more servers than needed, run some speed tests, and discard the servers that are under-performing. RightScale clients sometimes stripe their storage across multiple block storage volumes to normalise performance. Many RightScale clients choose which cloud best suits their application workload and could try Rackspace, AWS, Google Compute Engine, Azure or private clouds using OpenStack or CloudStack.

© Giri Fox for Giri Fox, 2013. | Permalink

This provides a view of the shift away from owner-operator enterprise IT and towards buying compute as a service through Amazon or other IaaS providers.

It’s fair to assume that Amazon and Facebook are in that top eight either directly or by proxy with their manufacturer (Quanta is one such). The article also mentions Facebook’s open compute project, a strategy to reduce the acquisition and ownership costs of the hardware, as they cool more effectively, too.

IDC and fellow analysts don’t have solid data on how much of the total addressable server market is taken by this new breed of buyer. Wired cleverly called it the “server world’s Bermuda triangle” because of analyst’s poor visibility of spending in that zone.

The economic factors which favour IaaS providers AWS and Google Compute Engine:

• They have equal or better buying power to IBM, Dell and HP
• They spend less on energy. AWS and Google are run in data centres with energy efficiency (“PUE”) of about 1.2; about 50% lower than most enterprise data centres which are around 2 to 2.4. Facebook’s Oregon DC runs at 1.11. In Australia, the NSW Whole of Government new data centre is likely to have PUE of 1.29
• Their scale plus automation systems drive down operational costs to a greater degree than an enterprise IT buyer can easily achieve.

At this scale, with the prior stalwarts of server sales losing ground to providers who don’t resell the chips but instead sell a service, the inexorable domination of cloud computing is obvious.

In 2008 Nicholas Carr gave his now-famous analogy in the Big Switch, that IT is leaving the company data centres, and shifting to cloud computing, mirroring the shift that electricity generation had from local steam-generation to the newly invented power grid.

Part of the reason enterprises are moving slowly to cloud is their (necessary) dependence on existing stable applications. That’s fair enough. All of my clients have systems which have been designed within the concept of traditional enterprise IT.

The next advance toward cloud comes from changes to the buying and architectural decisions of the IT organisation. It is to think of compute as a service, and to move to a service oriented architecture. For example, to design apps with the assumption of hardware will fail underneath it, as opposed to the current state where the apps can trust the hardware to be available > 99.9x% of the time.

Netflix put this eloquently in a zdnet article. In explaining the philosophical design shift, their cloud architect said:

The typical environment you have for developers is this image that they can write code that works on a perfect machine that will always work, and operations will figure out how to create this perfect machine for them. That’s the traditional dev-ops, developer versus operations contract.

Instead he says the way Netflix now do it is different. This is the point I’m making. Netflix:

We don’t keep track of dependencies. We let every individual developer keep track of what they have to do. It’s your own responsibility to understand what the dependencies are in terms of consuming and providing [services].

We’ve built a decoupled system where every service is capable of withstanding the failure of every service it depends on.

Everyone is sitting in the middle of a bunch of supplier and consumer relationships and every team is responsible for knowing what those relationships are and managing them. It’s completely devolved — we don’t have any centralised control. We can’t provide an architecture diagram, it has too many boxes and arrows. There are literally hundreds of services running.

A longer treatise on service oriented design is in Steve Yegge’s accidentally published rant about how well Amazon get it (and how Google don’t, but that’s now to be tested in Google Compute Engine). They started the transformation to a service-oriented architecture at Amazon in about 2002.

It was about 25 years ago that I started programming, and about 15 years ago I stopped. I never had to develop in this paradigm (but I keep wanting to try). I haven’t led an IT organisation through this scale of change. So I’m not naively saying this change is easy. Steve’s post gives some story to the huge difficulty of it.

I don’t think it’d be easy to change a large organisation’s IT from a traditional mindset to one that fully exploits cloud computing, but damn the rewards and journey would be awesome.

© Giri Fox for Giri Fox, 2012. | Permalink

Some background: I’m not an engineer, I’m a solution sales guy with a geek orientation. I have mostly webmaster technical skills. To be clear: I don’t know what /etc means in Linux, and when I tried learning Ruby recently I realised that having not coded for over 15 years definitely made me a novice again. But earlier this year I migrated my cloud server with multiple cPanel accounts to a shared host and used cloudflare to minimise downtime. My day job is in sales: major account management with Cisco Services.

However, by the end of this little project, I realised that someone much less technical than me could have done this. At the same time, someone more technical than me would really maximise the potential and be able to use RightScale for its true purpose. I barely touched its surface.

With a nod to RackSpace’s announcement of their Sydney data centre opening later this year, I chose to create an account with them. I previously had used a cloud server with Liquidweb.

Creating a RightScale account is much like you’d expect. No credit card required. I’m obviously going to use a free account for this test. The process steered me quite easily to the quick start guide.

In Rackspace, as an aside, I was annoyed whilst setting up secret Q&A so I could be verified, I repeatedly got a error about an invalid password. On third attempt, it was accepted. No apostrophes accepted was one of the problems. Also I was reminded of a pet hate, which is security question choices that include “your favourite” item x or y. My favourite things change over time, if I have any, so I’ve always thought these are the stupidest options to suggest because challenge questions should have an unequivocal answer. (I later worked that in fact Rackspace was asking me to reset my secret Q&A each time. Some UI problem.)

Rackspace gave me a call to verify my account, so I was confirmed to be activated.

In RightScale then, the first step once you have an account with a cloud provider is to add it so RightScale can act on your behalf . I took the API key for my Rackspace account and stuck it into the RightScale dashboard, but I was getting an error of “Too many requests…”. After a few tests this error disappeared without me being able to isolate root cause. Pretty odd.

So at this point, I have a RightScale account and a Rackspace account. No servers created on Rackspace, but I’m ready to do so. Next up, creating servers.

If you’ve ever bought a shared host, VPS or linode server, you’d know how easy it is to buy a webserver with (or without) cPanel.

The difference when using RightScale is that instead of directly creating a server within the IaaS provider’s control panel, I do it through Rightscale – like a remote management interface – using one of the ServerTemplates provided by RightScale (or of my own devising if I had the skills).

This is a powerful abstraction. The server deployment workflow looks like this:

The RightScale marketplace of ServerTemplates is comprehensive too – including one for a high availability MySQL 5.5 master/slave server, another is provided by IBM for a DB2 Express (their free-edition) and there are a few memcache templates too. Because the build process is scripted, you can create one that’d function identically on a Rackspace or an AWS server, or others if the template supports it. This in turn means you can more easily deploy new capacity across multiple cloud providers, and that lets you design around zone outages.

Anyhow, RightScale thoughtfully provide a basic template for LAMP server with WordPress, and the quick start guide covers that too. So I go and add it.

Choosing that ServerTemplate, and a few steps later the server is ready within my RightScale account.

But it’s not live on the Rackspace servers yet. I need to choose to do that, when I’m ready, with Launch.

After this, I saw a scary-looking page with dozens of pre-completed fields. I check the quick start at this point, wondering if I had to customise it. This stage is where you could make the server unique and provide any overrides on settings like password or database prefix. It’s defined in my template to inherit and scripted such that I don’t have to change things; this template is designed for instructional purposes and not production.

Then, RightScale starts the creation process on Rackspace on my behalf. I get some status progress information in RightScale, with the ‘events’ sidebar being a bit hard to decipher due to lack of familiarity.

Within Rackspace, I can see it’s been created.

Then, a few minutes later, I’m given a public IPv4 address, click it, and I can see the WordPress registration screen. I could SSH into the server too. My server is running.

If I’d had the need, I could have set up a separate MySQL server, a memcache server and WordPress with W3 Total Cache installed, or something like that. That’s really what RightScale is designed for – managing multiple IaaS servers, including financial reporting on their usage.

Creating those servers through RightScale, using templates, would give me the capability to migrate the lot to other cloud providers, or increase the availability by serving from more than one IaaS provider.

This really is such a neat system.

© Giri Fox for Giri Fox, 2012. | Permalink

What is the Agile Philosophy?

As described in the Agile Manifesto, the Agile Philosophy is characterized by the following values:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan.

I thought it’d be interesting to consider how deal pursuits could benefit from Agile.

Which ideas from Agile could work in Major Deal Pursuits?

Evidently amongst these core principles, there are ideas that have a degree of synergy with Major Deal Pursuits.

Within the remit of Major Deal Pursuits there is an element of business creation and business model generation. It makes sense to apply Agile Philosophy and ideas from Lean Startup, since a more tailored solution is likely to emerge when there is less waste and more scope for feedback from the client. In turn, this is more likely to result in a deal being sealed and is especially the case for solutions that include large-scale software development, design and construction of datacentres or outsourcing entire network operations.

Integrating Agile as a client feedback loop would obviously lead to overall improvements compared to traditional processes such as Waterfall. Certainly Agile would be a useful way to fix any issues prior to implementation in a similar way that RUP advocates testing after small increments of development. Certainly if a solution doesn’t work in terms of cost, risk or compliance it should be changed rapidly. Agile seems to delight in scrapping a solution in order to respond to change and this is an attitude that bid teams could consider.

Which Agile ideas could prove problematic?

There are of course elements that do not fit so well with Major Deal Pursuits.

Agile does not fit well with the fact that Pursuit Leaders work to strict deadlines. Pursuit Leaders like to gauge interest quickly and so there is the potential for customer interaction to adversely affect the familiar and expected deal-making process. Whereas the Agile Philosophy states a preference for the shorter timescale, for the Pursuit Leader, it is a necessity.

Similarly, during the negotiation phase you need to demonstrate that your solution is worthy of, say, a $100M+ investment. Over-reliance on feedback could undermine the perceived robustness of a solution and your firm’s expert authority become lessened. Indeed, for a Pursuit Leader, the focus is on agreeing a large contract and this contradicts one of the principal values of the Agile Philosophy; customer collaboration over contract negotiation.

Thull’s diagnostic selling method outlined in “Mastering the Complex Sale” however could very well benefit from taking an Agile view of the method, as its method does not presume a time-bound pursuit window.

In practical terms, there are also tight restrictions on how much information can be shared about the solution design and it could be harmful for the Pursuit Leader to be seen as reluctant to share information with individuals or unable to explain why certain ideas cannot be implemented. It may be worth looking at ideas around “minimum viable audience” and creating a scalable proposition that could be presented to the client. Interesting, but would only work if you were in a position of control during the negotiation, rather than being in a position of competition with others.

How would a Major Deal Pursuit Leader go about implementing Agile?

Let us turn our attention to the possibility of practical implementation of Agile in Major Deal Pursuits.

The Pursuit Leader would have to consider timing as a primary concern, namely, at what point during the process would you look to implement Agile? Do you look to instill Agile as an over-riding culture for the pursuit or should there be specific checkpoints for Agile? Beyond that, how exactly do you build agility into the process? The issue of personnel is another important consideration here. Is Agile the responsibility of the whole team or does it make more sense to assign Agile relationship building to a particular team member? If so, do you appoint the role based on character and soft skills or on status and position within the bid team?

What do we need to consider most closely when thinking about Agile Philosophy within the context of Major Deal Pursuits?

The main factors to consider when potentially assimilating Agile into Major Deal Pursuits can be distilled into these five criteria:

• Impact on Negotiation
• Benefits for Solution Design
• Adverse Effects on Deadlines
• How to Harness the Potential of Collaboration
• Implementation and Personnel

As we have seen, some elements of Agile are more applicable than others. The important thing to take away is that Agile gives the scope to find a good fit for the parts of the philosophy that will work and offers some intriguing possibilities for consideration.

© Giri Fox for Giri Fox, 2012. | Permalink

Having reviewed recent literature on the topics of change initiatives, sales management and behavioural management, I distilled the key barriers to success down to these six:

What are the barriers to success?

1. Personal bias and blinkered thinking
2. Poor understanding of the market and sales context
3. Failure to address dissenting behaviour
4. Muddled and ineffective planning
5. Lack of leadership/ ownership
6. Failure to follow-through

Whilst these barriers may seem intuitive, they are commonly overlooked in practice. I think the root cause of this oversight is often an unconscious avoidance of the work it takes to do things properly. With this in mind, I wanted to outline how to succeed for those readers who have the strength of character to do it right.

How do we mitigate against failure?

Understanding and acting within the right context is very important.

Using the decline of Sony from its pre-eminences in the 80s and 90s as a case study, Sohrab Vossoughi points out in HBR that “a great strategy is only great in context” and “all the hard work in the world won’t matter if you’re working toward a strategy that was framed for an another era”. Message: don’t let your decisions become biased by entrenched assumptions about the way things should be done. Re-assess reality.

I want to continually improve how accurately I see reality. This also means questioning my own views. The skill here is for “strategic decision-making leaders to recognize their own biases”¹. In order to avoid bias during the decision making process, it is crucial not only that you ask the right questions, but also that you ask the right people². Don’t just invite your direct reports and usual leaders: go wider, skip levels and look for disruptive thinkers.

McKinsey provides an insightful guide to mitigate flaws in strategic decision-making, which – along with the other key articles I’ve sourced – is worth reading. In short, successful strategic planning³ has these qualities:

• Stakeholders shared all critical information
• Actively sought evidence contrary to initial plan
• Truly innovative ideas were allowed to reach senior management
• Dissenting voices were given ample opportunity to express themselves.

Bias

Of course, you shouldn’t be afraid to trust your own instincts, just remember to consider bias. Don’t assume you are viewing reality with perfect clarity. Consider these tests by the authors⁴ of Think Again:

1. The familiarity test: have we frequently experienced identical or similar situations?
2. The feedback test: did we get reliable feedback in past situations?
3. The measured-emotions test: are the emotions we have experienced in similar or related situations measured?
4. The independence test: are we likely to be influenced by any inappropriate personal interests or attachments?

Actionable

Always ask yourself ‘Does this strategy balance commitment and flexibility?’ Once you are clear on a robust strategy, make sure it can be adapted to suit a changing situation. Next ask yourself ‘Is there conviction to act on the strategy?’⁵  This is one of several recommended tests, which essentially ask whether it will actually work.

Don’t let your sales initiative fail because of ‘AWOL Sponsors’, where the leadership you are relying on do not provide the political clout, time, or energy to see a project through⁶. Make sure everybody is on board with the strategy and that the leadership is committed to seeing the project through.

It would be better to qualify out of an initiative than to invest yourself in one which will fail due to lack of executive sponsorship.

How to assure effective execution

Instead of hoping your planning process is robust, reflect on the steps you’re taking, on how you make decisions and the quality of input, and your next major sales initiative can be a success. You should:

• Build on unbiased facts
• Deal openly with dissent and internal concerns
• Construct a robust yet flexible plan
• Ensure the full commitment of the sponsor.

Pay attention to the decision process itself.

Think about how you go about making a decision, and consider how you will execute on the decision. Don’t be seduced by the fun part of making the decision. The lists I’ve provided let you decide on how you will make the decision by considering the requisite preconditions and subsequent actions required to ensure success.

© Giri Fox for Giri Fox, 2012. | Permalink

• cloud computing,
• competitive strategy
• recruitment incentive.

Read all of these and you’ll see the pattern.

Profound gifts to the open source

LinkedIn open sourced one of their core systems, called SenseiDB. It’s a NoSQL system for incredibly fast searches of massive data, Hadoop integrated and handles massive concurrent load. They open sourced it! This is a highly-engineered solution from the core of a very large company.

Twitter is open sourcing its highly-optimised MySQL fork. This system has incredible capability for enormous transaction rates. It’s now available to everyone. Facebook have been publishing their MySQL experience for a while too, sharing knowledge and code.

The importance of platforms

Eucalyptus have an agreement with AWS to use their APIs thoroughly. It creates the potential for users to have a hybrid of private and public clouds that migrate loads between them, using the same API language.

The implication of this was eloquently put by their Rich Wolksi:

It is the raising of the level of abstraction — from mechanism (“plumbing”) to policy (“architecture”) that I find to be the exciting possibility enabled by an agreement between Eucalyptus and AWS.

A Googler accidentally posted an internal essay on the importance of platforms, on service oriented architecture and how important accessibility is. It’s a magnificent piece, you basically have to read it all, since summarising overly simplifies the message.

Ostensibly the piece is on Google+ but really the message is about platform architecture.

How these pieces build a competitive strategy

Having understood the above articles, this final piece will give you a so what moment: Be wary of geeks bearing gifts.

Basically, open source is a competitive weapon.

It’s well known to be part of possible business models – Red Hat, Squiz and Canonical are examples of businesses built on top of open source.

The key further point is how open source is also a competitive strategy.

Linkedin and MySQL and OpenStack should be seen in this context. There are so many angles to it. It’s easier and cooler to recruit coders if they’ll be working on projects like these. Plus, they get volunteer efforts to improve it (minor benefit initially). Plus they built a platform which gains the power of network effect.

Consumers’ eye-level to the world of IT is often at the level of the smartphone app, but the real corporate battles being waged are behind the app, beyond even the AWS infrastructure that runs it (eg. Instragram use AWS), and is being waged amongst APIs and architecture which rules all of those subordinate moving parts.

Awesome times for IT.

© Giri Fox for Giri Fox, 2012. | Permalink

I’m an introvert, and am aware of how to get the best out of myself. I’m not shy – that’s a common misunderstanding – but I prefer the inner world and gain energy from it. Too much time in busy groups and workshops is draining for me.

Thanks to Susan Cain’s great work, introverts are being more accurately represented and celebrated.

Introverts can be sales people

I produce the best analysis and solutions by putting my headphones on, being alone, and having the time to think deeply. I don’t provide the same kind of contributions when I’m in a group, because then I find myself facilitating the group process rather than going inward. In a group, I’ll lead and draw-out others’ thoughts, but not generate my own ideas to the same degree as privately.

In fact, being an introvert, a listener and systems thinker makes me well suited to selling complex solutions because my diagnosis and proposal is thorough. If I was shy, it would be a problem, but I’m not. I’m assertive. Introversion does not mean submissive – that’s a false association.

It’s important to understand that sales people can be introverts. You will be working with introverts, but they may not have declared themselves so because there has been a kind of shame around it for years. So, how to get the best from us? This fellow blogger has a few tips on working with them, such as providing an agenda so we can think about things in advance.

Michael Hyatt, Chairman of a of a large book publisher, is an introvert and said this recently:

Most people assume that I am an extrovert, because I am a CEO of a large company and do a lot of public speaking. But things are not always what they seem. Many leaders I know are introverts. They can “turn it on” when they need to, but are much more comfortable away from the crowds and the lights.

When hiring, you will interview introverts and thus you want to give them an fair chance to be hired. However, interviewing often has a bias towards extroversion, such as thinking up creative solutions on the spot with an audience. A poor interviewer can misinterpret being thoughtful for being shy or lacking assertiveness. This article discusses that problem. I also wrote about interviewing sales people.

Susan Cain

The TED video by Susan Cain is really excellent and will help extroverts to understand us introverts. She’s written a book on introversion – which I’ve ordered – based on six years of research.

Susan also wrote this superb article in the NYT which blasts brainstorming and the bias to group activities.

Her research highlights a few great points which are mentioned in that article:

• Privacy makes us productive. What distinguished programmers at  top-performing companies wasn’t greater experience or better pay. It was how much privacy, personal workspace and freedom from interruption they enjoyed.
• Conversely, brainstorming sessions are one of the worst possible ways to stimulate creativity. Decades of research show that individuals almost always perform better than groups in both quality and quantity.

There has been a lot of press, and Susan’s put a recent list together on her site.

For technical discussions, this quote from Linus (from Wired) also succinctly captures a good reason for written communication, rather than physical meetings:

I actually think it’s very annoying to talk technology face-to-face. You can’t write down the code.

The inner world

On a related note, reading novels – as opposed to business books – is good for your emotional intelligence. Research reported by HBR outlines the benefits to social skills.

Andrew McAfee also wrote on how solitude lets you enter flow, that highly productive state.

Right now – for example – I wrote this post whilst listening to progressive on di.fm.

© Giri Fox for Giri Fox, 2012. | Permalink