Thanks to the company I’m working for (Techsys) I’ve had the opportunity to attend the configuration management camp in Gent (be) for its 2016 edition. I really enjoyed those two days of talks, watching people present different ideas of a possible future for the infrastructure and deployment engineering. Beyond the technical demonstrations and the experience sharing, I’ve spotted a bunch of ideas Among all, those that comes to me spontaneously are:

I’ve read a lot about graph theory recently. They have changed the world a lot. From the simple representation to Bayesian network via Markov chains, the applications are numerous. Today I would like to imagine a graph as a workflow of execution. Every node would be considered as runnable. And every edge would be a dependency. It is an important framework that may be used to as an orchestrator for any model, and of course I am a lot thinkingabout TOSCA

From time to time, I’m involved into a trolling conversation when any linux kiddie tells me: Bash is really the superior shell I totally disagree, but as I’m getting older, I don’t argue anymore. Anyway, in this post I will expose two arguments, or I should say two reasons, why I usually use ksh93 to run my scripts. Note I’m really talking about the engine of the script, (the shebang definition).

About TOSCA The TOSCA acronym stands for Topology and Orchestration Specification for Cloud Applications. It’s an OASIS standard. The purpose of the TOSCA project is to represent an application by its topology and formalize it using the TOSCA grammar. The [TOSCA-Simple-Profile-YAML-v1.0] current specification in YAML introduces the following concepts. TOSCA YAML service template: A YAML document artifact containing a (TOSCA) service template that represents a Cloud application. TOSCA processor: An engine or tool that is capable of parsing and interpreting a TOSCA YAML service template for a particular purpose.

In the cloud computing, alongside of the hosting monsters such as amazon or google, there is the Openstack Platform. Openstack is not a single software, it is more a galaxy of components aim to control the infrastructure, such as hardware pools, storage, network. The management can then be done via a Web based interface or via a bunch of RESTful API. I would like to evaluate its identity service named keystone and use it as a AuthN and AuthZ backend for my simple_iaas example.

In a previous post I have explained how to develop a very simple API server. Without the associated documentation, the API will be useless. Let’s see how we can use swagger-ui in this project to generate a beautiful documentation. Note I’m blogging and experimenting, of course, in the “real” life, it’s a lot better to code the API interface before implementing the middleware. About Swagger Swagger is a framework. On top of the swagger project is composed of several tools.

Abstracts Recently, I’ve been looking at the principles of a middleware layer and especially on how a RESTFULL API could glue different IT services together. I am reading more and more about the “API economy” I’ve also seen this excellent video made by Mat Ryer about how to code an API in GO and why go would be the perfect language to code such a portal. The problem I’m facing is that in the organization I’m working for, the developments are heterogeneous and therefore you can find ruby teams as well as python teams and myself as a go team (That will change in the future anyway) The key point is that I would like my middleware to serve as an entry point to the services provided by the department.