Cloudify introduces Environment as a Service, the next generation of orchestration covering all your automation needs.

1. 1
All Clouds
Any Service
Unlimited Locations
Introducing
‘Environment as a Service’
-Cloudify 5.0.5 Webinar
Cloudify Product Update Webinar

2. Agenda
● Cloudify 5.0.5 update
○ Cloudify at scale
○ Service composition & EaaS
○ Operability
● What’s next

3. Cloudify at Scale

4. Enterprise-grade
Highly Available Topology
Cloudify’s high availability topology has been updated in v5.0.x to
improve the availability and robustness of the Cloudify service in
cases of malfunction. It further allows for easier scaling to get
more work done by your Cloudify manager.
The new topology allows for either:
● Single, all-in-one manager (with no high availability and
no cluster option)
● Highly available cluster as described here, based on 3
services (on separate nodes) with Managers, database,
and messaging queue each operating as a highly
available cluster, on separate nodes.

5. Public Cloud DBaaS as
Cloudify’s Database
With version 5.0.5 Cloudify supports an external DBaaS. The certified
solutions are Amazon Relational Database Service (RDS) and Azure
Database for PostgreSQL.
Setting up Cloudify with external DBaaS leverages public cloud
support for mission-critical workloads and predictable performance,
security, high availability, as well as dynamic scalability.
Customers may also bring their own maintained PostgreSQL
server/cluster

6. Cluster & Manager Status
Improved system health mechanism is introduced in v5.0.5, extending
the manager status information with cluster status command and
widget providing visibility into the operational status of the cluster
(active, degraded service, service is down) with detailed information
about each of the nodes by role type.
The manager’s health and cluster management (HA) widgets
have been updated to better describe the system’s health.
Manager status command - the operational health of each
manager for load balancing among the active-active managers.
Cluster status command - designed to support Global Load
Balancers (GLB) or other networking services as a means to
determine the cluster health.
[root@2a85ca0b2643 /]# cfy status
Retrieving manager services status... [ip=localhost]
Services:
+--------------------------------+--------+
| service | status |
+--------------------------------+--------+
| Cloudify Console | Active |
| PostgreSQL | Active |
| AMQP-Postgres | Active |
| Manager Rest-Service | Active |
| RabbitMQ | Active |
| Webserver | Active |
| Cloudify Composer | Active |
| Management Worker | Active |
+--------------------------------+--------+

7. Scaling of the Cloudify manager (for more workload) is
achieved via two methods:
● Enhancing the cluster form factor (more compute power
and memory)
● Setting more Cloudify managers in the cluster.
Thanks to the new active-active approach, scaling is made easy,
and each added manager will partake in the workload.
● Linear scaling using HW
● Almost linear scaling with additional managers (verified
with 3-6 active managers)
Cloudify Manager Scaling
● 1000 workflows per hour on a single box
● Over 5000 workflows per hour on a Cloudify cluster
● Tested with over 2M deployed nodes

8. Organize the Chaos
Leveraging Site Management
Managing multiple locations with massive numbers of
systems and services is challenging.
Cloudify ‘Sites’ allow grouping of deployments by location,
providing visibility into installations in your data centers,
public cloud regions, branches, or edge sites.
The site’s concept with filtering and operations is partially
available for all premium users, while the map view and UI
widgets are limited to Spire license.

9. Service Composition

10. Service Components
Composing a service blueprint is easy. Keeping your blueprint code maintainable, readable and reusable is typically the challenge.
As a service designer, one should not have to describe every tiny object each time a service is required. Service components provide the
answer to this.
Services grow more and more complex, with a larger number of components and more complicated sub-services (e.g. a database cluster in
highly available mode consisting of dozens of nodes, ports, VMs, security groups, etc. as a sub-component).
A service component is a new node type that embeds a complete sub-service blueprint as a single node. Service components are easy to use
across blueprints and keep your code organized, easy to read, maintainable, and most importantly reusable. Components can be updated
independently from their hosting deployment- making day 2 operations even easier.

11. Shared Resources
Shared resources are a special case of components and represent those that are used by multiple services. These can be referenced directly
through the blueprint without the concern of setting them up or tearing them down as part of the deployment.
Cascading workflows from the hosting deployment to the component can be enabled/disabled, allowing for complete flexibility running day 2
operations on the relevant parts of the service.
app_using_shared_resource_node:
type: cloudify.nodes.Root
relationships:
- type: cloudify.relationships.depends_on_shared_resource | cloudify.relationships.connected_to_shared_resource
target: shared_resource_node
target_interfaces:
cloudify.interfaces.relationship_lifecycle:
establish:
inputs:
workflow_id: <workflow id of the shared deployment>
parameters: {}
Parameters to
be passed as
workflow
inputs

12. Cloudify Composer
5.0.x provides a makeover to the Cloudify Composer making it much
easier to create your first blueprints through a drag-n-drop
interface. The Cloudify composer provides a new project view
organizing your blueprint packages and providing better visibility
into the blueprint resources and properties.
Easy composition, switching from code to topology views, package
import, and real-time code validation are available out-of-the-box.

13. Environment as a Service

14. Operability

15. Reduce Human Errors Using
Input Validation
An operator or any team member running a deployment is not
always aware of the input specifics required for that blueprint. Input
constraints allow the service designer to enforce a set of validations
per input so that user will have to comply. For example limit port
numbers to an integer between 2500 and 5600. Name specific
values, base the validation on a pattern, etc

16. Real-Time Visibility Into Orchestration Task Execution
Deploying a multi-domain clustered service may consist of multiple steps with many inter-dependencies. Cloudify 5.0.x provides a
fully detailed task execution graph clearly displaying the planned nodes, execution steps along with their order and dependencies.
This visual tool makes it easy to track executions in real-time, gain visibility into their progress & status, and easily identify issues and
failures.

17. Dry Run Preview
Gain a better understanding of changes before they take place
with dry run preview
Cloudify’s intent-based model simplifies your day 2 operation and
deployment maintenance and makes them extremely easy to
maintain. Automation usually comes with some lack of visibility
into the steps that the system is going to apply with every
requested topology update. Getting a preview into the changes
before they are applied provides that missing layer of
visibility, and allows the operator to understand exactly what is
going to take place and apply or correct if needed.

18. Secrets (secure properties) are a key part of every project &
environment. A secure process for secret export from a manager (e.g.
Dev) and import into another manager (e.g. QA) allows for a secure
automatic flow of pipeline for Cloudify code.
Tie Into CI/CD Workflows With
Secure Secret Migration
A key part of a healthy CI/CD pipeline is the ability to shift
products through different environments - from Dev to QA to
Staging, and to Production.
Integrating Cloudify into the pipeline allows for greater flexibility
and reduces considerable time; it also requires that the Cloudify
code (in the form of blueprints, plugins, and secrets) can be
migrated through this process.
In 5.0.5 we introduce a complete secret export-import flow
supporting:
A secure flow with data encryption, anti-tampering flow, and
collision detection
A mapping functionality allowing for different tenant and account
names in different systems
A new option for bulk secret import from a file
A fully automated flow leveraging API/CLI.

19. Keeping Plugins Up-to-Speed
Plugins are the interfaces to your infrastructure and services. In an
ever-changing environment, plugin changes are inevitable and should
be considered as part of the ongoing maintenance of your systems.
Automatic update of plugins is now much simpler using two new 5.0.x
capabilities.
PEP440 format for plugin import is supported allowing the blueprint
designer to specify a range of supported plugin versions (e.g. >=2.1,
!=2.4, <3.0). Cloudify will take the most recent available plugin
matching that range.
Bulk update of a new plugin version across multiple deployments can
now be executed. Updating a plugin does not require a deployment
update.
[centos@cloudify ~]$ cfy plugins update -h
Update plugins in all deployments of a blueprint
Options:
-b, --blueprint-id BLUEPRINT_ID The id of the blueprint

20. What’s Next?

21. Please note that all references to future releases and timing represent indicative strategy and future
product plans known to Cloudify at this time, and that all references to dates and features are subject to
change. Cloudify retains the right to make changes at any time to future software development plans or
timescales and assumes no liability for the use of the information set out herein.
Cloudify Roadmap Summary
2020 (H1) - Cloudify 5.1
(Minor maintenance release)
● Cloudify Composer service catalog
● Cloudify Management Console UX improvements
● Out-of-the-box CI/CD integration
○ Jenkins plugin
○ Dedicated API
● Python 3 migration
● Snapshot & Restore flows improvements - Faster, simpler.
● Plugin improvements (GCP, Terraform, Ansible, Kubernetes)
● Cloudify as a Service (Trial)
● Minor features across the board
● Bug fixes
2020 (H2) - Cloudify 5.2
(Major release)
● Environment as a Service - Reports and ecosystem
● Criteria based orchestration (Placement policy)
● Topology refresh - Identify production/model discrepancies
● Cross manager workflows
● Kubernetes multi site workload orchestration
● Edge lightweight manager
● TOSCA requirements-Capabilities
● Improved scaling flows
● Non-privileged container deployment
● Blueprint versioning
● Plugin improvements
● Minor features across the board

22. Q & A

23. Thank You.