DevOps

Cloud Run vs GKE vs GKE Autopilot

Posted on by jamesbetteley

What are the main differences and when should you choose one over another?

Aren’t they all just managed container services?

Yeah, they’re all “managed”, but to differing degrees. 

GKE = K8s platform where GCP take care of the underlying infra and control plane. So it’s a “Managed” service in the sense that someone else (namely Google) manages the VMs and the initial control plane setup.

GKE Autopilot = K8s platform where the folks at Google take care of the underlying infra AND the node configuration & management AND the monitoring & logging.

Cloud Run = Fully Managed container Platform-as-a-Service (or serverless container platform, if you’re a hipster), which basically means you can’t touch anything and it’s all built-in and managed for you by the google GCP bots – this includes auto-scaling (obvs), health checks, and monitoring & logging. 

Is that the only difference between them?

Nope, but it’s the most fundamental one. Because you’re getting different levels of “management” from each offering, you’re also getting different features and benefits. For example, with autopilot, the management of the nodes is done by Google, so to a consumer the nodes are locked down. That’s arguably a good thing. It also means that Google take care of all the node maintenance and security.

And I’m guessing the billing is different too?

Correct. The billing is different too.

For autopilot, you don’t get charged for unused pods or for any unallocated space. So that’s nice.

Check out the pricing calculator for an estimate: https://cloud.google.com/products/calculator

And the other main differences?

  • Cloud Run is a doddle to work with compared to GKE. Hardly any learning curve worth mentioning. However, it does have some limitations. For example the fully managed Cloud Run solution doesn’t support Kafka events/messages, so you’d need to move to pub/sub!
  • You also can’t increase the limits on Memory and CPU (obviously – it’s a fully managed platform, duh)
  • If you’re one of those posh people who have Security Command Centre Premium tier, the bad news is Container Threat Detection doesn’t work with autopilot or cloud run https://cloud.google.com/security-command-center/docs/concepts-container-threat-detection-overview
  • Binary Authorization https://cloud.google.com/binary-authorization/docs/overview is available for Cloud Run and GKE but NOT autopilot, so there’s that (why??).
  • Other security features such as Google Groups for RBAC, App layer secrets encryption and customer-managed encryption are available in Autopilot – you just need to enable them (in the Advanced options) when you’re creating a cluster:

If you’d like an exhaustive side-by-side comparison of all features of GKE and Autopilot (not just the main differences) then this is the place to go: https://cloud.google.com/kubernetes-engine/docs/concepts/autopilot-overview#comparison

Which one should you use?

Cloud Run.

And if that doesn’t fit your requirements then use autopilot.

And if that doesn’t fit your requirements then use GKE.

When should I use Cloud Run?

People say Cloud Run is ideally suited to startups, which I agree with (ease of setup, faster time to market, blah blah blah). But I don’t think this makes it unsuitable for any other type of organisation. I work with large financial services and I could see a massive benefit of using Cloud Run because it’s so easy to get up-and-running with. Larger, older enterprises tend not to have broadly distributed up-to-date DevOps skills across the whole organisation, and many also (or maybe as a result) have “trust” issues with giving teams the ability to customise and configure the hell out of everything. 

I’ve even seen organisations build container platforms for their dev teams to use and then lock them down so much that they might as well have just used something like Cloud Run.

When should I use Autopilot?

Whenever you think “I should just use GKE” that’s when you should use Autopilot. UNLESS you have a really compelling reason (I bet you don’t. Seriously, whatever you’re thinking of right now is NOT a compelling reason. Except if it is).

When should I use GKE?

If you like things that are harder to setup, harder to manage and harder to maintain, then GKE is for you. Just kidding (not really), you should use GKE if you’re already using it and have already done the hard work of configuring it and learning all the nuances (and are blissfully unaware of the sunk cost fallacy).

But seriously, go ahead with GKE if you need fine-grained control of your cluster nodes (how many of them, what CPU & memory they’ll need etc) or if you have some super-specific security requirements that I can’t even think of (apart from Binary Auth as mentioned above).

In summary:

You could use all of them. Why not? Use Cloud Run for the simpler stuff and Autopilot/GKE for the more complex (and edge cases).

DevOps Scrum Framework

Posted on by jamesbetteley

Imagine this hypothetical conversation I didn’t have with someone last week…

THEM: “Is there a DevOps framework?”
ME: “Noooooo, it doesn’t work like that”
THEM: “Why?”
ME: “Well DevOps is more like a philosophy, or a set of values and principles. The way you apply those principles and values varies from one organisation to the next, so a framework wouldn’t really work, especially if it was quite prescriptive, like Scrum”
THEM: “But I really want one”
ME: “Ok, I’ll tell you what, I’ll hack an existing framework to make it more devopsy, does that work for you?”
THEM: “Take my money”

So, as you can see, in a hypothetical world, there is real demand for a DevOps framework. The trouble with a DevOps framework, as is always the problem with anything to do with DevOps, nobody can actually agree what the hell DevOps means, so any framework is bound to upset a whole bunch of people who simply disagree with my assumption of what DevOps means.

So, with that massive elephant in the room, I’m just going to blindly ignore it and crash on with this experimental little framework I’m calling DevOpScrum.

Look, I know I don’t have a talent for coming up with cool names for frameworks (that’s why I’d never make it in the JavaScript world), but just accept DevOpScrum into your lives for 10 minutes, and try not to worry about how crap the name is.

In my view (which is obviously the correct view) DevOps is a lot more than just automation. It’s not about Infrastructure as Code and Containers and all that stuff. All that stuff is awesome and allows us to do things in better and faster ways than we ever could before, but it’s not the be-all-and-end-all of DevOps. DevOps for me is about the way teams work together to extract greater business value, and produce a better quality solution by collaborating, working as an empowered team, and not blaming others (and also playing with cool tools, obvs). And if DevOps is about “the way teams work together” then why the hell shouldn’t there be a framework?

The best DevOps framework is the one a team builds itself, tailored specifically for that organisation’s demands, and sympathetic to its constraints. Incidentally, that’s one reason why I like Kanban so much, it’s so adaptable that you have the freedom to turn it into whatever you want, whereas scrum is more prescriptive, and if you meddle with it you not only confuse people, you anger the Scrum gods. However, if you don’t have time to come up with your own DevOps framework, and your familiar with Scrum already, then why not just hack the Scrum framework and turn it into a more DevOps-friendly solution?

Which brings us nicely to DevOpScrum, a DevOps Framework with all the home comforts of Scrum, but with a different name so as not to offend Scrum purists.

The idea with DevOpScrum is to basically extend an existing framework and insert some good practices that encourage a more operational perspective, and encourage greater collaboration between Dev and Ops.

 

How does it work?

Start by taking your common-or-garden Scrum framework, and then add the following:

Infrastructure/Ops personnel

Operability features on the backlog

A definition of Done that includes “deployable, monitored, scalable” and so on (i.e doesn’t just focus on “has the product feature been coded?”)

Continuous Delivery as a mandatory practice!

And there you have it. A scrum-based DevOps Framework.

 

Let’s look into some of the details…

We’ll start with The Team…

A product owner (who appreciates operability – what we once called “Non-Functional Requirements in the olden days. That term is so not cool anymore. It’s less cool than bumbags).

bumbag

Bumbags – uncool, but still cooler than the term “non-functional requirements”

Devs, Testers, BAs, DBAs and all the usual suspects.

Infrastructure/Ops people. Some call them DevOps people these days. These are people who know infrastructure, networking, the cloud, systems administration, deployments, scalability, monitoring and alerting – that sort of stuff. You know, the stuff Scrum forgot about.

Roles & Responsibilities

Pretty similar to scrum, to be fair. The Product Owner has ultimate responsibility for deciding priorities and is the person you need to lobby if you think your concerns need to be prioritised higher. For this reason, the Product Owner needs to understand the importance of Operability (i.e the ability to deploy, scale, monitor, maintain and so on), which is why I recommend Product Owners in a DevOps environment get some good DevOps training (by pure coincidence we run a course called “The DevOps Product Owner” which does exactly what I just described! Can you believe that?!).

There’s no scrum master in this framework, because it isn’t scrum. There’s a DevOpScrum coach instead, who basically does the scrum master coach and is responsible for evangelising and improving the application of the DevOps values and principles.

DevOps Engineers – One key difference in this framework is that the team must contain the relevant infrastructure and Ops skills to get stuff done without relying on an external team (such as the Ops team or Infrastructure team). This role will have the skills to provide Continuous Delivery solutions, including deployment automation, environment provisioning and cloud expertise.

Sprints

Yep, there’s sprints. 2 weeks is the recommended length. Anything longer than that and it’s hardly a sprint, it’s a jog. Whenever I’ve worked in 3 week sprints in the past, I’ve usually seen people take it really easy in the first couple of weeks, because the end of the sprint seemed so far away, and then work their asses off in the final week to hit their commitments. It’s neither efficient nor sustainable.

Backlogs

Another big difference with scrum is that the Product Backlog MUST contain operability features. The backlog is no longer just about product functionality, it’s about every aspect of building, delivering, hosting, maintaining and monitoring your product. So the backlog will contain stories about the infrastructure that the application(s) run on, their availability rates, disaster recovery objectives, deployability and security requirements (to name just a few). These things are no longer assumed, or lie outside of the team – they are considered “first class citizens” so to speak.

I recommend twice-weekly backlog grooming sessions of about an hour, to make sure the backlog is up-to-date and that the stories are in good shape prior to Sprint Planning.

Sprint Planning

Because the backlog is different, sprint planning will be subtly different as well. Obviously we’ve got a broader scope of stories to cover now that we’ve got operational stories in the backlog, but it’s important that everyone understands these “features”, because without them, you won’t be able to deliver your product in the best way possible.

I encourage the whole team to be involved, as per scrum, and treat each story on merit. Ask questions and understand the story before sizing it.

Stories

I recommend INVEST as a guiding principle for stories. Don’t be tempted to put too much detail in a story if it’s not necessary. If you can get the information through conversation with people, and they’re always available, then don’t bother writing that stuff up in detail, it’s just wasting time and effort.

The difference between Scrum and DevOpScrum in respect to stories is that in DevOpScrum we expect to see a large number of stories not written from an end-user’s perspective. Instead, we expect to see stories written from an operation engineers perspective, or an auditor’s perspective, or a security and compliance perspective. This is why I often depart from the As a… I want… So that… template for non “user” stories, and go with a “What:… Why:…” approach, but it doesn’t matter all that much.

Stand-ups

Same as Scrum but if I catch anyone doing that tired old “what I did yesterday, what I’m doing today, blockers…” nonsense I’ll personally come and find you and make a really, really annoying noise.

Please come up with something better, like “here’s what I commit to doing today and if I don’t achieve it I’ll eat this whole family pack of Jelly Babies” or something. Maybe something more sensible than that. Maybe.

Retrospectives

At the end of your sprint, get together and work out what you’ve learned about the way you work, the technology and tools you’ve used, the product you’re working on and the general agile health of your team. Also take a look at how the overall delivery of your product is looking. Most importantly, ask yourself if you’re collaborating effectively, in a way that’s helping to produce a well-rounded product, that’s not only feature-rich but operationally polished as well.

Learn whatever you can and keep a record of what you’ve learnt. If any of these lessons can be turned into stories and put on the backlog as improvements, then go for it. Just make sure you don’t park all of your lessons somewhere and never visit them again!

Deliver Working Software

As with Scrum, in DevOpScrum we aim to deliver something every 2 weeks. But it doesn’t have to just be a shiny front-end to demo to your customers, you could instead deliver your roll-back, patching or Disaster Recovery process and demo that instead. Believe it or not, customers are concerned with that stuff too these days.

Continuous Delivery

I personally believe this should be the guiding practice behind DevOpScrum. If you’re not familiar with Continuous Delivery (CD) then Dave Farley and Jez Humble’s book (entitled Continuous Delivery, for reasons that become very obvious when you read it) is still just about the best material on the subject (apart from my blog, of course).

As with Continuous Integration, CD is more than just a tool, it’s a set of practices and behaviours that encourage good working practices. For example, CD requires high degrees of automation around testing, deployment, and more recently around server provisioning and configuration.

 

Summary

So there it is in some of its glory, the DevOpScrum framework (ok, it’s just a blog about a framework, there’s enough material here to write an entire book if any reasonable level of detail was required). It’s nothing more than Scrum with a few adjustments to make it more DevOps aligned.

As with Scrum, this framework has the usual challenges – it doesn’t cater for interruptions (such as production incidents) unless you add in a triage function to manage them.

There’s also a whole bunch of stuff I’ve not covered, such as release planning, burn-ups, burn-downs and Minimum Viable Products. I’ve decided to leave these alone as they’re simply the same as you’d find in scrum.

Does this framework actually work? Yes. The truth is that I’ve actually been working in this way for several years, and I know other teams are also adapting their scrum framework in very similar ways, so there’s plenty of evidence to suggest it’s a winner. Is it perfect? No, and I’m hoping that by blogging about it, other people will give it a try, make some adjustments and help it evolve and improve.

The last thing I ever wanted to do was create a DevOps framework, but so many people are asking for a set of guidelines or a suggestion for how they should do DevOps, that I thought I’d actually write down how I’ve been using Scrum and DevOps for some time, in a way that has worked for me. However, I totally appreciate that this worked specifically for me and my teams. I don’t expect it to work perfectly for everyone.

As a DevOps consultant, I spend much of my time explaining how DevOps is a set of principles rather than a set of practices, and the way in which you apply those principles depends very much upon who you are, the ways in which you like to work, your culture and your technologies. A prescriptive framework simply cannot transcend all of these things and still be effective. This is why I always start any DevOps implementation with a blank canvas. However, if you need a kick-start, and want to try DevOpScrum then please go about it with an open mind and be prepared to make adjustments wherever necessary.

DevOps in 5 Easy(ish) Steps

Posted on by jamesbetteley

I’ve said before that I’m a big believer that there’s no “one size fits all” solution for DevOps, and nothing in my experience as a DevOps Consultant has led me to change my mind on that one. Each organisation is subtly different enough to warrant their own approach to adopting, and then succeeding with DevOps.

However, I do think there are some good patterns for successful DevOps adoption. “The right ingredients” you might say. But as with cookery and chemistry experiments, it’s the quantity of, and order in which you introduce these ingredients that makes all the difference (I discovered this first-hand as a chemistry undergraduate J ).

Below is a list of 5 steps for starting out on a successful DevOps journey (“DevOps journey” = 100 cliché points btw). It’s not a solution for scaling DevOps – that’s step 6! But if you’re looking for somewhere to start, these 5 steps are essentially the blueprint I like to follow.

 

  1. Agree what your goals are, what problems you’re trying to solve, and what DevOps means to you (is it just automation or is it a mindset?). You all need to be on the same page before you start, otherwise you’ll misunderstand each other, and without knowing your goals, you won’t know why you’re doing what you’re doing.
  2. Build the platform. DevOps relies heavily on fast feedback loops, so you need to enable them before you go any further. This means putting in place the foundations of a highly automated Continuous Delivery platform – from requirements management though to branching strategy, CI, test automation and environment automation. Don’t try to create an enterprise-scale solution, just start small and do what you need to do to support 1 team, or this thing will never get off the ground. You’ll probably need to pull together a bunch of DevOps engineers to set this platform up – this is often how “DevOps teams” come about, but try to remember that this team should be a transitional phase, or at least vastly scaled down later on.
  3. Assemble the team. We’re talking about a cross-functional delivery team here. This team will include all the skills to design, build, test, deliver and support the product, so we’re looking at a Product Owner, Business Analyst, Developers, Testers, and Infrastructure Engineers among others (it largely depends on your product – it may need to be extended to include UX designers, Security and so on).
  4. Be agile, not waterfall. Waterfall’s just not going to work here I’m afraid. We’re going to need a framework that supports much faster feedback and encourages far greater collaboration at all times. So with that in mind, adopt a suitable agile framework like scrum or Kanban, but tailor it appropriately so that the “Ops” perspective isn’t left out. For example – your “definition of done” should stretch to include operability features. “Done” can no longer simply mean “passed UAT”, it now needs to mean “Deployable, monitorable and working in Pre-Live” at the very minimum. Another example: Your product backlog doesn’t just contain product functionality, it needs to include operability features too, such as scalability, maintainability, monitoring and alerting.
  5. Work together to achieve great things. Let the delivery team form a strong identity, and empower them to take full ownership of the product. The team needs autonomy, mastery and purpose to fully unlock its potential.

 

Once you’ve achieved step 5, you’re well on your way to DevOps, but it doesn’t end there. You need to embrace a culture of continuous improvement and innovation, or things will begin to stagnate.

As I mentioned earlier, you still need to scale this out once you’ve got it working in one team, and that’s something that a lot of people struggle with. For some reason, there’s a huge temptation to try and get every team on-board at the same time, and make sure that they all evolve at the same rate. There’s no reason to do this, and it’s not the right approach.

If you have 20 teams all going through a brand new experience at the same time, there’s going to be a great deal of turmoil, and they’re probably going to make some of the same mistakes – which is totally unnecessary. Also, teams evolve and change at different rates, and what works for one team might not work for another, so there’s no use in treating them the same!

A much better solution is to start with one or two teams, learn from your experience, and move on to a couple more teams. The lessons learnt won’t always be transferrable from one team to the next, but the likelihood is that you’ll learn enough to give yourself a huge advantage when you start the next teams on their journey.

Sure, this approach takes time, but it’s more pragmatic and in my experience, successful.

 

One final comment on the steps above concerns step 2 – building the Continuous Delivery platform. It’s easy to get carried away with this step, but try to focus on building out a Minimum Viable Product here. There’s no getting away from the need for a high degree of automation, especially around testing. The types of testing you might need to focus on will depend on your product, its maturity, complexity and the amount of technical debt you’re carrying.

Other aspects you’ll need to cover in your Continuous Delivery MVP are deployment and environment automation (of course). Thankfully there are external resources available to give you a kick-start here if you don’t have sufficient skills in-house (there are plenty of contractors who specialise in DevOps engineering, not to mention dedicated DevOps consultancies such as DevOpsGuys J). Don’t spend months and months assessing different cloud providers or automation tools. Speak to someone with experience and get some advice, and crack on with it. Picking the wrong tool can be painful, but no more painful than deferring the decision indefinitely. Anyway, it’s relatively easy to move from Chef to Ansible, or from AWS to Azure (just examples) these days.

Many years ago I worked for a company that spent over a year assessing TFS, while continuing to use VS etc in the meantime. I worked with another company more recently who spent a year assessing various cloud providers, all the while struggling along with creaking infrastructure that ended up consuming everyone’s time. My point is simply that it’s better to make a start and then switch than it is to spend forever assessing your options. It’s even better to take some expert advice first.

DevOps in an ITIL environment

Posted on by jamesbetteley

At IPExpo in London a couple of weeks ago, I was asked if it was possible to “Do DevOps in an ITIL environment”.

My simple answer is “yes”.

ITIL and DevOps are two different things, they both attempt to provide a set of “best practices”; ITIL for Service Delivery and Maintenance, DevOps for Software Delivery and Support.

DevOps is mostly concerned with a couple of things:

  • The mechanics of building and delivering software changes (we’re talking about Continuous Delivery, deployment automation, Configuration automation and so on).
  • The behaviours, interactions and collaboration between the different functions involved in delivering software (Business, Dev, Test, Ops etc)

ITIL largely stays away from anything to do with the mechanics, and doesn’t touch on culture and collaboration – preferring instead to focus more on the tangible concepts of IT service support. It’s essentially a collection of procedures and processes for delivering and supporting IT services. Most of those procedures and practices are just common sense good ideas.

DevOps isn’t a prescriptive framework, it’s more like a philosophy (in the same way as Agile isn’t a framework). Because it’s not prescriptive, it can work with any framework (such as scrum) provided that framework isn’t at odds with the DevOps philosophy (such as waterfall).

ITIL provides a set of concepts which you then implement in your own way. For example, ITIL promotes the concepts of Incident and Problem Management. It doesn’t tell you exactly HOW you should do them, it simply suggests that these are good processes to have. There are recommendations around actions such as trend analysis and root-cause analysis, but it doesn’t prescribe how you should implement these.

Change Control

Probably the area with the greatest amount of cross-over is change management. ITIL explicitly mentions it as a procedure for the efficient handling of all changes, and goes on to talk about Change Advisory Boards, Types of Change, Change Scheduling and a bunch of other “things to do with deploying changes to an environment”.

DevOps also advocates smooth and efficient processes for deploying changes through environments – so there’s no conflict here. The only slight misalignment is that in ITIL, change management is seen as an activity that happens during the Service Transition phase, while in DevOps we tend to advocate the identification and promotion of pre-authorised changes (standard change), which means the change management process effectively starts prior to service transition. But that’s about it really.

Some people get a bit carried away with the role of the Change Advisory Board in ITIL, and insist that every change must pass through some sort of CAB process (usually involving a monthly CAB meeting, where a bunch of stakeholders review all changes queued up for a production deployment, which usually only serves to cause a delay in your software delivery process and add very little value). ITIL doesn’t explicitly say it has to happen this way – it’s not that prescriptive!

Similarly, DevOps doesn’t say you can’t have a CAB process. If you’ve got a highly complex and unstable environment that’s receiving some sporadic high-risk changes, then CAB review is probably a good idea. The only difference here is that DevOps would encourage these Change Advisory Board reviews to happen earlier in the process to ensure risk is mitigated right from the start, rather than right at the end.

 

So, in summary, ITIL and DevOps are not having a fight in the schoolyard at home time, there’s nothing to see here, go about your business. 🙂

DevOps Certification – Part 2

Posted on by jamesbetteley

In part 1 of this exciting 2-part blog series, I argued, quite elegantly I think, that DevOps certification is perhaps not the single greatest breakthrough in the advancement of software delivery since the invention of computing. In this part, I’ll attempt to go into even further detail in support of my hypothesis…
At an agile conference last year I did a quick survey to see what people valued the most about Agile Cerification. The results were conclusive, not one single person said they valued the certification itself. Most people said they thought the training was the most valuable thing, and I can understand that 100%. Quite rightly, people valued the knowledge they had gained and the content they’d been taught over a certificate they walked away with.

devops_cert
But certification is still very popular, and that’s hardly surprising when you see how many people advertise roles for “certified” scrum masters. But the abundance of certified scrum masters doesn’t seem to have done much, in my view, to help progress the agile movement as a whole. In fact, I’m more inclined to believe that some “agile” certification has done more to confuse and derail the agile movement than to actually help it.
Here’s why:
Organisations think they’re agile because they’ve hired some certified scrum masters (or sent some people to get scrum master certification). I’m sorry, but hiring a certified scrum master makes you no more agile than hiring a violinist makes you an orchestra.
I’m not going to try to make excuses for misunderstanding the very meaning of “agile”, but it’s pretty easy to see how some people might think “well I’ve now got these Scrum Masters for christs sakes, MASTERS – not just any old scrum practitioners, and they’re certified! So if that doesn’t make us agile then why did I spend so much money on sending them on that certification course!?!!” (Answer: because you stoopid). Scrum certification is “reassuringly expensive” (genuine quote right there), and is VERY useful for teaching people about how to run scrum, but it doesn’t make you agile. Don’t be fooled by the price tag and the highly egotistic “Master” title.

scrum master
As part of my role as a consultant, I sometimes get asked to assess organisations agility. More often than not I get told “Oh we’re agile, we do scrum”, or “Oh we’re agile, we do sprints and have stand ups” and that sort of thing. These things, sadly, don’t necessarily make you agile. They’re just things. But one big problem in the software delivery world right now is that many people DO think that those things “make you agile”, and that’s all there is to it.
The silver lining for me of course, is that I get quite a bit of work out of it! I get to help some of these organisations realise that thier ability to do scrum, and their overall agility are two quite separate things.

And this brings me round to DevOps.
The DevOps world has an identity crisis every bit as bad as the agile world. Where agile suffers from people confusing the link between “agile” and scrum, in DevOps we suffer from people believing DevOps means Automation.
To be clear, DevOps doesn’t mean Automation. There’s already a word for Automation, and that word is Automation.

For me, DevOps is about the way in which teams work in order to create high quality products from Operational and Development perspectives.

Sure, automation can play a part in that, but it’s only a part.
Part of my role is to help teach people about how to unlock the power of DevOps, and to do that I usually have to start by explaining what DevOps is and what it isn’t. We call this the “Education” piece, because that’s exactly what it is – it’s not simply a case of defining something and drawing up a glossary, we’re literally opening people’s eyes and minds to what DevOps actually is, and what it can do for organisations who do it properly.
At one point we even thought about formalising this DevOps Education and even providing some sort of certification or professional credits system, but we quickly realised that this was utter bollocks.
The thing is, you can’t certify something that doesn’t have a commonly agreed definition, and you can’t certify a philosophy. You can certify actions and behaviours, and how well people understand particular frameworks (like scrum for instance), but you CAN’T CERTIFY A PHILOSOPHY. And anyway, who are these self-proclaimed guardians of the DevOps philosophy? These people who are so sure that they not only understand DevOps better than the rest of us, but also believe they’ve stumbled upon the perfect training program for passing this most precious wisdom on to people who attend their course? It must be a veritable who’s who of the DevOps movement, the Adrian Cockrofts, Jez Humbles, Patrick Dubois and John Allspaws of this world… Hint: it isn’t.
It’s almost as if the whole thing is just a scheme to make money! Imagine that!

So to conclude, I fear that DevOps certification isn’t worth the paper it’s written on, and bandying around a DevOps certification is only going to perpetuate the problem that we already see within agile, where organisations will believe that they’re “doing DevOps” simply because they’ve hired people with some bullshit certification.

Keep CALMS and do DevOps!

Posted on by jamesbetteley

In order for any sort of process, framework or methodology to succeed in the IT world, it absolutely must involve a large number of acronyms. And devops is no different. In the devops world we like to say that there are five underlying principles of devops, and they’re represented by the acronym CALMS. As with any good IT acronym, you start with the acronym itself and then work backwards from there. The main reason why the CALMS word was chosen for the devops world was because of the unlimited marketing oportunities it offers. For instance, you could use the “Keep CALMS and carry on” slogan and plaster it all over anything that you can actually print onto, like T-Shirts, mugs, foreheads, powerpoint presentations etc and so forth.

img_20150624_131537_720 keep-calms-and-do-devops img_20150623_154452_360

CLAMS?
The next trick was to work out what the CALMS should stand for. This was the hard part, and required the input of some of the smartest minds in the devops world to come together and use their collective brainpower to think of some devops words that would conveniently fit the CALMS acronym. So, in May 2013 or something (lets say), some people with names like Gene, John, Jeremy, David, John and Adrian all got together at the top of a mountain in North Wales and meditated on the CALMS acronym. That didn’t work, so they all got really drunk and that’s when they came up with what we now know as the five pillars of devops:

C and S stand for Cats on Skateboards
As everyone knows, the vast majority of the internet is made up of billions of pictures or videos of skateboarding cats. That’s why the internet is so big (and that’s also where the term “BigData” comes from). Devops is all about deploying pictures of skateboarding cats to the internet, in order to satisfy the world’s seeemingly endless desire for more and more pictures of kittens doing cute things. The better you arer at deploying skateboarding cats, the better you are at devops. Simple as that.

cat-on-skateboard

A stands for Agile
Devops was invented because sysadmins felt they were missing out on the whole agile party. So devops is just agile plus sysadmins. AMIRITE?

2848324491_b1d8eff41f

L stands for Letters
Acronyms are nothing without letters. Letters are very much the key ingredient of a good acronym. The trouble with acronyms though is that the letters don’t always lend themselves to a word that’s relevant to your topic. One way around this is to think of a world beginning with that troublesome letter, let’s take the letter L for example, and let’s randomly pick the word “Lean”, and then simply write a book which demonstrates how “Lean” is actually quite relevant and applicable to the topic of devops. It’s a clever one this, because you can then use it to help flog copies of your book.

potd-cat-black_2798668k

M stands for Money
Doing devops will make you rich beyond your wildest dreams. A recent survey has discovered that firms with high performing IT functions are less likely to suck ass than one’s with crappy IT teams. It only takes a medium sized leap of faith to believe that this has anything to do with devops. So it’s crystal clear then – doing devops means your organisation will outperform your competitors and we’ll all be sipping cocktails on a beach somewhere by this time next week.

3552926886_47c2e4d1b3

So what are you waiting for? Go deploy those skateboarding cats and I’ll see you on the beach!

Upcoming DevOps & Agile Events

Posted on by jamesbetteley

London Puppet User Group Meetup
London, Thursday May 21st, 2015
6:00pm
http://goo.gl/C2zuKb

DevOps Exchange London – DevOps & DevOps
London, Tuesday May 26th, 2015
6:30pm
http://goo.gl/Xmdqxl

London Agile Discussion Group – Should DevOps be a person or a team-wide skill?
London, Tuesday May 26th, 2015
6:30pm
http://goo.gl/xksVOH

AWS User Group UK – meetup #15
London, Wed May 27th, 2015
6:30pm
http://goo.gl/uBsiUj

Chef Users London – Microsoft Azure / Chef Taster Day
London, Friday May 29, 2015
9:00am to 5:00pm
http://goo.gl/VOvkC3

DevOps Cardiff – Herding ELKs with consul.io
Cardiff, Wednesday, June 3, 2015
6:30pm
http://goo.gl/WwOvkQ

Agile Testing – Visual Creativity: Using Sketchnotes & Mindmaps to aid testing @ #ltgworkshops
London, Thursday June 4th, 2015
8:30am
http://goo.gl/34iIXM

ABC (Agile Book Club) London – Review Jeff Patton’s User Story Mapping
London, Thursday June 4th, 2015
6:30pm
http://goo.gl/X0qPwb

Agile Testing – Hooking Docker Into Selenium @ #ltgworkshops
London, Thursday June 4th, 2015
8:30am
http://goo.gl/ONH8dQ

UK Azure User Group – Cloud Gaming Hackathon
London, Saturday June 6th, 2015
9:30am
http://goo.gl/ONH8dQ

London DevOps – London DevOps Meetup #10
London, Thursday June 11th, 2015
7:00pm
http://goo.gl/uolxJk

Kanban Coaching Exchange – Continuous learning through communities of practice – Emily Webber
London, Thursday June 11th, 2015
6:30pm
http://goo.gl/9aFD8x

Lean Agile Manchester
Manchester, Wednesday June 17th, 2015
6:30pm
http://goo.gl/Z15ac3

London Lean Coffee – Holborn
London, Thursday, June 18th, 2015
9-10am
http://goo.gl/QkIBhj

UK Azure User Group – Chris Risner
London, Thursday June 18th, 2015
7:00pm
http://goo.gl/EfbNnn

Jenkins User Conference – Europe (London)
London, Tuesday June 23rd – 24th, 2015
2 days
http://goo.gl/achJJX

BDD London June Meetup
London, Thursday June 25th, 2015
6:30pm
http://goo.gl/C2zuKb

Automated Database Deployment (Workshop – £300)
Belfast, Northern Ireland, Friday June 26th, 2015
1 day course
http://goo.gl/fXlJr7

Database Continuous Integration (Workshop – £300)
London, July 8th, 2015
1 day course
http://goo.gl/lW4TjA

Database Source Control (Workshop – £100)
London, July 8th, 2015
1 day course
http://goo.gl/C2zuKb

London Lean Coffee – Holborn
London, Thursday, July 16, 2015
9-10am
http://goo.gl/mtJ3k4

Agile Taster – a free introductory Agile training course
Cardiff, Saturday 18 July 2015
10am – 3pm
http://goo.gl/qFYS6b

AWS User Group UK – meetup #16
London, Wed July 22nd, 2015
6:30pm
http://goo.gl/Tc3hlD

What does devops have to do with agile?

Posted on by jamesbetteley

One of the questions I commonly get asked at the workshops we run is “What’s the connection between Agile and Devops?” or vice-versa. My usual tactic is to let the workshop attendees argue that one out amongst themselves. Firstly, because it’s quite an emotive question, so it gets people chatting, and secondly because I’m always keen to hear what other people’s opinions and experiences are.

Here are a few of the things I’ve heard from the workshop groups:

  • “Devops is an evolution of Agile”
  • “Devops is the missing link between agile development and operations”
  • “Devops is a subset of Agile”
  • “Agile is a subset of Devops”
  • “What time are we having lunch?”

I’ve heard strong arguments in support of each one, and I’ve also heard people say there is no link between agile and devops (again, with a strong argument to support this opinion).

For me though, I like to think of devops and agile as complimentary. I also think devops is a key enabler for enterprise agility, and this is where things get a little murky. I don’t want to get into any great yak shaving exercise, but before we can describe the relationship between agile and devops, we really need to define what we mean by “agile”.

Agile development vs Organisational Agility

Agile development comes with many different frameworks, some more prescriptive than others, but they all share a certain number of core “agile“ features in common – namely that they embrace change, and are able to comfortably respond to it (ok there are plenty of other features in common, such as focus on customer value and working software etc, but I’m going to concentrate on the responsiveness to change for now).

The agile manifesto "values"

The agile manifesto “values”

 

Scrum, on the other hand, is a framework for helping you do agile software development, it has clearly defined team roles and a few rules you need to follow. But let’s be clear – Scrum is NOT agile. Don’t confuse the two!

Scrum is a framework for helping you do agile software development, doing agile software development helps you become agile

Now let’s take a deeper look in to what being “agile” is all about. It’s about being able to respond to changing conditions, changing market forces, changing requirements, and not only survive, but to succeed. “Change” is the arena in which agility thrives. So, to be agile you need to be able to react and respond to changes quickly. This is where the agile world and devops come together. Devops encourages closer and more meaningful collaboration between the business, development and operations, to help organisations deliver higher quality applications that can be deployed quicker, be maintained and monitored more easily, and provide fast and accurate feedback to the business. Without these key enablers, you’d be hard pressed to respond or react quickly to anything, let alone changing requirements, changing markets and changing technologies.

So in a nutshell, agility is all about the ability to embrace change, and succeed in a changing environment. Devops is one of the key ingredients to helping you achieve this.

Can you do agile software development without doing devops? Yes, of course you can, you could do Scrum, for example. But doing agile software development and being agile are two very different things.

So, now for the harder question: Can you “be agile” without doing devops?

Some might argue that this must be possible, because organisations have been agile for longer than devops has been around – to which I would respond by saying that the term “devops” may be relatively new, but the ethos behind it has been around for as long as agile has.

I imagine that under certain circumstances it may be possible to be highly agile and yet have an anti-devops culture, where there’s very little collaboration between the business, development and operations, but I’ve not actually come across it, if it does exist. In my experience, highly agile organisations from start-ups through to large enterprises, are embracing the principles behind devops whether they know it or not.

In summary, agile is NOT about sprints, it’s NOT bout stand-ups, it’s NOT about retrospectives or any of the following:

  • Velocity
  • Points
  • Planning
  • Stories
  • TDD
  • BDD
  • Automation
  • Demos

You can’t do agile, you can be agile, but you can’t DO it. You can “do” scrum, XP, Devops, TDD, BDD etc – these are explicit activities, unlike agile, which is more of a set of values and principles. You can perform all of the individual activities listed above, independently of any other. Sure, they certainly complement each other, but they can be done separately. The same can be said of agile software development and devops.

The relationship between devops and organisational agility is that one is an enabler for the other. The relationship between devops and Scrum, for example, is simply that they are both enablers for organisational agility, but they can also exist independently of each other.

The DevOps Team Myth

Posted on by jamesbetteley

Should “DevOps” be a job title? Are DevOps teams an anti-pattern? Can you do DevOps within a single team? Were the moon landings staged in the Arizona desert? These are the sort of questions you’re never more than 5 feet away from at any DevOps conference or meetup. The answers, of course, are:

  • Yes
  • Yes and no
  • Maybe
  • Don’t be silly

Everyone seems to have an opinion on the whole “DevOps Team/Job Title” question, and I’m no different, except my opinion is this:

I passionately don’t care

Let me explain:

If you have a devops team, and their job is to encourage and develop a devops culture within the organisation, then that’s perfectly fine, surely? If that team is successful and a devops culture blossoms, then you’re definitely winning. Maybe that team could subsequently change its name, but that just seems a bit pointless and overly hung-up on semantics. In this case, I don’t care what the team is called, because it doesn’t matter.

If you have a devops team, and they don’t encourage or foster a devops culture within the organisation, then you’re doing devops wrong, as simple as that. If you’re doing devops wrong then it doesn’t matter what you call a team, you’re still doing it wrong. In this case, I don’t care what the team is called, because it doesn’t matter. 

I do understand the opinions of the anti-pattern crowd. Setting up a separate silo responsible for “doing devops” is completely wrong. It discourages other teams and individuals from adopting a devops attitude, as they’ll see it as someone else’s responsibility. But the problem isn’t with the existence of the team, the problem is the purpose of the team and the fact that whoever decided the team should “do DevOps” clearly doesn’t understand what DevOps is.

At the very core of the issue is an understanding of what DevOps actually is. If your CTO, (or Head of Technology or whoever calls the shots within the technology division) thinks that DevOps just means automating builds and deployments, treating Infrastructure as Code, or adopting Continuous Delivery, etc then you’ve already got a problem. DevOps is about these things (and more), sure, but it’s about everyone understanding the importance of them, and absorbing them into their culture.

I’ve previously posted about the dangers of having an obsession with Ownership and Responsibility and I think these factors can also contribute to a failed adoption of devops. Drawing up clear lines of ownership and responsibility is risky – if you get it wrong, you’re going to struggle. For instance, if you draw a clear line of ownership around “devops” and place it firmly in the domain of the devops team, then you’re not going to do devops. A single team cannot own and be responsible for a culture, it just doesn’t work like that. The lines of ownership need to be blurred or wiped out entirely. Nobody and everybody should be “responsible for” and “own” the devops culture.

Conclusions On The DevOps Team

Anyone who thinks that you can get something ingrained into an organisation’s culture by setting up an isolated group of people who are solely responsible for doing those things, is flying in the face of conventional wisdom. Even my experience suggests that this doesn’t work (and I always fly in the face of conventional wisdom, coz I’m stooopid). By all means create a DevOps Team, but don’t make them responsible for “doing devops”, that’s just wrong. Instead, give them the challenge of spreading the DevOps gospel, evangelising DevOps within the organisation and training everyone on the benefits of devops, as well as some of the tricks of the trade.

On The DevOps Job Title

Everyone’s a devops engineer these days. I’m a devops engineer, my wife’s a devops engineer, even my dog’s a devops engineer. It’s a booming industry and everyone wants a piece of it. I’m afraid we don’t have any control over this anymore, we’ve created a beast and it’s consuming everything!! Luckily it’s not the end of the world. Sure, sysadmins the world over are now rebranding themselves as devops engineers, but does it make any difference at the end of the day? If you’re hiring, you don’t just hire someone on the strength of their previous job title do you? No, you actually read their CV and interview the candidate. Good candidates will always shine through. Working out if someone’s a sysadmin or a build engineer is just a bit more hassle for recruitment agents, that’s all!

My dog, the DevOps Engineer

My dog, the DevOps Engineer

In a way I’m thankful for the devops job title. I honestly think it has helped to make the whole devops thing more popular and opened it up to a wider audience.

Should there really be such a thing as a “DevOps Engineer”? Probably not, but we’re far too late to stop it, and trying to stop it seems a bit of a waste of energy to me. Eventually “DevOps Engineer” will come to mean something more specific, but for now we’re just going to have to read a few more lines on CVs.