Continuous Delivery and DevOps

Join me on #Microsoft’s ongoing journey to #DevOps. This journey has #inspiration, #suspense, #humour, #heartache, and a happy ending. #GetInspired to implement #DevOps in your organisation.

At VSTS in Microsoft, we’ve been on a DevOps journey and have moved 82,000+ Microsofties to DevOps. We’re not perfect, we didn’t do this in six months and we’re not done. We had major milestones along the way and the pattern that we followed is very similar to the pattern I see customers following. They start with, “Gosh, I want to reduce my cycle times. I want to do this DevOps thing. I want to move to that cloud cadence. My business isn’t keeping up.” Yes, that’s why we changed too.

The tech industry thrives on the new, with leaders telling us to “move fast and break things.” But what about writing software with the expectation of a lifespan longer than the average Javascript framework?

Kris has been working in the tech industry for over 20 years, and she’s seen many projects and products come and go. One of her own projects is now in its second decade of life online, and she’ll share with you the lessons she’s learned from it. You’ll learn about several key decisions that can set your project up for longterm success, and what trade-offs you can choose to make when speed is of the essence.

Building complex apps are hard and so is adopting sustainable CI/CD practices – we’ll show you how easy it is to develop complex container-native apps using Red Hat technologies and deliver them continuously.

As part of this ‘live’ hands-on workshop, you’ll get to witness the entire journey of developing, building and finally deploying a complex Java application into a staging and production environment, continuously, on OpenShift 3 using OpenShift.io. You’ll learn how to bring analytics to the developer right into her container-based workspace powered by Eclipse Che, for making intelligent decisions on choice of third-party dependencies.

As we uncover how to do Continuous Delivery efficiently using OpenShift.io, we will also showcase how we are building OpenShift.io using efficient CI/CD practices in a fully transparent and open-source way.

Moving IT infrastructure to AWS services creates a model of shared responsibility between the customer and AWS. This shared model can help relieve customer’s operational burden as AWS operates, manages and controls the components from the host operating system and virtualization layer down to the physical security of the facilities in which the service operates.

How can you create a frictionless on-boarding environment when each of the product must implement specific requirements based on the 1) type of products is offered and 2) country in which their products are sold.

How do you create a secure cloud management layer between Application teams infrastructure as to ensure security in the cloud while balancing the developer productivity and enabling continuous integration? Take the operations team on a journey of automation and how the organization looks like after hiring engineers to develop those capabilities following SRE model.

For each layer, the control objectives are defined. For each control objective, the necessary responsibilities & process controls are defined, including company policies and procedures to be followed i.e:

Control Objective: IT third party can demonstrate the effectiveness of their operating model and control environment.
Process Control: The CSP owner will annually review the effectiveness of the AWS operating model and control environment.

Real-time analysis through cloud-based solutions is expected in every domain, including life sciences. However, keeping runtime to real-time and constant can be challenging for problems that vary in their complexity such as genome engineering. Here, the whole genome needs to be analyzed for every potential modification spot, hence the computational complexity of finding the optima spot can vary by orders of magnitude. Using AWS Lambda we break down this task into smaller sub-tasks that can be solved in parallel by instantaneously recruiting additional Lambda functions as the complexity increases. The resulting web-tool, GT-Scan2 was featured on the prestigious AWS Jeff Barr blog as it brings together novel scientific insights and unprecedented cloud-compute capacity. This same idea has been used for building CryptoBreeder.

In this presentation, we will discuss the general template for serverless web-application and discuss bespoke solutions for overcoming technical limitations server-less imposes.

Infrastructure as Code is a radically different way of working for many infrastructure teams, and for application teams.

Users are used to raising tickets, sending emails, or coming around to the desks of infrastructure people to ask for things to be done. Infrastructure people are used to carrying out work by following checklists and running scripts. Managers are used to having detailed designs and project plans for major work, and change request forms and change review boards to handle smaller tasks.

Infrastructure as Code is very different. Infrastructure is defined in files in source control. Change management pipelines – like application deployment pipelines – propagate changes, automatically integrating and testing changes before they are pushed into production. The end result of this is that it’s possible to have much more rigorous control and assurance of infrastructure implementation and changes, with much less planning and ceremony.

This talk aims to describe the moving parts of a typical organisation using Infrastructure as Code. Moving beyond the general patterns, to looking at exactly how changes are implemented and rolled out.

We often think of software architecture as one of those things we just have to do right at the begging of a project, often using fancy tools.

In this talk, James offers an alternative. What decisions would we make differently if we had the ability to rapidly evolve our architecture? The tools and techniques we now have available allow a new type of architectural decision making possible; from Software Defined Networking, IaaS and Continuous Delivery to Real Options and Architecture Decision Records. James will cover pre-requisites that allow us to make small bets on architecture and explore the strange world of evolutionary design that this technique makes possible.

Agile methods and DevOps approaches can bring enormous benefits to an organization by increasing flexibility, reducing time-to-value, all while increasing quality. However, these are not methods you simply “adopt”. They require a substantial transformation of a company’s values, beliefs, and processes. For example, DevOps is about removing impediments from the flow in the software delivery to the business. Likewise, agile requires changing the way the company budgets and funds projects.

This session reflects on the experience of truly transforming IT inside a large organization as opposed to simply adopting DevOps.

People often say that they’re practicing continuous delivery, and then add something like “I can let the security team know any time” or “I just have to run the performance tests.” Ken Mugrage explains why you’re not done with your continuous delivery journey if you can’t push your software to production right now. Along the way, Ken explores code management strategies, deployment patterns, and types of continuous delivery pipelines you can use to make sure you can deploy right now.

Modern software-based services are implemented as large scale, highly distributed systems running in cloud or data centers. Disruptive real-world events like hardware failures or software bugs can create turbulent conditions in the environments where these systems and can lead to unpredictable outcomes. Chaos Engineering is a study of system’s ability to withstand such disruptive turbulent conditions. It works by purposefully injecting failure into the production environment that mirrors the actual failure modes and monitors the recovery.

Chaos engineering uses experimentation to study effects of such disruptions. These experiments typically start by defining “steady state” of the system and come up with metrics that can be used to measure this steady state. Then various events that mirror the failure modes (aka “Chaos”) that are possible in our production environment (e.g. server crash), are injected systematically in the system in controlled environment.

Effect of the injected “Chaos” is observed by collecting and analyzing the metrics identified above. If the system is able to recover successfully, this builds confidence in system’s ability to handle an actual unplanned outage.

If a failure to recover is observed, then it becomes a target for improvement before that behavior manifests in the system at large. By continuing to run these simulations, it is possible to identify several such vulnerabilities. Fixing these vulnerabilities strengthens the system over a period of time. Extensive monitoring and logging is essential for the success of Chaos Engineering in its goal to improve the resiliency of the system.