It’s cloud, nothing more and nothing less

Public cloud, private cloud, hybrid cloud – let’s stop the nonsense; it is all cloud.

The delta comes in the form of access.

Many enterprises have, in fact, not built a cloud but done some infrastructure automation, automation that serves the purposes of the infrastructure and operations folks but is not a cloud.

So what’s the distinction?

A cloud is all about the API and after the API it is all about the content.

If a service cannot be requested, acquired and operated via an API you do not have a cloud. If the underlying infrastructure is not terminated automatically based on demand (or lack of it) and returned to a pool of available capacity…. you guessed it; it is not a cloud.

Forget where the cloud is, you should not care.


Andy Hawkins

+44 7795 464517

Twitter Google Plus LinkedinSkypeWordpress

This e-mail message may contain confidential or legally privileged information and is intended only for the use of the intended recipient(s).

Buzzwords demistyfied (for the cynic)

Serverless: it’s what the guys who want to sell you cycles are peddling vs. what the guys who want to sell you the tin to run those cycles on

Microservices: how we used to build distributed systems before Moores law made it possible to colocate everything in one image

DevOps: it’s what the new kids on the block do….until they get to twenty five employees and then they don’t quite know what to do except NOT to do ITIL

Agile: it’s the methodology for guys who don’t want to commit anything to writing, in either a document or calendar form

API: intelligent glue unlike SOA which was academically superior but incomprehensible to anyone but an academic

Stateless: something that is technically useless in any meaningful application

App: code that is too trivial to be used in any backend

Experiment: in applied computing this is often used to disguise something that is not well thought out or suitable for the intended purpose


Andy Hawkins

+44 7795 464517

Twitter Google Plus LinkedinSkypeWordpress

This e-mail message may contain confidential or legally privileged information and is intended only for the use of the intended recipient(s).

The Right Patterns

I am committed to the ideas behind Continuous Delivery and the approach that has become known as DevOps and I want to help organisations adopt and start delivering solutions using these approaches.

I try to use common sense approaches to guide enterprises in their adoption and present the following four patterns (in order of preference) to help guide selection of the right project to kick-off their journey:

1. A Greenfield project; you may argue that you don’t have a suitable target but I challenge this as most IT departments have something, even a component, in motion at any time

2. A strategic application (service) that is based on technologies / components that are core architectural blueprints for the long-term

3. The fragile artefact; the fragile artefact is a great pattern but requires very careful consideration before you commit. What makes it fragile & is that something you can address?

4. A third-party / COTS product

Why look for these?

1. Building blocks that can be re-used; early projects need to be used as an incubator to accelerate what follows

2. They are likely to provide good ROI and reduce TCO – and that can be measured and used to improve what follows

3. The size of the change can be made to be manageable; the emphasis is ‘be realistic’

4. In conjunction with solving the core problem it is likely one will be deploy supporting capabilities and this must be achievable; success will include tackling CI, approvals, orchestration, code review, peer programming, instrumentation – solely for the selected target but with the potential to reuse

5. We will learn but also we will be less likely to be inhibited by corporate memory or corporate inertia

6. Speed. We can deliver something tangible in a reasonable time

7. The COTS project often surprises people. It is in your best interest to ensure that your suppliers deliver product in a manner that you understand and can consume; it is necessary to ensure you understand and are able to manage it in the longer-term. As a supplier I have always been receptive when a client tells me a product needs to be delivered in a certain manner and keen to help.

DevOps: Coming to an enterprise near you.

In an industry where hype is the norm the DevOps movement has been fairly low-key until quite recently. Well, low-key in the enterprise perhaps, but there is a massive and very passionate community that has been doing great things for some time. Things like deploying code to production, at scale, every 15 minutes or creating super computer scale systems for pharmaceutical research in the cloud and paid for with a personal credit card.

DevOps is now coming to an enterprise near you and will have a huge impact in 2015 and beyond, so get ready.

Compare DevOps with the production line; DevOps is the IT equivalent to help you understand the relevance.

The production line revolutionised industry and underpins our consumer world delivering a dazzling array of innovative products that are accessible to anyone.

While web and gaming companies pioneered this space it’s merits have been identified by global software companies, retailers, banks and even heavy industry.

Over five years we have observed many engineers content being blissfully ignorant of DevOps. Others have dismissed it but take note; this is changing and changing fast and now many enterprises have now nailed their sails to the DevOps mast.

DevOps is as essential as it is inevitable; it will become ubiquitous in the enterprise and is fundamental to redress the impact that ITIL and out-sourcing has had on innovation and expertise.

How can we be so confident? DevOps shortens the software development lifecycle and reduces waste (time, process, repetition) and improves quality enabling you to focus on what is important to the business and innovate. Most fundamentally it is about automating all things including process, infrastructure, deployment, test, build and change. This has been something that many organisations have tried to tackle alone and have not succeeded.

So ask yourself:

  1. Do you have the culture, capability and confidence to commence your DevOps journey?
  2. Do you know where to start and where to avoid?
  3. Do you understand what DevOps best practices look like and can you avoid anti-patterns?

DevOps is a C-cubed world. Culture, Capability and Confidence. You need all three to succeed.

Don’t fall into the common trap and assume this is simply about adopting the cloud or implementing tools – talk to someone who knows this space and has the hands-on experience to advise.

DevOps & Visible Patterns

Dealing with C-C­­2 in a DevOps culture

If DevOps is about Culture is is equally about Capability and Confidence.

Perhaps I am alone but I am increasingly seeing the following mathematical equations in organisations:

a) C­­3
b) C­­2-C
c) C-C­­2

While many early advocates had great cultural awareness and technical expertise they often lacked ‘enterprise’. Recently I see too many C-C2’s.

My experience is that anything other than C3 is incredibly harmful. Choose your team wisely and coach them well.

Testing your automation

I was prompted to write this after enquiring why the team was applauding in the background while I was on a conference call the other day and I recognised that a deploy is still fraught and laden with unnecessary angst.

It’s time for an admission!

A long time ago I was part of a team that spent six months automating the delivery of a major platform for a client.

We automated everything, tested it and waited to deployment day.

So far so good…..

We tested every unit, tested everything in isolation, then integration tested in a range of pre-production environments.

But it went horribly wrong on release day!


Storage, security, authentication, routing, name services, timing and perhaps just poor planning or bad luck.

Actually it was a combination of these things that I should have foreseen.

To name just a few root causes.
1) firewalls
2) routing and name service deltas
3) latency
4) user permissions.

All sounds simple and straightforward but all caused problems plus perhaps 20 other things. Our unit and integration tests did not protect us.

The solution; we developed a framework called probes. Non-destructive tests, some as simple as a traceroute or ping to be run repeatedly in the weeks, days, hours and immediately before and after deployment to help determine readiness and identify failure. We choreographed the probes using iConclude, now HP Operations Orchestrator, in a matter of days and it was one of the most pleasing aspects of our project.

Anytime we needed to check status run the probe suite and validate our tests. Prior to the deploy run the probe suite and look for red alarms. No alarms then all pre-conditions were met. Run the probe at deployment time and it also raised and closed tickets in the release system and updated the monitoring tools. Deployment down from 48 hours of overtime to minutes on a normal day.

Sounds simple. It was simple!

As I look at the current state of DevOps I cannot see anything as elegant as this being developed.

I think there is huge value in this approach and perhaps people are doing it so I will continue to look and hope to see it soon.

Oh, and by the way, probes were our friend in finding problems with the solution once it had gone live.

It Started Off As A Post On DevOps In The Enterprise

As the title says; I started writing this post to explore the suitability of DevOps practices and the Enterprise but then realised that the question that needed addressing first was a little different.

What should the Enterprise expect to gain from adopting DevOps and how should they go about it?

IT departments in the Enterprise are increasingly adopting tooling that is associated with DevOps but are they adopting the practices that will yield future benefits?

Let’s not forget that DevOps is an idea that extends on the themes of source management, automation and collaboration across a number of teams involved in architecture, development and operations.

So DevOps is quite complicated and like ITIL, 6Sigma etc. DevOps is not immediate. You do not become an organisation capable of functioning in a DevOps manner overnight, it is something that takes work to adapt to and adopt. While adopting the practices of these processes will improve future performance when done properly it is about future performance. The controls, tools, policies and learnings do not affect what has gone before and may have been considered ‘finished’.

For future services the benefits of a DevOps approach should be consistent with the early proponents and therefore easy to categorise and quantify. But in the enterprise how much of the budget, effort and intellect goes into maintaining the status quo and how much into future?

If 80% of the IT budget goes into maintaining services then the benefits will not be seen until technology refresh occurs, this does not necessarily mean replacing the service or even the hardware but it certainly does mean change.

You have the (technical) debt from previous activities to deal with and technical debt in the enterprise is significant by any measure!

So in the enterprise I summarise that the benefits of a DevOps approach are there in the long term and the key to gaining early value is closely linked to your approach to maintenance and how well you have delivered your platforms historically. I will explore this in future posts.

In the short-term the costs will exceed the benefits. Clearly you may be investing in tools and training and if you are wise you will also perform some [process] integration / automation on top of the relatively simple concepts of configuration management.

 DevOps Value Map

Once you have a ‘top team’ of proficient specialists you should look to prove your process and capabilities by taking on a project, product or deliver a component using a DevOps approach. Of course once you have one project in production which has been delivered using a DevOps approach you need to ensure that you have the organisational construct and management vision to support the service ; building this competency takes time and great leadership and understanding and we will visit this in another post.

As your competency grows look at the standard MTTF, MTBF, MTTR metrics and determine where to attack the technical debt and be prepared for a journey.

The series continues.

The value of metrics

If you do not measure it you cannot manage it. That has been an management consultants mantra for as long as I can remember, yet so few IT operations have defined performance indicators and this surprises me.

Sure, people talk about 5*9s and mean time to repair, mean time to fail and mean time to isolate but real operational performance indicators and key performance indicators are rarely considered.

It is true but put more appropriately….
If you cannot measure it you cannot improve it so please get measuring!

What to measure? Well that is the most important decision.
I take a range of approaches – clearly if you do something often you can measure effort, iterations and the impact on your operational team. At the other end of the spectrum perhaps there is one task that occurs rarely but is so costly (SLA, effort, risk, knowledge) that it warrants automation. You know your business and are best placed to judge.

If you want advice on what to measure then get in touch.

Technology Leadership

The shelf-life for many leaders in IT is dreadfully short and often leads to organisations being unable to comprehensively execute strategy.

Achieving balance between delivering today and innovating and setting stretch goals is incredibly hard.

Perhaps the issues in many organisation are compounded because too many technology leaders have a distant relationship with technology?

Clearly there are a number of topical debates around technology at the moment and I have participated in, and led, many discussions around them.

With many organisation having broad ranging strategy that touch:
– Cloud
– DevOps
– Big Data
– Mobile
– Security
Is there little wonder that CIO’s and even CTO’s struggle?

Perhaps we need to look at this debate from a number of angles.
1) Education

Too few of the innovators in the technology world can present their ideas clearly and even when they are able to there is often an agenda. Take big data as an example; a storage vendor in this space has one perspective, traditional RDBMS companies another and Map Reduce occupies a third position.

Leaders need to take the time to educate themselves and guide their team to identify problems and map them to solutions. Vendors need to start helping with education and community events more to enable end-users to have a better understanding.

2) Experience

Expert technologists need to develop new skills, or hone their existing abilities, so that they are able to assist in the corporate decision making process. And conversely their leadership needs to have a better compass to help identify who they should trust and when to be skeptical.

Technologists need to also broaden their exposure, experiment and not be afraid to make mistakes. But all the while be realistic about the potential and potential pitfalls of a decision to go down a direction of A or B.

3) Business Value

Enterprises must learn to measure the benefits of their strategic choices to help improve.

Suppliers must start to measure the value of their solutions and not simply in a sales cycle but when also be prepared to work with their clients in the long-term when real results can be measured.

Is your product|service mature enough?

How much Enterprise software sits on a shelf unused?

Unused because it didn’t work as expected or perhaps it required a higher level of skill than perceived. Maybe it was bought by one team and ignored by the others?

In reality it is probably a mix of these with a few other challenges thrown in for good measure.

With open source and community-driven software – will this impact the value chain?

Heath Robinson

Let’s discuss.

Be under no illusions open source often has a commercial basis so what levels of support or frequency of release might you expect. This will vary dramatically across companies, product and geography and in many cases you will find the contributors are also active in the support communities responding to you before any commercial response.

Then consider the maturity, or perhaps better expressed as enterprise understanding, of the contributors. Do the people designing, writing or reviewing the code or features have a real background in the enterprise or an understanding of context. As someone who has spent two year at Chef I believe this is one of the more significant and, as yet, unresolved challenges. It is UNLIKELY that the community does have exposure or understanding!

Do not under-estimate the expectations of the community. Open source fosters an expert audience – expert but often lacking emotional connection or empathy. The author has observed contributors who no appreciation of the expertise available in a standard IT department and have never been exposed to IT service management tools or practices. This is not surprising but it is a significant consideration when you buy in to their ecosystem. Beware of features or processes that don’t or cannot fit with the way you run your business, examples include:
– inconsistent user management / directory integration capabilities
– ignorance of IT risk and mitigation
– poor documentation
– over-reliance or ignorance of tooling and process such as orchestration
– the ‘you can write that’ syndrome
– solutions that actually cause problems including false positives and ignorance of the need to use exception-based notifications when working at scale