Introduction In my last post I introduced the notion of choreography as a way to deploy an manage application. It could be possible to implement self-healing, elasticity and in a certain extent self awareness. To do so, we must not rely on the certainty and the determinism of the automated tasks. Mark Burgess explains in his book in search of certainty that none should consider the command and control anymore.

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.

It is a week now that I’m playing with my chromebook. I really enjoy this little internet Terminal. I “geeked” it a little bit and I installed my favorites dev tools eg: The solarized theme for the terminal zsh with Oh-my-zsh tmux (stared with tmux -2 to get 256 colors) git vim a Go compiler The HUGO tool to write this blog. All of it has been installed thanks to the “brew” package manager and following those instructions.

In this series of posts I’ll explain how to setup a simple polling app, the cloud way. This app, written in go, will be hosted on a PAAS, and I’ve chosen the Google App Engine for convenience. I will not explain in this post how to setup the Development environment as it is described here A word about the Hosting Google Apps Engine is a cloud service aim to host applications without worrying about scalability, and technical architecture of the hosting environement.