On July 2 Gary Announced the release of Overlord 1.1.0 Beta1. Our webinar this week, Runtime governance to achieve greater business visibility touched on some of the RTGov capabilities. See the information below for the Overlord announcement and the webinar information.
Overlord 1.1.0 Beta Announcement
The Overlord team is pleased to announce the release of Overlord 1.1.0.Beta1, comprised of SRAMP 0.5.0.Beta1, DTGov 1.5.0.Beta1 and RTGov 2.0.0.Beta1. We will also be launching our new website shortly (http://governance.github.io/). Please take a look and let us know what you think.
The common features across the components are:
Support for EAP 6.3 and Fuse 6.1 (Fabric support to follow shortly)
Numerous bug fixes
Numerous bug fixes
SRAMP:
Maven facade (early preview)
Many doc improvements
Moved from jline to aesh
More details: http://red.ht/TBjjAl
DTGov:
Jetty 8 Support
New Admin UI to manage Workflow Triggers
Notification Service email templates can now come from S-RAMP
More details: http://red.ht/1lyY0pF
RTGov:
New UI to replace previous Gadget Server approach
Integration with Elasticsearch and Kibana for analytics
More details: http://red.ht/1iVa0r6
Speak thanks to Ivan McKinley for Elasticsearch contributions, Michael Clay for work on the new RTGov UI, and help from the SwitchYard, ModeShape and Fuse teams.
Run Time Governance Webinar
1: Demo Identity and react on trends
- During my session i will have a process running in back ground that is generating data against a switchyard service- I will show RTGov and Kibana presenting this data.
- I will use kibana to show which served is “Slow”, data drill down
- I will then create and deploy a RTGov EPN that reacts on the response time by creating “SLA breach” situations.
- Send a “Request” which will result in a SLA Breach which i will show in RTGOv situations UI
- Purpose is to show how we can actively react on data in the runtime
2: Demo Apply runtime policy based on business data
- Via Kibana
- After addressing our SLA problem I move to intpretating the rest of the data in kibana
-The generated data, from previous demo, show a trend of “insufficent funds” errors occurring
- I will create a Preprocessor EPN. The EPNs purpose is to ensure the users has enough fund before been allowed to place a request
- This demos a business policy been applied to a service. Restrict users access services based on business data
3: Demo Pre-emptively identify increase in service load
- The previous example showed load average of 3 request per second.
- This I deploy a EPN that utilises CEP. The rule aggregates requests hitting a service over a 1 second window.
- If it detects the load increase pass 20 requests a seconds a midium situation “Alert” is created
- If it detects the load increasing pass 30 requests a second a Critical situation “Alert” is created
- Purpose is to show how we anticipate any increasing load on our service
- Test will be done via a soapui load test
- potentially Combined with business data. Eg, over 20 requests for product X in the last hour.
