| marp | theme | class | ||
|---|---|---|---|---|
true |
default |
|
Defining and standardizing Enterprise Cloud Infrastructure for organizations.
- Senior Software Engineer
- Content Creator (@TheAltF4Stream on Twitch and YouTube)
- Flowchart Artist
- Problem Solver
- Started with frontend (2+ years)
- Followed curiosity to backend (2+ years)
- Continued curiosity to fullstack (2+ years)
- Found passion in DevOps (currently - 4+ years)
A quote from generative AI:
If you don't know what problems you are solving, you can't solve them.
Building of what we learned in "DevOps for Developers" our goals in this course are:
- Break down common problems an organization has
- Identify who solving these problems helps the most
- Explain why it is important to solve these problems
- Build a solution to these problems using standardized practices
- No, but it will help.
We will follow the three W's of strategy for our organization challenges:
- What problem are we trying to solve?
- Who are we solving it for?
- Why are we solving this problem?
- Access Control and Permissions
- Software lifecycles
- Supporting infrastructure
- Developer expierence (aka DX)
- Developers
- Quality Assurance
- IT
- Others
- Organization needs (internal)
- Organization units needs (product, service, etc)
- Role-Based Access Control
- Domains & DNS
- Networking
- Resources (compute, storage, etc)
- Organizational Units (teams)
- Individuals (developers)
- Outside Contributors (third-parties)
- Private vs public TLDs (top-level domains)
- DNS management and routing
- Private networks
- Public networks
- Firewall security boundaries
- Secure connections (VPN, etc)
- Amazon Web Services
- Google Cloud Platform
- Azure Cloud
- Others (boutique or self-hosting)
- Source Control
- Service Management
- Continuous Integration
- Continuous Delivery
- Repository management
- Branch protections & policies
- Code reviews & approvals
- Configuration
- Provisioning
- Building artifacts
- Testing changes
- Code coverage
- Code quality
- Deploying artifacts
- Environment releases
- Faster development cycles
- Faster feedback loops
- Faster time to market
- Faster time to value
Another quote from generative AI:
If you don't know what you did, you can't do it again.
GitOps is a paradigm or a set of practices that emphasizes using Git as a single source of truth for declarative infrastructure and applications.
- Infrastructure as Code
- Automated Deployments
- Reproducibility and Rollbacks
- Enhanced Collaboration
Infrastructure and application configurations are stored in a Git repository and versioned for complete history. This allows for changes to be tracked and reviewed.
Changes to the repo trigger automatic deployments using pipelines or other methods, ensuring the live environment matches the repo's state. This allows for changes to be deployed quickly and reliably.
Since all changes are tracked in Git, it's easy to roll back or recreate specific states of the infrastructure or applications. This allows for changes to be reverted or recreated quickly.
Developers use familiar Git-based workflows for both application and infrastructure changes. This allows for changes to be made by anyone in the organization with proper permissions.
Essentially, with GitOps, if you want to know the current state of your system or how it looks, you just look at your Git repo.
If you want to change the system, you change the repo.
- Terraform* (widely used)
- Pulumi (growing community)
- *OpenTofu (maybe)
OpenTofu, currently, only helps licensing with developers or providers who want to resell Terraform-like solutions. This could change in the future or it could also be another tool.
- declarative based configuration
- very low entrypoint for starting
- massive developer support
resource "aws_vpc" "main" {
cidr_block = "10.0.0.0/16"
instance_tenancy = "default"
tags = {
Name = "main"
}
}- imperative language configuration (NodeJS, Python, Go, .NET, Java & YAML)
- more "customized" solutions with possibly higher entrypoint
- more "flexible" solutions with ability to use any language
import * as pulumi from "@pulumi/pulumi";
import * as aws from "@pulumi/aws";
const main = new aws.ec2.Vpc("main", {
cidrBlock: "10.0.0.0/16",
instanceTenancy: "default",
tags: {
Name: "main",
},
});
- Focus on the problems you are trying to solve
- Focus on how efficient you want to be
- Focus on the tools you are already using
- Desire to use declarative configuration
- Desire to use a single language for all configurations
- Desire to use a single tool for all configurations
- Desire to use imperative configuration (NodeJS, Python, Go, .NET, Java & YAML)
- Desire to use multiple languages for configurations
- Desire to use multiple tools for configurations
- Standardized practices
- Collaboration features
- Additional features (cost management, etc)
- No, but it will help focus money on other problems.
- You can build your own solutions
- You can use open-source solutions
- You can pay engineers to build solutions (employees or contractors)
- Terraform Cloud*
- Pulumi Cloud
- Env0, Spacelift, and others
- Industry standard for enterprise
- Maintains state of infrastructure
- Provides access control features
- Includes infrastructure (no hosting required)
- Alternative to Terraform Cloud
- Maintains state of infrastructure
- No pipelines (requires hosting)
- Alternatives to Terraform Cloud and Pulumi Cloud
- Includes infrastructure (no hosting required)
- Supports multiple types of automation tools (both Terraform and Pulumi, etc)
- Additional features (cost management, etc)
- Focus on the problems you are trying to solve
- Focus on the tools you are already using
- Focus on the features you need first
Continuous integration (CI) is the practice of automating the integration of code changes from multiple contributors into a single software project.
Continuous delivery (CD) is an approach to software engineering based on producing software in short cycles.
- Continuous integration (CI) validates code changes
- Continuous delivery (CD) deploys code changes
- GitHub Actions*
- GitLab CI/CD
- AWS CodePipeline
- Azure Pipelines
- Others (CircleCI, Bitbucket Pipelines, etc)
- Jenkins (not recommended)
- Drone (limited features)
- Others (Concourse, etc)
- Argo Workflows
- GoCD
- Tekton
- No... just no.
- No.
- Also no.
- You will spend more money on engineers.
- You will spend more money on maintenance.
- You will spend more money on security.
- You have specific requirements for a problem.
- Yes. Colocation datacenter.
- Yes. Private clouds (OpenStack and VMware).
- Amazon Web Services*
- Google Cloud Platform
- Azure Cloud
- Others (IBM, etc)
- Digital Ocean
- Linode
- Others (Heroku, etc)
- They can help with specific requirements.
- They can help with specific problems.
- They can help with speed to market.
- Evaluate your requirements
- Include possible future requirements
- Determine which provider fits your needs
- Determine which provider fits your budget
- Test with a constant proof of concept (same used for all providers)
- Document your findings and compare
- Doppler (development secrets management)
- GitHub + Actions (source control & pipelines)
- Terraform Cloud (automation provider)
- AWS (cloud provider)
- Doppler CLI
- GitHub CLI
- Terraform CLI
- AWS CLI