La voix d'Absimiliard

To content | To menu | To search

Tuesday 12 May 2015

Publish an API Service and have success

The idea is simple; nowadays everybody knows that exposing an API Service that will be used by a lot of developers that will create a lot of killer applications that will be used by millions of users will generate a big success for you. But as for other Internet services, exposing something on Internet is not enough to make it used. So often most of API Services are just never used because nobody care they exists.

Of course you can answer “Look at Facebook or Google, every time they propose a new API every body knows and it’s a success”. Yep but everybody is not Facebook or Google, and even them, look at Google+! They don’t need to make a lot of effort to promote a new service because they already have a lot of costumers that will make the promotion for them. It is to prevent company to abuse of that kind of situation that in Europe we have the notion of “abuse of a dominant position”.

So how can you make people see you service on Internet?

Continue reading...

Monday 11 May 2015

The legend of the One API

“One API to rule them all, One API to find them, One API to bring them all and in the darkness bind them”. There is no such thing as a one API. There are different kinds of API for different kinds of use. The rules to design them and to use them depend of the purpose of the chosen API. We can identify three main categories of API based on how they are exposed and on their purpose.

  • The Core API: It exposes elementary functions on a Data model to allow building a service.
  • The Service API: It exposes a service hat could be use by others applications.
  • The Presentation API: It exposes an API dedicated to an application for performance issues and simplifies development.

Continue reading...

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...