When Microservices Meet Classical IT Organizations (Alexander Heusingfeld)

by Alexander Heusingfeld, innoQ

The “microservices” topic has meanwhile reached numerous IT departments and is discussed there. Interestingly, initiatives for introducing microservices are often started by middle management. However, frequently too little thought is spent on the effect a microservice architecture has on the (IT) organization of enterprises. Because of this I would like to tell of a number of “surprises” that I experienced during the introduction of such an architecture approach.

Pets versus Cattle

“Pets vs. cattle”[1] is a slogan that reached a certain fame at the outset of the DevOps movement. Its basic message is that in times of Cloud and virtualization, servers should not be treated like pets but rather like a herd of cattle. If a pet gets sick, the owner will likely nurse it back to health. Sick cattle, on the other hand, are killed immediately in order not to endanger the health of the entire herd.

Thus the point is to avoid the personification of servers—for example, by giving them names (like Leviathan, Pollux, Berlin, or Lorsch). If you assign such “pet” names to servers, there will be a tendency to care for them like pets and thus provide individual updates, scripts, adjustments, or other specific modifications. However, it is well known that this has negative consequences for the reproducibility of installations and server state. Especially considering auto-scaling and failover features as they are required for microservice-based architectures, this is a deal breaker.

One of my projects addressed this problem in a very interesting manner. The server and virtual machines still had names. However, the administration of these systems was completely automated via Puppet. Puppet downloaded the respective scripts from an SVN repository. In this repository individual scripts for each server were stored. This scenario could be called “Puppets for automated pet care.” The advantage is that crashed servers can quickly be replaced by exact copies.

However, requirements for scalability are not taken into consideration at all, since there can always only be one instance of a “pet server” named Leviathan.

An alternative is to switch to parameterized scripts and to use templates like “production VM for app XYZ.” At the same time this also enables more flexible deployment scenarios like Blue/Deployments. In that case it is not relevant anymore whether the VM app-xyz-prod08.zone1.company.com or app-xyz-prod045. zone1.company.com gets the job done. The only relevant point is that eight instances of this service are constantly available, and at times of high load additional instances can be started. How these instances are named does not matter.

  • [1] http://www.slideshare.net/randybias/architectures-for-open-and-scalable-clouds
< Prev   CONTENTS   Source   Next >