The IT Toolbox #001 - Definitions

It is vital that IT people communicate with the same lexicon.  This helps to establish definition which provides the specificity necessary to discuss complex topics.

The marketing engine, not to mention the general media, does little to correct ambiguity.  It can be argued that ambiguity in the marketing engine suffers ignorance in the hopes of capturing the next big headline.

This isn’t new.  Key terms do matter.  They are refined over time.

What makes matters worse, we often don’t know ~exactly~ what these terms mean until they are ingrained in a pattern that everyone comes to accept.

One of the best examples is Cloud Computing, “The Cloud” or just simply ‘Cloud.’

The problem with ‘Cloud’ is it doesn’t fit the definition of what everyone believes it to be.

The various definitions I’ve come across include:

Cloud is hosting on the internet.  (True-ish, but not very meaningful.)

Cloud is Infrastructure as a Service.  (It’s not only, but that’s OK.)

Cloud is Platform as a Service.  (A better definition, but also incomplete.)

Cloud is Cloud Native applications.  (This is about as ill fitting as Infrastructure as a Service.)

Cloud is Serverless.  (No, it’s not.  Never was, never will be.)

Cloud is where I’m moving all of our Enterprise Applications.  (That’ll be fun)
            Cloud is Digital.  (as in Digital Transformation, everyone talks about it, but few know how to                                           do it.)

If you’d like to read a thoughtful description of Cloud, have a look at this Wikipedia article: https://en.wikipedia.org/wiki/Cloud_computing  (16 pages and 125 references, 7 deployment models and 6 service models AND 23 disambiguation references)

What I’m getting at is that calling anything ‘Cloud’ lacks definition, its meaning has no precision what-so-ever.

Please make sure others know what you mean, when you say Cloud.

Declarative IT and Design for Operations

Was reading a very insightful and interesting blog from @TorstenVolt on Linked.in titled "Digital Transformation Requires Autonomic Computing 3.0" and started to see some commonality in the needed operations processes with a digital future.

This, by the way, is right after @AWS announces their AWS Outposts, a telling example of how coevolution in IT validates concepts and models (Yes, everyone, Hybrid is real, even Microsoft things so) and how terribly important it is to get to the data.

Torsten brings up some very important points about post transformational examples on what direction needs to take place.  It's very much like the conversation that @cpswan brings up almost every time we talk, how does the future solve the problems we see through Design for Operations.

The solution for Design for Operations revolves distinctly around Declarative IT plus a bit of truth and trust in the platform(s) associated with that same delivery.

I've done my best in capturing/mapping this in a Wardley Map as a way to illustrate the idea.

Figure 1.  Wardley Map showing Declarative needs and Design for Operations of IT Infrastructure

In general, IT Infrastructure Design for Operations includes a Platform for management of Declarative states of underlying infrastructure.

With the abstraction of server virtualization and cloud computing, the declarations became very much least common denominator and not very permissible with respect the evolution of application development (the Dev part of DevOps).  It eased operations of the abstracted layer considerably, but it didn't really enhance the Ops side of the infrastructure model.

At this point, we could argue that the Cloud Titans have already achieved a more horizontally evolved Declarative Platform, but now that everyone seems to be reaching back into the Enterprise Datacenter, permissible use and least common denominator may very well come into play again.

So, looking at the problem that now needs to be solved, truly Declarative Storage and Declarative Compute need to be pressed into evolution toward commodity to achieve the rewards of application integrated software definition of the hybrid datacenter.

This should go a long way toward solving the Design for Operations problems as well as matching up with @TorstonVolt's re-conceptualization of the Digital future state.

Descriptive Evolution Mapping

Thanks to @swardley and the community for steering me to a better definition of the Wardley Maps I was attempting to produce.

Wardley Maps - Evolution Map

The graphic above introduces the product view of each phase of Design.

As a starting point, it is the output of the workload or application that has value.

The applications, and indeed the early computers, were Designed for Purpose.  They were also Custom built.  This is illustrated by the simple fact that repurposing an early computer may very well mean that the equipment necessary to run a different program may have to be changed in some pretty fundamental ways.

     Evolution of computing lead to computers that were capable of multi-purpose computing.  The applications were no longer specifically tied to hardware that they operated on (I know there's an argument brewing here, but it's the generalization I'm illustrating).

This provided the means for individuals and companies to run a multitude of programs on computing equipment.  This was a generational improvement in application development and lead to an entire industry of boxed software delivery.

     The box software products were developed within the framework of a particular operating system with guidelines about what and how commands were processed.  This is a manufacturing guideline and therefore we can identify the boxed software industry as Design for Manufacture and each "box" contained a Product on some type of media.

     Interestingly, the Product area is not necessarily the valuable output of the workload or application, but a means integrated to produce the valuable output.  This means that, while boxed software may very well be a Product, the overall application may still be Custom build, retroactively putting the entirety of said application back into Design for Purpose.

     Another interesting tidbit, the tight control over box software lead to the creation of competitors and the OpenSource industry.  This happened because the design of the overall application mandated variation that the box software vendors were either unwilling or unable to easily produce or it came at great licensing expense.

We reach another evolutionary state with what are arguably extremely easy to consume application outputs.  Built specifically with the consumer in mind and creating a service category (Utility Service) built upon commodity components. These are more easily offered in a volume consumption model of cost/volume-time.

     Utility specifically targets ease of consumption, foremost the usage mechanisms or operation.  It therefore represents a Design for Operations method of delivery.  Constantly being updated and firmly rooted in the idea that the easier it is to use, the more difficult it will be to replace.

     An interesting consequence of Design for Operations is that competitive pressures in Utility drive new business practices like Business Agility/Agile DevOps.

What's next you might ask?  google serverless, then google codeless

Decoupled Hardware and Application Chaining

To start things off, I'm going to "abuse" the value chain from +Simon Wardley mostly because I haven't figured out a better way of describing this.

It is intended to be the start of a conversation, not the end of one.

The argument I'm making is that hardware from the classical/traditional sense of computing is procedurally being decoupled from the execution of the application.  To be sure, we saw some of this with the introduction of virtualization, but it wasn't so much decoupled as pushed so far down the value chain that application architects simply quit thinking of hardware. 

To understand how we get to that state, we should probably start with what has happened to hardware.  A high level depiction provided in Figure 1:

Figure 1.  Value Chain Evolution of Hardware in Computing

 Starting with mechanical computing in the Genesis (lower left) and showing each high level hardware change, like IDC's representation of 1st Platform in the range of Mainframe to "still" Mini Computer, 2nd Platform from Micro Computer to Server Virtualization and 3rd Platform with Cloud Computing and upward with outliers just kicking off in IoT and Private Computing.

Figure 2.  Value Chain of Software Evolution in Computing

Software from a hardware perspective has a more complex value chain with respect to the hardware.  While we could argue the position, the relative perspective can be used to illustrate the mechanics that have driven software and subsystems toward commodity.

A case in the argument being, the use of Operating Systems need to be product, providing ease of use, but input to something like computer Languages has to be custom because of the deep learning required to learn and master.  

This being as much a case of cost of the output of the products as the education needed to create the products and make them useful/use-able.

Ultimately there's something unique happening today that is not necessarily the easiest thing to describe.  Its called #serverless.

We've done things like this before with portability of languages like Java, where the execution method was abstracted away from the hardware sufficiently to run it on multiple hardware devices.

Today we're thinking about a more absolute abstraction of the hardware.  This will make it possible to decouple multiple and complex languages, libraries and applications from the hardware.

To show where and how this is happening, I'm overlaying these two value chains.  Apologies if I've just offended the #Mapping #Gods.

Figure 3.  Combined Hardware - Software

Upper right hand corner holds the primary elements to decoupling hardware from the software.  Hardware is still there, but is only important to those that have to care about it.  

The feedback loop of Agile Development with "Loosely Coupled, Message Event driven and Backflow tuning of the software plays a critical role in reaching the state of the Decoupled Application Function.  Quite a lot of this is to make the application more aware of itself.  

In the hardware area, some element of containerization (capture of all relevant parts of the execution of function of an application or sub application) moves the awareness of the application design away from the hardware to the operating system (arguably another abstraction of the function of the hardware).

Containerization provides the means to swiftly move the application or subcomponents from one hardware underlay to another (think one server to another or one cloud to another).

Ultimately this makes it possible to create components of applications that can become highly standardized or industrialized.  Something we might call #microservices.

These components being decoupled, can be called upon independently by API.  Sufficiently optimized, they can be spun up and down on demand for the execution of a particular function.

The application could simply become a cascade of API calls between decoupled application functions to create an output.

I believe the next trick is going to be related back to a platform mechanism.  We're going to need a schematic or blueprint to create / modify the application.  Something that can understand all of the sub-component elements and provide the messaging and feedback necessary to execute more complex arrangements of applications.

A platform that does Application Chaining.  

This platform could also abstract away the complexity in creation of an application.  With the most simplified models providing a GRAPHICAL interface to the creation of an application.

Also, the sensors that this would provide would be incredibly valuable to the operator of the platform.  It would provide advanced knowledge of new methodologies of applications and sub-components.