La voix d'Absimiliard

To content | To menu | To search

Sunday 10 May 2015

Architecture: The source of the Devops Path

One of the most important challenges of a project that wants to engage itself on the Devops Path is to reduce the noise on information flows between activities. Each time you have to take a data from a document to put it on another you create noise. You can make a mistake on the copy/paste; you can misunderstand the value you copy and loose some information or create false one; or you just cost time on a useless action.

To limit noise, the idea is to share the same Information System with all activities in a way it allow each one to have that fit its own needs.

All start with the architecture. If the guy who think the architecture of your project design that for some purpose component A has to send requests to component B to consume the API it proposes; it imply a lot of configuration.

  • Component B has to listen connection on its IP and port.
  • A flow has to be open between component A and component B with the valid IP and port (and all elements on the route have to be properly configured).
  • The IP and port of component B has to be configured on component A playbook.
  • Component B has to be monitored on component A side (it’s a resource of component A).
  • The context of the requests sent from component A to component B has to be documented for Support team.

Here for example we saw that the network flows are not really attached to the VM but to the software components that are deploy on those servers.

Continue reading...

Monday 4 May 2015

Support: A POI on Devops path

How the support team will manage to diagnostic issue is rarely think from the begining. Usually on non Devops project, developer create a software they give to integration that package it and deliver to operator that install and try to keep it up and running until next release. And then marketing detect a strange issue, so they ask dev team to investigate and as they don’t understand what occurs they send a kindly mail to operators “We have a strange issue. Thanks to investigate quickly” just like they could send lemons to Cave Johnson. The problem here is that developers should have the best knowledge of how their software works. So if they don’t know how to investigate the issue, how could they think other guys know?

The Devops Path offer a way to solve those kind of issue; Developers will have to take care of support needs on build phase rather waiting issues occurs.

What support team need?

To be allow to do troubleshooting and to keep a service up and running, you need several tools:

  • Monitoring: To check every component and their resources are ok.
  • Post Install check: To check all components are well configured.
  • Organized Logs: To check if a problem has occurs on use of the service.
  • Functional Diagnostics: To check all the data are consistent

And for all those checks, actions plan to solve the issue.

Continue reading...

Saturday 2 May 2015

What about continuous delivery?

Continuous delivery comes after continuous integration. The idea is to be able to have fluid deliver process to put evolution of application on production. One way that looks easy and simple to do continuous delivery is to automate the process of the delivery to allow developers to automatically send their stuff on the production platform without involving someone else. But as I try to present it on my previous ticket this is the dark path of the Devops.

The good way to make the delivery process fluid is to remove useless actions and documentations but to be careful to keep important knowledge exchange between team. For example having a word document that explain every command the operator has to copy/past to do the install is not an efficient way to allow him do deploy the software and to learn how to operate it. It could be great if the document that describe how to deploy the software could be understand by all the people involve and automatically execute by the computer.

So the first step is to find a way that all team involve on the delivery and deployment of the software speak the same language. It have to be simple to write but also simple to understand by some who use it; if you already has try to debug a big shell script you know that understanding script language is not always enough to understand what a shell does.

One language I found good for that need is the state language use by tool like Puppet or Ansible. Your deployment document describes the state of each element and its dependence with the other elements. When your document is executed by the tool, it ordnance each element according its dependence and check the state of each one, executing the action to change the state if needed.

So with little experience it is easy to write, easy to execute and easy to troubleshoot.

Continue reading...

The Devops path

Devops is the new Agility. As for Agility few years ago every IT projects are already or plan to be soon in Devops mode. But as for Agility when you speak with teams and check what is really done you quickly understand that most of people don’t know what Devops mean. It starts to become as Agility a good word to use for “bullshit bingo” and an excuse to do stupid things on IT project management.

The Wikipedia page about Devops starts with: “DevOps (a portmanteau of "development" and "operations") is a software development method that stresses communication, collaboration (information sharing and web service usage), integration, automation, and measurement of cooperation between software developers and other information-technology (IT) professionals.”

The Agility methods were created to solve the issues implied by the long development cycles on internet services: most of the functions think months ago are useless and now the service is launched we discover that most of the functions that users need have not been coded. So Agility methods answer those issues with shorter development cycles that allow building the service step by step with loopback from the user to redefine the target of the project.

Devops movement come from an observation: on small project that involve a team that work together on Think, Build and Run activity, the quality of the service is better and adding new feature on production are more “fluid” than for bigger project with clear boundaries between each team. So Devops principles are to reorganize the work on the project to remove the boundaries between teams and allow guys to better work together. Devops not just involve developers and operators; all the people involve on the project are concerned by Devops.

If your Devops approach is to remove one team of the equation, you are probably on the wrong way!

Continue reading...