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.

While microservice architectures allowed teams to scale delivery of independently deployable services, most frontend layers are still run as monolithic applications. Similar to server-side applications, frontend layers often grow into large monoliths that are difficult to maintain and evolve. Building, deploying and consuming frontend components across a diversity of teams and web applications can be a daunting task, especially at scale. To address this issue, at OpenTable we enable fast-moving teams to easily build and deploy front-end components using OpenComponents, an open-source, battle tested, front-end microservice architecture for painless component delivery.

The idea behind https://www.thoughtworks.com/radar/techniques/micro-frontendsmicro frontends is to enable multiple teams to work seamlessy together by fostering end-to-end ownership of independently developed, tested and deployed features.

Think about UI as the composition of features which are maintained by independent teams. These teams could be cross-functional allowing them to develop such features end-to-end, from a database to user interface and independently deploy them.

During this session I’ll explain how OpenComponents works, how do we use it at OpenTable and how we allows teams to build ship and consume frontend components at runtime across teams and web applications at scale.

Moving from a traditional Enterprise Data Warehouse culture, i.e. single monolithic Data Warehouse, to a more flexible Integrated Data Warehouse comprising of data marts on different data platforms that meets a specific need, is a challenging proposition but necessity for a nimble agile organization. This case study/talk is an agile/devops transformation journey that started with focus on

* Speed (brings analytics closer to real-time business decisions and insights)
* Scale (Store first, explain later for all data elements) and
* Cost (Modernize with open source technology stack)

We will share insights on our pitfalls and how we overcame the challenges, tooling and open source technologies adoption, realigned our strategies to enable 40+ data engineering teams servicing a complex retail business.