DevOps & Cloud promises for non-technicals

September 9, 2019 Published by mcochet

By François Piquard

A few days ago, I did a presentation to our Business Managers called DevOps & Cloud promises for non-technicals. The goal was to clarify a bit those buzzwords, make sure they could prospect our clients and help them qualify the leads better. My name is François Piquard, I work at ADNEOM as a Project Leader and I do not have any CS background either. So I thought it could be a good challenge!

First, let’s define “non-technical”. 

 It can mean a lot of things. It ranges from “I can’t code” to what does “servers” means. So I asked a few questions to probe their understanding of basic WeMo ( Web & Mobile, what we do at Adneom ) stuffs. In our case, it was the former. And it is perfectly normal. Those guys have their field of expertise and as a former Business Developer, I know that the complexity of the job might be different, but it is there.

Once I knew more, I explained a few keywords,

like server, instance, VM, etc. I made sure to use some analogies. It goes a long way to link the abstract relation between the Dev and the Ops to the familiar one between a pizza and the restaurant. The presentation was built on the idea that the software we were making, or rather the Web/Mobile app they were selling, was a pizza. While this whole thing is more than an approximation, the audience got it.

By using this analogy, I wanted to explain two things. 

The first one was about the Cloud way of outsourcing & the all the * as A Service (IaaS, Daas, Saas,…). While the second one was about the concept of DevOps. What does it mean? Why isn’t is a job and how do we apply it in correlation with our agile (Scrum) way of developing software? I knew I would not be able to fully explain both concepts in an hour, but it was more than enough to have an impact, to make sure DevOps would not mean only CD/CI and that cloud would lose a bit of magic (Magic as a Service?).

Pizza as a service? 

This one is the most common analogy and for a good reason. I wanted to make sure when a prospect asked what kind of Platform as a service we used, the lead would not get a ‘let me call one of my colleagues’. So, I used the pizza as a service metaphor, and it made wonders! I told them that in the early ages we had no level of abstraction from the Servers. If you wanted a website, one of your IT had to plug the machine and make sure it worked. The OS had to be installed, the temperature of the room controlled, … It is called on-prem.

But the idea of all the *As A Service was to bring a level of outsourcing to the game. Indeed, not having to manage the infra seems cool, maybe someone could do it for me. BOOM, Infrastructure as a service. I also explained the idea behind EC2. Then I told them that all the set up was kinda tedious, and maybe you would want some integrated auto-scaling and other goodies? And now you have PaaS. I told them about App Engine and Beanstalk (debatable I know).

But the real, *aaS means abstraction made sense when I asked them when was the last time they had to patch their Gmail because of Linux’s security patch. The SaaS model was understood, and it made sense to them that a server was running those services, they just had someone managing those for them. Now, those guys are in sales and like me, from a business degree. So out of all people they know that there are no such things as free meals. It was evident that if someone managed things for you, you would still pay for it !

To conclude the ‘Infra’ point, a good question I would advise any sales or business manager to ask themselves would be: “to which extent am I willing to outsource?”. Does it make sense for me to have your datacenter? If yes, on-prem it is. If not, do I have any IT capable, willing or available to install and maintain your servers? If so, I should maybe check if IaaS is the solution.

At this point, I thought those words were well understood. There is no silver bullet and, once again, the decision should be taken on a case per case basis.

DevOps > CD/CI && DevOps =/= Job. 

Now, to explain the concept of DevOps, I brought back the Pizza analogy. Keeping the metaphor of our pizza as a software, I asked them to imagine that everything the manager could have instead of a [insert positive adjectives] pizza was the Ops. I know it is vague, but you have to keep in mind that for some people, to have an app on an iPhone, to first and only step is to code it. And people don’t see the tests, the monitoring, the infra, the planning and the rest.

So to make sure they have a global vision of products development processes, I told them it was not only the infra, the gas or the oven, but also the way it is was tested, how the cook collected feedbacks, how the new toppings would be chosen, etc. Once they got that, the best way to describe DevOps in a one-liner was:

The research to develop an ‘assembly line’ in an iterative way to have a consistently better pizza and faster.

Don’t quote me on that, but it gets the essence of the thing. First, it is more of a concept/research than really a defined way of doing. My DevOps is not yours. Netflix had the simian army and we at Adneom use a continuous inspection tool. Your pipeline might need manual verification or not.

I also like the idea of an assembly line, it is a nice way to explain that in our software development process, if everything goes smoothly, the code goes through multiple phases (plan, test, deploy, [ … ], monitor). I also took a moment to explain that every part of the assembly line could be improved, automated, etc.

Indeed, like Netflix’s simian army you could improve the way you test, you could better monitor your software and DevOps was not only a rsync command once the code was pushed to the master branch. The iterative part was to tie the DevOps concept to the Agile way we have put in place to develop our WeMo’s products. To quote Atlassian:

“DevOps is Agile applied beyond the software team”

— https://www.atlassian.com/agile/devops

When Business Managers and Developers meet clients, the first questions is often “how are you?’, and the second one is always “how much will it cost?”. A good way to answer that is “we can give great value to smaller budgets and if you want we can increase the scope of the project one step at a time, see what goes well and build on that (iteratively)”.

You could start your DevOps journey with the basics then iterate until you have all the best practices in place. Or maybe just a CD/CI and a few integrated tests are all you need. As a matter of fact, this is exactly what I have for my website Piquard.cloud (shameless plug, but if you made it this far we are probably friends).

The end of the quote refers to the goal of having a consistently better pizza faster. For the “better” part, business managers and folks in sales are aware of the critical importance a software has on the client’s activities. And they know a faster time to market can mean a lot in today’s market, so they are sensitive to that too. But when I told them that consistently was for testing, I realized that the importance of testing was a bit overlooked. They knew the amounts of money involved in any software development contracts.

And I informed them that a good way to meet the availability SLAs was to make sure nothing that goes to production has a bug. The best way to assure that no pizza leaves the kitchen cold is to have someone TEST it is not. It underlined the importance of good quality assurance to avoid the penalties.

Thanks for making it there ! 

In case you are yourself a non-techy, I hope this article made it easier for you. On the other hand, if you are more tech-oriented, make sure to share this article to your BM or Sales if you find it relevant (if not tell me why so I can improve it!). They will most certainly be thankful and more productive!

Remember that being great at making software with no one to sell them to is useless, and so is being a great Sales with nothing to sell.

François Piquard, Project Leader at ADNEOM

Categorised in:

This post was written by mcochet