Service Providers

Currently, most computer systems are managed incredibly inefficiently and at a significant cost. There are organisations and IT suppliers that make a considerable amount of money by providing support services. On the other hand there are also suppliers that know how to provide excellent products that require minimal support yet arguably operate in simplified, constrained environments which by there very nature reduce customer choice (often to the suppliers considerable benefit).

If commodity computing is to be used reliably by its consumers (organisations and individuals alike) then it should be sold fit for purpose and not in a DIY form!

Customers should also be able to demand a wide variety of software and hardware from multiple suppliers yet also have it all pre-configured and automatically maintained.

To provide this truly heterogeneous yet reliable environment to the customer would require two things:

1. Completely independent IT providers that are motivated to provide an extremely high level of customer service with no vendor lock in.
2. A way software can be provided and then continually maintained in a truly cost effective way without compromise on features or security.

A whole industry of Service Providers could easily provide extremely reliable and more capable software services to customers if the cost of support could be largely mitigated through the use of total automation.

If this environment existed the most likely Service Provider differential could become customer service level rather than hardware or software availability or simply 'compatibility'.

CrowdSourced Support

Wouldn't it be great if software could fix itself off the Internet?

Even when a fix isn't readily available for the exact problem it could be solved by a community of 'solvers' who could gain a reduction in IT service costs by contributing solutions to IT problems.

This would require a few things:

1. IT service providers who provide the software in a unique configuration shared by many customers.
2. The exact configuration of a customer's system may be replicated by willing 'solvers' who can work to publish suitable and fully automatic fixes back to the service provider for validation.
3. A way for the service provider to deploy fixes to the 'shared solution' (ie. service) in a way that can be pre-tested, verified and then ultimately accepted by customers with problems.

See my posts 'Deployment Appliance' and 'CML' for more about standardising automation.

Deployment Appliance

I'll elaborate on this more with some pictures and a list of requirements but for now just a simple definition:

"A computer system distribution designed to deploy entire computer environments from C.M.L. files."

C.M.L. : Freeze dried I.T.

This post discusses technical detail - I'll discuss more after putting this out there!

In my previous post I described a system using source control to express and deliver software deployments. Here I'll expand on one piece of the jigsaw: an XML document type called Configuration Markup Language or CML. A potential RFC in progress?

In short CML should be capable of describing entire user service(s), or technically a software stack, from the hardware up!

Some initial thoughts on the technicalities involved:

1. Must ultimatly describe required hardware type(s) and initial boot images used.
2. Must refer to all dependant services (CML files).
3. Must refer uniquly to a compatible software stack used to 'run' this CML file see 'Builder Appliance'.
4. Describes every post boot configuration change and refers uniquly to all binary image(s) and other files required to get the job done!
5. Will NOT describe any deployment detail specific to a specific site or environment instalation; these details (host names, passwords, ports, number of devices available and unique references etc.) should be held in an environment specific repository.

Total Automation - Remove the root of all errors!

What? - we should aspire to build and maintain computer systems that deliver user services without ANY manual intervention.

Why? - Commodity computer systems may be cheap to aquire but they require many software configuration changes to be made consistently to many environments if they are to be tested and made ready for use. This requires a complex change process which involves (at best) documenting and subsequent interpretation and re-implimentation of complex procedures. This very often introduces errors, support, more change and complexity which ulimatly means unreliable and costly computing!

I believe that we should be automating computers and not writing procedures to try and automate people as we are ultimatly the source of all computer errors!

By comitting all changes to a computer system to documentation that computers can follow directly (automation) we eliminate the source of most errors - human error!

Introduction

I'm the geeky host of this Blog - mad about how to deliver more out of the great potential, but rarely completly working, world of computers!

I'm not really a natural writer or editor (goes with the geeky teritory). I am however bursting with enthusiasm to communicate how to fix the bits of software deployment I know a thing or two about and get some feedback in the process...

I've grabbed my knowledge through many software development, deployment and support projects over the last decade or so and I have some ideas about why computers often don't work, why they do and what to do about it!

People keep giving me work as a contractor and seem to appriciate my work but I want to contribute to something bigger than the next contract - hopefully what I have to say is worth something out there...

Continuous Deployment

Here's an idea; 'Continuous Deployment' defined as: 'the fully automated deployment and configuration of software as expressed in a source control system'. I've borrowed the term from 'Continuous Integration', CI as used in Agile or 'eXtreme Programming'. It would use many similar tools but is concerned with the total automated configuration of user services unlike CI which deals with the build of code and deployment and test of a single software package...

Here's a picture of a scribble I drew on a plane - I'll get a diagram up soon: