update-alternatives --config java
or more recently appears to have changed to:
alternatives --config java
2015/04/22
2015/04/12
Waterfall v Agile v Reckless
I was recently asked when I would use an agile instead of waterfall methodology to which I don't think I gave a very good answer at the time. These things tend to dwell in the mind; in this case at 3am!, and though thoughts at such a hour aren't necessarily too be trusted, here goes.
"Quality, time, cost - pick any two", is an often quoted project management notion which I'll not go in to. A similar triplet can be used to identify which methodology to choose - functionality, time and cost.
The idea goes like this - you can prioritise any two of functionality, time or cost and doing so will tell you which method to use:
Prioritise functionality & cost over time - use waterfall. You know what you want so you can plan it all out up-front, minimise technical-debt, reduce redundancy and keep costs down. It may though be that it takes longer than you really want before you see anything go live. Good for fixed-price work, anything where the scope is well defined and time is less of a concern and some package implementations (package customisation to be avoided (as a general rule!)).
Prioritise cost & time over functionality - use agile. You want something out there soon, at minimal initial cost (think MVP) and can limit the functionality that's delivered within these time/cost constraints. You can define short delivery cycles, size these accordingly and constrain the functionality that gets delivered within them. Good for T&M projects and anything where the vision/scope or requirement priorities are less clear or subject to change - i.e. most projects.
Prioritise functionality & time over cost - use the reckless approach. This essentially says you don't give a damn about the money but you want it all and you want it now! If you ever hear a customer claim "money is no object!" run away. Ok, there are a handful of cases; usually government and compliance projects, where this happens but these projects are rare and typically indicative of failings elsewhere in an organisation. In all other cases the customer has frankly lost the plot. Essentially the reckless approach is one where you start trying to deliver all the functionality ASAP without much concern for anything else. You will likely throw out a lot of testing, ignore non-functional requirements, use whatever tools are to hand; whether they're right for the job or not, and ignore any corporate processes/procedures and standards on the way. Hell, it can work! But most often it leads to unforeseen costs late in projects, excessive rework and; if you do go live with it, a lot of tech-debt and long-term costs which needs to be paid back.
It's just unfortunate that the reckless approach is used so often when it should be so rare. It's also unfortunate that those that deliver reckless projects often get promoted (they delivered on-time) without the long term cost being fully understood - a corollary with the quarterly focus issues many large corporations suffer.
So agile should be most common, then waterfall, then reckless. I'd also suggest waterfall should be used sparingly as there's a tendency for the project to disappear into dark-room for many months before resurfacing and being "not what I wanted" due to poor requirements definition and lack of a good feedback loop. Agile keeps the customer much more engaged on a day-to-day basis which provides that feedback loop and minimises such waste.
It should also be noted that neither agile or waterfall say anything about the work-products needed to deliver them. They don't say "don't do requirements definition", "don't do design" or "don't test", far from it, they just do it in different ways (user-stories v consolidated requirements definition for example). You also need to have an understanding of the long term vision, scope and dependencies within an agile project to avoid excessive tech-debt; or at least be conscious of the implications of short term decisions. From an architectural perspective you still need to identify the building blocks, do the design (logical and physical), establish non-functionals, identify key decisions and dependencies etc. But whilst you may go into all the detail up-front in waterfall you can spread this out in agile with a relatively shallow but broad scope solution outline up-front (essentially identifying the key building blocks and non-functionals) and go into depth as and when needed. To believe you can avoid such work is to make assumptions and to; consciously or otherwise, adopt the reckless approach...
"Quality, time, cost - pick any two", is an often quoted project management notion which I'll not go in to. A similar triplet can be used to identify which methodology to choose - functionality, time and cost.
The idea goes like this - you can prioritise any two of functionality, time or cost and doing so will tell you which method to use:
Prioritise functionality & cost over time - use waterfall. You know what you want so you can plan it all out up-front, minimise technical-debt, reduce redundancy and keep costs down. It may though be that it takes longer than you really want before you see anything go live. Good for fixed-price work, anything where the scope is well defined and time is less of a concern and some package implementations (package customisation to be avoided (as a general rule!)).
Prioritise cost & time over functionality - use agile. You want something out there soon, at minimal initial cost (think MVP) and can limit the functionality that's delivered within these time/cost constraints. You can define short delivery cycles, size these accordingly and constrain the functionality that gets delivered within them. Good for T&M projects and anything where the vision/scope or requirement priorities are less clear or subject to change - i.e. most projects.
Prioritise functionality & time over cost - use the reckless approach. This essentially says you don't give a damn about the money but you want it all and you want it now! If you ever hear a customer claim "money is no object!" run away. Ok, there are a handful of cases; usually government and compliance projects, where this happens but these projects are rare and typically indicative of failings elsewhere in an organisation. In all other cases the customer has frankly lost the plot. Essentially the reckless approach is one where you start trying to deliver all the functionality ASAP without much concern for anything else. You will likely throw out a lot of testing, ignore non-functional requirements, use whatever tools are to hand; whether they're right for the job or not, and ignore any corporate processes/procedures and standards on the way. Hell, it can work! But most often it leads to unforeseen costs late in projects, excessive rework and; if you do go live with it, a lot of tech-debt and long-term costs which needs to be paid back.
It's just unfortunate that the reckless approach is used so often when it should be so rare. It's also unfortunate that those that deliver reckless projects often get promoted (they delivered on-time) without the long term cost being fully understood - a corollary with the quarterly focus issues many large corporations suffer.
So agile should be most common, then waterfall, then reckless. I'd also suggest waterfall should be used sparingly as there's a tendency for the project to disappear into dark-room for many months before resurfacing and being "not what I wanted" due to poor requirements definition and lack of a good feedback loop. Agile keeps the customer much more engaged on a day-to-day basis which provides that feedback loop and minimises such waste.
It should also be noted that neither agile or waterfall say anything about the work-products needed to deliver them. They don't say "don't do requirements definition", "don't do design" or "don't test", far from it, they just do it in different ways (user-stories v consolidated requirements definition for example). You also need to have an understanding of the long term vision, scope and dependencies within an agile project to avoid excessive tech-debt; or at least be conscious of the implications of short term decisions. From an architectural perspective you still need to identify the building blocks, do the design (logical and physical), establish non-functionals, identify key decisions and dependencies etc. But whilst you may go into all the detail up-front in waterfall you can spread this out in agile with a relatively shallow but broad scope solution outline up-front (essentially identifying the key building blocks and non-functionals) and go into depth as and when needed. To believe you can avoid such work is to make assumptions and to; consciously or otherwise, adopt the reckless approach...
2015/04/03
My big fat hairy....
... so I've just been told the most important thing about a computer is the number of "pouce" it has (thumbs to you and me). Humm... well, ok. Mine generally has two at most and I get angry if it's got any more. My father in-law has 15.6 of them. Wow! That's one powerful machine (I guess)!?
2015/03/28
Cynical bugger that I am...
I can be a little cynical sometimes though going through the morning news it seems there's been a couple of rather heartwarming moves by a some of our overlords today...
I suspect the shareholders of neither MS or Apple will care much though as it doesn't really affect them and there's a long way to go yet to address the inequality but... oops, there goes my cynicism again... :)
Microsoft to require suppliers to provide paid leave to workers (though Bill doesn't look too happy in the photo he's got my respect for the work of the Gates Foundation).
Apple boss Tim Cook 'to donate millions' to charity (and he can pay my sons university fees if he wants to as well!).
I suspect the shareholders of neither MS or Apple will care much though as it doesn't really affect them and there's a long way to go yet to address the inequality but... oops, there goes my cynicism again... :)
2015/03/26
Security Vulnerability Review
Secunia have released an interesting report on the number of vulnerabilities found across various products. There's much talk about MS and non-MS products which kind of makes sense from a Windows perspective but the report also contains a list of "20 core products" with most vulnerabilities identified in 2014.
Trouble is the report doesn't specify where and how this "core" list was compiled; contrary to the 50 portfolio products which is based on the Secunia client running on Windows devices.
If it's the same Secunia client - and I suspect it is since the number of vulnerabilities match for those products in both lists where I would expect some potential variance (Chrome on Windows v OSX for example) - then it's rather odd that OSs such as Oracle Solaris and Gentoo Linux crop up... Hypervisors perhaps...
Another shocking thing for me was the number of IBM products in that top 20; 8 out of 20! Really? 40% of the products with most vulnerabilities are from IBM? Of course few people use these things (IBM Tivoli Composite Application Manager for Transactions anyone?) but it's possible the stats are skewed due to too little data but it doesn't sing well for big-blue... other than perhaps noting that they seem to find-'em and fix-'em.
... and that Java was #17 on the list is more worrying. That beastie is everywhere and riddled with problems...
Trouble is the report doesn't specify where and how this "core" list was compiled; contrary to the 50 portfolio products which is based on the Secunia client running on Windows devices.
If it's the same Secunia client - and I suspect it is since the number of vulnerabilities match for those products in both lists where I would expect some potential variance (Chrome on Windows v OSX for example) - then it's rather odd that OSs such as Oracle Solaris and Gentoo Linux crop up... Hypervisors perhaps...
Another shocking thing for me was the number of IBM products in that top 20; 8 out of 20! Really? 40% of the products with most vulnerabilities are from IBM? Of course few people use these things (IBM Tivoli Composite Application Manager for Transactions anyone?) but it's possible the stats are skewed due to too little data but it doesn't sing well for big-blue... other than perhaps noting that they seem to find-'em and fix-'em.
... and that Java was #17 on the list is more worrying. That beastie is everywhere and riddled with problems...
2015/03/19
2015/03/09
Session Abolition
I've been going through my bookcase; on orders from a higher-being, to weed out old, redundant books and make way for... well, I'm not entirely sure what, but anyway, it's not been very successful.
I came across an old copy of Release It! by Michael T. Nygard and started flicking through, chuckling occasionally as memories (good and bad) surfaced. It's an excellent book but made me stop and think when I came across a note reading:
There's nothing fundamentally wrong with this other than it chimes with a problem I'm currently facing and I don't like any of the usual solutions.
Sessions either reside in some sort of stateful pool; persistent database, session management server, replicated memory etc., or more commonly exist stand-alone within each node of a cluster. In either case load-balancing is needed to route requests to the home node where the session exists (delays in replication means you can't go to any node even when a stateful pool is used). Such load-balancing is performed by a network load-balancer, reverse proxy, web-server (mod_proxy, WebSphere plugin etc.) or application server and can work using numerous different algorithms; IP based routing, round-robin, least-connections etc.
So in my solution I now need some sort of load-balancer - more components, joy! But even worse, it's creating havoc with reliability. Each time a node fails I lose all sessions on that server (unless I plumb for a session-management-server which I need like a hole in the head). And nodes fails all the time... (think cloud, autoscaling and hundreds of nodes).
So now I'm going to kind-of break that treasured piece of advice from Michael and create larger cookies (more likely request parameters) and include in them some every-so-slightly-sensitive details which I really shouldn't. I should point out this isn't is criminal as it sounds.
Firstly the data really isn't that sensitive. It's essentially routing information that needs to be remembered between requests - not my credit card details.
Secondly it's still very small - a few bytes or so but I'd probably not worry too much until it gets to around 2K+ (some profiling required here I suspect).
Thirdly, there are other ways to protect the data - notably encryption and hashing. If I don't want the client to be able to read it then I'll encrypt it. If I don't mind the client reading the data but want to make sure it's not been tampered with, I'll use an HMAC instead. A JSON Web Token like format should well work in most cases.
Now I can have no session on the back-end servers at all but instead need to decrypt (or verify the hash) and decode a token on each request. If a node fails I don't care (much) as any other node can handle the same request and my load balancing can be as dumb as I can wish.
I've sacrificed performance for reliability - both in terms of computational effort server side and in terms of network payload - and made some simplification to the overall topology to boot. CPU cycles are getting pretty cheap now though and this pattern should scale horizontally and vertically - time for some testing... The network penalty isn't so cheap but again should be acceptable and if I avoid using "cookies" for the token then I can at least save the load on every single request.
It also means that in a network of micro-services, so long as each service propagates these tokens around, the more thorny routing problem in this sort of environment virtually disappears.
I do though now have a key management problem. Somewhere, somehow I need to store the keys securely whilst distributing them to every node in the cluster... oh and don't mention key-rotation...
I came across an old copy of Release It! by Michael T. Nygard and started flicking through, chuckling occasionally as memories (good and bad) surfaced. It's an excellent book but made me stop and think when I came across a note reading:
Serve small cookies
Use cookies for identifiers, not entire objects. Keep session data on the server, where it can't be altered by a malicious client.
There's nothing fundamentally wrong with this other than it chimes with a problem I'm currently facing and I don't like any of the usual solutions.
Sessions either reside in some sort of stateful pool; persistent database, session management server, replicated memory etc., or more commonly exist stand-alone within each node of a cluster. In either case load-balancing is needed to route requests to the home node where the session exists (delays in replication means you can't go to any node even when a stateful pool is used). Such load-balancing is performed by a network load-balancer, reverse proxy, web-server (mod_proxy, WebSphere plugin etc.) or application server and can work using numerous different algorithms; IP based routing, round-robin, least-connections etc.
So in my solution I now need some sort of load-balancer - more components, joy! But even worse, it's creating havoc with reliability. Each time a node fails I lose all sessions on that server (unless I plumb for a session-management-server which I need like a hole in the head). And nodes fails all the time... (think cloud, autoscaling and hundreds of nodes).
So now I'm going to kind-of break that treasured piece of advice from Michael and create larger cookies (more likely request parameters) and include in them some every-so-slightly-sensitive details which I really shouldn't. I should point out this isn't is criminal as it sounds.
Firstly the data really isn't that sensitive. It's essentially routing information that needs to be remembered between requests - not my credit card details.
Secondly it's still very small - a few bytes or so but I'd probably not worry too much until it gets to around 2K+ (some profiling required here I suspect).
Thirdly, there are other ways to protect the data - notably encryption and hashing. If I don't want the client to be able to read it then I'll encrypt it. If I don't mind the client reading the data but want to make sure it's not been tampered with, I'll use an HMAC instead. A JSON Web Token like format should well work in most cases.
Now I can have no session on the back-end servers at all but instead need to decrypt (or verify the hash) and decode a token on each request. If a node fails I don't care (much) as any other node can handle the same request and my load balancing can be as dumb as I can wish.
I've sacrificed performance for reliability - both in terms of computational effort server side and in terms of network payload - and made some simplification to the overall topology to boot. CPU cycles are getting pretty cheap now though and this pattern should scale horizontally and vertically - time for some testing... The network penalty isn't so cheap but again should be acceptable and if I avoid using "cookies" for the token then I can at least save the load on every single request.
It also means that in a network of micro-services, so long as each service propagates these tokens around, the more thorny routing problem in this sort of environment virtually disappears.
I do though now have a key management problem. Somewhere, somehow I need to store the keys securely whilst distributing them to every node in the cluster... oh and don't mention key-rotation...
Subscribe to:
Posts (Atom)
-
** Warning: Functional rant! ** I've spent a significant part of the past few years swearing at Lotus Notes. So much in fact that this p...
-
If you really wanted to know you'd have found it but for what it's worth, this site now runs on Redhats OpenShift platform . For a w...
-
PO: We need a bridge over the river right here? Me: Why? PO: Because the customer needs to get to the other side? Me: Why can't they use...
