Welcome!

@DevOpsSummit Authors: Yeshim Deniz, Elizabeth White, Liz McMillan, Zakia Bouachraoui, Pat Romanski

Related Topics: Microservices Expo, Industrial IoT, Containers Expo Blog, @CloudExpo

Microservices Expo: Blog Feed Post

Devops Is Not All About Automation

Tools are for automation, devops is for people

It’s easy to get caught up in the view that devops is all about automation. That’s because right now, most of the value of devops and repeatable processes is focused on deployment of applications within virtual or cloud computing environments and dealing with that volatility requires automation and orchestration to combat the growing dearth of human resources available to handle it. But devops isn’t about the environment, or the automation. Those are just tools, albeit important ones, to achieving devops. Devops is more about the agility and efficiency gained through streamlining processes and being able to react rapidly. You know, agile. It’s about iterating over processes and refining them to make them more efficient. You know, agile.

blue devops Devops is about continuity; about ensuring continuous delivery. More often than not this focuses on automated and integrated deployment processes enabling rapid elasticity, but that’s just the most obvious use case. Not every process can be automated, nor should they be. Agility is about being able to react; to have processes in place that can efficiently and effectively address challenges that crop up from time to time.

devopsmaturitymodel_thumb[3]The programmability of infrastructure, for example, can enable devops to put into place processes that define how IT reacts to emerging threats. This is one of the promises of SDN and OpenFlow – that the network can adapt to external pressures and events through programmatic intervention. With generally new and unknown threats, there’s no immediate remediation available and no button operations can push to deploy a preventive measure against it. Programmatic intervention is necessary. But who is responsible for intervening? That’s part of the question devops should be able to answer.

AN EXAMPLE

If we take as an example the typical response to an emerging threat, say a 0-day threat, we can see how devops applies.

Initially, organizations respond by panicking (more or less. The agitated state of a security professional upon learning about the threat appears similar to panicking in the general population). The response is unpredictable and reactive. If the threat is in the application or application server infrastructure layers, no one’s quite sure who is responsible for handling. The threat may remain real and active for hours or days before someone figures out what it is they’re going to do.

In a more mature devops stage, experience may have taught operations what to do, but response is still reactive. Operations may not always proactively monitor or scan for potential threats and thus may be caught off-guard when one suddenly appears on the threat radar. The process for handling, however, is repeatable on a per-service basis.

As organizations continue to mature, standards evolve regarding how such threats are handled. Potential threats are monitored and processes are in place to manage eventual emergence. Responsibility is well understood and shared across operations and development. Operations understands at this point how what stop-gap measures – such as network-side scripts to prevent penetration of emergent application layer threats – are likely to be needed, and development and administrators understand which of these threats must be addressed by whom, and at what point in the process they must be mitigated.

Quantifying metrics for success follows, with both development and operations using the same metrics. Time to initial redress, time to complete resolution, time at risk, etc… Finally optimization – streamlining – of processes can begin as devops fully matures. Substitution of automated scanning and virtual patching for scanning and manual mitigation occurs, speeding up the process as well as assuring a higher security profile for the entire organization.

Most of this maturation process does not involve nor require automation. Most of it requires people; people who collaborate and define processes and policies that govern the delivery of applications. Devops must first define and refine processes before they can be automated, thus automation is unlikely to occur except in the most mature of devops-enabled organizations.

In many cases, processes will still comprise manual steps. Some of those steps and tasks may be automated at a later date, but until an organization is fully invested in devops and allows the maturation process to occur organically (with guidance of course) automation may result in nothing less than what developers and architects got with SOA – lots of duplication of services that made the entire system more complex, more costly to manage, and more difficult to troubleshoot.

Devops is a verb. It’s not something you build, it’s something you do.

Read the original blog entry...

More Stories By Lori MacVittie

Lori MacVittie is responsible for education and evangelism of application services available across F5’s entire product suite. Her role includes authorship of technical materials and participation in a number of community-based forums and industry standards organizations, among other efforts. MacVittie has extensive programming experience as an application architect, as well as network and systems development and administration expertise. Prior to joining F5, MacVittie was an award-winning Senior Technology Editor at Network Computing Magazine, where she conducted product research and evaluation focused on integration with application and network architectures, and authored articles on a variety of topics aimed at IT professionals. Her most recent area of focus included SOA-related products and architectures. She holds a B.S. in Information and Computing Science from the University of Wisconsin at Green Bay, and an M.S. in Computer Science from Nova Southeastern University.

@DevOpsSummit Stories
Dynatrace is an application performance management software company with products for the information technology departments and digital business owners of medium and large businesses. Building the Future of Monitoring with Artificial Intelligence. Today we can collect lots and lots of performance data. We build beautiful dashboards and even have fancy query languages to access and transform the data. Still performance data is a secret language only a couple of people understand. The more business becomes digital the more stakeholders are interested in this data including how it relates to business. Some of these people have never used a monitoring tool before. They have a question on their mind like "How is my application doing" but no idea how to get a proper answer.
Enterprises are universally struggling to understand where the new tools and methodologies of DevOps fit into their organizations, and are universally making the same mistakes. These mistakes are not unavoidable, and in fact, avoiding them gifts an organization with sustained competitive advantage, just like it did for Japanese Manufacturing Post WWII.
DevOpsSUMMIT at CloudEXPO, to be held June 25-26, 2019 at the Santa Clara Convention Center in Santa Clara, CA – announces that its Call for Papers is open. Born out of proven success in agile development, cloud computing, and process automation, DevOps is a macro trend you cannot afford to miss. From showcase success stories from early adopters and web-scale businesses, DevOps is expanding to organizations of all sizes, including the world's largest enterprises – and delivering real results. Among the proven benefits, DevOps is correlated with 20% faster time-to-market, 22% improvement in quality, and 18% reduction in dev and ops costs, according to research firm Vanson-Bourne. It is changing the way IT works, how businesses interact with customers, and how organizations are buying, building, and delivering software.
This is going to be a live demo on a production ready CICD pipeline which automate the deployment of application onto AWS ECS and Fargate. The same pipeline will automate deployment into various environment such as Test, UAT, and Prod. The pipeline will go through various stages such as source, build, test, approval, UAT stage, Prod stage. The demo will utilize only AWS services including AWS CodeCommit, Codebuild, code pipeline, Elastic container service (ECS), ECR, and Fargate.
The current environment of Continuous Disruption requires companies to transform how they work and how they engineer their products. Transformations are notoriously hard to execute, yet many companies have succeeded. What can we learn from them? Can we produce a blueprint for a transformation? This presentation will cover several distinct approaches that companies take to achieve transformation. Each approach utilizes different levers and comes with its own advantages, tradeoffs, costs, risks, and outcomes.