Versatile release: This is what the new evoila Service Broker Framework offers you

[et_pb_section bb_built=”1″][et_pb_row][et_pb_column type=”4_4″][et_pb_text _builder_version=”3.0.105″ background_layout=”light”]

Before developing and introducing a new release, developers are usually confronted with the same questions:

1. How can we further improve our product?
2. Which features are most useful to our customers?
3. Hopefully we have covered with our tests as sources of error?
4. Are there drastic changes in the user experience?

These are exactly the questions we took up in the revision of the Service Broker and supplemented them with customer expectations. The result is a release with many variants, which is characterized by the following features, among others:

• High availability through clustering of all components
• Load Balancing for all necessary deployments (e.g. Postgres, MySQL) for optimal performance
• Integrated auto discovery for monitoring services
• More insights into the service status through improved monitoring dashboards
• Pipeline-based deployments via concourse
• Renew all deployments to Bosh 2.0

[/et_pb_text][et_pb_text _builder_version=”3.0.105″ background_layout=”light”]

And what changes have we made to the Service Broker?

Let’s concentrate on the MongoDB Service Broker for now:

Our goal here was to make the existing MongoDB Service Broker even more robust. To achieve this, it was necessary to make some changes. These were in detail:

• Dynamic scaling of the cluster size of a replica set
• Transformation of a single instance into a replica set
• Extension of configuration options for MongoDB
• Update of the Node and MongoDB Exporter and extension of the monitoring dashboards for even better monitoring

PostgreSQL Service Broker – new architecture:

When building the new architecture of the evoila PostgreSQL Service Broker, we focused on one thing in particular:

“We wanted PostgreSQL Service Broker above all to improve the reliability and flexibility of deployments.”

We have succeeded in achieving this goal and its implementation:

• Increase read performance by distributing the requests to all cluster nodes
• The dynamic scaling from a cluster size of 2 instances
• A targeted update of the Node and PostgreSQL Exporter and a consistent extension of the monitoring dashboards for even better monitoring

[/et_pb_text][et_pb_text admin_label=”Update für den RabbitMQ Service Broker und den LBaaS Service Broker” _builder_version=”3.0.105″ background_layout=”light”]

Update for the RabbitMQ Service Broker and the LBaaS Service Broker
No question that the RabbitMQ Service Broker and LBaaS Service Brokers were also on the to-do list of our developers. And what exactly has changed here? We have summarised this for you in the following overview:

RabbitMQ Service Broker

• • Update to the latest Erlang and RabbitMQ versions
  • Improvement of parameterization of small deployments by dynamic disk threshold specification

Dynamic scaling from a cluster size of 1 instance

• Update of the Node and RabbitMQDB Exporter and extension of the Monitoring Dashboards for even better monitoring

MySQL Service Broker

• Dynamic scaling from a cluster size of 2 instances
• Update the node and MySQL Exporter and extend the monitoring dashboards for even better monitoring

Dynamic scaling, scaling decisions and learn-based scaling – that’s what you can expect from the new CF Autoscaling Service Broker:

Dynamic scaling
Dynamic scaling was a decisive criterion in the revision of the CF Autoscaling Service Broker. The Service Broker now allows scaling based on:

• Cpu (lower and upper limit)
• RAM (lower and upper limit)
• latency (lower and upper limit)
• Requests (quotient-based procedure)

[/et_pb_text][et_pb_text _builder_version=”3.0.105″ background_layout=”light”]

Scaling decisions
In addition, different metrics can now be combined with each other. Because now scaling decisions are not or, but and/or based rules.
Furthermore, the autoscaler also enables learn-based scaling that looks at historical data intervals to make scaling decisions.
In addition to the scaling factors, the definition of upper and lower limits as well as the definition of a cool-down time and unnecessary scaling are available as further rough framework parameters.

Interfaces for the connection of Kubernetes interfaces for the connection of Kubernetes interfaces for the connection of Kubernetes
The generic implementation of the CF Autoscaling Service Broker also provides an interface for the connection of Kubernetes. These can be provided on request.

Test now and learn more:
Take the opportunity now to get to know and test the functionality of the new CF Autoscaling Service Broker yourself. Please contact us now: osb@evoila.de

[/et_pb_text][/et_pb_column][/et_pb_row][/et_pb_section]