thecoded.prof
CMU Coding Bootcamp
feat: devops cloud pdf
+286
-2
devops/ci_success.png
devops/cicd/ci_success.png
devops/ci_success.png
devops/cicd/ci_success.png
devops/ci_success.webp
devops/ci_success.webp
This is a binary file and will not be displayed.
devops/cicd.pdf
devops/cicd/cicd.pdf
devops/cicd.pdf
devops/cicd/cicd.pdf
This is a binary file and will not be displayed.
+2
-2
devops/cicd.typ
devops/cicd/cicd.typ
+2
-2
devops/cicd.typ
devops/cicd/cicd.typ
···
167
167
168
168
#meta("Owner", "FreshlyBakedCake")
169
169
#meta("Repository", "Patisserie (default branch: main)")
170
-
#meta("CI/CD System", "Tangled Actions")
170
+
#meta("CI/CD System", "Spindle a.k.a. Tangled Actions")
171
171
172
172
#callout(
173
173
"Scope",
174
174
[
175
-
This document describes the CI/CD pipeline for *Patisserie/PacketMix*, including triggers,
175
+
This document describes the CI/CD pipeline for *PacketMix*, including triggers,
176
176
stages, environments, artifacts, quality gates, and operational procedures.
177
177
],
178
178
)
devops/cloud/cloud.pdf
devops/cloud/cloud.pdf
This is a binary file and will not be displayed.
+284
devops/cloud/cloud.typ
+284
devops/cloud/cloud.typ
···
1
+
#import "@preview/tablex:0.0.9": tablex, rowspanx, colspanx
2
+
3
+
#set page(margin: 1in, height: 14in)
4
+
#set text(font: "Times New Roman", size: 12pt)
5
+
#set par(justify: true)
6
+
7
+
#pad("", 5em)
8
+
#align(center)[
9
+
#text(size: 18pt, weight: "bold")[Cloud Deployment Strategy for Acme Corp Application]
10
+
]
11
+
#pagebreak()
12
+
13
+
#v(1em)
14
+
15
+
= Part 1: Cloud Deployment Model Analysis
16
+
17
+
== Key Factors Influencing Cloud Deployment Model Choice
18
+
19
+
The following key factors influence cloud deployment model selection:
20
+
21
+
1. *Data Sensitivity and Compliance Requirements*
22
+
- Level of sensitive data handled (PII, financial, healthcare)
23
+
- Regulatory compliance needs (GDPR, HIPAA, SOX)
24
+
- Data residency requirements
25
+
26
+
2. *Security and Control Requirements*
27
+
- Need for custom security configurations
28
+
- Level of infrastructure control required
29
+
- Audit and monitoring capabilities
30
+
31
+
3. *Scalability and Performance Needs*
32
+
- Variable vs. consistent workloads
33
+
- Peak processing requirements
34
+
35
+
4. *Functionality Requirements*
36
+
- Application functionality requirements (real-time analytics, machine learning, IoT)
37
+
- Functionality that must be implemented to use the cloud platform
38
+
39
+
== Evaluation of Cloud Deployment Options for Acme Corp
40
+
41
+
#figure(
42
+
tablex(
43
+
columns: 3,
44
+
align: left,
45
+
stroke: 0.5pt,
46
+
[*Deployment Model*], [*Pros*], [*Cons*],
47
+
[*Public Cloud*],
48
+
[• Excellent scalability for variable workloads \ • Minimal management overhead \ • Access to latest technologies \ • Global reach and availability],
49
+
[• Limited control over security configurations \ • Potential compliance challenges with PII \ • Integration complexity with on-premises systems \ • Data sovereignty concerns \ • Shared infrastructure security risks],
50
+
51
+
[*Private Cloud*],
52
+
[• Maximum control over security and compliance \ • Customizable to exact requirements \ • Better integration with on-premises systems \ • Complete data sovereignty \ • Dedicated resources],
53
+
[• High upfront capital investment \ • Significant management overhead \ • Limited scalability compared to public cloud \ • Requires specialized IT expertise],
54
+
55
+
[*Hybrid Cloud*],
56
+
[• Sensitive data kept on-premises/private \ • Can leverage public cloud for scalability \ • Maintains on-premises integration \ • Flexible workload placement],
57
+
[• Increased complexity in management \ • Integration challenges between environments \ • Potential security gaps at connection points \ • Requires expertise in multiple platforms],
58
+
),
59
+
caption: [Cloud Deployment Model Comparison for Acme Corp]
60
+
)
61
+
62
+
#pagebreak()
63
+
64
+
== Recommended Deployment Model: Hybrid Cloud
65
+
66
+
*Justification:*
67
+
68
+
I recommend a *hybrid cloud deployment model* for Acme Corp's application based on the following analysis:
69
+
70
+
1. *Data Sensitivity Handling*: The hybrid approach allows sensitive PII to remain in a private/on-premises environment while leveraging public cloud for less sensitive operations like user interface and general processing.
71
+
72
+
2. *Compliance Requirements*: GDPR compliance can be better managed by keeping personal data in controlled environments while using public cloud services that are GDPR-compliant for supporting functions.
73
+
74
+
3. *Variable Workload Management*: The public cloud component can handle peak processing loads through auto-scaling, while the private component maintains baseline operations and sensitive data processing.
75
+
76
+
4. *On-Premises Integration*: The private cloud component can maintain direct, secure connections to existing on-premises systems, while the public cloud provides modern capabilities and global reach.
77
+
78
+
*Implementation Strategy:*
79
+
- *Private Cloud*: Core database with PII, authentication services, integration layer with on-premises systems
80
+
- *Public Cloud*: Web frontend, API gateway, analytics processing, backup and disaster recovery
81
+
- *Secure Connectivity*: VPN or dedicated connections between private and public components
82
+
83
+
#pagebreak()
84
+
85
+
= Part 2: Service Model Selection (IaaS, PaaS, SaaS)
86
+
87
+
== Functionality Analysis by Service Model
88
+
89
+
#figure(
90
+
tablex(
91
+
columns: 4,
92
+
align: left,
93
+
stroke: 0.5pt,
94
+
[*Functionality*], [*IaaS*], [*PaaS*], [*SaaS*],
95
+
96
+
[*Web Frontend*],
97
+
[*Responsibilities*: VM management, OS patching, web server configuration, load balancing setup \ *Control*: Full control over environment, custom configurations \ *Considerations*: High management overhead, maximum flexibility],
98
+
[*Responsibilities*: Application deployment, configuration management \ *Benefits*: Simplified deployment, automatic scaling, managed runtime \ *Considerations*: Good balance of control and convenience],
99
+
[*Responsibilities*: Configuration and customization only \ *Limitations*: Limited customization, vendor lock-in \ *Considerations*: Minimal control, not suitable for custom applications],
100
+
101
+
[*Backend API*],
102
+
[*Responsibilities*: Server provisioning, OS management, runtime installation, security patching \ *Control*: Complete infrastructure control, custom middleware \ *Considerations*: Maximum flexibility for complex business logic],
103
+
[*Responsibilities*: API development and deployment \ *Benefits*: Managed runtime, automatic scaling, integrated monitoring \ *Considerations*: Ideal for API development with managed infrastructure],
104
+
[*Responsibilities*: Configuration only \ *Limitations*: Very limited - no suitable SaaS for custom APIs \ *Considerations*: Not applicable for custom business logic],
105
+
106
+
[*Database*],
107
+
[*Responsibilities*: Database server setup, backup management, security configuration, performance tuning \ *Control*: Full database control, custom schemas \ *Considerations*: High complexity, maximum customization],
108
+
[*Responsibilities*: Schema design, query optimization \ *Benefits*: Managed backups, automatic scaling, built-in security \ *Considerations*: Good balance for most database needs],
109
+
[*Responsibilities*: Data management and queries \ *Limitations*: Limited to standard database services \ *Considerations*: Suitable for standard database requirements],
110
+
111
+
[*Authentication*],
112
+
[*Responsibilities*: Identity server setup, security implementation, user management system development \ *Control*: Complete control over authentication logic \ *Considerations*: High development overhead, security risks],
113
+
[*Responsibilities*: Authentication flow configuration, user management \ *Benefits*: Faster implementation, fewer security concerns \ *Considerations*: Good for custom authentication with managed infrastructure],
114
+
[*Responsibilities*: Configuration and user management \ *Benefits*: Proven security, compliance certifications, reduced development time \ *Considerations*: Excellent option with established providers],
115
+
),
116
+
caption: [Service Model Analysis for Each Application Functionality]
117
+
)
118
+
119
+
#pagebreak()
120
+
121
+
== Recommended Service Model Mix
122
+
123
+
*Proposed Architecture:*
124
+
125
+
1. *Web Frontend: PaaS*
126
+
- *Rationale*: PaaS provides the right balance of control and management simplicity for frontend applications. It allows for rapid deployment, automatic scaling during peak times, and reduces operational overhead while maintaining sufficient customization capabilities.
127
+
128
+
2. *Backend API: IaaS*
129
+
- *Rationale*: Given the need to handle sensitive customer data and integrate with on-premises systems, IaaS provides the maximum control needed for custom security configurations, specialized processing logic, and secure connectivity requirements.
130
+
131
+
3. *Database: PaaS (Managed Database Service/DBaaS)*
132
+
- *Rationale*: Managed database services provide enterprise-grade security, automated backups, compliance certifications, and professional management while allowing full control over data schemas and access patterns. This is crucial for PII handling and GDPR compliance.
133
+
134
+
4. *Authentication: SaaS*
135
+
- *Rationale*: Authentication is a critical security component where leveraging established, proven solutions reduces risk. SaaS authentication providers offer GDPR compliance, enterprise security features, and integration capabilities while reducing development and maintenance overhead.
136
+
137
+
*Justification Summary:*
138
+
- *Security*: Mix provides appropriate security levels for each component
139
+
- *Compliance*: Managed services often include compliance certifications
140
+
- *Scalability*: PaaS frontend can auto-scale; IaaS API can be customized for scaling
141
+
- *Integration*: IaaS API layer can handle complex on-premises integrations
142
+
143
+
#pagebreak()
144
+
145
+
= Part 3: Data and User Authentication Strategies
146
+
147
+
== Data Model Considerations
148
+
149
+
=== Data Sensitivity Categorization
150
+
151
+
1. *Highly Sensitive Data (Tier 1)*
152
+
- *Personal Identifiable Information (PII)*: Names, addresses, phone numbers, email addresses
153
+
- *Financial Data*: Payment information, transaction records
154
+
- *Authentication Data*: Passwords, security tokens, biometric data
155
+
- *Storage Requirements*: Encrypted at rest and in transit, strict access controls, audit logging
156
+
157
+
2. *Moderately Sensitive Data (Tier 2)*
158
+
- *Transactional Data*: Purchase history, usage patterns, preferences
159
+
- *Business Data*: Internal analytics, operational metrics
160
+
- *Storage Requirements*: Encrypted at rest, controlled access, regular backups
161
+
162
+
3. *Low Sensitivity Data (Tier 3)*
163
+
- *Application Logs*: System performance logs, error logs (without PII)
164
+
- *Public Content*: Marketing materials, general application content
165
+
- *Storage Requirements*: Standard security measures, regular maintenance
166
+
167
+
=== Storage Strategy: Partitioned Approach
168
+
169
+
*Recommendation: Partitioned Data Storage*
170
+
171
+
*Justification:*
172
+
173
+
1. *Privacy Protection*: Separating PII from transactional data reduces exposure risk and limits the scope of potential breaches.
174
+
175
+
2. *Compliance Alignment*: GDPR requires specific handling of personal data. Partitioning allows for tailored security measures and easier compliance management.
176
+
177
+
3. *Performance Optimization*: Different data types have different access patterns. Partitioning allows for optimized storage and retrieval strategies.
178
+
179
+
4. *Scalability*: Non-sensitive data can leverage more scalable public cloud solutions while sensitive data remains in controlled environments.
180
+
181
+
*Implementation Strategy:*
182
+
- *Partition 1*: PII and authentication data in private cloud with maximum security
183
+
- *Partition 2*: Transactional and business data in managed database services
184
+
- *Partition 3*: Logs and analytics data in scalable public cloud storage
185
+
186
+
=== GDPR Compliance Strategy
187
+
188
+
1. *Data Residency*: Store EU citizen data within EU data centers
189
+
2. *Encryption*: AES-256 encryption at rest, TLS 1.3 in transit
190
+
3. *Access Controls*: Role-based access with principle of least privilege
191
+
4. *Right to be Forgotten*: Implement data deletion capabilities across all partitions
192
+
5. *Data Portability*: Enable data export functionality
193
+
6. *Audit Logging*: Comprehensive logging of all data access and modifications
194
+
7. *Consent Management*: Track and manage user consent for data processing
195
+
196
+
== User Authentication Strategy
197
+
198
+
=== Recommended Authentication Method: Multi-Factor Authentication (MFA)
199
+
200
+
*Primary Method*: Username/Password + MFA
201
+
202
+
*MFA Options*:
203
+
- SMS-based codes
204
+
- Authenticator apps (TOTP)
205
+
- Hardware security keys (for high-privilege users)
206
+
207
+
*Justification:*
208
+
209
+
1. *Security*: MFA significantly reduces the risk of unauthorized access, even if passwords are compromised
210
+
2. *User Experience*: Familiar primary authentication method with additional security layer
211
+
3. *Compliance*: Meets most regulatory requirements for sensitive data access
212
+
4. *Flexibility*: Multiple MFA options accommodate different user preferences and security needs
213
+
214
+
*Additional Features:*
215
+
- Single Sign-On (SSO) for internal systems integration
216
+
- Adaptive authentication based on risk assessment
217
+
- Account lockout policies and monitoring
218
+
219
+
=== Authorization Implementation
220
+
221
+
*Role-Based Access Control (RBAC) with Attribute-Based Access Control (ABAC) Elements*
222
+
223
+
1. *Role Definition*:
224
+
- *Customer*: Basic application access, own data only
225
+
- *Customer Service*: Read access to customer data, limited modification rights
226
+
- *Administrator*: Full system access with audit logging
227
+
- *Data Analyst*: Read-only access to anonymized data
228
+
229
+
2. *Attribute Considerations*:
230
+
- Time-based access (business hours for certain roles)
231
+
- Location-based restrictions for sensitive operations
232
+
- Device trust levels
233
+
234
+
3. *Implementation Approach*:
235
+
- Centralized authorization service
236
+
- Token-based access control (JWT with appropriate claims)
237
+
- Resource-level permissions with fine-grained controls
238
+
- Regular access reviews and automated privilege management
239
+
240
+
#pagebreak()
241
+
242
+
= Part 4: AWS Best Practices (Web Application Deployment)
243
+
244
+
== Chosen Scenario: Web Application Deployment
245
+
246
+
I have chosen *web application deployment* as it directly aligns with Acme Corp's need to deploy a customer-facing application with sensitive data handling requirements.
247
+
248
+
== AWS Best Practices by Category
249
+
250
+
=== Security
251
+
252
+
1. *AWS Identity and Access Management (IAM) with Least Privilege Principle*
253
+
- *Description*: Implement fine-grained IAM policies that grant only the minimum permissions necessary for each role
254
+
- *Importance*: Reduces the attack surface and limits potential damage from compromised credentials, especially critical when handling PII
255
+
- *Reference*: AWS IAM Best Practices (https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
256
+
257
+
2. *AWS WAF (Web Application Firewall) and Shield for DDoS Protection*
258
+
- *Description*: Deploy AWS WAF to filter malicious web traffic and AWS Shield for DDoS protection
259
+
- *Importance*: Protects the application from common web exploits and ensures availability during attacks, crucial for customer-facing applications
260
+
- *Reference*: AWS WAF Best Practices (https://docs.aws.amazon.com/waf/latest/developerguide/waf-best-practices.html)
261
+
262
+
=== Reliability
263
+
264
+
1. *Multi-AZ Deployment with Auto Scaling*
265
+
- *Description*: Deploy application components across multiple Availability Zones with auto scaling groups
266
+
- *Importance*: Ensures high availability and fault tolerance, automatically handling failures and traffic spikes
267
+
- *Reference*: AWS Well-Architected Reliability Pillar (https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html)
268
+
269
+
2. *Amazon RDS Multi-AZ with Automated Backups*
270
+
- *Description*: Use RDS Multi-AZ deployments with automated backups and point-in-time recovery
271
+
- *Importance*: Provides database high availability and data protection, essential for preserving customer data
272
+
- *Reference*: Amazon RDS Best Practices (https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_BestPractices.html)
273
+
274
+
=== Performance Efficiency
275
+
276
+
1. *Amazon CloudFront CDN with Caching Strategies*
277
+
- *Description*: Implement CloudFront for content delivery with appropriate caching policies
278
+
- *Importance*: Reduces latency for global users and decreases load on origin servers, improving user experience
279
+
- *Reference*: CloudFront Best Practices (https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/best-practices.html)
280
+
281
+
2. *Elastic Load Balancing with Application Load Balancer*
282
+
- *Description*: Use Application Load Balancer with proper health checks and routing algorithms
283
+
- *Importance*: Distributes traffic efficiently and provides layer 7 routing capabilities for better resource utilization
284
+
- *Reference*: ELB Best Practices (https://docs.aws.amazon.com/elasticloadbalancing/latest/application/application-load-balancer-best-practices.html)
devops/deploy_success.png
devops/cicd/deploy_success.png
devops/deploy_success.png
devops/cicd/deploy_success.png
devops/deploy_success.webp
devops/deploy_success.webp
This is a binary file and will not be displayed.