Around the time I first wrote about the trend and movement to label things ‘as-a-service’, my thoughts were primarily around illustrating the risk expectation could become disconnected from delivery.
If you’ve had a vendor pitch on anything ‘as a service’ you will know it sounds like a compelling case, mature, stable, plenty of reference customers, does this mean we should now be considering the how as well as the if, of Xaas?
Web sites and web applications are increasingly using secure connections (HTTPS) for all traffic not just obviously sensitive data, as a way to guard against security threats. However, HTTPS requires encryption/decryption of data, which is computationally intensive. Web applications can therefore benefit from “offloading” the encryption/decryption processing required for HTTPS to specialised hardware devices.
Too few people understand the benefit of using a caching reverse proxy server to improve web page delivery speeds, and instead go straight to a CDN solution, which can be costly and complex to administer.
Is Xaas is a dangerous delusion? I had intended to label this little piece of commentary, ‘Why the details matter far more than you realise’, but I digress.
In the increasingly technical world in which we live and work, I see a growing tendency for broad brush stroke explanations being used to obfuscate detail involved in the running and maintenance of services we are beginning to consider to be ubiquitously available.
It started with email, website hosting, and more recently I’ve begun to notice the creep into both storage and database deployment [Saas, PaaS, IaaS, etc.].
One possible argument in support of this entails statements such as, ‘this is an indicator of maturing technology’ or ‘ it’s commoditisation of expertise’, wherein the proponent often asserts that implementation, and management are ‘easy’. What you can’t really get away from is the need to have someone sufficiently skilled at understanding how to integrate your operations into the Xaas product in question.
Assisting in driving this trend are the technology companies who seem to have re-invented all manner of things ‘as-a-service’, the Xaas sales people are running exactly these lines today.
Having recently been exposed to several presentations and articles aggressively touting the superiority of feature toggles over feature branches, I decided to examine the two techniques a little more closely.
Defining terms: feature branch and feature toggle
A feature branch is a fork in the history of a codebase allowing concurrent development of different features on different version control system (VCS) branches. A feature toggle is a conditional statement that enables or disables a particular feature. All feature development is conducted on mainline, and when features are ready to be deployed the toggle is changed to enable the feature.