Serverless Containers on Azure

What the hoot?

Yes. There are half a dozen ways to host Docker containers in multiple cloud ecosystems. But sometimes, you need simple. And spinning up a container shouldn't always require a full Kubernetes cluster or a VM for that matter.

I had a requirement to create an existing application hosting solution, that would be isolated from the internet, but available to a client, from their infrastructure. Basically something bound to an isolated VLAN. Notably, Sonarqube.

This was to be a medium sized solution for the client and data retention was not critical. So I don't know about you, but when the words "stateless application" come to mind, so does simple Docker containers, pop in mine.

So I went about investigating how I could get this spun up quickly in my customer's Azure subscription.

I hadn't worked a lot with the Azure CLI (command line interface), and was rather fond of using PowerShell to spin my infrastructure as code. But as things turn out, it seems that the azure CLI has got more love that the native PowerShell objects to spin up infrastructure (some things you can do in the CLI, that you couldn't in native PowerShell 😒)

PowerShell to the rescue!

I had to reevaluate why I use PowerShell. I use it to automate. In the end, I am agnostic to what creates the Infrastructure. As long as it's flexible and can be saved as code, I shouldn't really care.

What I like particularly about using PowerShell, is it's ability to take JSON strings and convert them to queryable objects. You get that whole "intellisense" experience when drilling down into the objects's properties.

It makes exploring objects returned in JSON string very easy to explore and discover properties.

Also enumerating collections of, those items, if need be.

And because the AZ CLI, returns it's data natively in JSON format, it basically allows me to query it as if PowerShell created the object itself. So it's rather transparent.

The only caveat being, that it doesn't give you a handle on the underlying object to update it. But I can live with that. (Sometime's I can be practical and not so fussy, see? 😅)

So my first thought was how do we go about scripting a simple web app and a DB using PS (PowerShell) and AZ CLI

Aaaaand that's when the DevOps guy in me got woke.

Recycling is good. 'Mkay?

There is no way this can be single use. But the requirement make the practicality of the solution a bit rigid. But, what if, we added an optional Application Gateway? That way we can either firewall a specific origin network, or have an open access/authentication gated solution for those who require it!

So what do we need all in all? And in what order?

1. A Vnet to host the apps
2. A database (I'll use SQL server in case the clien wan't to migrate the thing to his managed instance later)
3. A a web app container
4. Optionally a public IP
5. An optional Application Gateway

Spoiler Alert!👈

So we need to have some sort of control flow, to check and make sure the requirements are created and in the right order. So if we assume that we have built some functions: isvnet, isdatabase, isSonarQube

and so on, that either returns true, if the requires infrastructure exists or is successfully created, then we can do this: 

So what would the functions look like?

Here's the Vnet inspection and creation function

Now I considered using a name for the vnet, in case multiple ones need to be in the same subscription/tenant. But in reality, if we think about it. It shouldn't be necessary. A single VNET can keep all the required infrastructure isolated from the world. Unless... you have to have multiple instances of the app, isolated from themselves... so ok let's name them so we can have separate ones...in case. BUT...what if...

If we use the name of an existing VNET in our parameters, we can REUSE an existing one. To insert our infra in that one.

So our function checks if the vnet exists first and if it does, passes it along. If not, tries creates it and returns what it just created or not. If there was an error it will return nothing. Which is okay 'cause we trap it in our previous control logic.

All the other variables are defined at the beginning of the script.

Oh and by the way, there are my publicly available containers for creating SonarQube as a serverless container.

Side Note

SonarQube, runs on Java. And the built in database search engine it uses is an open source version of Elasticsearch. Elasticsearch, has a peculiar requirement to ensure it has enough memory, ressources to run properly. This can be very useful in environments where we are keeping a tight control on ressources. But in most cases, we will have at our disposal, much more than the 2 GIGs (if memory serves) that Elasticsearch requires.

However, the Engine, will query the operating system at SonarQube startup time, to see if it has that ressource reserved. Not available, but reserved. And that means, that unless you set this manually on your OS (btw this is linux based) the app won't run.

Not having a handle on the underlying OS in Azure, which hosts the containers (it's serverless, see?) caused the containers to not be able to spin up, ever.

Fortunately, the original SonarQube Docker container source is on GitHub. So luckily I could hack the startup file and tell him to ignore the check and put up my own container without any licensing issues. This is all open source. And the original author is properly credited. 😀 So says I. 

So yeah, it took some doing.😓

Drum-roll please

So how do you, create the serverless container(s)?

It turns out it's pretty simple. Pretty much the same way you create any other infra with the AZ CLI.

The container creation syntax is very reminiscent of the one on the Docker CLI when it comes to the container specific parameters (environment variables, notably).

And yes this function could be optimized and broken up in smaller parts, for controlling the hosting SKU size and the BD check. 

But it is just as quick to edit the script to change the values than to add parameters and consume them. So I didn't really see the point. (see? practical...again, yes me!)

 Conclusion

Not so bad 'eh? Because the AZ CLI returns a nice JSON that PS handles very easily, it is simple to query or set-up. Automation becomes very feasible as long as you have installed the Azure CLI (which runs on linux and windows) and PowerShell, ditto.

And considering that our friends at Microsoft will give you a free 200$ credit to play with Azure your first subscription (260$ CAN, yay for once we get parity! Thank you Microsoft 💓) there is no reason for you not to start hacking this stuff right away.

So. What are you waiting for?⏰

The Struggle to get Devops Adopted

The identity crisis

What I've been noticing, is that where Devops works, the level of organisational change and improvement that arrives, creates such an explosion of greatness, that people are shell shocked and only remember that Devops was the instigator.

Backblow

The negative effect of this, is that people have the word, Devops burned in their brains. The word only. For the few that follow up and try to grasp what changed and how everything got better, since it is a whole practice that needs to be comprehended, a few elements get anchored in the person's mind.

It's no surprise. Human beings are bad witnesses. People remember what they do, for reasons that are all their own. So hence, Devops takes a flavour, depending on the person hearing what it is. It's not unusual or extraordinary, new paradigms are hard to assimilate.

The good and the bad.

So there is a risk: that we have a business decision maker that realizes, rightfully, that they need to get ahead of this curve. But that they have only the faintest clue what it represents.

This is when they reach out for help, but they will probably rely on lessons of the past and proceed to plan bringing Devops in, like a project.

The hypothesis

If, continuous improvement was part of the business, deeply, it would be easy to see or even obvious that it is, yet another change. Just a different way to approach change. But my experience says it is not in a very important way. People are too preoccupied with their day to day activities to consider improving what they do. After all it would start with auto-criticism, and that most criticism, no matter the source, is to be avoided. And of course, we are too busy.

So, what differentiates the endeavors that will win and those that won't or don't, is pretty easy to see as well: change. Innovation, improvements and evolution are all synonyms for change. Those who adapt, improve and evolve are taking a risk, but between risking gaining ground on the competition and falling back on old habits, it seems that the actual risk of failure is pretty small.

As a matter of fact, DevOps requires manageable risk and success scoping. In the Jargon, we call it "Quick Wins". Changes are planned to give the maximum benefit for the smallest risk. And gradually these gains add up. Ans it all comes to a head, when it becomes a way of doing things.

Change is people.

What is more, the limits we set to our roles, often driven by titles are an obstacle to change. Just think how many times you've heard "that's not my job" or "it's not my responsibility". Think of it as a chain. Does it matter which link fails, for the whole thing to be a failure? No. Well projects live and die because of a single fault. And they live and thrive when everyone participates.

If there is a lesson to keep from blockchain, it is that having redundancies in our records and transactions insures a better future for our business. This is also true with human capital. 

Individuals care as far as they can see. So proximity, in preoccupations and physical location can be key to improving work relations. We often speak in DevOps about "the wall of confusion". This metaphor for the existence of very different preoccupations in a single organisation is often due to the lack of proximity. If people are to change, they must be able to sense how things are and see how their contributions can make a difference. All of this is very difficult when we are separated or isolated, imaginary isolation or otherwise. This is why DevOps has to be a cultural shift.

Change is Process

On of the things I have great fun is at explaining how processes are supposed to be organic changing and living things. It is impossible to maintain growth and improvement if your processes and your rule-book doesn't adapt with it. Luckily, in IT and in software development, we are used to to keeping the sources of our programs in a repository.

Why is this useful? Well if you are to find a way to track your progress, not only will you need to measure it, but you will need to understand how it happened. You must be able to link changes in your way of doing things and progress made. This requires to have your processes documented and stored somewhere where they can be reviewed. So yet another obstacle to get DevOps adopted is to have visibility and traceability on procedural changes.

And don't even get me started on governance. I am incessantly amazed in organisations that preach holocracy and autonomy but don't clear a path for their teams to accomplish anything. 

It's very simple: your entire velocity is dependent on the slowest part of your assembly line, figuratively. So if you have a supplier or an internal service that doesn't adhere to your model and that management doesn't ingrate them to your processes and keeps them apart, you will always be a victim of their preoccupations. We often forget that processes aren't there to make people slaves, but they exist to serve the people that are trying to get things done.

Change is Production

While this is probably the least of the mysterious aspects of DevOps, it has a tendency to overshadow the rest. Automation and integration techniques are no the most prevalent ones, but they often yield impressive results. Thus we are under the impression that we must get a hold of some technological guru, who can DevOptimize all the things, meaning automating and tracking fastidious aspects of software delivery. For technical people, using technical means to solve problems is natural. Creating yet another

Again, we tend to forget that these tools are there to support an existing and sometimes changing process.

Conclusion

We are all a bit victim of our ways or habits. To recognize this allows us to change. And change means to become a bit more permeable and empathetic to other people's preoccupations. In the end we are all trying to succeed together. If we take a moment to look at what and how we change, we can analyze what we do that makes us better. We have so much technology to help us, it behooves us to be judicious in our choices and sensitive to our peers' situation.

L'incident avec mon fournisseur de services financiers: Desjardins.

Aujourd'hui, j'ai reçu ce qui s'approche à une indemnisation de la part de de Desjardins. Un abonnement illimité, gratuit les premiers 60 mois, à une surveillance de mon dossier de crédit Equifax.


Avec ce dernier, une lettre qui explique comment activer ce dossier et des explications, tres tres tres sommaires sur les origines de l'incident.


Premièrement je comprends que la société a voulue etre aussi transparente que possible avec la situation telle qu'elle le pouvait.


De mon côté je me suis dit, qu'il fallait attendre de voir comment la société allait changer et quoi elle allait changer pour que je puisse me faire une opinion.


Et nous voici.


Je n'ai malheureusement pas de louanges à faire et quelques reproches, justement, parce que du changement, on ne nous en a proposé aucun.


Avec toute les informations et communications, publiques et privées que j'ai vues, il n'y a eu aucune admission de faute de sa part. Même si c’était que pour se protéger de litiges légaux, le fait que l'incident a pu se produire, il serait raisonnable qu'une évaluation et peut-être un changement s'en suivrait. Et c'est mon premier reproche.


D'admettre qu'une amélioration doit s'en suivre, n'est pas autant ouvrir au litige que de dire que l'amélioration continu, c'est une chose courante dans l'organisation. Clairement ce n'a pas fait partie d'aucune communication. C'est navrant.

Seconde, l'inscription à Equifax, est un abonnement OVERT mas gratuit pendant soixante mois. Et comme Equifax nous le mentionne, l'abonnement restera ouvert et facturable à taux de xx$ par mois après le 60e. Le mécanisme pour arrêter l'abonnement est flou et semble orienté pour s'assurer une clientèle payante si elle n'est pas diligente dans ses actions.

Bref si on oublie cette affaire, il vont faire de l'argent sur notre dos. Ce ne serait pas le premier modèle d'affaire que je connaisse qui se sert de l'apathie des gens, pour l'enrichissement.

C'est un à côté, toutefois, du deuxième reproche, que je voulais faire. C'est que cet incident, et la gestion de notre dossier de crédit, reste au final, notre responsabilité. Je n'ai pas vu aucune mention que Desjardins se mettait la tête sur le bloc, si un pépin arrivait à notre dossier de crédit.

L'engagement d'assurance, de responsabilité fiscale, est, on ne peut plus floue.
En public il disent qu'il vont offrir une police d'assurance que notre risque est assuré. Mais en privé, c'est beaucoup moins clair et rassurant. On nous communique: "Voici un abonnement, surveille tes affaires". Si il y a une problématique, voici un numéro "1-800" mais on vous en dit pas plus.

Ce qui sous-entend, on la limiter notre engagement et on espère qu'un appel téléphonique est le pire qui en ressortira. Un engagement de responsabilité, clair et écrit, c'est pas pour tout de suite, sinon jamais.

Il y a eu une opportunité de manqué, de briller dans cette affaire. Et à la place on nous offre du brouillard. Dans un post, subséquent, je vous partagerai le document (anonymisé).

Finalement, ce que j'aurais aimé, c'est qu'ils allaient garder mes (nos) données comme dans un silo nucléaire. Qu'a chaque étape à franchir, pour accéder à mes (nos) données, qu'il doit y avoir deux personnes qui se regardent dans les yeux, et qui se mettent d'accord pour un accès légitime à ceux ci.

Ainsi, on ne pourra pas parler "d'un seul individu" qui agissait avec malice. Qu'il y aura une responsabilité claire, organisationnelle, sur l'accès aux données sensibles. Plutôt que la bonne foi des individus et des principes holocratiques.

Pour être complètement transparent, j'ai une vision bien pratique et opérationnelle (SecDevOps) sur la gestion des projets TI en entreprise et l'intégration des bonnes pratiques sur la sécurité.

Peut-être que cette vision me rend un peu plus critique, mais je vais laisser le soin à me co-opératifs fiscaux ou mes co membres Desjardins, d'en juger la sévérité.

Why do we do DevOps if we have Agile?

Is Devops the same as agile and how are they different?

So I'm often asked, JP, what is Devops Anyway? We already have Agile, is Devops supposed to replace it?

The short answer is no.

Agile is a software development methodology, that leverages cyclic reviews (sprints or iterations) that are defined as shorter than a month, to ensure the process maintains sanity. These reviews are traditionally driven by the people on the team(s) and quite subjective. They focus on delivering what was promised above and beyond all manage intrinsic "unexpected" change. 

Devops over-arches this. It reviews cycles with "mechanical" and automated metrics. It attempts to depersonalize and make measurements as objective as possible. It's cyclicity is as short as a delivery cycle, which ideally can be several times of day. But the data can be reviewed at any periodicity, included the sprints or iterations that Agile has defined.

Agile protects and isolates the development team. Their motivation is usually delivering what was promised in the most expedient way. In some ways, it contributes to silos.

Devops exposes and wants to include the teams of previous and following processes. The pretension being the more you know about those you will be working for or with, the better off you will understand what you need to do. It promotes autonomy rather than isolation. Continuous improvement instead of a stable recipe for stable software delivery. It considers the human factor as something to leverage, by also the Agile process itself. And lets not forget all the tools and automation that people usually associate with the term, in the first place.

So in my opinion, Agile is more about software development and Agile is more about all around business needs. After all it allows you to do more while using less. It focuses on adding value rather than maintaining a stipulated agreement.

But as I often say, my promise is my process. If it is built to consider experimentation, failure and success as part of it. How can I possibly lose? And to me, that is the best of what Devops has to offer.

Qu'est-ce qui a de nouveau a comprendre de DevOps?

Qu'est-ce qui a de nouveau à comprendre de DevOps au Québec?

Les deux faces de DevOps

Il semble que si on allait simplifier la signification du terme DevOps on l'aurait fait.

Démystifier DevOps, cela restera un enjeu, mais pourquoi?

Étant un sujet toujours aussi "sexy" il y a beaucoup "d'appropriation" du terme DevOps.

En effet il y a des ressources qui prétendent être "DevOps" comme si c'était un rôle.

Pour que cette ressource soit désirable comme un espèce de nouveau Guru dans l'entreprise.

Certainement en plaçant un guru sur lequel la réussite ou le blâme peut être facilement visé, est d'intérêt pour la cupidité humaine, par exemple. Et les recruteurs du Québec profitent de cette confusion en allant chercher tout et n'importe quoi qui est précédé ou qui contient le terme DevOps et le vendant comme une panacée.

Et on en a pas fini avec la cupidité, regrettablement...

On est pas un "DevOps", pas plus qu'on est un "Agile".

Mais c'est vrai qu'il y a des spécialistes en opérationalisation ou en automatisation de déploiement qui sont critiques à DevOps, c'est vrai. Et c'est l'étiquette DevOps est hyper-vendable... alors il s'approprient aussi le terme, se disant qu'il s'expliqueront et comprendront avec le client ultime. 

J'ai du mal à les blâmer.

Tout comme un Scrum Master est requis dans la méthode Agile, ces spécialistes sont cruciaux, certes, mais tant que ce faux débat ne sera pas éclairci, le bruit qu'il représente justifiera un ralentissement de l'adoption du DevOps.

Alors quoi?

Aujourd'hui comment on peut mieux exprimer c'est quoi l'apport de DevOps?

Dans les faits il s'agit plutôt d'une façon de faire, holistique. Avec DevOps on veut devenir une équipe hyper performante et celle-ci ne doit pa être dépendante d'individus détenant la science infuse, au contraire. Même si on veut industrialiser le processus de livrer du logiciel, pour être efficace on doit considérer la ressource ou matière première: les gens. Pas des gurus ou des Super Héros.

Effectivement si ils s'agit d'humains, il nous servira bien de les apprécier à leur pleine valeur, et quel est le meilleur moyen d'en tirer le maximum, sinon de les avoir motivés à réussir?

Donc, contrairement à Agile ce n'est pas tant une méthode qu'un état d'esprit ou une philosophie, à la limite, à cultiver.

On doit capitaliser sur le bénéfices d'un esprit collectif, notamment.

• L'aise de communication
• Un effort orienté vers un but commun
• Une compréhension des préoccupations/des rôles professionnelles des individus au sein de cette collectivité pour être sensible à comprendre que la réussite de l'un entraîne la réussite de la collectivité. Et il en est de même pour l'échec.
• L'expérience collective est un atout important.

Il devrait être clair qu'un saine collaboration gagne sur l'individualité.

Et parmi les préoccupations majeures que DevOps tente d'adresser dans un projet, au sein des équipes en voici des exemples saillants, dans aucun ordre particulier:

• Savoir négocier et décider en équipe de façon efficace
• Réduire le travail en cours (WIP ou Work In Progress)
• Faire la bonne chose au bon moment (Do the right thing at the right time)
• Faire les choses en amont, de ne pas faire attendre ce qui ne le doit pas. (Shift Left)
• Exploiter les contraintes
• Cultiver la confiance
• Augmenter l'autonomie des équipes.
• Faire les erreurs au bon moment.
• Experimenter et apprendre.
• Que DevOps soit un objectif commun
• Comprendre la valeur que DevOps apport au projet(s)
• Défaire les silos qui séparent les préoccupations classiques, soit entre Dev et OPS ou même encore La sécurité DevOps/SecDevOps
• Bien gérer le travail planifié versus le travail imprévu.
• Cultiver un environnement de travail sain, où le bien commun et la charge est bien distribuée.
• Avoir un processus qui supporte la réalisation efficace.
• Automatiser et systématiser ce qui en vaut la peine, plutôt que de tenter tout le faire.
• Capitaliser de la flexibilité des infrastructures virtuelles et agiles pour aller plus vite avec moins de risques.

Si il y a raison de voir un importance de comprendre ce que cette relativement nouvelle façon de faire apporte, est justement la sensibilité au temps que ceci peut avoir.

Pourquoi c'est si lent à arriver?

Démarrer une initiative DevOps sans échec est beaucoup plus facile qu'on se l'imagine et pourtant le monde des TI est très hésitant à démarrer particulièrement au Québec.

Depuis près de cinq ans la communauté et moi-même, poussons et tirons dans tous le sens pour obtenir une traction sur le changement bénéfique proposé. Tout le monde parle de révolution numérique, mais les projets TI ne consomment pas les bénéfices systémiques qu'ils proposent souvent eux mêmes!

Quand on comprend qu'il ne s'agit pas de tout révolutionner d'un seul coup, qui s'agit d'utiliser la progressivité itérative pour, experimenter et mesurer sa réussite, on comprend du coup, qu'il s'agit d'une transformation culturelle et mentale à la base. Et même si l'initiative est bien mature dans les pays francophones de l'Europe, au Québec, on traîne de la patte, comme on le dit. 

Et si on regarde le temps que la méthodologie Agile prend du temps à se propager ici, et pourtant sa maturité, on comprend qu'on ne peut pas se vanter d'être toujours à l'avant garde des bonnes pratiques de industrialize.

Les organisations justifient leur reticence, en partie de ne pas vouloir perturber les employés ou opérations actuelles. Surtout qu'au Québec, je dois le dire, la pénurie de main d'oeuvre qualifiée en TI a généré toute une troupe de personnes sur le marché du travail qui se comportent en "royauté", qui au moindre dérangement menace le départ.

Mais DevOps n'est pas sensé être perturbateur même si c'est transformateur. On est sensé travailler mieux et non plus fort. Plus intelligemment avec plus d'empathie.

Et c'est pourquoi il est impératif comme leader ou dirigeant d'entreprise de bien comprendre le bienfaits. Si on est sensé en faire une transformation organisationnelle, il devient évident comment le choix du porteur de cette initiative est critique.

Mais cela s'en vient.

Mon observation du marché propose qu'il y a un movement en cours. Éventuellement il y aura ceux qui sont Agiles et Devops et les autres. Le organisations qui tardent à changer auront toujours une place figurant dans le logiciel "à bon marché" ou peu dispendieux. Le prix final de la réalisation d'un projet est encore un facteur important dans la considération de la clientèle actuelle du Québec.

Mais ceux qui auront adopté Agile et Devops, auront l'avantage de la qualité, l'habileté à redresser des scénarios incohérents, des équipes heureuses et surtout efficaces. 

Alors ma question pour vous est: avec qui voudriez vous travailler?

What Is Devops (again)?

Besides all the unicorns and harmony that the evangelists will surely blare your ears off with, lets talk about why DevOPS works.

Operationalizing

Yeah, a big word indeed. But let's face it, if you have reached peak workplace harmony you certainly will have achieved something, but certainly not the 40 to 60% improved effectiveness that Forbes forecasts :

DevOps practices are designed to dramatically improve both the efficiency and effectiveness of the delivery process to increase speed and lower cost and risk. Companies like Nationwide (a former customer of mine) have seen a 50% improvement in code quality and a 70% decrease in end-user downtime, with 58% of their teams in the top productivity quartile of the industry. 

Kristof Kloeckner CommunityVoiceForbes Technology Councili

Feb 23, 2018

Source DORA State of Devops 2018

So what does it take to get these increased performances and high effectiveness?

Let's talk about value..

Value is the product of Quality and effectiveness or as I like to express it Q x E = V.

So what we are trying to accomplish is twofold, improve Quality and Effectiveness. Increasing one at the expense of the other is possible, but in the end, if "V" doesn't go up, you have failed at delivering what DevOPS promises. There are many other factors that can fit in the equation including security and velocity. Suffice it to say, we are trying to get more value out of the existing processes.

The reason it's called that way, is because traditionally, there were isolation between the Dev teams and the Ops teams. And DevOPS uses increased visibility and collaboration between these two entities as a means to improve effectiveness. But that is hardly all it means. We do know now that a breakdown of this "traditional" silo is great.

And it doesn't mean that we must necessarily hire people that have both competencies. We just need to work together, better.

The "trifectas"

So any technique we can find, to help anchor the basic ideas behind DevOPS, within teams' work, turn out to be very useful tools to keep them focused on the goals and principles that we strive for.

The use of visual aides is certainly one of them. Psychologically, Venn diagrams are effective to imprint on memory conceptual links between what are sometimes distinguished as separate and unrelated entities. The fact that the number of elements is limited to three is also a factor. Memory works good in threes. Even memory is a three stage system.

And as far as mental data processing, pictures just work.

This is one of the classical representations. Of DevOPS, but not the only one. 

Again, this visual representation takes on the combining the 3 skills that DevOPS want to promote.

And Finally:

There is an important thing to note. Though none of the proposed diagrams address specifically quality it is my belief that through these efforts, better quality is attained. It is part of my "value received" equation, but not something whose focus should suddenly appear because DevOPS is what we are trying to achieve.  Instead we try to focus on bringing new skills to the table.

The diagram I find the most compelling is the center one.

There's an important point there. And that is, that though DevOPS is real and there are some techniques that are becoming time proven, there is no sigle approach that works for all.

It can be compared to an effective hack. Though the results are known, valid and measurable, there is no science known that states clearly how to optimize a complex process such as a software delivery project. Hence, this is the approach I have adopted and may not be the same as other proponents.

Creating a team or company DevOPS manifesto, focusing on the desired values is very helpful in understanding the common goal.

People

It should be clear at least, that the primary resource for a software delivery project is it's people. Their endeavor must be done with a maximum of cohesion and motivation. With these two main factors well tuned, work can be accomplished conscientiously, that is, considering the other parties that each required to get something "out the door" at some point.

So in practice, if the software developer wants and desires a good product review, they must be "aware" and "care" about quality, which arguably is someone specific/else's department. This empathy and consideration is really great for ensuring the collaboration level that can be reached in high performance environments. All kind of techniques including pull principles, team building exercices and other playful ways to learn how to become better collaborators, will tune this very essential part of the business' work. It is in fact in the business' best interest to make sure of the cohesion and well being of the people that produce the work. A less coercive and a more "buy in" approach becomes more effective. We need to evolve to a better way of working together less we fail compared to the ones who do. Simple, but hard.

Process

I've come to really like the sentence: Being efficient is doing it right, but being effective is doing the right thing. Realizing this, there is a time for doing either and both. And it has much to do with understanding constraints. Constraints are often artificial artifacts present to protect processes. By reevaluating the actual gains from eliminating them versus the risk of hitting an issue from having removed them, are we able to effectively decide if they are meant to be. And when we remove constraints we often gain in velocity or efficiency.

Once we have our people on board, it becomes possible to use their personal aptitudes, beyond their specialties, to fill in some gaps to make processes become even more fluid.

On that note I would like to share two videos that were part of the last DevOPS event I went to.

As you can see the principles demonstrated in these clips can give some interesting cues about one's process. Another key clue it to remind oneself that processes are there to serve people, not the other way around.

There is fortunately an abundance of techniques and methodologies to help plan effective work in the software development cycle, such as CMMI, Agile or SAFE agile. However there are parts outside these processes, that require some examination in order to become more effective, so, in DevOPS we look at the whole picture, all of the formalities if you like, that make-up the processes to deliver software.

A good way to explain the way to work, is by having stages of planning, doing, validating and adapting. PDCA is a good example of this.

Ideally, we will treat this workflow, as a document, or artifact that upon revision, gets tracked. And performance of our delivery is measured between iterations of these revisions. Thus, finally, we can know objectively that when something within the process changes, the impact, is. So yes KPIs are essential to measure a successful change.

Tools

As I wrote in a previous whitepaper, there certainly is a appetite for this part of DevOPS' benefits. It is certainly what seems the most tangible thing to change. Automation and uniformity is indeed a good way to maintain a level of efficiency and velocity. Uniformity is truly an important key to make the tools work right. After all, my motto is "my process is my promise". If my process works once it should always work the same, the condition being that there are no unexpected or untested changes between the différent stages or iterations.

After all, it seems obvious, that tool builders need tools. So software delivery services will need tools to make their processes thrive. Well integrated and good quality (good support and maintained) software tools will make these deliveries safer and easier. The tools are made to be helpful and improve work. So using tools just to be up to date and understand technology is a adding risk, which is anything but DevOPS.

And speaking of tools, one I find is often lacking is a proper CMDB. Having a place where your tools can get the most updated version of your configurations, documentation and processes can be a great help in increasing value to your projects.

One of the People aspects that is greatly affected by the tools is communication. Better communication tools bring in better collaboration. Thus we can see how these three imperatives intersect, for real.

Conclusion

Here are some tips on how to approach this endeavor with the greatest chances of success.

• Identify the weaknesses of your current ways of doing. See if there is a match for some values that could make it a quick win/benefit for a project, to fix or improve these flaws.
• Prepare to fail. Not only is it realistic to say something like so, but with today's technologies there are ways to simulate delivery in effective ways that will not impact business but teach you much needed lessons.
• Make it so that people want to own failure as much as success. There is no silver bullet solution to this, but it can be such a great value to have in collaboration to make failures learning experiences instead of demoralizing experiences.
• Baby steps. Try to make a map of the smaller changes that can bring the better benefits. This is like saying minimize you risks but do not lose sight of gains.
• Get everyone on board. A general buy-in from all parties (including the "C" suite) is a requirement for your endeavor to succeed. Beware of the detractors and of roles in ivory towers.
• Choose your tools wisely. Trying to be too ideological will only create unnecessary constraints. It does makes sense to have a certain cohesion and integration in your tooling. But refusing to integrate other tools simply because they are not part of the "out of the box" experience is nonsense dogma, unless you have deliberately chosent to limit what your practice will cover.
  This is a business decision, not a DevOPS one.

Need more help? Join me via the comments section below. I will be sure to put my 25 years of practice to your service. As they say, the first one is free. ;-)

The Millennial Workforce Needs Mentors, Not Managers

Celinne Da Costai

TWEET THIS

• First of all, sorry for copy pasting this, but there is just too many pop ups on the forbes website.
  But here's an article I wanted to share.
• 
  
• 
  
• We need leaders who set us up for success, instill in us a sense of bigger purpose, and give us the confidence we need to persevere when the work gets challenging.

Millennials need leaders who set us up for success, instill in us a sense of bigger purpose, and give us the confidence we need to persevere when work gets challenging.PATRICK FARRELL PHOTOGRAPHY

Millennials are currently the largest generation in the U.S. labor force and will comprise more than 75% of the workforce by 2025. Not only that, Millennials now have the most spending power of any generation, which means that creating a work environment that they can thrive in matters more than ever.

As a Millennial who worked in corporate for several years before calling it quits, I’ve witnessed first-hand the many ways in which companies adhere to outdated norms, many of which are still tailored to older generations. This is particularly true when it comes to management.

Today’s workers don’t need some Big Brother figure hovering over us to tell us that budgets are cut, that we will be in big trouble if we don’t meet deadlines, and to "make do with less." We need leaders who set us up for success, instill in us a sense of bigger purpose, and give us the confidence we need to persevere when the work gets challenging.

Corporate culture in the U.S. is changing in a big way, and companies who pay attention and adapt to these changes will be the ones attracting the most talented, passionate, and dedicated employees.

Millennials don’t want (nor will respond to) an archaic management system that dictates rules and constraints – this generation craves mentors that guide and inspire them. Management can help the rising Millennial workforce thrive by:

Make the work a relationship, not a transaction.PHOTO BY RAWPIXEL ON UNSPLASH

Creating a relationship of trust and understanding. Management should empower and build the confidence of its employees. This means no guilt trips, blaming, or pressuring. Employees should feel free to approach their managers and speak openly with them without intimidation, while still respecting employer-employee boundaries.

We no longer live in a world where it’s possible to completely leave our work at home. People deal with personal issues all the time, and management should have some level of sensitivity towards that instead of pretending that the separation between life and work is an impenetrable brick wall. For example, context is important – perhaps someone isn’t performing because they had a recent family death, and that does not mean they’re incompetent.

Employees should feel that management won’t turn its back on them the second something goes wrong. When people feel understood and part of something bigger than themselves, they will go to greater lengths to excel in their work.

This mentorship dynamic builds way more trust and loyalty than a raise or bonus ever could, as it cultivates a mutual relationship instead of a transaction. Knowing that management has their back is priceless and will benefit both parties in the long run.

Letting people fail... and helping them get back up. Ideally, mistakes in the workplace are avoided altogether as some can be very costly and put the company in jeopardy. If that is not the case, however, mistakes should be approached as opportunities for learning and improvement.

Mentors should teach employees to take responsibility for their actions, as well as accountability to fix what goes wrong. Most people won’t thrive with finger pointing, blaming, or winded lectures: we need to be made aware that we’ve made a mistake, given the confidence that we are capable of fixing it and receive the support to do so.

By guilting or threatening employees, there is a good chance that they will develop fear or apprehension towards the task they originally “failed” in, which only makes the situation worse and poorly sets them to deal with future mistakes. Mentors should push employees so they’re exiting their comfort zone (which means failure is a possibility), but at the same time guide and set them up for success. That way, when someone does inevitably make a mistake, he or she knows how to deal with it responsibly and confidently.

allow people to be themselves and create the environment they need in order to thrive, and they most likely will.DEREK SIMPSON PHOTOGRAPHY

Giving space for growth. People operate differently when it comes to getting into their zone of genius. Allow them to practice freedom and accountability when it comes to their working style: for example, why not allow an employee to work remotely, from a coffee shop, or in the nighttime if that is how they best excel in their tasks? Have a detailed discussion on what they personally need to thrive in the workplace, and as long as it does not interfere with the quality of the work, let them do it.

Management should not push employees to work a specific way, as that will stifle them and therefore affect their ability to perform. If an employee works best out of coffee shops and you make him or her feel guilty about leaving the office, the overall productivity of the team will suffer.

The gist of it is: allow people to be themselves and create the environment they need in order to thrive, and they most likely will. Coerce them to do things a certain way, and they’ll likely resent management and subconsciously (or consciously) sabotage the work.

When it comes to the Millennial workforce, focus on the results and not the method in which they are achieved. In the end, the companies who stay up-to-date with their workforce’s needs and desires will be those who make the most profit and have a societal impact.