#Day 1 Introduction to DevOps

DevOps is the combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity: evolving and improving products at a faster pace than organizations using traditional software development and infrastructure management processes. This speed enables organizations to better serve their customers and compete more effectively in the market.

Automation

DevOps automation is the addition of technology that performs tasks with reduced human assistance to processes that facilitate feedback loops between operations and development teams so that iterative updates can be deployed faster to applications in production.

Scaling

The definition of scaling in DevOps is the process of expanding and shrinking your systems and practices as you need them. Scaling in DevOps requires automation technologies and a forward-thinking DevOps mindset.

DevOps Scaling: Examples + Components to Consider

Different teams do DevOps differently, so the elements that matter most when scaling may also differ. But there are a few marks of a successful DevOps scaling initiative. The components of your DevOps practices you should consider when scaling up or down include:

• A streamlined deployment process. Once you streamline your process, it becomes your framework to drive scalability.

• Automated tests. Most Ops people don’t like to write automated unit/integration tests. Bureaucracy in some companies to simply test in developer environments. Ideally, you can test, integrate, and deploy without fear of stepping on other devs’ toes.

• A smooth CI/CD workflow that eliminates the need to wait for manual approvals.

• Cultural adoption. Change can be hard for teams. Spreading DevOps principles and sharing knowledge is essential to scaling a DevOps initiative across a bigger team with more stakeholders of diverse perspectives.

  The Challenges of Scaling DevOps

  Of course, scaling something as complex, nebulous, and wide-reaching as a DevOps initiative isn’t easy. Here are some of the growing pains of a DevOps scaling strategy:

  • Mitigating deployment challenges. You probably have an existing deployment process that works: it puts hotfixes or new features in the production environment. But how would this same process work if you have more than one team using it? Would you need to request access for each DevOps engineer? How would it work if those two teams were trying to push changes simultaneously? Testing, conflicts, metrics, monitoring, rollback – you can see how the challenges start to mount when you scale. Before achieving an initial framework to scale your CI/CD workflows, your challenge will be finding and optimizing those DevOps bottlenecks that are caused by the simple fact of introducing a new team with potentially different goals, different source code, and metrics.

  • Increasing test coverage. A combination of unit tests and integration tests will help to catch any bug before it goes to production. The Ops side will need test coverage of more than 90% in declarative code – then the challenge becomes keeping that test coverage as your code grows.

  • Getting rid of manual tasks. As everything grows and scales, chances are that manual tasks will keep growing as well, like manual requests for infrastructure (via Excel sheets and emails), manual approvals for several stages of your pipeline, and change management and code freeze stages.

  • Keeping people informed. Without an advocate who can communicate needs and benefits to teams affected by scaling DevOps, your scaling will likely run into friction from internal users and management.

How Do You Know if You Need to Scale Your DevOps?

Here’s how to know it's time to scale up your DevOps practices:

• If you’re struggling to make changes without breaking other systems.

• When you’re seeing increased error rates on production code.

• If increased toil is delaying your releases. When you have so many manual parts in your CI workflows and/or pipelines that is delaying releases.

• When cognitive load slows down your teams. If it’s adding cognitive load to your team just to keep platforms and tools running, you probably need to start scaling up your DevOps initiative.

• When things are going really well for your DevOps. When you’ve proven DevOps success in your area or department, that’s often a great reason to scale it up and adopt DevOps in other engineering teams.

DevOps Scaling: What to Do First

• Evaluate where you are right now. Consider the signs above. How would each department or team benefit from increased scale?

• Identify pain points. Ask yourself what would happen if you took on more work without alleviating problems like error rates, cognitive load, and slow releases.

• Structure your priorities. Think about what’s critical to your organization (like QA, new features, deployment frequency, speed of delivery). How would scaling up your DevOps enable you to achieve each of those?

• Establish success metrics. Do you want pull requests to move to production in a certain time? Will code deployments be limited to a certain number per week?

• Introduce one change at a time. Bite off only what you can chew (or a little less). You’ll have the chance to ask your internal users for feedback and discover what's really holding them back. Then, you can use that information to prioritize improvements as you scale your DevOps.

  Picking DevOps Tools for Scalability

  Your choice of DevOps tools matters as much as your mindset when it comes to scaling. Think of it this way: Would you rather look for solutions to a problem while you’re dealing with it, or pick a tool that can handle it all before you ever encounter the problem?

  Of course, you can’t see the future – but the right choice of tools can make your job much, much easier when it comes time to scale your DevOps initiative. Here’s what to look for in a DevOps tool that can help you scale:

  • Parallelism and availability. You don't want to wait for 20 hours for the CI pipeline to finish.

  • DevOps team collaboration built in.

  • Governance. A scalable DevOps tool should let you track the impact of your actions in the tool, even at large volumes.

  • Extensibility. Scalable DevOps tools should integrate with other tools in your toolchain.

Automation in Scaling DevOps

Automation is the lifeblood of DevOps. It’s not just that automation speeds up work by automating repetitive tasks. From a business perspective, the value of automation in DevOps is that it allows your team to focus on things that really matter to the business, like creating killer software and infrastructure.

Here’s how automation makes it possible to scale DevOps with less effort:

• It starts with automated unit/integration tests

• Then reduce toil with automation in the CI/CD workflow

• Automate reports

• Automate interactions with change management (particularly in enterprises).

• Puppet: Built for DevOps at Scale

  As you can probably tell, scaling DevOps isn’t just a matter of telling more people how to do the same jobs. It’s also not a simple tool swap. It’s both, and moreover, it’s about rethinking the way you do DevOps, why you do it, and your criteria for the tools you pick to do it.

  Many automation tools are built for quick provisioning, testing, and deployment to get you started in DevOps. Puppet is an IT automation and configuration management solution built from the ground up to scale with your organization’s DevOps. With a free trial of Puppet Enterprise, you can get your hands on robust automation tools before you need to scale up.

Infrastructure as code

• Infrastructure as code is the process of managing and provisioning computer data center resources through machine-readable definition files, rather than physical hardware configuration or interactive configuration tools.

• Why DevOps is important ?

• 

  1. Shorter Development Cycles, Faster Innovation

  When development and operations teams are in separate silos, it’s usually difficult to tell if an application is ready for operations. When development teams simply turn over an application, the operations’ cycle times are extended needlessly.

  With a combined development and operations team, applications are ready for use much more quickly. This is important, since companies succeed based on their ability to innovate faster than their competitors do. In fact, Kevin Murphy from Red Hat estimates that shorter development cycles translate to bringing an application to market 60 percent faster than with traditional approaches.

  2. Reduced Deployment Failures, Rollbacks, and Time to Recover

  Part of the reason teams experience deployment failures is due to programming defects. The shorter development cycles with DevOps promote more frequent code releases. This, in turn, makes it easier to spot code defects. Therefore, teams can reduce the number of deployment failures using agile programming principles that call for collaboration and modular programming. Rollbacks are similarly easier to manage because, when necessary, only some modules are affected.

  Time to recover is an important issue, because some failure has to be expected. But recovery is much faster when the development and operations teams have been working together, exchanging ideas and accounting for both teams’ challenges during development.

  3. Improved Communication and Collaboration

  DevOps improves the software development culture. Combined teams are happier and more productive. The culture becomes focused on performance rather than individual goals. When the teams trust each other, they can experiment and innovate more effectively. The teams can focus on getting the product to market or into production, and their KPIs should be structured accordingly.

  It’s no longer a matter of “turning over” the application to operations and waiting to see what happens. Operations doesn’t need to wait for a different team to troubleshoot and fix a problem. The process becomes increasingly seamless as all individuals work toward a common goal.

  4. Increased Efficiencies

  Increased efficiency helps to speed the development process and make it less prone to error. There are ways to automate DevOps tasks. Continuous integration servers automate the process of testing code, reducing the amount of manual work required. This means that software engineers can focus on completing tasks that can’t be automated.

  Acceleration tools are another opportunity for increasing efficiency. For example:

  • Scalable infrastructures, such as cloud-based platforms, increase the access the team has to hardware resources. As a result, testing and deployment operations speed up.

  • Build acceleration tools can be used to compile code more quickly.

  • Parallel workflows can be embedded into the continuous delivery chain to avoid delays; one team waits for another to complete its work.

  • Using one environment avoids the useless task of transferring data between environments. This means you don’t have to use one environment for development, a different environment for testing, and a third for deployment.

5. Reduced Costs and IT Headcount

All of the DevOps benefits translate to reduced overall costs and IT headcount requirements. According to Kevin Murphy from Red Hat, DevOps development teams require 35 percent less IT staff and 30 percent lower IT costs.