DevOps the Wall of Confusion understanding the basics of DevOps

In a traditional development cycle, the development  team kicks things off by “throwing” a software release “over the wall” to Operations.

Operations picks up the release artifacts and begins preparing for their deployment. Operations manually hacks the deployment scripts provided by the developers or creates their own scripts.

They also hand edit configuration files to reflect the production environment, which is significantly different than the Development or QA environments.

At best they are duplicating work that was already done in previous environments, at worst they are about to introduce or uncover new bugs.

The IT Operations team then embarks on what they understand to be the currently correct deployment process, which at this point is essentially being performed for the first time due to the script, configuration, process, and environment differences between Development and Operations. Of course, somewhere along the way a problem occurs and the developers are called in to help troubleshoot. Operations claims that Development gave them faulty code. Developers respond by pointing out that it worked just fine in their environments, so it must be the case that Operations did something wrong. Developers are having a difficult time even diagnosing the problem because the configuration, file locations, and procedure used to get into this state is different then what they expect. Time is running out on the change window and, of course, there isn’t a reliable way to roll the environment back to a previously known good state. So what should have been an eventless deployment ended up being an all-hands-on-deck fire drill where a lot of trial and error finally hacked the production environment into a usable state.

DevOPS

In the real world, there are real consequences if you are unable to deliver high-quality software quickly or build the wrong thing to begin with:

40% of IT implementations end up getting reworked because they don’t meet the users’ original requirements

The average cost of one hour downtime of a customer-facing app is calculated at $100.000 dollars per hour – and this does not take into account the damage to reputation, which can be even greater.

Fixing such production issues takes on average 200 minutes per incident

Three quarters of development teams have adopted Agile methodologies today, enabling them to develop faster.

While this is a great number, it does not help if a development team is Agile but deployment still takes weeks or months because IT Ops is perceived as not being Agile

These are just 3 very high-level examples but all the data we have today points toward the same conclusion – this is about more than just frustration or minor delays. Lack of collaboration between development and operations can have substantial impact on a company’s bottom line and success

People = Culture

The people/staff of an organisation are fundamental attributes of successful culture. Trying to change the culture, with takes time, changing culture is no exception and you can't do it alone, exploit compelling events to change culture: downtimes, cloud adoption, devops buzz

Some initial questions?

Have a Shared mission and incentives: infrastructure as code, apps as services, DevOps/all as teams

Consider  hardware as a commodity, servers are like farm animals.

Build deep instrumentation into services, push complexity up the stack

Rally around agile, shared metrics, CI, service owners on call, etc.

 

PROCESS - Definition and design, compliance, and continuous improvement

PEOPLE -   Responsibilities, management, skills development, and discipline

PRODUCTS - Tools and infrastructure

Practices such as ITIL

•Infrastructure as Code (IaC)

•Continuous Integration

•Continuous Delivery

•Continuous Deployment

•Automated Testing

•Release Management

•App Performance Monitoring

•Load Testing & Auto-Scale

•Availability Monitoring

•Change/Configuration Management

•Feature Flags

•Automated Environment De-Provisioning

•Self Service Environments

•Automated Recovery (Rollback & Roll-Forward)

•Hypothesis Driven Development

•Testing in Production

•Fault Injection

•Usage Monitoring/User Telemetry

 

Implementation Practices

There are tools and technologies available to enable DevOps

Microsoft also invests heavily in the open source ecosystem and enables you to keep your existing investments in open source tools while potentially enabling integration with our own technologies.  In the heterogeneous environment below you can see a number different open source products we have interoperability with which play different roles across the entire application lifecycle. 

These open source tools often play a part in more than one aspect of the product lifecycle, but they are listed here based on the primary integration point with a Microsoft technology.

Last but not least, I’d like to point out that the Microsoft Azure platform where you might decide to host your application supports various programming languages like node.js, php, and java as well as underlying open source operating systems like Linux.

https://msopentech.com/blog/project-categories/devops

Using Azure as a infrastructure

 

There is a lot of confusion in the industry when it comes to the cloud. It’s important that you understand both what is happening in the industry and how we think about the cloud.

This is the most commonly used taxonomy for differentiating between types of cloud services.

The industry has defined three categories of services:

•IaaS – a set of infrastructure level capabilities such as an operating system, network connectivity, etc. that are delivered as pay for use services and can be used to host applications.

•PaaS – higher level sets of functionality that are delivered as consumable services for developers who are building applications. PaaS is about abstracting developers from the underlying infrastructure to enable applications to quickly be composed.

•SaaS – applications that are delivered using a service delivery model where organizations can simply consume and use the application. Typically an organization would pay for the use of the application or the application could be monetized through ad revenue.

It is important to note that these 3 types of services may exist independently of one another or combined with one another.

On Premise or Off Premise

Microsoft Azure Stack gives your organization the ability to do anything you can do in the public cloud via the new Azure Resource Manager API at portal.azure.com, on-premises in their own datacenter. So no matter whether you prefer to do your business in the cloud, hybrid, or on-premises, Microsoft has you covered.

So if your interested in teaching DevOps  or want to share your stories please get in touch. 

Resources

Microsoft DevOps factory https://www.thedevopsfactory.com/

DevOps Github https://microsoftdevops.github.io/

Microsoft DevOps https://www.microsoft.com/en-us/server-cloud/solutions/development-operations.aspx

Visual Studio https://www.visualstudio.com/en-us/news/release-archive-vso.aspx

Getting Started with Visual Studio https://www.visualstudio.com/get-started/overview-of-get-started-tasks-vs

Microsoft Channel9 online learning and resources https://channel9.msdn.com

Visual Studio Application Lifecycle Management  https://blogs.msdn.com/b/visualstudioalm

Azure Grant for DevOps in the Curricula https://aka.ms/azureforeducation

Download Visual Studio – https://www.dreamspark.com