Skip to content
Technical

Montlake: Application Blueprinting in more detail

Cloudsoft

This is a follow up to my previous post. Not all blueprints are equal where we introduced, under the Montlake moniker, a project comparing and contrasting different ways of creating application blueprints. Here we drill-down on the modelling, deployment and in-life management of applications with Apache Brooklyn and Cloudsoft AMP using a simple Node.JS application as our exemplar.

The application consists primarily of .bom or catalog files that describes how to install and manage a MariaDB node a Node.JS node and a file app.yaml that describes how to combine them, along with a load balancer.

If we look more closely at either the nodejs.bom or mariadb.bom, we can see that the basic layout and job of the blueprint is quite clear. We state what the application is, along with some metadata, the parameters it takes, and commands used to install, customize, start, stop and monitor the application.

Deployment of the application is as straightforward as adding the .bom files to Brooklyn's catalog, and directing app.yaml to be deployed to a given location.

https://www.youtube.com/embed/ARIdMi4DPNE?wmode=opaque&enablejsapi=1

Now that the application is deployed, we should look at some of the in-life management features contained in the brooklyn-app.bom catalog file. In it, there is a deceptively simple Service Restarter policy that's been attached to the NodeJS application.

      - type: org.apache.brooklyn.policy.ha.ServiceRestarter

        brooklyn.config:

          failOnRecurringFailuresInThisDuration: 5m

This policy will continually monitor the process or service to which it has been attached; if the monitored process or service stops unexpectedly for any reason, the Service Restarter detects that failure, and restarts the process.

https://www.youtube.com/embed/XOsSGUE56_4?wmode=opaque&enablejsapi=1

Cloudsoft AMP is an enterprise-ready application management platform build on the foundation of Apache Brooklyn. AMP builds upon the autonomic management capabilities of Brooklyn bundling a graphical blueprint composer, container services built on Kubernetes and Docker Swarm, a framework for continuous testing of application blueprint against a variety of clouds and platforms and a rich, modular UI.

One highlight of the AMP-specific three-tier Node.JS demo application is its use of application network security. Application network security allows the blueprint designer to model network boundaries in the blueprint, and AMP will use the underlying cloud mechanisms that are available (security groups, subnetting, etc.) to enforce separation.

You can see in three-tier-nodejs-amp/app.yaml that the MariaDB node can only speak on the appservers network:

    # The database exposes its port to the app servers

    - type: io.cloudsoft.amp.networking.NetworkSecurityCustomizer

      brooklyn.config:

        enforcement: mandatory

        networks:

        - backend

        networks-ingress:

        - network: appservers

          exposing:

          - port

...where it is able to connect to the NodeJS cluster

          # Members of the cluster expose their http.port to the frontend.

          - type: io.cloudsoft.amp.networking.NetworkSecurityCustomizer

            brooklyn.config:

              enforcement: mandatory

              networks:

              - appservers

              networks-ingress:

              - network: frontend

                # Note that the metrics endpoint isn't exposed, meaning that the sensitive data

                # is only visible to the management network.

                exposing:

                - http.port

No direct ingress to either is allowed; all inbound traffic must flow through the load balancer.

Cloudsoft AMP is still very much Brooklyn under the hood; application blueprints written for Brooklyn will always work with AMP. There is an ever-growing collection of ready-to-deploy community-produced blueprints in the Blueprint Repository.

https://www.youtube.com/embed/r6qkrjzRWbc?wmode=opaque&enablejsapi=1

In Apache Brooklyn and Cloudsoft AMP, policy-based application management is a first-class citizen, completely portable and configurable, and sophisticated enough to meet the demands of any application. Many frameworks, clouds and platforms offer some form of auto-scaling behaviour, but the implementations tend to be limited by what is available natively on the platform. For AMP, an auto-scaling policy is portable enough to run on any cloud or platform, and powerful enough to scale with any metric or combination of metrics that is observable.

In our three-tier NodeJS demo application, the auto-scaling policy is written as:

    # Autoscales per the average number of reads across the cluster

    - type: org.apache.brooklyn.policy.autoscaling.AutoScalerPolicy

      brooklyn.config:

        metric: $brooklyn:sensor("nodejs.metrics.read.average")

        metricLowerBound: 50

        metricUpperBound: 100

        minPoolSize: 2

        maxPoolSize: 5

        resizeUpStabilizationDelay: 1m

        resizeDownStabilizationDelay: 2m

The most interesting line of which is:

        metric: $brooklyn:sensor("nodejs.metrics.read.average")

This line tells AMP that the metric that will drive its auto-scaling behaviour is one called "nodejs.metrics.read.average". If we trace the origin of that metric back through the blueprint, we'll see that it is the average reads from each member on the cluster, and that the metrics are generated by the application itself (in this case, via express-metrics). That is, auto-scaling is not based on an indirect measure of load, such as CPU utilization, but AMP is able to publish metrics tracked by the application and use those same metrics to reason about the application.

https://www.youtube.com/embed/4Ac9NSnefTw?wmode=opaque&enablejsapi=1

We will be contributing more examples to illustrate these points in the coming weeks and months, starting with enhancements to our Apache Spark blueprint. We’d be delighted if other people did the same. Join the conversation, and contribute examples at  https://github.com/Montlake/blueprint-illustrations.

Related Posts