Skip to content
Naveen Malik edited this page Mar 17, 2014 · 26 revisions

lightblue

<What..>

Purpose of lightblue

  • Ensure changes to service capabilities do not impact existing customers.
  • Enable deployment to cloud infrastructure.
  • Provide robust security.
  • Reduce maintenance costs.

Service Stability

To remove impacts to existing customers there are a few things that are done in lightblue:

  1. provide a robust and stable service API
  2. multiple active versions of metadata
  3. guarantee backwards compatibility of metadata changes

Cloud Enablement

Lightblue is designed to be deployed anywhere.

  1. flexible component architecture provides ability to talk to different datastores (MongoDB, RDBMS)
    • need to talk to something else, just write the controller implementation
  2. Hystrix to isolate external dependencies
  3. Servo for application monitoring (Graphite, CloudWatch, etc)

Security

All access to REST and Web UI components are designed to work with the authentication and authorization of your choice. Lightblue does not dictate how you will secure your assests. Expect some examples on how to do authentication and authorization to come as we finalize development of the first technical deliverable.

Reduced Maintenance

Analysis of changes done by Red Hat IT to modify data services show that we could have reduced the time spend on those enhancements on average by approximately 90% in calendar year 2013 if lightblue had been in place. Many of the enhancement requests that we receive would have gone away due to the flexible query language. Much of the other time moves from developing code to add new fields or new entities to instead managing metadata.

Existing workflow to add a single field to an existing entity involves many things as illustrated here: Slow

With lightblue everything that previously required code changes is now a change to metadata: Fast

Clone this wiki locally