├── .gitignore
├── LICENSE
├── README.md
└── doc
    ├── application_deployment_engineering_practices.md
    ├── concepts.md
    ├── identity.md
    ├── platform_apis.md
    ├── platform_development_resources.md
    ├── platform_foundation_pipelines.md
    ├── platform_services.md
    ├── starterkits.md
    └── tools.md


/.gitignore:
--------------------------------------------------------------------------------
1 | .DS_Store
2 | 
3 | 


--------------------------------------------------------------------------------
/LICENSE:
--------------------------------------------------------------------------------
 1 | MIT License
 2 | 
 3 | Copyright (c) 2020 ThoughtWorks, Inc.
 4 | 
 5 | Permission is hereby granted, free of charge, to any person obtaining a copy
 6 | of this software and associated documentation files (the "Software"), to deal
 7 | in the Software without restriction, including without limitation the rights
 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
 9 | copies of the Software, and to permit persons to whom the Software is
10 | furnished to do so, subject to the following conditions:
11 | 
12 | The above copyright notice and this permission notice shall be included in all
13 | copies or substantial portions of the Software.
14 | 
15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
21 | SOFTWARE.
22 | 


--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
 1 | <div align="center">
 2 | 	<p>
 3 | 		<img alt="Thoughtworks Logo" src="https://raw.githubusercontent.com/ThoughtWorks-DPS/static/master/thoughtworks_flamingo_wave.png?sanitize=true" width=350 />
 4 |     <br />
 5 | 		<img alt="DPS Title" src="https://raw.githubusercontent.com/ThoughtWorks-DPS/static/master/EMPCPlatformStarterKitsImage.png" />
 6 | 	</p>
 7 | </div>
 8 | <br />
 9 | 
10 | The EMPC Platform Starter Kits demonstrate the software building blocks for delivering a modern Engineering Platform inside the Enterprise, providing a self-serve, product experience to software development teams (the internal customers).   
11 | 
12 | #### 1. Introduction   
13 | 
14 | 1.1 [Concepts](./doc/concepts.md)  
15 | 1.2 [Identity and Authorization](./doc/identity.md)  
16 | 1.3 [A Note on Tools](./doc/tools.md)  
17 | 
18 | #### 2. Code 
19 | 
20 | 2.1 [Platform Development Resources](./doc/platform_development_resources.md)  
21 | 2.2 [Foundation Pipelines](./doc/platform_foundation_pipelines.md)  
22 | 2.3 [Customer Onboarding and Management APIs](./doc/platform_apis.md)  
23 | 2.4 [Platform Services](./doc/platform_services.md)  
24 | 
25 | #### 3. The `Demo` Customer 
26 | 
27 | (_pending_)   
28 | 
29 | ##### PSK Maintainers  
30 | 
31 | Internal developer documentation for EMPC Platform Starter Kit lab environments are [here](https://github.com/ThoughtWorks-DPS/documentation-internal).  
32 | 


--------------------------------------------------------------------------------
/doc/application_deployment_engineering_practices.md:
--------------------------------------------------------------------------------
1 | [x] Scope the IAM Role trust policy for IRSA Roles to the service account name, namespace, and cluster
2 | 
3 | Platform customers do not have AWS account access. SA roles are provided by automation.
4 | 


--------------------------------------------------------------------------------
/doc/concepts.md:
--------------------------------------------------------------------------------
  1 | <div align="center">
  2 | 	<p>
  3 | 		<img alt="Thoughtworks Logo" src="https://raw.githubusercontent.com/ThoughtWorks-DPS/static/master/thoughtworks_flamingo_wave.png?sanitize=true" width=200 />
  4 |     <br />
  5 | 		<img alt="DPS Title" src="https://raw.githubusercontent.com/ThoughtWorks-DPS/static/master/EMPCPlatformStarterKitsImage.png?sanitize=true" width=350/>
  6 | 	</p>
  7 |   <h3>1.1 Concepts</h3>
  8 | </div>
  9 | <br />
 10 | 
 11 | ![bootstrap](https://img.shields.io/badge/document-EarlyDraft-yellow.svg?style=for-the-badge&logo=markdown)  
 12 | 
 13 | #### 1.1.1 Engineering Platforms
 14 | 
 15 | The EMPC labs' OSS resources are related to building a modern engineering platform, consumed by internal customers, providing an independently useable, product experience. In the past we have also called these as Delivery Infrastructure products.  
 16 | 
 17 | We refer to these resources collectively as **Platform Starter Kits**.
 18 | 
 19 | > An Engineer Platform is “a foundation of self-service APIs, tools, services, knowledge, and support which are arranged as a compelling internal product. Autonomous delivery teams can make use of the platform to deliver product features at a higher pace, with reduced coordination.” - Evan Bottcher 
 20 | 
 21 | #### 1.1.2 Product Experience
 22 | 
 23 | _Product Experience_ refers to a high-quality, self-serve, consumer experience when using platform capabilities. 
 24 | 
 25 | This is analogous to the experience we've come to expect from the many SaaS providers now offering developer tools.  
 26 | 
 27 | Let's use GitHub as an example. In a well-implemented enterprise adoption of GitGub, as a Developer, knowing the url of the company's organization, I expect to be able to login using my company SSO credentials. I expect that I can interact with git services on-demand, using as much `git` as I need, whenever I need it. I can readily create repos, edit code, delete repos, and in general do all the git-things without needing to ask someone else to do these necessary things on my behalf. I can use the git cli, or I can use the UI wherever it makes sense for my tasks. And I expect to be able to directly call the github API to fully automate whatever behavior I find valuable. If I have to call someone at GitHub, or open a ticket, it should only be when something is broken on their end. And I also expect GitHub to be actively developing the product. As a valued customer, I want to be able to submit feature requests and otherwise influence the product roadmap. But from the start, the functionality available offers significant value and in those places where I wish it could do more - I can adopt my own work-arounds. There is adequaete documentation (text, video, etc) such that it is completely reasonable to expect that I can discover and make full use of GitHub in an independent and self-directed manner.  
 28 | 
 29 | This is the kind of `product` experience that goes into delivering an Engineering Platform.  
 30 | 
 31 | Providing a product experience means removing the organizational lead-time planning and engineering friction normally associated with deploying and managing software. 
 32 | 
 33 | What do we mean by _lead-time planning and engineering friction_? 
 34 | 
 35 | **Lead-Time Planning** 
 36 | 
 37 | When a development team, in the course of creating and delivering business capabilities and customer experiences, must coordinate their own delivery needs with other functional technology teams, this requires engaging in lead-time planning activities to prevent being blocked. 
 38 | 
 39 | Typical examples may include needing to schedule-ahead requests with: 
 40 | * an IAM Team - to create a machine account or custom roles so I can access and customize technologies.
 41 | * a DNS Team - to create DNS entries needed by my service
 42 | * an SSO team - to gain access to each of the various, standard developer resources such as git repositories, pipeline tools, or static code analysis tools. Or to coordinate accurate RBAC within such tools for myself or my team. 
 43 | * a separate DevOps team - to make changes to my pipeline, request additional compute resources, gain access to a production environment during an outage or direct members of the DevOps to perform outage responses on my behalf. 
 44 | * a Monitoring team - to gain access to infrequently used logs or metrics or to request the creation of monitors, alerts, or dashboards. 
 45 | 
 46 | And this is definitely the shortest of lists. 
 47 | 
 48 | A dev team will collectively spend significat hours trying to get needed changes scheduled ahead of the dependent stories, time taken away from delivering business value. As it is not possible to adequately anticipate everything before encountering the situationally specific need, nor predict how long these other teams may need to complete such tasks therefore work is routinely blocked. Yet, organizations are under tremendous delivery pressure and set aggressive delivery dates around backlogs running months and even years into the future. The result is not only blocked stories pilling up across team backlogs, but also teams are continuously re-prioritizing work based not on value but on which stories are not blocked this sprint.  
 49 | 
 50 | _Note. The inter-team dependencies in focus here are not the coordination needs that arise from creating multiple business services and capabilities that may have interdependent outcome goals. While poorly managed domain boundaries amongst business capability teams are also a source of planning challenges and friction, it is the traditional IT and technology silos that are at the heart of engineering platform products._
 51 | 
 52 | **Engineering Friction** 
 53 | 
 54 | Engineering friction is the ubiquitous result of the batch-and-queue assembly line operating model that result from establishing functional 'IT Service' silos. These functional teams are staffed to maintain 100% utilization resulting in widely variable cycle time, reduced quality, and overall increased risk[^1]. 
 55 | 
 56 | Multiple interactions with many such teams increase the communication challenges, additionally contributing to the variable cycle times and frequent re-work.  
 57 | 
 58 | #### 1.1.3 Use of SaaS versus Self-Managed capabilities  
 59 | 
 60 | Throughout the Platform Starter Kit, you will see extensive use of SaaS-based development tools and IaaS providers. This is intentional and recommended. 
 61 | 
 62 | While necessary for delivering high-quality customer experiences in software, none of the tools and technologies used in the development, release, operation, and maintenance of software are themselves strategic differentiators. 
 63 | 
 64 | Organizations routinely under estimate the cost of self-managing COTS, development-related services in particular, even going so far as to use poorly-suited but familiar tools like Jenkins. I.e., it is frequently the case that an honest and realistic assessment of actual cost reveals self-managed Jenkins as the most expensive component in a dev toolchain. 
 65 | 
 66 | Using secure and well-architected SaaS development tools is consistently one of the most accelerating and cost-saving strategies available. And not only during the implementation phase but over the entire life of the platform. 
 67 | 
 68 | Even if you have the financial resources to comfortably afford the increased costs of self-managed development and maintenance of non-differentiated capabilities, the opportunity cost alone negates any perceived value and cannot be recovered later through additional investment. Invest in creating and maintaining the capabilities that are your company's strategic differentiators amongst the competition. New business building is a defining characteristic of digitally successful companies. 
 69 | 
 70 | #### 1.1.4 Evolutionary Architecture and agility
 71 | 
 72 | Friction, rigidity, and instability are the results of organizational and architectural decisions. People often assume architecture is intrinsically hard to change. But what if we design and architect systems to be capable (affordable, timely) of continuous incremental change over time? 
 73 | 
 74 | > An evolutionary architecture supports guided, incremental change as a first principle across multiple dimensions[^2].
 75 | 
 76 | **Adopt** 
 77 | 
 78 | * Evolutionary architecture as a foundational practice.
 79 | * Commit to architecture decisions only after comparative experimentation and based on outcomes of working implementations for real development deliverables.
 80 | * Suitability to IaC lifecycle and domain-bounded implementation is a prerequisite for all tools and technologies.
 81 | * Apply software lifecycle practice to infrastructure code, e.g., test-driven development, continuous integration, pipelines
 82 | * Rigorously architect dimensions for change both in the selection of tools and technologies as well as in their implementation, e.g., use small or narrowly focused tools that are excellent at one thing and inter-operate easily (loosely copuled) with other technologies rather than all-in-one products that attempt to do many different things. Have ease of replacement in mind.
 83 | * Access to infrastructure is self-serve and on-demand. Either a development team self-manages their own infrastructure, or dedicated infrastructure teams deliver a self-serve interface to development teams.
 84 | 
 85 | **Avoid** 
 86 | 
 87 | * Required use of pre-defined solutions regardless of architectural suitability, e.g., must use self-managed technologies from a single vendor (we are an Oracle shop), all development must be in the same programming language (only Java permitted).
 88 | * Purchasing or otherwise committing to architectural solutions based solely on website documentation or sales-engineering assurances
 89 | * Functionally isolating technology or tool decisions away from the primary users or implementors.
 90 | 
 91 | #### 1.1.5 A Definition of Software Defined
 92 | 
 93 | Software Defined Infrastructure means:  
 94 | Use of modern SDLC practices and infrastructure frameworks in the continuous integration and delivery of systems that are resilient, secure, observable, and capable of change at scale.  
 95 | 
 96 | | Software Defined | vs | Not Quite |
 97 | |------------------|----|-----------|
 98 | | Entire Infrastructure deployed using diffable, versioned source Code and 3rd party artifacts| | Varying amounts of manual configuration |
 99 | | Engineered “as software” (evolutionary, tdd, dry, static code analysis, …) | | Engineered mechanically (attempt to pre-architect for all possible outcomes, copy/paste scripts between environments, human inspection for correctness) |
100 | | Orchestrated by domain bounded, heterogeneous pipelines | | Varying amounts of manual orchestration, monolithic infrastructure code |
101 | | Resiliency, security, observability are an attribute of every domain | | DR and monitoring are functionally siloed and optimized, security added on after the fact |
102 | 
103 | #### 1.1.6 Guiding Principals of Platform Product Architectures
104 | 
105 | <br />
106 | <div align="center">
107 |   <h4>Platform Manifesto</h4>
108 |   <p>• There is one platform, not a collection of platforms •</p>
109 |   <p>• The desired state of the platform is a known quantity •</p>
110 |   <p>• The desired state is machine parseable •</p>
111 |   <p>• The only authoritative source for the actual state of the platform is the platform •</p>
112 |   <p>• The actual state must self-correct to the desired state •</p>
113 |   <p>• The entire platform is deployable using diffable source code and 3rd party artifacts •</p>
114 |   <p>• Test don’t inspect •</p>
115 |   <p>• Convention rather than configuration •</p>
116 |   </p>
117 |   <br />
118 |   <p>
119 |   <p>_translation_</p>
120 |   <p>(Every environment is like production)</p>
121 |   <p>(Every detail of the desired state is documented)</p>
122 |   <p>(The "desired state" is part of or consumable by the source-code for the software-defined delivery of the platform )</p>
123 |   <p>(Avoid monitoring only proxies of state wherever possible)</p>
124 |   <p>(The platform architecture is based on resiliency, not just availability)</p>
125 |   <p>(It is software-defined, employing sdlc practices, not merely automated)</p>
126 |   <p>(No dependencies on human inspection either to determine or validate state)</p>
127 |   <p>(Naming is not merely an identifier but aims to be derivable from knowing the product, environment, component, etc)</p>
128 | </div>
129 | <br />
130 | <br />
131 | 
132 | [^1]: Donald G. Reinertsen, "Managing Queues," in _The Principles of Product Development Flow, Second Generation, Lean Product Development_ (Redondo Beach, California: Celeritas Publishing, 2009). The entire book is an excellent treatise on the effects of legacy batch-and-queue processes on the software development lifecycle. 
133 | 
134 | [^2]: Neal Ford, Rebecca Parsons, Patrick Kua, _Building Evolutionary Architectures_ (O'Reilly Media, Inc, 2017), 5. 
135 | 
136 | <hr>  
137 | 
138 | [<kbd> <br> Home <br> </kbd>](../README.md)
139 | 


--------------------------------------------------------------------------------
/doc/identity.md:
--------------------------------------------------------------------------------
 1 | <div align="center">
 2 | 	<p>
 3 | 		<img alt="Thoughtworks Logo" src="https://raw.githubusercontent.com/ThoughtWorks-DPS/static/master/thoughtworks_flamingo_wave.png?sanitize=true" width=200 />
 4 |     <br />
 5 | 		<img alt="DPS Title" src="https://raw.githubusercontent.com/ThoughtWorks-DPS/static/master/EMPCPlatformStarterKitsImage.png?sanitize=true" width=350/>
 6 | 	</p>
 7 |   <h3>1.2 Identity and Authorization</h3>
 8 | </div>
 9 | <br />
10 | 
11 | ![bootstrap](https://img.shields.io/badge/document-EarlyDraft-yellow.svg?style=for-the-badge&logo=markdown)  
12 | 
13 | Identity and authorization is a _solve-for-first_ issue, with repercussions across a platform product implementation.    
14 | 
15 | A general Identity Provider (IDP) is itself a capability that will need to be made available to platform users as well as incorporated into the platform. Effective productization of platform capabilities requires the abstraction of the platform user's identity from the underlying infrastructure IAM capabilities; as you are experiencing right now as you read this document on GitHub. Your identity integration with GitHub is not built around direct or SSO integration with their infrastructure providers IAM capability. Customer identity within GitHub is within an Abstraction layer.  
16 | 
17 | If you are going to deliver a self-serve experience for internal consumers of a engineering platform, how will you enable those internal teams to self-manage team creation and membership? When a team adds a team membership, how will that team member automatically have access to all of the team resources?  
18 | 
19 | The Platform Starter Kit integrates Github and Github Teams information as AuthN and AuthZ, respectively. It is assumed that internal customers will already have been granted access to the company's GitHub organization and can self-manage team creation and membership. Using a Platform touchpoint (CLI, Developer Portal), internal customers can onboard their github team and automatically inherit this team-level authorization across all Platform resources.  
20 | 
21 | PSK lab environments and working code examples make use of **auth0.com** for oauth2 workflows.
22 | 
23 | <hr>  
24 | 
25 | [<kbd> <br> Home <br> </kbd>](../README.md)
26 | 


--------------------------------------------------------------------------------
/doc/platform_apis.md:
--------------------------------------------------------------------------------
 1 | <div align="center">
 2 | 	<p>
 3 | 		<img alt="Thoughtworks Logo" src="https://raw.githubusercontent.com/ThoughtWorks-DPS/static/master/thoughtworks_flamingo_wave.png?sanitize=true" width=200 />
 4 |     <br />
 5 | 		<img alt="DPS Title" src="https://raw.githubusercontent.com/ThoughtWorks-DPS/static/master/EMPCPlatformStarterKitsImage.png?sanitize=true" width=350/>
 6 | 	</p>
 7 |   <h3>2.2 Onboarding and Customer Management APIs</h3>
 8 | </div>
 9 | <br />
10 | 
11 | ![bootstrap](https://img.shields.io/badge/document-EarlyDraft-yellow.svg?style=for-the-badge&logo=markdown)  
12 | 
13 | <hr>  
14 | 
15 | [<kbd> <br> Home <br> </kbd>](../README.md)
16 | 


--------------------------------------------------------------------------------
/doc/platform_development_resources.md:
--------------------------------------------------------------------------------
 1 | <div align="center">
 2 | 	<p>
 3 | 		<img alt="Thoughtworks Logo" src="https://raw.githubusercontent.com/ThoughtWorks-DPS/static/master/thoughtworks_flamingo_wave.png?sanitize=true" width=200 />
 4 |     <br />
 5 | 		<img alt="DPS Title" src="https://raw.githubusercontent.com/ThoughtWorks-DPS/static/master/EMPCPlatformStarterKitsImage.png?sanitize=true" width=350/>
 6 | 	</p>
 7 |   <h3>2.4 Platform Development Resources</h3>
 8 | </div>
 9 | <br />
10 | 
11 | ![bootstrap](https://img.shields.io/badge/document-EarlyDraft-yellow.svg?style=for-the-badge&logo=markdown)  
12 | 
13 | #### 2.4.1 local setup  
14 | [local-platform-environment](https://github.com/ThoughtWorks-DPS/local-platform-environment)  
15 | 
16 | #### 2.4.2 CircleCI executors and orbs
17 | 
18 | _executors_  
19 | [circleci-remote-docker](https://github.com/ThoughtWorks-DPS/circleci-remote-docker)  
20 | [circleci-base-image](https://github.com/ThoughtWorks-DPS/circleci-base-iamge)  
21 | [circleci-executor-builder](https://github.com/ThoughtWorks-DPS/circleci-executor-builder)  
22 | [circleci-infra-aws](https://github.com/ThoughtWorks-DPS/circleci-infra-aws)  
23 | [circleci-kube-ops](https://github.com/ThoughtWorks-DPS/circleci-kube-ops)  
24 |   
25 | [getting started with private runners](https://github.com/ThoughtWorks-DPS/experiment-circleci-private-runners)  
26 | 
27 | _orbs_  
28 | [twdps/base-packages](https://github.com/ThoughtWorks-DPS/orb-base-packages)  
29 | [twdps/orb-tools](https://github.com/ThoughtWorks-DPS/orb-tools)  
30 | [twdps/executor-tools](https://github.com/ThoughtWorks-DPS/orb-executor-tools)  
31 | [twdps/terraform](https://github.com/ThoughtWorks-DPS/orb-terraform)  
32 | [twdps/kube-ops](https://github.com/ThoughtWorks-DPS/orb-kube-ops)  
33 | [twdps/onepassword](https://github.com/ThoughtWorks-DPS/orb-1password-connect)  
34 | [twdps/pipeline-events](https://github.com/ThoughtWorks-DPS/orb-pipeline-events)  
35 | [twdps/python-api](https://github.com/ThoughtWorks-DPS/orb-python-api) 
36 | 
37 | #### 2.4.3 github runners and actions  
38 | 
39 | _workflow job runners_  
40 | [gha-container-base-image](https://github.com/ThoughtWorks-DPS/gha-container-base-image)  
41 | 
42 | _actions_  
43 | [gha-tools-action](https://github.com/ThoughtWorks-DPS/gha-tools-action)  
44 | [common-actions](https://github.com/ThoughtWorks-DPS/common-actions)  
45 | [base-packages-action](https://github.com/ThoughtWorks-DPS/base-packages-action)  
46 | [1password-action](https://github.com/ThoughtWorks-DPS/1password-action)  
47 | [terraform-action](https://github.com/ThoughtWorks-DPS/terraform-action)  
48 | [psk-gcp-cloud-builders](https://github.com/ThoughtWorks-DPS/psk-gcp-cloud-builders)
49 | 
50 | #### 2.4.4 pod configuration  
51 | 
52 | [certificate-init-container](https://github.com/ThoughtWorks-DPS/certificate-init-container)  
53 | [sidecar-mutatingwebhook-init-container](https://github.com/ThoughtWorks-DPS/sidecar-mutatingwebhook-init-container) 
54 | 
55 | <hr>  
56 | 
57 | [<kbd> <br> Home <br> </kbd>](../README.md)
58 | 


--------------------------------------------------------------------------------
/doc/platform_foundation_pipelines.md:
--------------------------------------------------------------------------------
 1 | <div align="center">
 2 | 	<p>
 3 | 		<img alt="Thoughtworks Logo" src="https://raw.githubusercontent.com/ThoughtWorks-DPS/static/master/thoughtworks_flamingo_wave.png?sanitize=true" width=200 />
 4 |     <br />
 5 | 		<img alt="DPS Title" src="https://raw.githubusercontent.com/ThoughtWorks-DPS/static/master/EMPCPlatformStarterKitsImage.png?sanitize=true" width=350/>
 6 | 	</p>
 7 |   <h3>2.1 Foundation Pipelines</h3>
 8 | </div>
 9 | <br />
10 | 
11 | ![bootstrap](https://img.shields.io/badge/document-EarlyDraft-yellow.svg?style=for-the-badge&logo=markdown)   
12 | 
13 | #### 2.1.1 Amazon Web Services
14 | 
15 | * platform authn and authz 
16 |   * [pskctl-auth0-management](https://github.com/ThoughtWorks-DPS/pskctl-auth0-managment)  
17 |   * [pskctl](https://github.com/ThoughtWorks-DPS/pskctl)  
18 | 
19 | * build pipelines  
20 |   * [psk-platform-global-env-values](https://github.com/ThoughtWorks-DPS/psk-platform-global-env-values) _for scaled_
21 |   * [psk-aws-iam-profiles](https://github.com/ThoughtWorks-DPS/psk-aws-iam-profiles)
22 |   * [psk-aws-platform-wan](https://github.com/ThoughtWorks-DPS/psk-aws-platform-wan) _reference_
23 |   * [psk-aws-platform-hosted-zones](https://github.com/ThoughtWorks-DPS/psk-aws-platform-hosted-zones)  
24 |   * [psk-aws-platform-vpc](https://github.com/ThoughtWorks-DPS/psk-aws-platform-vpc)
25 |   * [psk-aws-control-plane-base](https://github.com/ThoughtWorks-DPS/psk-aws-control-plane-base)
26 |   * [psk-aws-control-plane-services](https://github.com/ThoughtWorks-DPS/psk-aws-control-plane-services)
27 |   * [psk-aws-control-plane-extensions](https://github.com/ThoughtWorks-DPS/psk-aws-control-plane-extensions)
28 |  
29 | #### 2.1.2 Google Cloud Platform
30 | 
31 | (_pending_)  
32 | 
33 | #### 2.1.3 Microsoft Azure Cloud Computing Services
34 | 
35 | (_pending_)  
36 | 
37 | * build pipelines
38 |   * [psk-az-iam-profiles](https://github.com/ThoughtWorks-DPS/psk-az-iam-profiles)
39 | 
40 | <hr>  
41 | 
42 | [<kbd> <br> Home <br> </kbd>](../README.md)
43 | 


--------------------------------------------------------------------------------
/doc/platform_services.md:
--------------------------------------------------------------------------------
 1 | <div align="center">
 2 | 	<p>
 3 | 		<img alt="Thoughtworks Logo" src="https://raw.githubusercontent.com/ThoughtWorks-DPS/static/master/thoughtworks_flamingo_wave.png?sanitize=true" width=200 />
 4 |     <br />
 5 | 		<img alt="DPS Title" src="https://raw.githubusercontent.com/ThoughtWorks-DPS/static/master/EMPCPlatformStarterKitsImage.png?sanitize=true" width=350/>
 6 | 	</p>
 7 |   <h3>2.3 Platform Services</h3>
 8 | </div>
 9 | <br />
10 | 
11 | ![bootstrap](https://img.shields.io/badge/document-EarlyDraft-yellow.svg?style=for-the-badge&logo=markdown)  
12 | 
13 | <hr>  
14 | 
15 | [<kbd> <br> Home <br> </kbd>](../README.md)
16 | 


--------------------------------------------------------------------------------
/doc/starterkits.md:
--------------------------------------------------------------------------------
 1 | <div align="center">
 2 | 	<p>
 3 | 		<img alt="Thoughtworks Logo" src="https://raw.githubusercontent.com/ThoughtWorks-DPS/static/master/thoughtworks_flamingo_wave.png?sanitize=true" width=200 />
 4 |     <br />
 5 | 		<img alt="DPS Title" src="https://raw.githubusercontent.com/ThoughtWorks-DPS/static/master/EMPCPlatformStarterKitsImage.png?sanitize=true" width=350/>
 6 | 	</p>
 7 |   <h3>2.3 StarterKits</h3>
 8 | </div>
 9 | <br />
10 | 
11 | ![bootstrap](https://img.shields.io/badge/document-EarlyDraft-yellow.svg?style=for-the-badge&logo=markdown)   
12 | 
13 | (_pending_)  


--------------------------------------------------------------------------------
/doc/tools.md:
--------------------------------------------------------------------------------
 1 | <div align="center">
 2 | 	<p>
 3 | 		<img alt="Thoughtworks Logo" src="https://raw.githubusercontent.com/ThoughtWorks-DPS/static/master/thoughtworks_flamingo_wave.png?sanitize=true" width=200 />
 4 |     <br />
 5 | 		<img alt="DPS Title" src="https://raw.githubusercontent.com/ThoughtWorks-DPS/static/master/EMPCPlatformStarterKitsImage.png?sanitize=true" width=350/>
 6 | 	</p>
 7 |   <h3>1.3 A Note on Tools</h3>
 8 | </div>
 9 | <br />
10 | 
11 | ![bootstrap](https://img.shields.io/badge/document-EarlyDraft-yellow.svg?style=for-the-badge&logo=markdown)   
12 | 
13 | Tools are not neutral components. A chosen tool will either enable or impede architectural and engineering quality.  
14 | 
15 | Tools are not a strategic capability. TCO includes the opportunity cost of what a team could otherwise be working on. In other words, use SaaS tools wherever architecturally appropriate options exist. The use of a qualified SaaS is one of the most accelerating strategies you can adopt, paying dividends on an ongoing basis.  
16 | 
17 | The statement, “It’s not about the tools” means only: No tool is going to solve for or remove the impact of your organizational challenges and culture.  
18 | 
19 | Suitability to IaC lifecycle and a domain-bounded implementation is a prerequisite for all tools and technologies.
20 | 
21 | ### 1.3.1 General tool selection criteria
22 | 
23 | * Use small, focused tools that are exceptional in their implementation and interoperate well, over monolithic solutions. (One measure of _exceptional_ being, is an architecture designed clearly to be user-centric, with a roadmap based on real feedback.)  
24 | 
25 | * Use domain bounded tools and frameworks that can be implemented to enable low-friction changes to higher value alternatives as they become available. Domain-bounded implementation in this case refers to the degree of difficulty in changing the tool when a higher-value product comes along. Implement in such a way that the cost to change is relatively low and not a blocker to the adoption of alternative technologies.  
26 | 
27 | * Prefer solutions offered by qualified SaaS providers over self-managed options, being painfully honest about the actual costs of ownership.  
28 | 
29 | * Use or implement software that has an API.  
30 | * The API should be easy to use and include functional examples.  
31 | * The API should have all the functionality that the application provides.  
32 | * The API should be accessible by more than one language and platform.  
33 | * Coding around deficiencies in the product should be easier than recreating the product.  
34 | * All data stored in the product should be readable and writeable by other applications.  
35 | * For products that have authentication requirements, they should be able to authenticate and authorize from external, configurable sources. (In particular, they must integrate into the general AuthN/Z scheme of the overall platform, either natively or through custom integration.)
36 | * Place a high value on the depth of community involvement and support.  
37 | 
38 | ### 1.3.2 Tools and technologies used in Lab examples
39 | 
40 | #### 1.3.2.1 Artifact stores
41 | 
42 | There are several different types of artifact stores used in the development of a Engineering platform.  
43 | 
44 | **terraform state**  
45 | 
46 | Examples use [terraform cloud](https://www.terraform.io). Access to a quality SaaS terraform state backend addresses a key infrastructure bootstrap challenge for fully software-defined lifecycle management. e.g., you do not need to bootstrap a state store.  
47 | 
48 | Refer to vendor [documentation](https://www.terraform.io/docs/cloud/index.html) for detailed questions. 
49 | 
50 | **secrets management**
51 | 
52 | You will see various secrets-management systems or tools used in the lab environments and working-code examples.  
53 | 
54 | Most examples make use of `1password`.  
55 | 
56 | - [1password](https://1password.com/products/secrets/)
57 | 
58 | ### specific conventions
59 | 
60 | **Use of ENVIRONMENT variables in the configuration of pipeline tools**  
61 | 
62 | While pipeline tools are a critical and necessary part of any software-defined system, inappropriate pipeline architectural choices can result in overly complex and brittle systems.  
63 | 
64 | Environment variables are a key example. While every pipeline orchestration tool provides a built-in mechanism for defining and managing pipeline environment variables, even moderate use of such a feature creates a high-friction management lifecycle and increased security risk.  
65 | 
66 | The only variables defined within the pipeline tool, and thus available at the start of the triggered pipeline, should be the credentials of the pipeline service account. From this starting identity, the pipeline will then interact with the secrets-store or other env-key-store to bring in all other needed environment settings.  
67 | 
68 | By doing so, pipelines automatically benefit from any credential rotation pattern or events related to environment config. And additionally, the complexity of automating the credentials of the pipelines themselves is continuously constrained.  
69 | 
70 | _example with 1password and CircleCI_
71 | 
72 | A CircleCI `context` is defined that coincides with a GitHub team. All CircleCI pipelines reference the context.
73 | 
74 | The only CircleCI ENV var defined within the context is OP_SERVICE_ACCOUNT_TOKEN for the psk 1password vault.  
75 | 
76 | At the start of any pipeline run, inject the credentials for all other pipeline activities or uses of secure config as needed.  
77 | 
78 | **pipelines**
79 | 
80 | You will see examples using various well-suited pipeline tools, though chiefly it will be circleci.  
81 | 
82 | - [**circleci**](https://circleci.com)
83 | - [github actions](https://github.com/features/actions)
84 | 
85 | **build-artifact stores**
86 | 
87 | - [**github packages**](https://github.com/features/packages)  
88 | - [**dockerhub**](https://hub.docker.com)  
89 | 
90 | **code analysis reporting**
91 | 
92 | - [**codeclimate**](https://codeclimate.com)
93 | - [**snyk**](https://snyk.io)
94 | 
95 | <hr>  
96 | 
97 | [<kbd> <br> Home <br> </kbd>](../README.md)
98 | 


--------------------------------------------------------------------------------