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 |
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.
I used to spend some time talking about declarative configuration management (vs imperative) in the infrastructure as code boot camps (before everything was migrated to Katacoda).
ReplyDeleteI like the idea of declarative, but the practicalities are problematic, and you very quickly hit something resembling the halting problem. Too many possible ways of doing things leads to too many corner cases leads to an exploding test matrix of doom.
We can be declarative, but only in a clearly bounded context. So the first conversation needs to be about those boundaries. This turns out to be one of the neat things about cloud services, as the service provider sets the boundaries, and the customers are forced to work within them; thus we have a clearly bounded context that declarative stands a chance of working within. Where we need to be careful is on our own side of the line in the shared responsibility model, as there lies the opportunity to introduce too much variability, and destroy the boundaries of the provider curated bounded context. Serverless is a good example of how constraints are actually helpful, as the boundary definitions are much clearer than they are with (say) a VM (where I have the opportunity to mess things up with an endless choice of operating systems, middleware, languages and frameworks).
Thank you very much for this great post. I read that Post and got it fine and informative. Please share more like that.
ReplyDeleteIT monitoring trial