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.

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.



 

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.

DevOps - what does "good" look like?

I've blogged a lot about my definition of DevOps and what it means to me.

I've always thought it much larger than "Dev" and "Ops" and that there isn't really an end state - it's an ever changing idea that will adapt to meet the needs of the business.

That said, I'm asked quite often what "good" looks like?  How do you know you are on the right path?

For me DevOps is a primarily a cultural idea.  If the culture is right then the technology and people will follow.  I talk to a lot of people who see this word "DevOps" and reach out straight to technology.  DevOps isn't another word for automating Cloud servers...

In order to an effective "DevOps" organisation I think you need 4 main pillars:

1. Culture - does the culture of your company promote collaboration, self improvement etc?
2. Process - you need to have processes that support different silo's working together to achieve a fast pace of change
3. People - if you don't have the right people then it doesn't matter how great your technology is.  People and culture are very linked but I've tried to separate them here to demonstrate qualities that individuals hold vs values that the company holds
4. Technology - what are the building blocks you need to be a mature DevOps enterprise?

The following is very much my view of what "utopia" looks like.  The truth of the matter is that DevOps means different things to different people depending on what you are trying to achieve.  For example, you absolutely don't need to use public Cloud to achieve DevOps.  However, I do think it's a good pattern to promote working on high value tasks (rather than undifferentiated heavy lifting**) and using a common change process between development and Ops teams.

This is where I want my company to get to...


Culture

• Measure everything, always
• Individuals have empathy for the rest of the team (i.e. they don't pass the buck)
• Shared goals and incentives
• Don't reward the fire fighter, reward the fire preventer
• Reward innovation and challenging the status quo
• Don't punish people when they try something new but fail
• There is no IT and "business".  IT as much "the business" as the sales people.
• Seeking to break down silo's
• "It's not my job" doesn't exist
• "Its my server/code/network/database" doesn't exist
• Individuals are empowered to make decisions
• Top-up management rather than top-down

People

• Restlessnes (relentlessly looking to improve themselves, others, processes etc)
• Good technical ability across a broad skill set (understand as much of other people's jobs as possible)
• Everyone can code and use version control
• Everyone understands the test triangle
• Dev-test pairing
• Organised in small product focused teams rather than technology silo's (align teams to the business not the technology)
• Common incentive schemes
• Favour automation and repeatability above anything else
• CIO/CTO are DevOps biggest guardians & SME's and seek to destroy anything that affects that  culture
• Natural face-to-face influencers rather than endless emailers
• Natural sharers of information
• Take an interest in their specialism outside of work (i.e. go to conferences and take part in the wider community)

Process

• Agile
• Continuous Integration
• Continuous Delivery
• Lean
• Fail-early, fail often
• Release management team are facilitators of change not guardians of change (i.e. they try and aid change rather than stopping/slowing it)
• All change (I mean all) goes through the pipeline from left to right (dev, test, acceptance, production)
• Knowledge sharing and "just enough" documentation is part of the process
• Measuring success and failure is part of the process
• Retrospectives are part of the process

Technology

• TDD/BDD everything (including Puppet etc)
• Everything is in version control (code, automated tests, server config etc)
• Release automation tooling
• Convergent desired state tooling
• Cloud (private or public but the ability to spin servers up on demand)
• The same trending, monitoring & alerting solutions available through nonprod & prod 
• Application Performance Management
• Service Virtualisation
• Continuous Integration
• Continuous Unit tests
• Continuous Service level tests
• Continuous GUI tests
• Performance testing

If you can get half way to delivering all of that then I think you should be in a very good place indeed.

It's a long hard journey if you are a traditional Enterprise.  Nothing worth achieving was ever easy though!

I'm outta here for what proved a fantastically successful 2014 (personally and work).  2015 is a massive year too for me but good luck in whatever you have planned ahead.

Happy Christmas to you all!

J
xx

DevOps Rugby

I spoke at IBM DeveloperConnect a while back talking about DevOps and how it relates to what I'm doing in my current company.

That isn't particularly interesting in itself.  The really interesting thing was at the end of the day where I was well and truly blown out of the water by the key note speaker.

The key note was held by Kyran Bracken MBE (http://www.kyran.co.uk/) the World cup winning, ex-England rugby scrum half.

Firstly its impossible to compete against someone who has won the rugby world cup and captained the national team in your favourite sport.  In fact, I came away thinking I've never accomplished anything in comparison.  Soul destroying!

Kryan talked at length about the role of a manager vs. a leader, the importance of challenging convention and taking risks.

It was an hour speech so I won't document it all here.  However I thought the 3 things above are relevant to the world of DevOps.

Manager vs Leader
In a well functioning DevOps function, the team is empowered to make decisions.  You don't need a manager telling people what to do and how to do it.

However, you do need a leader.  Someone that wants to creates the future and inspires others to join him/her on a journey.

The leader welcomes risks because no one ever accomplished anything great by playing it safe.

Both Martin Johnson and Clive Woodward were leaders.  Martin because he inspired people and Clive because he challenged so many conventions...

Challenging convention
The only way to improve things is to take the status quo and change it/improve it.  You can't get better standing still.

The Leader facilitates these challenges and encourages them.  Its very healthy to look at what you do and critique it - even if it works really well as the current convention.

Don't rest on any laurels.

Before the World Cup England had a good team but in order to get that extra 1% from somewhere they needed to challenge long held conventions.

Most teams before mainly worked on training to improve their attack.  However, through statistical analysis found that teams with the best defense tend to win games.  They then spent a much greater proportion of time working on defense.

Traditionally, rugby player wore heavy jerseys like this:

They are really heavy when wet, don't let the body breathe and are easy to get a grip on them. The 2003 World Cup team were the first to champion the skin tight Lycra ones that everyone wears nowadays.


Taking risks
Trying new things can be seen to be risky.  However if you want to separate yourself from the competition you need to take risks.

Clive Woodward had the team training their eyes and working on other new techniques that may have been derided if they hadn't won the World Cup.

If your team doesn't take risks or is punished for every failure then they will never move forward.  Taking risks should be encouraged and not penalised if it doesn't work.  Learn from those failures and move forward.

DevOps results - part 1

Last week I was lucky to be copied in to an email to the exec board of my company.

The email was written by the CIO advertising some of the success of our recent deployment automation efforts.

On a very basic level it compares human effort vs. automated effort and therefore cost and time.

The results are pretty amazing (well for us anyway) - we did 39 releases in a week for 1 application saving us 17.5 man days of effort.  We've done 49 this week and it's only Wednesday...

The benefits of this are probably more profound but it's a useful start.

For example...

• How much time is saved by having environments consistently built? 
• How much more beneficial is it to have every part of the deployment audited?

These types of things are very difficult to calculate the benefits of.  Thus my point recently at IBM DeveloperConnect (UK) when I said to focus on the softer benefits (like time saved) rather than deep ROI calculations (like money saved).

 Metrics are super important...

• How do we know if we are delivering value if the team isn't measuring it?
• How do we know if we are working on the right area's if we aren't measuring it?
• How do we influence other teams to do more "DevOpsy" things if we can demonstrate the benefit?

Cloud tie-in

In thinking about moving to the Cloud (I'm specifically talking about Paas and Iaas here) I've always had in the back of my mind that we should ensure that we weren't too tied down to a particular vendor (such as AWS or Azure).

Wouldn't it be great if you had your whole infrastructure defined in Puppet manifests and you could just pick it up and move it?

Why might this be useful?

•     Move to whatever Cloud provider is the cheapest that month
•     Move away from a provider if you are experiencing issues (outages, performance etc)
•     Move to a provider that have introduced some sexy new features

I believe the reality is that whoever your first Cloud provider is then it's likely you are going to have to stick with them.  The reality is that the Cloud is basically just another data center (albeit a very big and clever one) and the challenges of moving between data centers remain.

If you have written automation scripts (which you should have) to operate in the Cloud (provisioning, monitoring, alerting etc) you have almost certainly hooked into that Cloud's API.  You will have probably created an eco-system around your Cloud provider.

Also bear in mind that although a Windows 2008 IaaS server might be the same thing between Azure and AWS that things like load balancers won't be.  You won't be able to export a Azure load balancer and import it into Azure.

Moving Cloud could therefore mean rewriting all of this (this is why Puppet & Chef need to up their game).

In addition, you have the more obvious considerations of how to move the mass of machines and data from one place to another.  How easy it to move Azure Blobs to Amazon Elastic Block Storage for example?  How do I prevent downtime?

I'm guessing it's not impossible to move from one Cloud provider to the next but it's certainly not trivial.

I love the idea of utility based computing (i.e. only paying for what you use and when you use it) and the commodisation of IT as a product (i.e. I don' really care about what is happening under the covers, I just press a button and get a server).

However, to be a true commodity Cloud needs to ultimately become more portable.

Competitors of your current Cloud provider will like this.  Your current provider won't.


OpenStack?
Perhaps this is one of the reasons OpenStack was invented although I have concerns over it's long term viability.  OpenStack Cloud providers seems to bolt on additions to these standards to integrate it with their own systems or to create competitive advantage over another provider.  They have taken a standard and added to it - meaning it's no longer a standard.

OpenStack functionality vs. the might of an Azure or an AWS is also lacking.



Not that you would pick a Cloud provider on a whim, just be very careful to think about the wider implications of your selection criteria including an exit strategy.