he new world order of business is increasingly centered on the speed in which an organization can leverage digital commerce to rapidly deliver goods and services to consumers. This movement was ignited by the success of companies such as Amazon and Google – who are disrupting traditional businesses by serving consumers better and faster with innovative technology.
To move at this kind of speed, businesses must transform. This means IT needs to be a front office strategic imperative to business and not the back office support system for internal operations. The reality today is that separation between Dev and Ops in large organizations still reigns supreme. We all know this has to change.
In the Ops world many of us seeDevOps as the future. Our developer brethren think about Agile development practices and moving from multi-month (or year!) development cycles to short sprints. We are all really talking about the same thing. Breaking down organizational boundary’s and integrating teams to move faster. Then integrating tool chains so that we have common tooling and don’t need to hand off artifacts (see CODE!) and continuously delivering innovation for the business. There is a process for making this transition and that we here at Opscode have seen in practice. Adam will talk about the 5 key drivers of success in making that transition.
Warning - business transformation is not for the light of heart!
There are many sources of complexity in any infrastructure automation project. Some are inherent to the infrastructure itself: Cloud vs. hosted vs. VMs, operating systems, software configuration, etc., but others are inherent to the problem users are trying to solve. As DevOps and infrastructure automation adoption keeps increasing outside of the datacenter, the scenarios get more complex and abstract. I would like to explore the sources of this complexity and talk about a programmatic approach.
In general, when talking about infrastructure automation, we tend to consider a single production scenario, OR maybe a few of them if you consider QA, staging, etc., or even different zones, but these scenarios are relatively static in number and in form. As automation goes upstream, from the Ops world into the Dev world, the number and dynamic nature of the scenarios increases dramatically. Developers see infrastructure as a fluid concept, just like the software they are accustomed to writing. For example, a developer needs to test a new code on an environment built to match the production one, but with some very specific variations, or sometimes to test the same code with many of those variations automatically. Often, the configuration and state of the services the developer requires might need a specific network layout, or the database loaded with a particular dataset. Furthermore, there usually are many developers on the same product team, and they might work concurrently on different code branches at any time, each branch possibly requiring different variation of the infrastructure. In these scenarios we see a combinatorial explosion of systems to build, and a big bottleneck for a DevOps team.
Similar complexity growth can be seen with cluster-centric infrastructures, as is the case in Big Data projects. Building a big data setup is a relatively complex but mostly solved task, but operating these clusters continues to be mostly an art form. The decision making required for operating these clusters varies from cluster to cluster, from user to user, and the decisions to be made involve OS, software, cluster, and application-wide knowledge. This is again a combinatorial explosion of factors and decisions.
One way to tackle such complexity is by taking a programmatic approach to automation. From this perspective, you first abstract over some of the inherent sources of complexity --infra, OS, software, etc--, then over the composite parts of your infrastructure, nodes, clusters, groups, and finally write the code to operate all OF these abstractions in a coordinated manner. With this approach, the actual programming is no different than regular software development, and hence you can leverage the tried and true Software Engineering practices for all other complex software development.
Security testing is often done at the cadence of auditors and not at the pace of the dev team. Gauntlt is an open source framework that helps you “be mean to your code” through development and into release--facilitating ruggedized software and better communication between dev, ops and security teams. This talk will help you implement Gauntlt into your projects with plenty of real world examples.
The values and ideas espoused by the DevOps movement are great, but by itself isn’t enough. That should be obvious because it is just Dev & Ops, right? Frankly, DevOps is just a piece of a bigger puzzle that needs to be put together to form a whole picture. The same goes for Agile development—not enough. We now have the Lean Startup and LeanUX. We have technologies and practices like the Cloud and Continuous Delivery. By themselves none of these are enough! They address only a part of the required transformation. To really be successful, companies and organizations need to adopt a holistic approach to create an organization that can sense, adapt, learn, and respond like a living, sentient entity.
The key to a holistic approach is creating a focus on customer purpose. All activities and organizational units must contribute to the creation of customer value and success. Without the proper orientation towards the customer each part of the organization will perform sub-optimally and could even unwittingly hurt overall efforts.
This talk will discuss how to align to our customer’s purpose (the REAL customer) and how to pull all of these related “agile ideas” into a complete, working, value creating organization.