VMUGIT User Conference 2014 Application Portability Kamau Wanguhu,VMware

1. © 2011 VMware Inc. All rights reserved
Virtual Application (vApp) Portability
Kamau Wanguhu
Staff Engineer - Integration Engineering

2. 2
 vCenter and VCD vApps
 vCAC vApps/Blueprints
 App Director Blueprints
 The Future of vApps

3. 3
vCenter and VCD Applications
vApps

4. 4
vApps in VC: Current State
 Distribution: OVF
• Packaging format, not directly runnable
• “Deploy”: Convert to target runtime format, and bind to resources
• Extensible format
• Built-in mechanism for customization on deploy
• OVF Properties
• Attributes to be configured
• Defined by vApp author
• OVF Environment
• Runtime method to assign values to OVF properties
• IP/mask/DNS/Gateway
• Passed to the VM, usually requires glue code

5. 5
OVF Properties

6. 7
Side-step: Guest Customization
 Another mechanism to customize VMs
 Fixed set of properties
• IP addresses
• Administrator password
• …
 Fixed UI
 Injects scripts into VM to apply settings

7. 8
Recap
 OVF: Distribution format
• Extensible
• Built-in data-driven customization during deploy
• Studio provides scripts to apply common settings
• vApp author must provide code for custom properties
 Guest Customization
• Customize a fixed set of properties
• During deploy (VC) or entire life-time (vCD)

8. 9
Multi-VM vApps in VC
 Modern Apps consist of multiple VMs
 vApp is a container of VMs, managed as one entity
• Import/Export
• Power On/Off
• Includes ordering, so VMs are powered on/off in the defined order
• Shared vApp Environment
• Used to discover other VMs in the vApp
• Built on resource pools
• Can specify resource settings for the whole vApp
• Supports nested vApps
• vApps are limited to the span of a resource pool

9. 10
vApps in vCD
 vCD vApps exist only in vCD
• Does not use the vApp construct in VC
• Spans entire VDCs, not limited to a resource pool
• No vApp-wide resource limits
• Limited support for shared vApp Environment
• No nested vApps

10. 11
Dependency Injection: vServices
 vService Providers register with vCenter
 vApps can depend on vServices
 Dependency is bound to provider during deploy
• Can be re-bound later
 vService Provider can add information to the vApp’s runtime
environment
 Example: Database vService
• When bound, creates database specific to the vApp
• Detailed requirements in vService Dependency section of vApp
• DB connection string (address, credentials) provided in vApp Environment

11. 12
vCAC Applications
Blueprints

12. 14
 A specification for provisioning virtual or physical machines,determining
the machines characteristicsand the policies applied to it.
 Global or local blueprints
 Key Attributes
• Machine Resources – CPU, Memory, Storage
• Placement using ReservationPolicy
• Quota using ‘max machines per user’, ‘lease’, ‘archive’
• Approval Policies
• Build information using extensible workflows
• Security using permitted operations, access rules
vCAC Concept: Machine Blueprint
A
Requisition
Cost Profile
Provision
Manage
Retire

13. 15
vCAC Screenshot: Machine Blueprint

14. 16
vCAC Screenshot: Blueprint Build Information

15. 17
vCAC Screenshot: Blueprint Security

16. 18
 Result of an end-user requesting a machine blueprint from self-service
catalog
 Can be virtual machine, cloud machine or physical machine
 Day 2 operations permitted to machines based on blueprint security
settings
 Machine reclamation based on blueprint lease and archival settings
vCAC Concept: Machine

17. 19
vCAC Screenshot: Machine

18. 20
vCAC Screenshot: Machine Operations

19. 22
Multi-machine Blueprints
 Model an application environment comprised of multiple machines
 Made up of component machine blueprints with additional
metadata
 Machine operations aggregated at multi-machine level

20. 23
MMBP CBP Network Network Tab

21. 24
MMBP CBP Network LB Tab

22. 25
App Director Applications
Blueprints

23. 26
 Logical Application Topology
 Made up of “Nodes” (ex: Web, AppServer, Database)
• Node has logical template and compute, network information
 Nodes contain building blocks called components
• Service components (ex: mysql, apache) or application components (ex: war)
• Components reusable across blueprints
• OOB components, import from marketplace or build new
 Inter-node dependencies, Property bindings, Overridability
 Same blueprint deployed to multiple environments (dev, test, prod)
 Managed by ‘Application Architect’
AppD Concept: Application Blueprint

24. 27
AppD Screenshot: Application Blueprint
Components

25. 31
Future Applications
Options

26. 32
Future of vApps
 Need for a unified Application Construct
• Used on all platforms
• Preferably a standard, like IETF
 OVF 2.0 adds extra features that could be supported
• Placement groups
• Scale-out settings
• Auxiliary files in OVF Environment (not just a single XML file)
 Future of vServices 2.0(??)
• Used by some critical services,
• Service registry should be moved out of vCenter
• Better scale if built into a core services model
• Usable by platforms that do not need vCenter

27. 33
Future of vApps
 Open Framework
• Combine OVF properties and the scripts to use them in a single entity
• Scripts are automatically injected into guest OS and executed
• Data-driven UI prompts for user-definable settings
• Examples:
• Set IP address
• Install MSI/RPM
• Configure DB connection
• Completes the OVF customization story
• vApp authoring becomes easier
• vApp = Base OSs + customization ‘bricks’
• Can be applied to running VMs
• Re-customization
• Upgrades

28. 34
Future of vApps
 Converge AppD and vCAC Blueprints into one
• So that all AppD and vCAC blueprint scenarios can be met with single set of
concepts
• Machine provisioning, Infra Services, Software, Shared Services, Orchestration
 Simplify user experience
• Remove duplicate concepts (Cloud Provider, Deployment Environment)
 Take the opportunity to build for the future
• Support for version-controlrepositories – Blue Prints in textual form
• Comprehensive Extensibility

29. 35
Challenges
 Generic model vs. Domain Specific
• Blueprint is a “list of things” vs. “list of tiers made up of machines and software”
 Generic composition vs. blueprint specific fulfillment engines
 Diverse Use cases
• Pure IaaS, IaaS++, App Environments, Apps, DBaaS, PaaS, XaaS
 Diverse Personas
• Infra admins, Middleware, Consumer, Governance Admin, Providers
 Legacy functional contracts and technical assets

30. 36
Portable Application Use Cases
• Can be published so that it can be deployed in dev/test, Prod or cloud
• An App vendor can publish a vApp which can easily be deployed.
• Have controls that allows for On, Off, Suspend, Snapshots...
• Ability to reconfigure Application (add/shrink, scale…)
• Monitored for performance, alerts, usage….
• Backed up and restore to a different environment
• Protectedfrom a data center outage (rename/re-IP/…)
• Migrated to a new datacenter (with or without disruption)
• Easily migrated from a Customer site to the “cloud” and back again.
• Can be distributed; part in the “cloud” and part on customer site
• Can be decommissioned

31. 37
Audience Ideas and Feedback