Smart customization with no scripting. No cloud vendor lock-in. Full traceability
This article explains the quickest and least cost way to create servers for test or production use at enterprise scale.
Below is a summary of the funcamental strategies to achieve speed for less money. It’s not doing the same thing faster. It’s a new way of working that takes less time and less risk to achieve more.
The narrative to the diagram above is here:
Servers are built on-premises or on major cloud environment (Amazon, Microsoft, Google, etc.), whichever cloud at the lowest cost. Such arbitrage can save money.
In addition to application programming source, infrastructure configurations are stored within a distributed versioned source repository (GitHub, or Bitbucket in the cloud or GitLab on-premises)
Server configurations are defined using declarative statements that specify the end result rather than specific steps This means when a server configuration is run several times, it doesn’t create a mess (this is called “idempotent”)
A single server configuration can be applied to one of several operating systems by use of Docker containers instead of hypervisors which repeat OS kernels in memory
Automation engines (such as Shippable) covers the entire pipeline so integration of Jenkins with 3rd-party tools doesn’t risk projects
Differences between servers in test, demo, prod, and other stages are handled automatically without requiring explicit manual scripting Thus, monitoring and various other utility software for diagnosis are automatically added to each type of server
Instances can be created quicker if build results can saved in a build repository (such as Artifactory) for reuse rather than building each instance from source code
Common to both are notifications sent via variety of channels (email, SMS text, IRC, Slack, Skype, etc.).
TODO: graphic table like https://www.wikiwand.com/en/Industry_4.0
Software for DevOps 2.0
Joe Bada’s list is way more comprehensive, which this post highlights.
“DevOps 2.0” is achieved by tools from several developer groups.
- GitHub / Bitbucket / GitLab
- Artifactory server image repository
- container registry services in cloud environments
- Shippable Lighthouse service watches and sends notifications to Slack, IRC, etc.
- Amazon’s EC2 Container Service (ECS)
- Google Container Engine (GKE)
- Microsoft Azure Container Service
- Docker Cloud
- Docker Datacenter
- Red Hat Openshift 3
Why Upgrade from DevOps 1.0
How long does it take to make a small change … and get it to the end customer? … through tests in various environments which gets more complex as more developers and components
“DevOps 2.0” improves on where the “12 Factor App” promise of DevOps has stalled:
- software too complex to learn
- software too difficult to test in production
- software too brittle
- software operates only within a single vendor’s environment
- inconsistencies of servers in different stages and environments
“Staging Servers Must Die” XebiaLabs @xebialabs https://t.co/oL8G01wq3i
Integration offerings such as Zapier,
Docker containerized environments use Docker Swarm and Compose
Alternative is Mesos-based DC/OS
Kubernetes software watches and adjusts the number of servers as appropriate.
Formation like shipping lanes for applications pipelines
individual deployment units are called Cells.
The main difference is that developers don’t need to learn Jenkins and Chef.
12 Factor App (Heroku)
More on DevOps
This is one of a series on DevOps:
- ci-cd (Continuous Integration and Continuous Delivery)
- Git and GitHub vs File Archival
- Git Commands and Statuses
- Git Commit, Tag, Push
- Git Utilities
- Data Security GitHub
- GitHub API
- Choices for DevOps Technologies
- Java DevOps Workflow
- AWS DevOps (CodeCommit, CodePipeline, CodeDeploy)
- Digital Ocean
- Cloud regions
- AWS Virtual Private Cloud
- Azure Cloud Onramp
- Azure Cloud
- Powershell Ecosystem
- Powershell on MacOS
- Jenkins Server Setup
- Jenkins Plug-ins
- Jenkins Freestyle jobs
- Dockerize apps
- Docker Setup
- API Management Microsoft
- Scenarios for load