Friday, August 24, 2012

Dream home projects

Home projects we dream(ed) about:
  • 4 season sun room
    • Had folks come out from Creative Energy  (here) to talk about a sun room .  
      • Wonderful products
      • Very good materials/engineering
      • Like the company
      • Cost way more than we are willing to pay
  • A sunny room (maybe with a pool) and retractable enclosure
    • Had a number of emails with someone from Libart (here)
      • Another GREAT product
      • Pretty good materials
      • Really like the company and attitudes
      • Cheaper than the sun room but the cost compared to benefits wasn't high enough.
  • Below-grade addition (1 or 2 story)
    • Really want to do it myself
    •  Concrete walls
      • Am thinking ICF might be the way to go
      • Also considered Superior Walls but they thought it might be pricey to use for an addition
      •  Reduce load on heat pump
      • sound deadening
    • Being "basement like", would need to somehow deal with excavating below existing foundation.  Looks possible but need to consult with someone more experienced.
  • "Screened" deck
    • Had a quote from a company for $5,000 for a pressure treated deck roughly 12x14 or so. 
    • Looking at building it myself now.
    • Result must be lower maintenance than our existing deck with looks like it was build in 1880 and not maintained.
    • Thinking about some (Brazillian?) hardwoods 
      • Importers
      • Expensive but given the right wood it could last 50+ years
      • Typically still requires an oil sealer to maintain the beautiful colors
      • Ipe was used on a number of high profile boardwalks
      • Some complaints about "sustainable" forests.  Most imports state that the forestry practices are sustainable now for their suppliers.  Not sure..
    • EzeBreeze windows
      • Here
      • Looks DIY friendly
    • Probably make concrete piers
    • This project should be in our budget and needs to get done soon one way or another.
  • Steel shingles (roofing)
    • various companies
    • Long warranties
    • Might be cost effective if I can install myself; some companies have training of some sort I think.
  • Greenhouse
  • Workshop
More to come..

Projects completed
  • Geothermal heat pump
    • Works great
    • Found a few companies/people worth their weight in diamonds
      • Delta Temp
        •  These guys are GREAT!  They fixed a VERY bad install; I wish I had started with them.
        • 804-739-5854
    • Learned a lot about bad contractors/companies and about how to evaluate better upfront
      • Town & Country mechanical - now defunct company from what I hear
      • Check that they have a license #
      • Check that they are licensed for a job of your size (i.e. Class A is better than C)
      • Check that their license isn't expired
      • Check with BBB
    • Learned that warranties are like statistics
      • lies and more lies
      • If warranty is through installer and installer goes out of business...no actual warranty exist

Thursday, August 23, 2012

OSGI to use or not to use

What are good reasons to move to an OSGI based infrastructure?
* It solves a real problem in your organization
* Your organization has the skills to support it
* Overall developer efficiency is either improved or not reduced compared to other gains
* Your application requires high availability which OSGI improves for some deployment cases
* Your infrastructure tends to support it

We have not done any prototyping with OSGI yet.  It has been on my "look into list" for a couple years now.  As I started looking into Apache ServiceMix I noted it probably is a good time to start researching more closely.

The number of books which discuss OSGI is increasing and the number of software products which either implement OSGI or work with it is increasing.  The alternative "module" system, project Jigsaw, sounds like it won't make it into Java 8 and may not cover some use cases (although I am not very knowledgeable on it).  If you have the money, maybe something like JRebel would be an alternative which helps with availability it seems.  Some recent new functionality in Apache Tomcat may improve availability as well but we have not tried it;  see the "Parallel deployment" Tomcat information here.

So far, our major need is the ability to minimize downtime especially for regular application updates which normally don't require DB changes.  Also, as we move more toward Web Services and messaging, I see a lot of potential for OSGI to help.  It should help enforce better structuring of code.  Although, if it is like many other things - what you get out is based on what you put in.  Some developers may not put the effort into using effectively.


Load balancing - Hardware or Software

Most of my load balancing experience is with F5 BigIP LTM.  This has served us well for a good number of years.  Recently I am left with a feeling that we should revisit this.  The hardware is getting older and is now showing signs of impending whole hog failure.  To top it off, the budget line items for replacements keep getting scratched off.

What are the options?
 Either more F5 equipment or maybe Citrix NetScaler or other hardware?
 On the other hand, we could go out on a limb with software load balancing.

What are the benefits of HW load balancing?
  1. Major features (of importance to us)
    1. SSL termination
    2. Load balancing
    3. Rewriting
    4. Caching
  2. Efficiency
  3. Ease of use
    1. TCL used for language
    2. Single point of SSL certificate management
  4. Support
    1. Nice to have someone you can call 
What are the downsides of HW load balancing?
  1. Cost
  2. (near) single point of failure (unless item 1 is not an issue for you)
  3. Limited features

What are potential benefits of SW load balancing?
  1. Potentially lower cost
  2. Potentially less of a "single point of failure"
  3. Handle high loads (notes below)
  4. More features available
  5. Flexibility 
There are downsides to SW load balancing.
  1. More challenging integration (potentially multiple products used to implement feature sets)
  2. Requires more in house expertise
  3. Others - work in progress
Software Options
  1. nginx
    1. http://nginx.org/
  2. lighttpd
    1. http://www.lighttpd.net/
  3. Apache Server
    1. http://httpd.apache.org/docs/2.2/mod/mod_proxy_balancer.html
  4. Apache Traffic Server
    1. http://trafficserver.apache.org/
  5. Squid
    1. http://www.squid-cache.org/
Need to include some supporting information sites.  Would be good to do some proof of concepts implementations and some performance benchmarking.



Central Authentication Service (JASIG CAS)

Problem:
A growing number of applications, all of which have their own authentication mechanisms.  Until recently, the authentication store consisted of a database and the user authentication data was pushed to most application authentication stores.  The amount of custom code, authentication data movement and data synchronization jobs has become a liability to our stakeholders.  Other problems include distributed logs of authentication and authorization info which makes research into potential security breaches difficult.

Solution:
Conversion of applications to use CAS instead of custom or internal authentication mechanisms.  This project is joined with a project for the creation of an enterprise active directory and an associated MS FIM identity management infrastructure.

Benefits of CAS:
* More thoroughly tested code authentication code
* Less maintenance required
* Less application specific integrations
* Some common applications have existing support
* Logs consolidated
* Can customize login for some use cases revolving around maintenance windows

I started to work on the CAS part of the project.  There were a number of hurdles to work out.  My preference was working in Eclipse and CAS is setup to build with Maven.  Instead of reinventing the wheel, I decided to try and use an Eclipse/Maven integration combined with our Subversion source repository.  This seemed like it should work without problem but then the dark side of open source came out.  The maintainers of the integration stopped work on the Subversion support for the integration and decided to only support Git. I was not impressed with the tone of things.  Here is a link to a related conversation.  Someone did fork the code and the Eclipse update site for it is here.  Very grateful for that.

I now had functional Eclipse/Maven/Subversion support but I can't say that I find the whole process very intuitive.  I was able to get the as delivered CAS code to compile and run fine and I was able to branch it with some basic additions for my organization.  I need to further externalize some of the application setup; as I indicate in another post I tend to try to leave most of the configuration in Spring based configuration files stored on NFS storage.

Started to create a Jenkins build for this.  I am trying to use the Maven build support but I am not sure how many things must get updated to build only the components I care about.  By default, it build all the components.

In-progress and near-term customizations include:
* Authentication with AD
* Initial clustering support
* Currently using Ehcache but am still thinking hard about updating it for JBoss Infinispan.  I think this is on the CAS todo list but I don't think it will be difficult to do so..  See if time permits me to work on this.
* DB backed service registry
* Multiple institution branding dynamically selected based on target IP or host.  I think branding support/infrastructure improved in CAS 3.5 but not sure of the overall state yet.

Longer term customizations:
* Ability to prevent logins by unprivileged users at certain times to allow easier testing of upgrades and other maintenance and support activities (handle per application and maybe even environment).

Also started prototyping changes to one custom application over to CAS.  This application poses some challenges since it has multiple login entry points for 2 distinct sets of users.

Need to research the Google auth/SSO support which is one of our bigger needs now.

[Update 9/9/2012]
* Active Directory authentication working well
* DB backed service registry implemented
*     Had a brief thought of trying to implement via a NoSQL solution or some other solution which would make the service registry highly available.  On a quick review, this doesn't seem to be as simple as hoped and more research into the registry indicates that availability should not typically be a problem.  Leaving this as a future enhancement idea though.
* Have an initial partial conversion of one client application. 
*     Redirection from application to CAS works. 
*     Main obstacle to review - current app has 2 different authentication entry points for 2 distinct sets of users.  I am hoping that this will not require substantial customization to support.  For now, one entry point makes the most sense to convert to CAS.  I think that a Java EE filter combined with some load balancer rewrite magic will help maintain the appropriate authentication flows.  Can't put many details in a blog on this though.

Next steps
*     Need to sort out ticket validation on client.
*     Need to work out branding; some apps centrally branded and others branded for 23+ institutions.  CAS 3.5.0 branding doesn't appear well documented at this point - am starting to review CAS code.
* Finish and deploy a Jenkins based build to a newly created dev server.