Why Software Defined Environments have to be open
Thomas Spatzier 120000FKVV Visits (2320)
Over the past couple of months, Software Defined Environments (SDEs) have been quite a hot topic in the IT industry and for IBM. There are a number of slightly varying definitions of what SDE means – Matt Hogstrom gave a good definition in one of his recent blogs – but I want to summarize just the most important points from my perspective: SDE is all about application workloads and about using orchestration technology to provide some IT service to end users under certain qualities of services. What started out as Software Defined Compute, Network or Storage using virtualization technology grew to also include middleware and application stacks and into what we call Software Defined Environments today.
One very important aspect with SDE is that workloads have to be described as machine-readable patterns so that orchestration engines can interpret them, can instantiate the required software-defined resources, deploy the respective middleware and application workloads on-top and manage the complete workload to fulfill service level objectives (SLOs). Since those patterns encapsulate quite some expert knowledge and it takes time and skills to create them, it is important to decide on the right format for encoding them. As a pattern author, it is a wise decision to stick to an open, standardized format. This will make your solution portable across environments of different providers, i.e. you will be able to run your workload on Software Defined Environments of different vendors without having to redo your pattern definition. Another aspect is that an open format allows you to use tools from different vendors to create your patterns or to manage workloads.
The IT industry and IBM are investing heavily in open standards and open source, and I have been involved in those activities myself. A few years ago we started – together with industry partners – to standardize a language for describing Cloud applications which led to the OASIS TOSCA standard that became final end of last year. TOSCA allows for describing workload patterns in a portable way so that you can, for example, use tools of different providers to build a workload model, or you can take one and the same model and deploy it to different Clouds. This kind of interoperability has actually been demo
Besides open standards, open source communities are another important pillar for an open ecosystem. Within the OpenStack program, project “Heat” is evolving as an orchestration layer on-top of OpenStack’s base infrastructure APIs. Heat provides for the deployment and management of workloads described as Heat Orchestration Templates (HOT), a language that is currently being defined by the community. Considering the vitality of the OpenStack community and the ever-growing number of contributors around Heat, it is not unlikely for HOT to become a de-facto standard for patterns.
How does that development in open source communities relate to work that is being done in standards bodies? Well, in an ideal world both are aligned so that standards are not a separate thing written down on paper but there is a vivid open source project implementing the standard. This is a path that IBM is following and I have been part of it for about year now. Having been involved in the TOSCA work, I got engaged with the Heat community in early 2013 to see how the two can fit together and to also learn from the community. I joined the definition of the new HOT language to contribute from what we had learned in TOSCA and to align HOT with TOSCA long term. On the other hand, we also started to revise TOSCA based on feedback we got from the Heat community: we started to define a simplified profile of TOSCA, and we started to specify a more easy to consume YAML rendering of TOSCA, both with the goal to align TOSCA closer with HOT development so that at the end, the next version of TOSCA and HOT are (nearly) the same.
Besides being able to describe just the functional aspect of workloads in patterns, one of the next steps that we will be working on with partners in the industry is to also include policies for qualities of services in patterns. This allows pattern authors to describe in a portable way how a workload should behave, no matter in which environment it is running. There are many activities going on in standards bodies and open source communities such as the OpenStack Heat project, and IBM is part of those communities to support and to influence based on our long experience in that area. Feel free to get engaged as well – it is all open!