Difference between revisions of "DevOps"
(→External links) |
|||
(One intermediate revision by the same user not shown) | |||
Line 113: | 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== |
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.
Contents
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 non-hosted solution)
- CircleCI (a hosted solution)
- See Comparison of continuous integration software for a more complete list.
- 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.
# | 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
- Linux
- Public Cloud (e.g., GCP, 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
- 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.0 1.1 1.2 Sbarski, Peter (May 2017). "Serverless Architectures on AWS". Manning. ISBN 978-1-617-29382-5.
- ↑ Hofmann, Michael; Schnabel, Erin; Stanley, Katherine (13 March 2017). Microservices Best Practices for Java. IBM Redbooks. pp. 2–3. ISBN 9780738442273.
- ↑ Wiggins, Adam. "The Twelve-Factor App". Archived from the original on 13 June 2017. Retrieved 21 December 2017.
External links
- DevOps Defined — by HashiCorp
- The Twelve-Factor App