Skip to content

Commit edbf0ff

Browse files
Merge pull request #841 from oracle-devrel/operating-model
manu-operating-model
2 parents 4c94f0a + 6f9c000 commit edbf0ff

File tree

3 files changed

+61
-0
lines changed

3 files changed

+61
-0
lines changed
Lines changed: 15 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,15 @@
1+
## Operating Models
2+
3+
This chapter is aimed at outlining the Operating Model importance and the possibilities in the different scenarios
4+
5+
- Single Cloud Provider
6+
- Multi-cloud provider
7+
- Hybrid
8+
9+
# License
10+
11+
Copyright (c) 2024 Oracle and/or its affiliates.
12+
13+
Licensed under the Universal Permissive License (UPL), Version 1.0.
14+
15+
See [LICENSE](https://github.com/oracle-devrel/technology-engineering/blob/main/LICENSE) for more details.
Lines changed: 46 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,46 @@
1+
<!--
2+
Owner: Manuela Fioramonti
3+
Last Change: 20 February 2024
4+
Review Status: Live
5+
Review Notes: -
6+
-->
7+
8+
This chapter briefly introduces Operations, a list of best practices, and a collection of useful resources for a unified operating model in a multi-cloud scenario.
9+
10+
As a quick reminder, Day-1 Operations: these are the operations related to deploying relevant resources in the tenancy, and their configurations.
11+
12+
Day-2 Operations: These are the operations related to being aware of everything going from computing usage and performance to application health, automation, D&R, and lifecycle management.
13+
14+
Operational Excellence means operating your deployments efficiently while focusing on maximum results. It ranges from automated deployments and patching to monitoring and getting ready for peaks, creating a culture of reliability, and accurate cost management.
15+
16+
Multi-Cloud context adds complexity: enterprises and companies must face dependencies and constraints while maintaining operational efficiency. A unified operating model allows them to leverage existing knowledge and processes, orchestrating operations. For this reason, it needs to be cloud-agnostic and provide guidance and best practices that can be applied independently of the technology of choice.
17+
18+
Let's start with the basics:
19+
20+
# Automation & Infrastructure as Code
21+
22+
1. Make Automation part of your culture if this is not the case.
23+
If, in a single-cloud provider scenario, its importance is not always perceived as crucial, except for large-scale deployments, automation becomes paramount in a multi-cloud scenario.
24+
25+
a.Define which Operating scenarios you need to automate: what will be the most frequent operations you will need to run? what are the most complex and prone to human errors?
26+
27+
b. Define the roles: Two typical roles in Infrastructure as Code (IaC) are IaC Developer and Cloud Operator. The IaC Developer provides essential building blocks--modules in Terraform, and Playbooks in Ansible--which are used by the Cloud Operator to deploy resources. The same module or playbook will be used many times to create the same type of resource, each time providing specific parameters for the instantiation. Reusable Terraform modules and Ansible playbooks ensure deployed resources adhere to company-wide or organizational standards.
28+
29+
c. Define Approval workflows for changes: typically you will want to protect resources from unwanted changes.
30+
31+
d. Make your coding provider agnostic and modular.
32+
33+
2. Decide on the repository structure: this will need to support your Multi-cloud approach.
34+
35+
3. Decide what tool you will use to operate. If in your practice you are already using a preferred one, and previous practices have been put in place, you will have no issue in expanding its usage to additional cloud providers.
36+
37+
**Example**
38+
39+
The following Diagram depicts as an example, the use of ServiceNow ITOM to operate across cloud vendors, using two different repositories.
40+
41+
![alt ServiceNow Itom Integration](servicenowitomintegration.png)
42+
43+
# Establish a FinOps practice
44+
45+
Just like Automation and Observability practices, keeping consumption and usage under control and forecastable across cloud providers is another key element to be kept into consideration in a Multi-Cloud Operating Model.
46+
FinOps FOCUS Group, started in April 2023, defined open standard for cloud cost, usage, and billing data, followed by the creation of FOCUS Converters, aimed at providing billing data conversions for FOCUS compliance for AWS, Azure, GCP, and OCI.

0 commit comments

Comments
 (0)