Thursday 17 December 2015

Back from the future

I'm just back from Dublin where we went to review the Microsoft Azure data centre.

I can't say too much because of NDA but I think it's ok to say 'wow'.

Cloud isn't anything magical and ethereal it's essentially a load of big data centres and some clever software over the top.  However that's really doing it an injustice.

The scale and attention to detail is just astonishing.

If you think you can run an IT operation or data centre better than that you need to visit a padded cell.

A big barrier to Cloud adoption is that of trust.  Do I trust their procedures?  Do I trust their infrastructure? Etc

It's safe to say one of the roles most untrusting or Cloud is that of the Security Manager.  We are lucky enough to have an open minded one that is up for change but even then it's job to distrust...

Think it's fair to say he's placated! Well at least from a physical security and operations point of view.

The place is so process driven to the most minimal of detail.  For example cutting up old disks in millimetre pieces and having multiple pairs of eyes ensure that they are disposed of appropriately.  

Azure data centres are annally retentative.  

In a good way....

This has to be the future - everything else seems amateurish in comparison.




Tuesday 15 September 2015

Interesting (ish) blog stats

You are probably a man
You are probably 30-40
You are probably in the USA
You are probably using Firefox
You are probably using Microsoft Windows (would have thought iOS)
You probably found the site via LinkedIn
You probably read an average of 4 blog posts
You probably spend 5-10 minutes on the site before moving off


The blog receives anywhere between 200-500 visits a day which is surprising (to me anyway!).  Especially as I don't post daily and secondly because it's largely a stream of consciousness rather than a well structured piece of journalism.


Not exactly Google scale but each one of those visitors comes to the blogs on purpose (via a Twitter, LinkedIn or devops.com referral).  No one comes via Google.  Excellent SEO :)


That's kind of interesting to me because that's 500 DevOps people (so nicely targeted) rather than 500 member of the general public that find the site by accident and much more than I would have thought.


Thankyou!

Monday 14 September 2015

DevOps is ALL about culture

Criticisms of defining DevOps with the word "culture"


I've heard a number of lazy criticisms of DevOps recently particularly where individuals talk about culture.

 
"It's fluffy"
"It's in-actionable"
"DevOps is just automation"
"Cultural change isn't relevant in a bank - its a term used by the Facebook's of this world"
 
I think part of this is the continuing confusion over what the term means, along with DevOps being used as an umbrella term for a dozen different other things (Continuous Delivery being the most prevalent).
 
I've talked at length about what DevOps is to me so I'm not going to cover that again.  However, I am going to talk about culture.
 
Let me start with a great definition of what culture is (it's not my quote but I wish it was) - apologies I forget the source.
 
Culture is what you do when there is no one around to tell you what to do
 
I think that's brilliantly simple and bang on the money.
 
DevOps is concerned with bringing two disparate groups together (unsurprisingly Developers and Operations) and encouraging empathy and collaboration between them.
 
Nothing in that talks about automation.
 
The companies with the right culture between Dev and Ops might land as automation as a solution to curing some of the challenges of unshared incentives and goals  However, it doesn't predicate it.
 
A strong DevOps culture might turn to Continuous Delivery as a process solution to meeting their demands for an increased pace of change.  But again it doesn't predicate it.
 
Its really important that people understand the differences and goals between DevOps, Agile, Continuous Delivery etc.
 
They all very closely relate and link but they are different things (take a look here for a glossary).
 
Back to the criticisms
 
Now lets have a look at some of those criticisms of using the word DevOps to represent culture...
 
"It's fluffy" - Culture is closely linked to human behavioural patterns and humans are very different.  So its a fairly loose term but does it make less important?  Not for me.  How your employees and colleagues behave and interact is THE most important thing in a company.  There are a squillion clichés out there about how your employees are the most valuable asset but its absolutely true.  Great people and accomplish great things.  Great technology is nothing without great people.
 
"It's in-actionable" - again this is a very lazy criticism.  Culture is actionable its just hard to change.  Changing the way you recruit, sitting people together in cross-functional teams, not micro-managing, encouraging lunch & learn presentations etc are all actionable ways of affecting culture.
 
Culture is hard to change though as we are dealing with people.  People have different reactions to change and are sometimes difficult to second guess.  It takes time and effort but that doesn't make it in-actionable.
 
"DevOps is just automation" - think I've done this to death but for clarity...the right culture could well lead towards automation as a solution.
 
"Cultural change isn't relevant in a bank - its a term used by the Facebook's of this world" - why is having high performing people in a high performing environment only relevant to the unicorns of this world (i.e. Netflix, Facebook etc)?  Its a daft comment in my eyes.
 
Besides who are the companies earning the big bucks these days?  Oh yeah its not the banks it's Facebook, Google etc...
 
 
Characteristics of a DevOps culture
 
Here are my top twelve characteristics of a DevOps culture.  How far are you off?
  1. Measure everything, always
  2. Individuals have empathy for the rest of the team (i.e. they don't pass the buck)
  3. Shared goals and incentives
  4. Don't reward the fire fighter, reward the fire preventer
  5. Reward innovation and challenging the status quo
  6. Don't punish people when they try something new but fail
  7. There is no IT and "business".  IT as much "the business" as the sales people.
  8. Seeking to break down silo's
  9. "It's not my job" doesn't exist
  10. "Its my server/code/network/database" doesn't exist
  11. Individuals are empowered to make decisions
  12. Top-up management rather than top-down
 
 

Wednesday 2 September 2015

I gotta (DevOps) feeling

I recently returned from Atlanta, US and A (as Borat would say), where I was helping set up a new Agile development team.

Actually, they are a little bit more than a dev team - they are one of these product teams I'm so keen on.  The teams owns the full lifecycle of change; development, testing, support, deployment etc all in one team.  The idea is that they start to make decisions as a team rather than individual silos and that they have empathy for the impact of their changes on others.  For example, if a change is poorly tested that is going to affect the velocity of the sprint due to rework.  Or if they develop a change that is difficult to deploy then the team are going to feel that pain.

I think of it as gradle to grave responsibility.  Your job doesn't stop at checkin.  Its only just begun.

Only once software has hit production does it realise any business benefit.

It's not the first time I've set up a team like this but I get the feeling that its going to be a fantastic success.

We are still in sprint zero so how can I make such a bold statement?  Largely its a gut feel but because I've done this a number of times I know what "good" feels like.

That's a bit of cop out though and not very interesting for anyone kind enough to read this blog.

Let's drill into a bit further and have a look why the ingredients of success are there:

Budget/investment in tooling
We are putting together a kick-ass CD pipeline with Bamboo, Jira, HipChat and Bitbucket all very neatly integrated.   Add into the mix Puppet, Urbancode Deploy and a load of other tooling and they have everything they need for a very fast pipeline.

What's more, there is budget for some consultancy if we get stuck or need some training.


Right people in the right team structure
We've been able to cherry pick some of the best people that already work for us and go to market for the rest. This means we can really closely get in the skillets we need "off the shelf" rather than having to train & influence a set of existing individuals.

When you employ people that already live Continuous Delivery, BDD, Git etc then your job is considerably easier.

We've really concentrated on the soft skills of the guys & gals that make up the team too.  Attitude for me is 99% of the job and technical skills 1%.  People with the right attitude will learn the tech.  The culture of the team is absolutely important.

Some banking type told me this week that culture is just fluffy and that its just about tooling and automation.  I bet you £10m that this team will be more successful than his.

Its all about culture.  Tooling and automation comes out of that culture.


Agile training
Teaching a development team the Scrum process is actually pretty simple.  What is often neglected though (I'm guilty of this one) is what it means to the business stakeholders outside of the core dev team.  In my experience, business users often want to assert some requirements and then walk away.  They also want the full product and the idea of Minimal Viable Product is a hard pill for them to swallow.

In an Enterprise you also get a million and one different stakeholders all fighting for their piece of the pie.  Having to prioritise the backlog is difficult when you have different stakeholders from different parts of the business and with a different management hierarchy.  You end up with stakeholders trying to reserve story points in a sprint and other work arounds.  This is a bad place to be in.

However, we've (the royal we) have spent considerable effort and time spending time with the business stakeholders training them in Scrum.  How does prioritisation work?  What are the sprint ceremonies?  Why should the Agile team be self managing etc etc

The fact that we spending the first month or two on technical setup (CI processes etc)and not on business change gives me confidence that the stakeholders "get it".

Aligned goals (minimal number of stakeholders)
Agile is easier the fewer people that are involved trying to pull the team in different directions.  We are lucky that we have a very senior stakeholder that is able to arbitrate and protect the team for the prioritisation noise and that has a clear direction of what they want to achieve.


Self organising
Agile teams need to be protected from outside interference so that they can concentrate on the task at hand.

Too often have I seen other interfere with the running of an agile team and decisions made on their behalf.

Go away!  Leave them alone!  The Agile team best knows how to organise themselves for optimum performance.

I see really good signs that the team aren't being micro-managed and are protected from the scary, outside world with a good Product Owner.

As long as the results are there, the stakeholder don't seem to care too much about how those results are achieved.  That seems simple but too often people hang on too tightly thinking that it will give them control and will help ensure success.  Its actually the opposite; don't strangle the team, let them breathe and hey will get you where you want to go.

Again this is aided but not having too many cooks (stakeholders).



Thursday 9 July 2015

Don't believe what I tell you

I presented at the Computing DevOps summit in London yesterday which was great and I met some really nice people.


There were some really interesting presentations from individuals and the usual bombardment of tooling choices from vendors.


Most of the people I spoke to at the event came from the "where do we start" camp with adopting DevOps.  It surprises me how immature the idea still is across the Enterprise - there are far more that haven't even started vs. the ones that are "doing" it.


I listened to a few panellists speak and a couple of presentations but it struck me that after a few hours no one could arrive at a common definition of "What is DevOps"? 


If we can't define it then how on earth can we put a process together for adopting it?


Before my session I asked the audience to stand up and put their hands on their heads which they obligingly did without question.






The pic is a bit dark but it amused me to get people to do this!  Power Hungry PowerPoint Fiend.


The point of this though was not to "follow the leader".  DevOps is a cultural idea - what it means to you and how to implement it will change between different companies.


For many, the pursuit of DevOps is in response to increasing the pace of change.


For some its about increasing quality.


Or it could be about reducing costs.


The point is that you need to work out what you are trying to achieve and you need to land on your own definition of what DevOps is.


Listen to me and others.  But don't blindly follow us. 


DevOps is an ideology so its open to interpretation and that's a good thing.

Wednesday 8 April 2015

The 8 why's of Cloud



A question in the form of a cloud.  Seen what I've done there?  Ok not very clever (nor my image - sorry whoever owns it!).

Myself and the gang have been talking about Cloud a lot recently as we embarking on a multi-year journey.

Cloud is fashionable but is this another cool toy for the techies?

As an architect I think the most powerful question in my toolbox is "why".
  • Why are we doing this?
  • Does it add business value?
  • What are we trying to achieve?
As IT folk it's instinctive to go straight into the "how" but its the "why" that is the really important question.

Get that right and how to do it should be relatively easy.  A solution is much easier to put in place if you've really captured and understood what it is you are trying to accomplish.

I think there are 8 reasons why companies commonly move the Cloud - I'm specifically thinking about IaaS and PaaS here but I guess this also could apply to SaaS in parts.

Scale 
The massive amounts of processing power or data storage that public Cloud offerings can achieve would be difficult to achieve building your own solutions (certainly at any kind of realistic price point).
 
Elasticity
The ability to expand and contract resources (such as compute) depending on your requirements.  Traditional IT departments buy capacity in advance which is unused until it is required.  The elasticity of Cloud allows us to buy what we want, when we need it and not be constrained by fixed overheads.

Cost saving/model
Some companies believe that moving to the Cloud will save them money.
 
I think the ROI for Cloud is really difficult to ascertain though.  How do you compare apples for apples when Cloud is a different model to on-premise? 
 
It might be easy to say a server costs X to run each year (power, data centre costs, depreciation, support etc) and compare that to a Cloud server.  However, what is the cost of having to wait for 3 weeks to get a new server on-premise when you can get it in 5 minutes in the Cloud?
 
It's not an easy calculation to be made and I don't think I've seen a really convincing argument from either side.

One insurance company I know said they did some calculations and Cloud was 3x more expensive than on-premise.  I've seen Cloud companies boast that IaaS is 3x cheaper than on-premise.

You should do some due diligence on the cost of Cloud of course.  However, in my eyes it's too complicated and fuzzy to create a compelling story at the moment. 

Does this mean you shouldn't move to the Cloud?  Absolutely not - but focus on the other benefits too as cost alone is too difficult to accurately determine.

The move from CapEx to OpEx is also a difficult question for many and really needs to be thought about.  How do you accurately budget for a service if you are using the elasticity and scale features of the Cloud for example?

Future proofing
The rate of new features hitting Cloud providers is pretty astounding.  AWS for example have over 450 services now and more hit the shelves every month.

You probably won't need the majority of these features now but what about in the future? 

As an IT department we can't predict the future but we can help to respond to it.

Why build it yourself when you can buy it as a commodity?

Time to market
With Cloud being pre-packaged and largely automated the time to market for adopting resources is often significantly lower than doing it yourself.

You might have a really neat automated server build at your company but chances are you still need to wait for the storage guy or the network guy to do something. 

Often its not even the time waiting for something to be spun up - its the time waiting for a person to become available in order to press the button to spin it up.  For example, in my company it takes 2 hours to build a VM.  However I might not be able to book a resource to kick the process off for 2-3 weeks depending on their availability.

I don't think this is a problem that only public Cloud can remedy but again why build it internally?

Resilience
This is a bit contentious but bear with me.

Cloud outages happen.  On-premise outages happen. 

However, I would argue that due to the scale of some of things like Azure (and the ease of employing it) that cloud is more resilient than traditionally hosted IT.

But....

Only if your application is written/configured in such a way to take advantage of the multiple availability zones and the resilient functionality that Cloud providers.....errrm....provide.

If you simply lift and shift from on-premise to Cloud you are just moving the problem.  If you treat Cloud just like another data centre you'll get just another data centre with much the same problems as you currently have.

Perhaps even worse.  At least in your data centre if there is a problem you are in charge of your infrastructure guys and can prioritise (shout at) them.  What is going to happen when you are speck on the Azure infrastructure?  Is your voice going to get heard?  Is it heck.
  
Increasing competitive advantage
Although there is value getting your IT teams to run infrastructure (it's likely your business couldn't operate without it), does they offer competitive advantage?

What competitive advantage do you realistically gain over your rivals by running your own SAN, servers etc?

Wouldn't it be better if your teams were concentrating on high-value tasks that separate you from competitors rather than undifferentiated heavy lifting?

Competitive advantage can be realised through such things as...
  1. Lowering costs
  2. Improving quality
  3. Increasing the pace of change
  4. Improving end user support
  5. Innovation
  6. Spending more time understanding the business
Wouldn't you want your teams spending time on the above rather than worrying about provisioning blades and making sure backup tapes get revolved?
 

Geographic reach
As companies grow and their worldwide reach increases (customers and internally) then it means getting data closer to the end user.
  • Your Google ranking is probably going to suffer in the US if you are serving your website from the UK. 
  • Your Citrix session is likely to be "sub-optimal" if you are sat in London trying to access your VDI farm in Australia.
  • How do you organise downtime for maintenance when your worldwide presence is open 24x7 because of your global reach?

The global reach of public Cloud companies enables to provision resources nearer the people that need them.


A word of warning
In order to fully realise the benefits of the Cloud (such as scale, resilience) applications need to be architected accordingly.  You are unlikely to realise the benefits I've talked about simply through "lift and shift".

It's also worth mentioning that people, process, technology, culture all need to be addressed as part of the a Cloud adoption.  This isn't just a technical exercise and nor is Cloud a panacea for all of the challenges that face IT.



 

Sunday 8 March 2015

Quick DevOps glossary

I write a lot about the meaning of DevOps as there is a lot of misunderstanding of the term.

There are other hipster terms which also seem to get banded about as "sub-DevOps" concepts although in reality they are quite different things.

Inspired by the many inaccurate articles I read from DevOps "experts" (i.e. http://devops.com/blogs/devops-is-agile-for-the-rest-of-the-company/) and the many conferences I attend where the speaker just talks about automation (i.e. a distinguished IBM fellow at IBM InterConnect 2015 I cringed at) -  I thought I'd pen my own quick reference guide.

I'd be really arrogant if I said that I'm right and all these guys are wrong.

But... I'm right and all (well a lot of) these guys are wrong :)

Agile
The name of a group of process for delivering short time-boxed, incremental delivery allowing early visibility of software to the customer.  Processes such as SCRUM and XP are examples of Agile processes.

Continuous Integration (CI)
At the rawest level CI serves to integrate and build code from multiple developers, several times a day.

CI aims to provide fast feedback that developers code integrates with one another.  It is often extended with things like unit tests to give visibility into the working state of the code.  Failing early (and more often) should make it easier and faster to resolve any defects.

Continuous Delivery(CD)
CD aims to ensure that software is always in a releasable state.  It's often said to finish the job CI started.

CD means continual  building the code, running tests against that code and making it automatically deployable into what's known as a delivery pipeline.

Martin Fowler (and he really knows what he is talking about) says you know you are doing CD when...
  • Your software is deployable throughout its lifecycle
  • Your team prioritizes keeping the software deployable over working on new features
  • Anybody can get fast, automated feedback on the production readiness of their systems any time somebody makes a change to them
  • You can perform push-button deployments of any version of the software to any environment on demand
http://martinfowler.com/bliki/DeploymentPipeline.html

Note Continuous Delivery doesn't mean you HAVE to deploy to production dozens of times a day.  Its really about getting the software in a releasable state.  You don't necessarily have to release it however.

Continuous Deployment
Continuous Deployment extends Continuous Delivery by automatically deploying into production depending on having passed multiple (automated) "gates".

Good article here

DevOps
DevOps is a culture of shared goals, incentives, empathy and empowerment.

The DevOps movement arose the counter the silo mentality endemic in IT organisations.  It aims to influence teams to realise they are trying to achieve the same goals by having empathy for the challenges that face their co-workers.  Empathy is great but if you aren't empowered then you won't be able to make anything better.  Therefore in a DevOps culture, teams are empowered to make decisions as proposed to more traditional manager-led, top-down organisations.