The following chapter describes the build methodology followed by OBS for the Full Build model. It is also the method recommended to the customer when building his cloud infrastructure and operations layer.
The quality of the build will determine the resilience, the maintainability, the recovery of the workloads and the efficiency of the run operations.
The methodology varies from one project to another and as such the quote is specific and depends on the scope of work.
For proper accurate quote of the build and kick-off of a build task the following specifications are pre-requisites:
- Architecture diagram of the application and its layout of deployment on AWS services
- Description of the environments required (Dev, Pre-Prod, Prod)
- Security policies and access control
- Environments topology
- Type and inventory of applications, middleware, IaaS/PaaS services used
- Scope and RACI
Should the Customer provide the information during the pre-sales, OBS would quote the build accurately.
Alternatively, should the Customer not have such information during the pre-sales phase, then generic hypothesis would be taken for the build estimation. The build specification and quote would be updated during the initial phase of the project after an audit or after the information is provided.
Nevertheless, please find here-below OBS default reference approach for building Managed Services on AWS. The scope of work will vary depending on customers’ projects.
At the initiation of the project, we build a so-called Landing Zone.
The deployment of the infrastructure is modeled as Infrastructure as Code (IaC) for quality, replicability, disaster recovery. The AWS services are deployed using this IaC as opposed to the use of Human Machine Interface on AWS:
- The deployment code can be tested and validated on non-production environment (e.g. dev, integration, staging, preprod) before going to production.
- Can be replicated and evolved
- Can be used to rebuild the service from a disaster
- Can be versioned
- Can associate deployment of resources as well as operations configuration (monitoring, logging, backup…)
- Optional: when available in a multi-cloud tooling e.g. Terraform, CaasCad, the IaC could be leveraged for other clouds with minimal changes.
By default, OBS uses Terraform and AWS CloudFormation as language for the IaC
- Terraform is more generic and usable across multiple clouds with limited adaptations
- AWS CloudFormation is specific to AWS.
The code base IaC is managed with a tool chain:
- By default, the preference would be to use Terraform.
- Optionally, multi-cloud platforms like CaasCad can be proposed based on cloud agnostic OpenSource like Concourse, Gitea / Gitlab, Terraform and Rancher, Quay for containers. In such case, the tooling is a specific quote separate from AWS subscription.
- Use of customer’s specific software factory needs feasibility assessment and scoping as it impacts the build and run processes.
3 main parts of IaC are leveraged
- The Repository based on GIT where the IaC code base is stored and versioned
- The Pipelines for Build
- The Pipelines for Releases/ Changes
Based on the specifications, OBS IaC developer assigned to the build, will code the IaC and prepare the pipelines for build based on Terraform plans.
Example the code can be structured in a variety of build pipelines and Terraform plans for:
– subscription,
– management
– Identity
– VM
– Database
– etc…
The IaC developer will test the quality of the code
Example for a build
- He makes a pull request on the master branch
- He runs automatically a Terraform Format, a Terraform validate to validate the syntax
- Launches a deployment on AWS to validate the proper deployment.
OBS IaC libraries help gain time in IaC development, nevertheless, projects are often specific and need specific adaptations and developments.
Then OBS developer create the release pipelines
- The release pipeline is the way one deploys the IaC on each AWS environment
- The release pipeline chains deployment to dev platform, then integration/staging, then pre-prod, then production as example would the Customer have such environments.
- The release pipeline is a code base which is moving through environment
- For each environment, OBS IaC developers sets environment variables to adapt consumptions according to the platform: e.g. tiny VM on dev, large on prod.
Custom development might be necessary depending on Customer’s SoW based on specific quote. E.g. implementation of a DNS forwarder for the platform connectivity.
OBS developer enriches the IaC build pipelines with the tooling for operations i.e. monitoring, logging, backups. By default, AWS CloudWatch, AWS Backup will be used. Then connection to OBS Managed Application central supervision system is set-up to alert Level 1 on incident.
Would the customer subscribe to Managed Services for Application Layer, this one would be added to the pipelines leveraging Ansible or Jenkins. The pipe can be decoupled or combined with the infrastructure layer.
The application layer pipelines can deploy the applications on a variety of services whether IaaS, Kubernetes, DBaaS or PaaS leveraging less or more decoupling with the underlying infrastructure and less or more agility and segregation of duty between the application management and the infrastructure management. This architecture is a key factor in providing agility to the application developers thanks to PaaS automation of the underlying infrastructure layers. It also drives the RACI between OBS and the Customer’s developers.
Multiple RACI can be thought through between the Customer and OBS depending on level of delegation desired or depending on environment platforms.
Example: there can be a Software Factory for the application code under the responsibility of the Customer deploying on an infrastructure managed by OBS thanks to a separate Software Factory of the Infrastructure.
Example 2: developers can test the alarms by themselves in the development, integration, and staging environments and then, thanks to SoW and procedures, such alarms can be used by OBS for the monitoring of the Production Environment.
The principle for changes is typically to edit the IaC in order to deploy additional resources or modification, and then leverage the release pipeline to test and deploy the change.
Large changes can involve coding evolution of the IaC or modifying the pipelines and therefore are quoted based on Scope of Work and Impact on the services.
Changes for redeployment consist in leveraging the release pipeline to redeploy.
Direct changes through the AWS user interface are avoided when possible as those changes could not be reproduced automatically in case of disaster or need.
Changes can consist in restoring a backup version of data plane service.
Depending on the organization and quality of code, changes maybe complex or less.
OBS Managed Application promotes the principle by which the team in charge of the run develops the IaC. Nevertheless, the developer of the IaC needs to explain the use of it to the whole team involved in the run including how to edit and release.
The customer shall define the Security Groups and Security Policies as well as Firewalling and Web Application Firewalling rules to be applied. Those policies will be implemented by OBS in the Infrastructure as Code and Firewall as a Service configurations.
The customer shall define the Virtual Private Networking topology and IP address schema that will have to be implemented by OBS.
The customer shall define the Access Control and Credentials that will have to be used by OBS administrators and implemented.
Security recommendations can be part of an optional security Scope of Work based on customer specific case and request. By default, the MRC work units for the RUN do not cover advanced security recommendations.