The document describes a multi-target application (MTA) deployment descriptor that defines modules, resources, and dependencies for deploying a sample Spring Music application in a distributed cloud environment. The MTA descriptor uses YAML files to specify configuration properties, placeholders, and references that allow flexible deployment of the application and its modules.
3. Spring Music 2.0
Spring Music inspired sample
web songs and albums
news provider
external news provider
spring-music
Lifecycle
Management
Unit
Version 1.0.0
news
provider
web
DB
service
instance
external news
provider
4. What are the Challenges?
Develop
Deployment-specific configuration
Package and deliver
Deploy
Update
with no downtime
Undeploy
Application
DevOps
Team (~ 2
Pizzas)
Other Service
Business capability
Lifecycle
Management Unit
Version x.y.z
Java
(heavy data
processing)
BACKEND
Node.Js
(heavy data
processing)
FRONTEND
DB service
instance
PERSISTE
NCE
Geo-spatial
Service
EXTERNAL
RESOURCE
5. Multi-Target Application (MTA)
Business capability
Lifecycle
Management Unit
Version x.y.z
Java
(heavy data
processing)
BACKEND
Node.Js
(user request
processing)
FRONTEND
DB service
instance
PERSISTEN
CE
Geo-spatial
service
EXTERNAL
RESOURCE
MTA: my-app
Module
type
Resource
type
Module
type
Resource
type
Version x.y.z
6. MTA Descriptors
YAML files
extends
MTA
deployment
descriptor
MTA
extension
descriptor
*1
extends
7. MTA Descriptors
YAML files
MTA Deployment Descriptor (mtad.yaml)
extends
MTA
deployment
descriptor
MTA
extension
descriptor
*1
extends
8. MTA Descriptors
YAML files
MTA Deployment Descriptor (mtad.yaml)
MTA Extension Descriptor (*.mtaext)
extends
MTA
deployment
descriptor
MTA
extension
descriptor
*1
extends
22. What is an MTA Archive (MTAR)?
Container, compliant with the
JAR specification
Contains modules
a manifest and the MTA
deployment descriptor
Used for distribution of the
packaged app
MTA
deployment
descriptor
Java
WAR
Node.Js
Code
...
23. CF Deploy Service
CF CLI plugin to deploy MTA with
a single operation
MTA
deployment
descriptor
MTA archive
module
MTA
extension
descriptor
CF CLI
operator
Cloud Foundry
Cloud
Controller
CF Deploy Service
PostgreSQL
database
target
state
workflows
cf deploy
current
state
24. CF Deploy Service
MTA
deployment
descriptor
MTA archive
module
MTA
extension
descriptor
CF CLI
operator
Cloud Foundry
Cloud
Controller
CF Deploy Service
PostgreSQL
database
target
state
workflows
cf deploy
current
state
Server app with the goal to
bring the app to desired state
26. Supported Operations
Deploy (incl. from Git, in future from directory)
Update (incremental)
Blue-green deploy
Cross-MTA configuration
27. Enterprise Qualities
Deterministic deployment order and timing
Recoverability of a multi-step operation
Logging and auditability
Version evolution policies
Deletion of non-relevant artifacts
30. Open Source Availability
MTA model guide
MTA parsers, validators, persistence and utilities
CF MTA plugin
CF MTA deploy service
Spring Music MTA
31. Outlook
Evaluation from CF Controller API team Pivotal tracker item [done]
Proposal for incubation in CF Extensions [pending]
32. Outlook
Evaluation from CF Controller API team Pivotal tracker item [done]
Proposal for incubation in CF Extensions [pending]
Planed features:
Parallel materialization of artifacts
Rolling updates
Version rollbacks
Application configuration update
Docker support
Lifecycle hooks
Secure configuration management
34. Credits
Special thanks to all the people who made and released
these awesome resources for free:
Presentation template by 際際滷sCarnival
Photographs by Unsplash
35. 際際滷sCarnival icons are editable shapes.
This means that you can:
Resize them without losing quality.
Change fill color and opacity.
Isnt that nice? :)
Examples:
#5: CF-apps which constitute a larger application might even not qualify for being micro-services. Although pushed to an individual container, they might lack the essential micro-services characteristics of being independently deployable units. This happens if they don't expose stable API contracts. Sometimes, it is just not worth the effort to create such contracts because the individual CF-apps might not be created as a result of a domain-driven design approach, but simply for enabling independent scaling of application parts. Another common pattern is to break down the application into a UI-part (also acting as the initial user request processing stage) and a backend-part, each implemented with adequate technologies (e.g. node.js vs. Java). Both parts will be tightly coupled as new backend features need to be reflected on the UI, and a pure compatible evolution of backend APIs is realistically impossible, especially for immature products. Further, application private service instances logically are constituents of the application which needs to be considered during initial deployment, updates and deletions.
#6: Definition: A multi-target application (MTA) is comprised of multiple software pieces (modules) which all share a common lifecycle for development and deployment. These modules can be written in different technologies and deployed to different targets respectively but they all serve (different aspects of) a particular purpose for the application users.
#24: Deploy with a single operation, which also includes validating the completeness and consistency of an MTA on this platform.
Workflow-based Java server application
Automating the lifecycle operations of MTA apps in CF
Analyses the MTA archive and MTA ext. descriptor to build desired platform model
Materialize this desired platform model
Integrated in the CF and XSA CLI clients via plugins
#25: Deploy with a single operation, which also includes validating the completeness and consistency of an MTA on this platform.
Workflow-based Java server application
Automating the lifecycle operations of MTA apps in CF
Analyses the MTA archive and MTA ext. descriptor to build desired platform model
Materialize this desired platform model
Integrated in the CF and XSA CLI clients via plugins
#27: Deploy with a single operation, which also includes validating the completeness and consistency
#28: Deterministic deployment order and timing
Recoverability - resume deployment from the point of failure of a multi-step operation
Logging and auditability of the entire application lifecycle
Implement version evolution policies
Deletion of non-relevant technical artifacts
#32: Proposal for incubation in CF Foundation
Establish the standard for CF packaged apps for CF certified platforms
Standardize CF packaged apps lifecycle management
#33: We are working on more lifecycle automation aspects based on the declarative application model. This list is not complete but should show you our intended direction.