Here our second post from our series on DevOps automation models. Model-driven delivery automation is based on predefined blueprints of the environments.

Blueprints model what needs to exist and where. Logic is then attached to the distinct components in the blueprint by defining how each component can be created, updated or decommissioned.

You see model-driven deployment as the preferred method used by many of recent Application Release Automation (ARA) and also some Configuration Management tools. The approach became popular in the early 2000s when Software Defined Data Centers and Virtual Machines became the new norm.

Models came as a welcome improvement over process systems. Using Model-driven systems, you need to understand and represent the environmental model first, then define how to deliver changes to it. By understanding the environment, model logic becomes segmented, and therefore reusable.

A higher abstraction

Let’s make another analogy to software development to make the model-driven concept clear. Around the early 2000s also Model-driven Development (MDD) became popular as alternative to traditional development. There are two core concepts associated with model driven development: abstraction and automation.

In MDD, the software application model is defined on a higher abstraction level and then converted into a working application using automated transformation or interpretations. The right model driven development approach leverages model execution at run time, where the model is automatically transformed into a working software application by interpreting and executing the model (removing the need to generate or write code). This means that executable code is “generated” automatically based on the model and transformation of this model based on the specific lower-level environmental settings. The higher the level of abstraction, the more likely reuse becomes possible. For this reason, a model driven development platform is often referred to as a high-productivity platform given the unprecedented speed at which developers can build and deploy new applications. This speed is derived from the use of models and other pre-built components that business and technical teams use to visually construct applications.

The approach described above can easily be mapped to application delivery as follows: Those responsible for environments, application components, and deployment processes are all able to work together, but they define and manage their own delivery related aspects separately. As such there is a clear separation of duties and abstraction is made for each area of focus:

• Application model (e.g. application server, web server, database server, WAR, SQL, GEM, service bus, etc.)
• Environmental model (e.g. public cloud (public, private), container platform, ERP packages, VM, OS, storage, network, security, etc.)
• Process model (e.g. installation order, variable settings, dependencies, etc.)

The first step in a model-driven approach is therefore to define a blueprint of the environment:

Model-driven delivery automation is often split into three or more layers. Each layer is orchestrated/modeled separately, for example:

The main features of model-driven automation include:

• Models the environment components and their relationships.

• Higher level of abstraction.

• Not tightly coupled.

• Components are reusable.

• Component orchestration process is detached.

Model driven automation requires complex orchestration to get even the simplest of things done

Pitfalls

Today, model-driven automation is important in and integral part of most configuration management tools and enterprise infrastructure automation software. Moreover, container technology such as Docker has models built into its metadata.

But this creates a challenge: in the realm of continuous delivery, modeling has become synonymous with duplication. In a world where containerized microservices and infrastructure-as-code has attained widespread adoption, the model is already embedded in the application or service being delivered. What is the point of having to implement another copy of it in your ARA tool?

On top of that, in hybrid platform environments, models are also hard to get started with. They require describing complex enterprise architectures and application relationships in a graphical view. It would be great to see the model of an environment that spans ERP packages such as SAP or Siebel or Salesforce, in combination with some mobile and mainframe LPARS…

Finally, previous work, such as scripts or processes, are harder to adapt to models, since we saw that scripts combine actions with correlated steps. So model-driven systems are tougher to migrate to if you want to retain investments already done.

In the next blog session, we will take closer look at rule-driven automation, a final alternative way to handle deployments which provides a solution to some of the challenges raised.

See also:

• (R)evolution in delivery automation paradigms 1/4

Get an early start and try Clarive now. Install your 30-day trial here.