Blood-e-mail

We all hate e-mail. We all love e-mail...

E-mail is like writing  a letter. There was a time when sitting down to write a letter (with pen) was an almost pleasant task which you expected to take a good hour on a rainy day... including moments of displaced thought spent staring out of the window (at this points anyone under the age of 30 is probably wondering what the hell I'm on about!).

I still can (and do) waste a good hour or two writing an e-mail.

E-mail is not:

1. A replacement for conversation. The best tech solutions we have for this are Google Hangouts, Facetime or Skype etc. or even; god forbid, the telephone (psst, don't tell the kids they can talk into those things). Ping-pong emails are just an ineffective and tedious form of conversation - even worse when they're to a cc list who mostly couldn't care less about the topic. It's morse-code compared to the telephone. If you can, get off your back-side, walk across the office and talk to them!


2. A replacement for instant-messaging. IM deserves more credit than it typically receives and in many organisations is a fundamental necessity to improve communication. You should be ashamed of yourself if you use e-mail this way! IM is quicker, simpler and crucially doesn't fill your day with a tonne of "in-box" items you'll never get round to. And if you're only experience of IM is Lync.. you need to get out more.


3.  A replacement for group conversation. Get a room for god-sake! Co-location is the #1 solution for group communication. But if you can't do that (and don't give in, fight for this as it will revolutionise your working life) then many tools are available to ease comms over a distance. Many of these; Slack notably in my experience, can be truly engaging for group conversations.


4. And the cherry on the cake... a replacement for documentation. If you think that sending an email with detailed information counts as "documentation" then you deserve to be taken outside, strapped to the stocks, de-trousered, painted in pigs-blood and have your children forced to throw a variety or spoiled food products at your sorry carcass till their tears run dry. Put it in a wiki or a teamroom or in a document on a file-system - I care not which. But stuffed in the crevice of some email chain where it's neither obvious or available to those that need it only serves to deter the distribution of knowledge, increase confusion and encourage chaos and entropy to thrive. If your organisation works this way then your organisation is likely living off institutionalised knowledge which may walk out the door tomorrow.

We all hate e-mail. We all love e-mail... No, scratch that. E-mail is rubbish and should be relegated to the same historic status as letter writing. Occasionally nice to receive but quaint and you'd rather not spend your time writing them... It's time to abandon e-mail!

Traceability

We can have a small server...



...a big server (aka vertical scaling)...



.. a cluster of servers (aka horizontal scaling)...



.. or even a compute grid (horizontal scaling on steroids).



For resiliency we can have active-passive...



... or active-active...



... or replication in a cluster or grid...



...each with their own connectivity, load-balancing and routing concerns.

From a logical perspective we could have a simple client-server setup...



...a two tier architecture...




...an n-tier architecture...



...a service oriented (micro- or ESB) architecture...



...and so on.

And in each environment we can have different physical topologies depending on the environmental needs with logical nodes mapped to each environments servers...



With our functional components deployed on our logical infrastructure using a myriad of other deployment topologies..



... or ...



... and on and on and on...

And this functional perspective can be implemented using dozens of design patterns and a plethora of integration patterns.



With each component implemented using whichever products and packages we choose to be responsible for supporting one or more requirements and capabilities...



So the infrastructure we rely on, the products we select, the components we build or buy; the patterns we adopt and use... all exist for nothing but the underlying requirement.

We should therefore be able to trace from requirement through the design all the way to the tin on the floor.

And if we can do that we can answer lots of interesting questions such as "what happens if I turn this box off?", "what's impacted if I change this requirement?" or even "which requirements are driving costs?". Which in turn can help improve supportability, maintainability and availability and reduce costs. You may even find your product sponsor questioning if they really need this or that feature...

JBOSS Openshift Queue Deployment

Deploying to Openshift is, in theory, as simple as git push. But if you've made any changes to the app-server environment you'll find it gets blitzed on deployment (this is actually a good thing since it'll force you to get into the habits of automating deployments).

To deal with this Openshift gives you the ability to define a set of action-hooks that get called during the various stages of the applications lifecycle.

These are just shell scripts and are pretty easy to define - just create a file in the .openshift/action_hooks directory in the project root matching the name of the hook you want.

In the case of queue deployment we need a post_start script which uses the JBOSS CLI to create queues.

The script .openshift/action_hooks/post_start looks like this:

echo "Starting JBOSS Queue Configuration..."
${OPENSHIFT_JBOSSAS_DIR}/bin/tools/jboss-cli.sh --connect controller=${OPENSHIFT_JBOSSAS_IP}:${OPENSHIFT_JBOSSAS_MANAGEMENT_NATIVE_PORT} --file=${OPENSHIFT_REPO_DIR}/cli/create-queues.cli
echo "JBOSS configuration complete!"


Make sure the script is executable via chmod +x .openshift/action_hooks/post_start.

The use of various environment variables ensures the script will work regardless of the configuration the image fires-up with and the "echo" commands ensures some sort of output is dumped to stdout during push for confirmation.

This script references a cli script (cli/create-queues.cli) looking like this:

jms-queue add --queue-address=queueA --entries=queue/QueueA
jms-queue add --queue-address=queueB --entries=queue/QueueB


And hey presto! On deployment you'll see a couple of messages output showing:

remote: Starting JBOSS Queue Configuration...
remote: JBOSS configuration complete!


And if you tail the logs (rhc tail -a ) you should see confirmation of the deployment as below:

2016/02/01 16:57:57,641 INFO [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-8) trying to deploy queue jms.queue.queueA
2016/02/01 16:57:57,644 INFO [org.jboss.as.messaging] (MSC service thread 1-8) JBAS011601: Bound messaging object to jndi name java:/queue/QueueA
2016/02/01 16:57:57,738 INFO [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-8) trying to deploy queue jms.queue.queueB
2016/02/01 16:57:57,740 INFO [org.jboss.as.messaging] (MSC service thread 1-8) JBAS011601: Bound messaging object to jndi name java:/queue/QueueB


Finally the JBOSS console will show your queues in all their glory...

Bearer v MAC

I've been struggling recently to get my head around OAuth2 access tokens - bearer and MAC tokens specifically...

Bearer tokens are essentially just static tokens valid for some predefined period before they need to be refreshed. They can essentially be passed around willy-nilly and will be accepted by a resource server so long as they can be validated. If a 3rd party manages to hijack one then they can use it to perform whatever the token is authorised to do just by submitting it in the correct manner. Consequently these tokens need to be looked after carefully. Shuffled over encrypted channels and protected by the client. They're arguably even less secure than session cookies since there's no "HTTP Only" option on an access token so preventing malicious access to tokens from dodgy code on clients is something the developer needs to manage. And given the number of clients around and quality of code out there we can pretty much assume a good chunk will be piss poor at this.

So Bearer tokens. Not so great.

MAC tokens aren't just static strings. A client secret and nonce is combined with some request data to essentially sign tokens. So if you hijack a request in flight you can't replay the token - it's valid only for the original request. This is good but really only protects against snooping over the wire which SSL/TLS does a pretty good job of managing without all the additional complexity. Beyond this a MAC token seems to make very little difference. The client needs to know the secret in the same way it would need a Bearer token. If someone manages to snatch this we're done for regardless and the false sense of security MAC tokens give isn't worth a damn.

The client application is often the weak point in OAuth since it's often an untrusted device - mobile phones and web-browsers (single page applications) etc. If the "client" is a downstream server (and this poor terminology by the way has caused way too much confusion and argument) then we've a reasonable chance to secure the server and data but ultimately we're still going to have a client ID and secret stuffed in memory just like we would have with a Bearer token. Ok, so we're adding some hoops to jump through but really it's no more secure.

So if we don't have transport level encryption (SSL/TLS) then MAC tokens offer some reasonable value over Bearer tokens. But if we do have transport encryption then MACs just add complexity and a false sense of security. Which I'd argue is a bad thing since increased complexity is likely to lead to increased defects... which in security is a very bad thing!

Besides, neither option allows me to identify the user or ensure the client calling the service is authorised to do so... Just that they appear to be in possession of a token saying the user has granted them authority (which may have been hijacked as per above).

p.s. One of my many failed new years resolutions was to post a new article every week of the year. This being the first four weeks in isn't a good start...

Microsoft Predicts 2016

Microsofts predictions for 2016. Worth a read. Lots about machine learning, big-data and encryption. All very optimistic including one guy (Lucas Joppa) who expects the human race to wake up to technology being the saviour to our impending doom. Unfortunately I fear the human race is all too desperate for a saviour - real or imagined - and that desperation can lead to a belief in false gods little better than the devil we know today. But still, there's a huge amount that can be done to improve the efficiency and effectiveness of technology in general and so vast room for improvement. Lets hope Mr Joppa is right...

... oh, and yes, environmental impact is a non-functional characteristic.

Women in IT

If you ever wondered why there aren't enough women working in IT, the problem appears to stem from earlier in life. The data below from ONS shows the greatest discrepancy between men and women is in Engineering & Technology and Computer Science (this from 2010 so could probably do with an update!). And whilst it isn't mandatory to have an academic background in IT I personally prefer it when I'm scanning CVs.



Let's remember that Ada Lovelace is generally regarded as the first computer programmer and was - shock! - a WOMAN!!! So, a few links to help get your daughters into IT:

• BCS Women in IT


• Girls in Tech UK


• Girls in Tech


• National Center for Women & IT


• MIT Womens Technology Program


• Girls in Technology


• Tech Needs Girls

Letsencrypt on Openshift

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 while I've been thinking I should get an SSL cert for the site. Not because of any security concern but because Google and the like rank sites higher up if they are https and; well, this is nonfunctionalarchitect.com and security is a kind of 'thing' if you know what I mean. But certs cost £'s (or $'s or €'s or whatever's). Not real pricey, but still I can think of other things to spend £50 on.

But hello!, along comes letsencrypt.org. A service allowing you to create SSL certs for free! Now in public beta. Whoo hooo!

It isn't particularly pretty at the moment and certs only last 90 days but it seems to work ok. For Openshifts Wordpress gear you can't really do much customization (and probably don't want to) so installing letsencrypt on that looks messier than I'd like. Fortunately you can create a cert offline with letsencrypt and upload it to wordpress. Steps in a nutshell:

1. Install letsencrypt locally. Use a Linux server or VM preferably.


2. Request a new manual cert.


3. Upload the specified file to your site.


4. Complete cert request.


5. Upload certificate to openshift.

Commands:

1. Install letsencrypt:
   
   
   
   1. 
      

      git clone https://github.com/letsencrypt/letsencrypt

      
      
   
   
   2. 
      

      cd letsencrypt

      
      
   
   
   
   


2. Request a new manual cert:
   
   
   
   1. 
      

      ./letsencrypt-auto --agree-dev-preview -d <your-full-site-name> --server https://acme-v01.api.letsencrypt.org/directory -a manual auth -v --debug

      
      
   
   
   
   


3. This command will pause to allow you to create a file and upload it to your website. The file needs to be placed in the /.well-known/acme-challenge folder and has a nice random/cryptic base-64 encoded name (and what appears to be a JWT token as contents). This is provided on screen and mine was called something like KfMsKDV_keq4qa5gkjmOsMaeKN4d1C8zB3W8CnwYaUI with the contents something like KfMsKDV_keq4qa5gkjmOsMaeKN4d1C8zB3W8CnwYaUI.6Ga6-vVZqcFb83jWx7pprzJuL09TQxU2bwgclQFe39w (except that's not the real one...). To upload this to an openshift wordpress gear site:
   
   
   
   1. SSH to the container. The address can be found on the application page on Openshift.
   
   
   2. Make a .well-known/acme-challenge folder in the webroot which can be done on the wordpress gear after SSHing via.
      
      
      
      1. 
         

         cd app-root/data/current

         
         
      
      
      2. 
         

         mkdir .well-known

         
         
      
      
      3. 
         

         mkdir .well-known/acme-challenge

         
         
      
      
      4. 
         

         cd .well-known/acme-challenge

         
         
      
      
      
      
   
   
   3. Create the file with the required name/content in this location (e.g. see vi).
      
      
      
      1. 
         

         vi KfMsKDV_keq4qa5gkjmOsMaeKN4d1C8zB3W8CnwYaUI

         
         
      
      
      
      
   
   
   4. Once uploaded and you're happy to contine, press ENTER back on the letsencrypt command as requested. Assuming this completes and manages to download the file you just created you'll get a response that all is well and the certificates and key will have been created.
   
   
   5. To upload these certs to your site (from /etc/letsencrypt/live/<your-site-name/ locally), go to the Openshift console > Applications > <your-app> > Aliases and click edit. This will allow you to upload the cert, chain and private key files as below. Note that no passphrase is required.You need to use fullchain.pem as the SSL cert on Openshift.com and leave the cert chain blank. If you don't do this then some browsers will work but other such as Firefox will complain bitterly...
   
   
   6. Save this and after a few mins you'll be done.
   
   
   
   

Once done, you can access the site via a secure HTTPS connection you should see a nice secure icon showing that the site is now protected with a valid cert :)



Details of letsencrypt.org supported browsers are on their website..

Good luck!