Network Working Group J. Algermissen Internet-Draft Jan Algermissen Solutions Engineering Intended status: Informational February 20, 2019 Expires: August 24, 2019 Software System Life Cycle Model draft-algermissen-software-system-life-cycle-model-00 Abstract This specification defines an abstract model for software systems and their relationships with each other in order to establish a basic abstraction on which the lifecycle of software systems and collaborations around them can be expressed. In addition, this specification defines a number of message formats and hypermedia controls, to enable the creation of tools and application in the space of software systems life cycle management. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 24, 2019. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Algermissen Expires August 24, 2019 [Page 1] Internet-DraftA model for software system life cycle manageFebruary 2019 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Services . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Execution Environment Types . . . . . . . . . . . . . . . . . 4 4. Basic System Model . . . . . . . . . . . . . . . . . . . . . 5 5. The System JSON Object . . . . . . . . . . . . . . . . . . . 7 6. Stage Sets . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. The Stage Set JSON Object . . . . . . . . . . . . . . . . . . 8 8. Well Defined Execution Environment Variables . . . . . . . . 9 9. Example Implementations . . . . . . . . . . . . . . . . . . . 9 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12 Appendix B. Implementation Notes . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction A wide variety of applications exists that support the journey of developers and other collaborators around the lifecycle of software systems. The aim of this specification is to facilitate integration options between such tools and applications by providing a common abstraction and coordination protocols. 1.1. Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Services The Software System Life Cycle Model aims to facilitate the integration into existing Internet technology and thus uses existing specified semantics whenever possible. One of such integration points is the notion of _Service_, which refers to an abstract capability associated with an interaction protocol expectation. This specification uses the term _Service_ in Algermissen Expires August 24, 2019 [Page 2] Internet-DraftA model for software system life cycle manageFebruary 2019 the exact same sense as it is used by the various specifications available through the IETF. Some relevant specifications are [RFC3232]. [RFC2782], [RFC6763]. On the one hand services are used by capability providing software systems to advertise that they meet the contract associated with a given service name, or in other words, that the providing system meets the expectations of consuming systems of a given service. On the other hand, services are used by consuming systems to express that they have certain protocol and capability expectations when interacting with a providing system. While services in most existing specifications are rather protocol focussed, the service notion seamlessly supports referring to capabilities that exist in more functional areas. The following examples show services that illustrate the notion of _servciew_ as understood by this specification: 'search', 'suggest', 'basket', 'ftp', 'postgres', 'smtp', 'http', 'aws-dynamo', 'gcp-pubsub', 'google-maps',... 2.1. Service Names Service names MUST conform to the syntax requirements stated in [RFC1034], meaning that service names MUST only consist of ASCII letters, digits, and hyphens and that they MUST NOT be longer than 15 characters. Service names are case insensitive. TBD: Differentiate between standardized global services and context- based services 2.2. Port Numbers Services MAY be assigned a port number, see [RFC3232] and https://www.iana.org/assignments/port-numbers 2.3. Service Catalog In order to express dependencies of a system on one or more services, the list of services available in a given context must be known. Systems that have the ability to manage dependencies SHOULD expose service catalogs that list the available services. Algermissen Expires August 24, 2019 [Page 3] Internet-DraftA model for software system life cycle manageFebruary 2019 2.4. Service List Documents The canonical model for a System document is a JSON [RFC8259] object. When serialized as a JSON document, that format is identified with the "application/vnd.ply.servicelist+json" media type. 2.4.1. Example { "services" : [ { "name" : "", "description" : "...", "docs" : [ "" , "" ] }, { "name" : "", "description" : "...", "docs" : [ "" , "" ] } ] } 2.5. The service-catalog Link Relation Type Links with the link relation type 'service-catalog' indicate that the target resource represents a service catalog. 3. Execution Environment Types Common to all software systems is the differentiation between something being developed and actually running it in a given context. The things being develop are inherently bound to the target type of execution environment. This specification defines the notion of _Execution Environment Type_ in order to capture this property of developed software items. An Execution Environment is anyting into which a developed software can be deployed to realize its capabilities in a given runtime environment. Examples of Execution Environment Types are the usual environments such as "Linux Operating System", "Docker", "AWS Lambda", "Java Application Server", "Oracle PL/SQL", but other possible runnable artefacts and Execution Environment Types are "Single Page Applications deployed to a CDN", "The configuration of an integration proxy", "A native mobile app deployed on a mobile phone". Algermissen Expires August 24, 2019 [Page 4] Internet-DraftA model for software system life cycle manageFebruary 2019 3.1. Execution Environment Type Definitions TBD 3.2. Execution Environment Variables TBD 3.3. Execution Environment Type Catalog Systems that support the deployment of software artifacts SHOULD provide an execution evironment type catalog to inform client systems about the supported execution environments. 3.4. The 'execenv-catalog' Link Relation Type Links with the link relation type 'execenv-catalog' indicate that the target resource represents an execution environment type catalog. 4. Basic System Model A software system is understood to consist of components. Components can have dependencies on services. Services are either backing systems like databases or they are external services, such as a search API, a backend IT system, or another system in the sense of 'system' used here. Components can share dependencies that are specific to a system, but no two systems may share the same service instances. Algermissen Expires August 24, 2019 [Page 5] Internet-DraftA model for software system life cycle manageFebruary 2019 +-----------------------------------+ | System | | ~~~~~~ | | -name | | | | +-----------+ +-----------+ | +-------+ | | Component | | Component +--+-- implements ->|Service| | | ~~~~~~~~~ | | ~~~~~~~~~ | | +-------+ | | -name | | -name | | | | -type | | -type | | | +----+-+----+ +-----+-----+ | | | | | | | | +----------------+ | | | | | | V V | | +----------+ +----------+ | | |Dependency| |Dependency| | | |-name | |-name | | | +-----+----+ +----+-----+ | | | | | +--------+-----------------+--------+ | | V V +-------+ +-------+ |Service| |Service| +-------+ +-------+ 4.1. System TBD 4.1.1. System Name Attribute System objects MUST exhibit a "name" property with a string literal value which conforms to the syntax requirements for DNS labels. The labels must follow the rules for ARPANET host names. They must start with a letter, end with a letter or digit, and have as interior characters only letters, digits, and hyphen. There are also some restrictions on the length. Labels must be 63 characters or less ([RFC2181]). 4.2. Component Algermissen Expires August 24, 2019 [Page 6] Internet-DraftA model for software system life cycle manageFebruary 2019 4.2.1. Component Name Attribute Component objects MUST exhibit a "name" property with a string literal value which conforms to the syntax requirements for DNS labels. The labels must follow the rules for ARPANET host names. They must start with a letter, end with a letter or digit, and have as interior characters only letters, digits, and hyphen. There are also some restrictions on the length. Labels must be 63 characters or less ([RFC2181]). 4.2.2. Component Type Attribute Components have an Execution Environment Type indicated by the 'type' attribute. 4.3. Dependency TBD Dependencies are named to differentiate between them. This makes it possible for a system to exhibit one or more dependencies on the same service. 4.4. Service Implementation When systems expose capabilities for use by other systems, they must expose them in order for other systems to consume them as dependencies. 5. The System JSON Object The canonical model for a System document is a JSON [RFC8259] object. When serialized as a JSON document, that format is identified with the "application/vnd.ply.system+json" media type. 5.1. A YAML-formatted example of a system model Algermissen Expires August 24, 2019 [Page 7] Internet-DraftA model for software system life cycle manageFebruary 2019 name: search dependencies: - name: index service: solr - name: config service: postgres components: - name: importer dependencies: ["index","config"] - name: searcher dependencies: ["index"] implements: ["opensearch","my-suggest"] 6. Stage Sets TBD 7. The Stage Set JSON Object The canonical model for a Stage Set document is a JSON [RFC8259] object. When serialized as a JSON document, that format is identified with the "application/vnd.ply.stageset+json" media type. 7.1. A YAML-formatted example of a stage set model name: myset systemref: http://foo.bar.myssystem.example budget: '66474-gghk-88733/00' stages: - name: dev criticality: work dependencyInstances: - name: mydb parameters: - name: foo value: bar componentDeployments: - name: searcher artifact: myrepo.example.com/images/foo:1 dns: www.example.org - name: prod ... Algermissen Expires August 24, 2019 [Page 8] Internet-DraftA model for software system life cycle manageFebruary 2019 8. Well Defined Execution Environment Variables TBD Define the list of common environment variables for execution environments o PLY_LOC_STAGE o PLY_LOC_REGION o PLY_LOC_SYSTEM o ... 9. Example Implementations TBD: Consider describing some areas of application of ply, such as writing a call center user agent for a an origin server. 10. Security Considerations TBD 11. IANA Considerations This specification defines two new Internet media types [RFC6838]. 11.1. application/vnd.ply.system+json o Type name: application o Subtype name: vnd.ply.system+json o Required parameters: None o Optional parameters: None; unrecognized parameters should be ignored o Encoding considerations: Same as [RFC8259] o Security considerations: see Section 5 of this document o Interoperability considerations: None o Published specification: TBD (this document) o Applications that use this media type: HTTP Algermissen Expires August 24, 2019 [Page 9] Internet-DraftA model for software system life cycle manageFebruary 2019 o Fragment identifier considerations: Same as for application/json ([RFC8259]) o Additional information: o Deprecated alias names for this type: n/a * Magic number(s): n/a * File extension(s): n/a * Macintosh file type code(s): n/a o Person and email address to contact for further information: Jan Algermissen algermissen@acm.org [1] o Intended usage: COMMON o Restrictions on usage: None. o Author: Jan Algermissen algermissen@acm.org [2] o Change controller: IESG 11.2. application/vnd.ply.system+yaml TBD 12. References 12.1. Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, . [RFC3232] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, DOI 10.17487/RFC3232, January 2002, . Algermissen Expires August 24, 2019 [Page 10] Internet-DraftA model for software system life cycle manageFebruary 2019 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . 12.2. Informative References [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, DOI 10.17487/RFC2782, February 2000, . [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, . 12.3. URIs [1] mailto:algermissen@acm.org [2] mailto:algermissen@acm.org Algermissen Expires August 24, 2019 [Page 11] Internet-DraftA model for software system life cycle manageFebruary 2019 Appendix A. Acknowledgements Thanks to TBD for their comments. Appendix B. Implementation Notes TBD Author's Address Jan Algermissen Jan Algermissen Solutions Engineering EMail: algermissen@acm.org URI: http://algermissen.io Algermissen Expires August 24, 2019 [Page 12]