DevOps the handy buzzword for PaaSOps

I was interviewed this week by 2 consultancy firms which according to their websites apparently are leading UK devops solutions providers, each with an impressive list of highstreet brands and boast using the latest cutting edge tools with the best engineers money can buy.

These were interviews I didn’t really want to partake in but recruitment agents can be a persuasive lot and sometimes may bend the truth a little in order to try and get you into a role which may not be the one which you are hunting for.  Regardless I did want to know more about these operations and what I found out was, well enlightening.

Here are the highlights from one particular interview.

Founding devops director: Hello Aidan, thank you for seeing us at such short notice.  I trust your journey went ok?

Me:  It’s a pleasure to be here and thank you for wanting to see me.  Yes, I got here without incident.

Some more small talk ensued while I was introduced to the other members of the interview panel, a principle devops engineers and another “senior” devops engineer I would be working with.

Principle devops engineer: So according to your CV you’ve been doing devops for quite some time.  How long exactly would you say that you’ve worked as a devops engineer?

Me: No time at all.

Principle Engineer: Sorry?

Me: I have never worked as a devops engineer.  I am an DevOps coach and specialist in Agile methodologies, ITIL business processes and full software life cycles.

Principle Engineer: Right, but in your CV it says you know (lists various tools and cloud environments).

Me: That’s right.  If I didn’t have oversight of those tools and environments and fully understand the pros and cons of each I would not be able to recommend solutions that match a customers requirements.

Principle Engineer: Ok.  In your last role can you give an example of how you used some-tool in your day to day work schedule.

Me: Not really.  The client already had those skills within their engineering team and were using it in their day to day operations before I got there.  My input was dealing more with how they could improve their use of that tool in other areas of the business.

Principle engineer: So are you saying you didn’t actually get involved in the actual hands on implementation of the tooling?

Me: That is correct.

Director: The role that we’re recruiting for is a devops engineer role.  Did the agency not tell you this?

Me: Yes and I informed the agency that I was not an engineer but they assured me that you were looking for someone with more seniority who understood agile and continuous CI/CD life cycles.

Director: I see.  We are looking for someone senior but someone who will lead teams of engineers in the tooling.  This role will not be customer facing but you will be working in an agile environment and be using our CI/CD pipelines.

Me: Your CI/CD pipelines?  Can you define what you mean by not customer facing?

Director: We provide cloud based solutions for our clients along with appropriate automated deployment tools that they can use off the shelf.  But we need devops engineers to make sure that the correct cloud environments are created for our clients to use and that those environments are scaleable.

Me: I’m not sure I’m with you on this.  Why are your clients not managing their own cloud environments and CI/CD pipeline?

Director: Some of them do, but for the majority of our current client base we host their environments  and CI/CD solutions on our cloud service for them

Me: so let me get this straight.  Your clients are not involved at all in managing their own environments or CI/CD pipeline?  You are basically reselling them PaaS?

Director: Oh no, the clients will have full control and access to their environments and we give them direct control over their CI/CD pipeline to create new jobs for testing and release.  And yes you are right these are PaaS environments which is why we need devops engineers.

Me: So your engineers will be working with your clients to create those environments?

Director: No, our engineers work on our site.  You’ll be creating the cloud environments for them to use for their apps.

Me: But you said they had full control over those environments.

Principle: Ok, they have full access to the environments so can push their apps to it, but we manage the actual creation of those environments and administration.  Some of them are PaaS, some are actual VMs which we manage and we need people to create the deployment and automation projects when clients request them.

Me: Ok, I’m struggling with understanding exactly how any of this is related to DevOps.  When you say “devops engineer” what exactly do you mean?  What by your definition is a “devops engineer”?

Principle: I would say someone who is fully skilled in using a full set of devops tools.

Me: How would you define what being a devops tool is?

At this point in the interview we all knew it was over, but some morbid sense seemed to grip us all and we just kept going.  They were all looking uncomfortable, even the director.  It gets better so keep reading

Principle: Well automation tools for starters and of course cloud services.

Me: Such as tivoli, terminal services and VMWare?

Senior: Tivoli?  I’ve never heard of that. What is it?

Me: A configuration management and automated deployment tool which IT businesses have been using since the early 90s.

Senior: I wasn’t aware of that.  I wouldn’t consider a tool that old to be devops in any case?

Principle: Perhaps tivoli could be considered as a forerunner for devops tools but as my senior stated I wouldn’t consider it part of the current devops stack.

Me: Why?  What rules out tivoli from the devops stack?

Uncomfortable looks between the panel.  Nobody could answer why an automation tool was not a devops tool. I took pitty on them.

Me: Ok so for arguments sake if a devops engineer is someone skilled in automation tools and cloud environments, how does it relate to devops?  I can certainly see the ops but where is the dev?

Director: From our point of view a devops engineer is someone who can DEVELOP solutions with devops tools.

My jaw litterally hit the floor.  Jesus take the wheel! what did I just hear there?

Me: could you repeat that?  Do you guys actually understand what devops is

Director (very affronted): of course we do! We’ve been offering devops services for nearly 10 years! we helped define devops into what it is today?

Me: By developing operations solutions?

Director: Exactly.

And thus the interview was called to a close, apologies were offered for wasting my time but they really were looking for someone a bit more hands on.

So there we have it.  Why are there so many “devops engineer” roles out there at the moment?  Certainly not to help operations teams adopt Agile working practices and teach them scrum or kanban implementations to dove tail into the development sprint retrospective.

Not to help the operations team gain control over their on prem environments or help them release legacy applications.

Definately not to help Developers or IT Operations staff work better together and try to meet customer requirements by reducing the time to live from customer raising the requirement to receiving the feature.

No.  devops engineers are there to develop PaaS/IaaS solutions to be sold to clients because developing operations solutions is what devops is about.



Microsoft NO-tepad

This may be old hat news to some people, but I’ve been out of the Micro$oft camp for some time now.  I did mention I was a Penguinista!

One of the roles I’m working on is to automate the installation of MSSQL server through the use of an unattended configuration file.  While working on this I came upon a very interesting problem.  There are some options that will be different in production environments from localised development environments so I’ve placed the configuration in the role’s templates folder.  The various dynamic values I want to ensure match environment types were replaced with {{ variables }}.  Sounds easy right? What could go wrong?

As I found out, plenty.  When I edited the files in Atom locally on my Development environment (Windows 7) the configuration file looks ok. It even looked fine on my personal development environment (Linux Mint 17) but when the role is ran against the virtualized environment (a Vagrant Virutalbox machine) it failed.  Opening the file on the guest there were some extra odd symbols at the start of the file that weren’t on the host.  And all the values I’d entered had changed to what looked like a mix of Russian Crylic and Chinese.

The configuration file I’m using had already been written by the Ops team to help them define standard settings for their SQL servers.  Except that they had edited those settings in Microsoft Notepad.  Which I recently found out places a binary byte marker at the start of the file thus corrupting it when attempting to parse it through Ansible’s Templates module that uses the Jinja 2 templating language.

When I recreated the file, keeping it as far away from Notepad as I digitally could, the role parsed the new template perfectly.

So moral of the story is don’t use Notepad!  Use a proper text editor like Notepad++ or Atom.

Hello world!

Supposedly the first post in your blog is the most important.  Capture the audience, state your intentions, introduce yourself yadda yadda yadda.  Sounds so easy until you sit there for half an hour with out a clue what to type.

Who am I, what am I, what do I do?  Existential dilemma aside all valid questions.

Those who know me well, know that I am a self certified Linux fan boy.  I love Linux! I use it as much as I can!  It’s been my main OS for nearly a decade and it has filled a major part of my career to date, so it may come as a surprise to many to find out that my current contract has almost no Linux technology.  My client is an entirely Windows based house with MSDN subscriptions to everything, yet they have employed me in the position as a DevOps consultant to analyse and implement improvements to their current development environments and software delivery processes.

There are many out there who think that DevOps is not something that can be successfully implemented into a windows based environment, but even though I come from the dark side of the force, I am going to take the challenge and prove that DevOps is not limited by technology, tools or operating systems, but is truly about the attitudes and willingness of people who want to improve their software development and delivery environments.

This blog is to help me keep track of my journey into implementing the processes, methodologies and some of the tools I’ve used in previous Linux based organisations into this Wintel house.  To talk about many of the challenges I face, the compromises I have had to and will have to make, and how I will bring about what is considered the impossible.