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.

Join us for a deep dive into the nuances of breaking a large complex system into smaller independently scalable MicroServices. This will be a hands-on workshop that will introduce you to the MicroServices ecosystem.

MicroServices as an architecture pattern does not guarantee characteristics such as composability, maintainability, resiliency and fault tolerance. It only facilitates our thinking around these aspects better. We will be sharing the design principles that we have learned and applied to achieve these characteristics.

In this workshop, we will be building a Cloud Native MicroServices application from the ground up. In the process will be introducing the following concepts and discussing advantages, disadvantages, alternative approaches etc.

*Gateway/edge services
*Service discovery
*Load balancing
*Inter-service communication and protocols
*Circuit breaker pattern
*Autoscaling

We will be using SpringBoot to build the application and Pivotal Cloud Foundry to deploy the same. However, the concepts are platform agnostic.

All code samples will be available on GitHub. Please feel free to bring your laptops and join us for the ride.

Feature branching is again gaining in popularity due to the rise of Distributed Version Control Systems (DVCS) like Git and Mercurial. With DVCSs, branch creation became very easy. But it comes with a certain cost. Long living branches break the flow of the software delivery process impacting throughput and stability.

This session explores some of the reasons why teams are using feature branches, what problems are introduced by using feature branches and what techniques exist to avoid them all together. In conclusion it explores what is exactly evil about feature branching. Which is not necessarily the problems they introduce. But rather the real reasons teams are using them for.

The key takeaway is an appreciation of a different branching strategy and how it relates to Continuous Integration.