Difference between revisions of "DevOps"

From Christoph's Personal Wiki
Jump to: navigation, search
 
(3 intermediate revisions by the same user not shown)
Line 98: Line 98:
 
* Jenkins (a non-hosted solution)
 
* Jenkins (a non-hosted solution)
 
* CircleCI (a hosted solution)
 
* CircleCI (a hosted solution)
 +
* See [[:wikipedia:Comparison of continuous integration software|Comparison of continuous integration software]] for a more complete list.
  
 
;Jenkins
 
;Jenkins
Line 112: Line 113:
 
;BaaS : Backed as a Service
 
;BaaS : Backed as a Service
 
: Cloud hosted, managed, undifferentiated, scaleable
 
: Cloud hosted, managed, undifferentiated, scaleable
 +
 +
==Twelve-Factor App==
 +
 +
The '''Twelve-Factor App methodology''' (aka '''12-factor app''') is a methodology for building software-as-a-service (SaaS) applications. These best practices are designed to enable applications to be built with portability and resilience when deployed to the web.
 +
 +
{|class="wikitable" style=text-align:left
 +
|+ The Twelve Factors<ref name="Red1">Hofmann, Michael; Schnabel, Erin; Stanley, Katherine (13 March 2017). Microservices Best Practices for Java. IBM Redbooks. pp. 2–3. ISBN 9780738442273.</ref><ref name="The12">Wiggins, Adam. "The Twelve-Factor App". Archived from the original on 13 June 2017. Retrieved 21 December 2017.</ref>
 +
! # !! Factor !! Description
 +
|-
 +
| I || Codebase || There should be exactly one codebase for a deployed service with the codebase being used for many deployments.
 +
|-
 +
| II || Dependencies || All dependencies should be declared, with no implicit reliance on system tools or libraries.
 +
|-
 +
| III || Config || Configuration that varies between deployments should be stored in the environment.
 +
|-
 +
| IV || Backing services|| All backing services are treated as attached resources and attached and detached by the execution environment.
 +
|-
 +
| V || Build, release, run || The delivery pipeline should strictly consist of build, release, run.
 +
|-
 +
| VI || Processes || Applications should be deployed as one or more stateless processes with persisted data stored on a backing service.
 +
|-
 +
| VII || Port binding || Self-contained services should make themselves available to other services by specified ports.
 +
|-
 +
| VIII || Concurrency || Concurrency is advocated by scaling individual processes.<!-- Needs improvement but I am tied by WP:NOR -->
 +
|-
 +
| IX || Disposability || Fast startup and shutdown are advocated for a more robust and resilient system.
 +
|-
 +
| X || Dev/Prod parity || All environments should be as similar as possible.
 +
|-
 +
| XI || Logs || Applications should produce logs as event streams and leave the execution environment to aggregate.
 +
|-
 +
| XII || Admin Processes || Any needed admin tasks should be kept in source control and packaged with the application.
 +
|}
 +
 +
==Tools & Technologies==
 +
 +
* [[Linux]]
 +
* Public Cloud (e.g., [[Google Cloud Platform|GCP]], [[:Category:AWS|AWS]], and Azure + their CLIs/SDKs)
 +
* [[Kubernetes]]
 +
* [[Docker]] (or containerd / CRI-O)
 +
* [[Rancher]]
 +
* [[Helm]] (v2/v3)
 +
* [[Terraform]] (+Enterprise)
 +
* [[Ansible]]
 +
* [[Git]]
 +
* CI/CD (e.g., [[Jenkins]])
 +
* Scripting language(s) (e.g., [[Python]], [[Bash]], etc.)
 +
* [[Istio]]
 +
* [[Prometheus]]
 +
* [[Grafana]]
 +
* [[Vault]]
 +
* [[Apache]] and/or [[Nginx]]
 +
* Some DB/SQL (e.g., [[MySQL]])
 +
* [[Redis]]
  
 
==Glossary==
 
==Glossary==
Line 124: Line 179:
  
 
[[Category:Technical and Specialized Skills]]
 
[[Category:Technical and Specialized Skills]]
 +
[[Category:DevOps]]

Latest revision as of 18:34, 4 February 2021

DevOps (a clipped compound of "software DEVelopment" and "information technology OPerationS") is a term used to refer to a set of practices that emphasize the collaboration and communication of both software developers and information technology (IT) professionals while automating the process of software delivery and infrastructure changes. It aims at establishing a culture and environment, where building, testing, and releasing software can happen rapidly, frequently, and more reliably.

DevOps is a software development methodology that flattens and streamlines the communication, collaboration, and integration activities between the software developers and information technology (IT) professionals during the different phases of Software Development Life Cycle.

The adoption of DevOps is being driven by the following factors:

  • Difficulties in use of Agile and other software development processes and methodologies;
  • Demand for an increased rate of production releases from application and business stakeholders;
  • Wide availability of virtualized and Cloud infrastructure from internal ("Private Cloud") and external providers (e.g., AWS, GCP, etc.); and
  • Increased usage of data centre automation and configuration management tools.

Why DevOps?

  • To increase deployment frequency.
  • Significantly shorter time-to-market.
  • For faster recovery when problems occur.
  • For more robust and better integrated security.
  • Better product quality, more reliable releases.
  • A "shift left" in quality — quality of code, testing, architecture, deployability, and culture.
  • For fast feedback loops and effective communication between teams and departments.

Shared Responsibility Model

IaaS (Infrastructure) PaaS (Container) SaaS (Abstract)
Data Data Data
Application Application Application
Operating System Operating System Operating System
Virtualization Virtualization Virtualization
Infrastructure Infrastructure Infrastructure
Physical Physical Physical


Serverless

Serverless is a set of architectural principles.[1]

The principles of serverless[1]
  • Use a compute service to execute code on demand.
  • Write single-purpose stateless functions.
  • Design push-based, event-driven pipelines.
  • Create thicker, more powerful frontends.
  • Embrace third-party services.
Serverless pros and cons[1]
  • Pros
    • It is serverless (i.e., no servers to mange)
    • Flexible
    • Scaleable
    • Low cost
    • Less code
  • Cons
    • Public Cloud
    • Reliance on Service Level Agreements (SLAs)
    • Non-customizable
    • Vendor lock-in
    • Decentralized challenges
Serverless providers (in the Public Cloud)
  • AWS Lambda
  • Google Cloud Functions
  • Azure Functions
  • IBM OpenWhisk
Cost

CI/CD

Continuous Integration (CI)
  • CI is the practice of merging development work with the main branch constantly.
  • Developers commit code to a shared repository (e.g., git) on a regular basis.
  • The version control system (e.g., GitHub) is monitored and when a commit is detected, a build (e.g., via Jenkins) will be triggered automatically.
  • If the build is not "green", developers will be notified immediately.
  • Benefits:
    • Detect problems or bugs as early as possible in the development lifecycle.
    • Since the entire code base is integrated, built, and tested constantly, the potential bugs and errors are caught earlier in the life-cycle, which results in better quality software.
Continuous Delivery
  • Continual delivery of code to an environment, once the code is ready to ship. This could be staging or production. The idea is that the product is delivered to a user base, which can be QAs or customers for review and inspection.
Continuous Deployment
  • The deployment or release of code to production as soon as it is ready.
  • Requires both continuous integration and continuous delivery to be operating first.
CI tools include
Jenkins
  • A continuous integration and build server.
  • It is used to manually, periodically, or automatically build software development projects.
  • It is an open source CI tool written in Java (requires a minimum of Java 7; Java 8 or newer is recommended).

*aaS

IaaS 
Infrastructure as a Service
PaaS 
Platform as a Service
SaaS 
Software as a Service
FaaS 
Functions as a Service (e.g., AWS Lambda)
Cloud hosted, event driven, stateless, massively scaleable
BaaS 
Backed as a Service
Cloud hosted, managed, undifferentiated, scaleable

Twelve-Factor App

The Twelve-Factor App methodology (aka 12-factor app) is a methodology for building software-as-a-service (SaaS) applications. These best practices are designed to enable applications to be built with portability and resilience when deployed to the web.

The Twelve Factors[2][3]
# Factor Description
I Codebase There should be exactly one codebase for a deployed service with the codebase being used for many deployments.
II Dependencies All dependencies should be declared, with no implicit reliance on system tools or libraries.
III Config Configuration that varies between deployments should be stored in the environment.
IV Backing services All backing services are treated as attached resources and attached and detached by the execution environment.
V Build, release, run The delivery pipeline should strictly consist of build, release, run.
VI Processes Applications should be deployed as one or more stateless processes with persisted data stored on a backing service.
VII Port binding Self-contained services should make themselves available to other services by specified ports.
VIII Concurrency Concurrency is advocated by scaling individual processes.
IX Disposability Fast startup and shutdown are advocated for a more robust and resilient system.
X Dev/Prod parity All environments should be as similar as possible.
XI Logs Applications should produce logs as event streams and leave the execution environment to aggregate.
XII Admin Processes Any needed admin tasks should be kept in source control and packaged with the application.

Tools & Technologies

Glossary

SOA
Server Oriented Architecture (legacy way of doing things; microservices are the next step in the evolution of moving away from monolithic applications)

References

  1. ↑ 1.0 1.1 1.2 Sbarski, Peter (May 2017). "Serverless Architectures on AWS". Manning. ISBN 978-1-617-29382-5.
  2. ↑ Hofmann, Michael; Schnabel, Erin; Stanley, Katherine (13 March 2017). Microservices Best Practices for Java. IBM Redbooks. pp. 2–3. ISBN 9780738442273.
  3. ↑ Wiggins, Adam. "The Twelve-Factor App". Archived from the original on 13 June 2017. Retrieved 21 December 2017.

External links

Retrieved from "http://wiki.christophchamp.com/index.php?title=DevOps&oldid=7929"