Welcome!

@DevOpsSummit Authors: Yeshim Deniz, Dana Gardner, Elizabeth White, Liz McMillan, Zakia Bouachraoui

Related Topics: @DevOpsSummit, Java IoT, Microservices Expo, Linux Containers, Containers Expo Blog, @CloudExpo

@DevOpsSummit: Blog Feed Post

Habitually Successful Delivery

We usually call it "continuous" but we really want is for deployment to be habitual and, more importantly, successful

It's that time of the year, when resolutions promising grand changes in our lives are made - and more often than we'd like to admit, broken. Along with the resolutions comes advice on how to make them "stick." In other words, how to make them habitual.

Many folks still cite the old "21 days to form a habit" wisdom that has, in more recent research, been proven to be less than accurate. Turns out it takes longer than that for most people, with only a few actually able to form a habit that quickly. Unless it's something bad for us*. Then it seems to become a habit in under 2 days. Go figure.

resolutionOne of the goals of devops is really to form good habits around deployment. Advice on forming good habits is still applicable, and whether we're talking about exercise or making your bed every day or provisioning the right services for every application, part of the recipe for success is repetition.

But not just any repetition. Repeating bad or broken processes will result in "bad' habits that we'll have to resolve to remedy in, oh, about a year - right after the calendar turns again.

Forming Good Habits using Context

ovid-habitSo we need to make sure that the processes we're trying to make habitual are good ones; that they are not only repeatable, but successful. That means not only ensuring the deployment of an application, but the application services upon which that application depends to ensure its security, performance and reliability are able to meet end-user (and business) expectations. To get there, we need to apply what's called "context-dependent repetition":

"We know that habits are formed through a process called ‘context-dependent repetition’.  For example, imagine that, each time you get home each evening, you eat a snack. When you first eat the snack upon getting home, a mental link is formed between the context (getting home) and your response to that context (eating a snack). Each time you subsequently snack in response to getting home, this link strengthens, to the point that getting home comes to prompt you to eat a snack automatically, without giving it much prior thought; a habit has formed." -- Busting the 21 days habit formation myth [emphasis added]

Most advice on forming good habits is about eating or exercising or other personal things. But we can - and should - apply this concept to devops. Context-dependent repetition forces us to examine not just what we're doing, but why it was triggered. When an application is thrown over the wall, it's not enough to say "oh look, there's an application, we should deploy service X" because service X may not be appropriate, or may need a specific configuration to match it to the application's requirements and needs.

For example, if the application is mobile only, you'll want to ensure the services provisioned to support it are enhancing its performance and availability by leveraging mobile-specific optimization and acceleration services. Conversely, if the application is a machine to machine (i.e. it's an API or used to integrate partners / distributors / suppliers) then you're going to want to identify the specific security services - including identity and access control - that need to be in place to ensure the integrity of transactions conducted via that application (or API), but you probably don't need image optimization or caching because, well, machines don't care all that much about images and most M2M traffic doesn't exchange images in the first place.

This is the part of devops that's harder than just writing scripts and automating provisioning of services. It's the part that requires a more intimate relationship with not just the applications but the consumers of those applications. It's understanding the application, not the application protocol. This is where fluency is required to be successful, where context is king and enables devops to not only consistently deploy applications and their requisite services, but to successfully deploy applications that meet (or exceed) the expectations of both consumers and the business.

Remember, it's easier to form a new habit than break an old one.

So don't get into the habit of just automatically provisioning the same old set of services for every application. Make provisioning context-dependent on the application and its consumers to ensure habitually successful deployments.

*That's a personal observation, by the way.

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
Nicolas Fierro is CEO of MIMIR Blockchain Solutions. He is a programmer, technologist, and operations dev who has worked with Ethereum and blockchain since 2014. His knowledge in blockchain dates to when he performed dev ops services to the Ethereum Foundation as one the privileged few developers to work with the original core team in Switzerland.
"We do one of the best file systems in the world. We learned how to deal with Big Data many years ago and we implemented this knowledge into our software," explained Jakub Ratajczak, Business Development Manager at MooseFS, in this SYS-CON.tv interview at 20th Cloud Expo, held June 6-8, 2017, at the Javits Center in New York City, NY.
All zSystem customers have a significant new business opportunity to extend their reach to new customers and markets with new applications and services, and to improve the experience of existing customers. This can be achieved by exposing existing z assets (which have been developed over time) as APIs for accessing Systems of Record, while leveraging mobile and cloud capabilities with new Systems of Engagement applications. In this session, we will explore business drivers with new Node.js apps for delivering enhanced customer experience (with mobile and cloud adoption), how to accelerate development and management of SoE app APIs with API management.
As Cybric's Chief Technology Officer, Mike D. Kail is responsible for the strategic vision and technical direction of the platform. Prior to founding Cybric, Mike was Yahoo's CIO and SVP of Infrastructure, where he led the IT and Data Center functions for the company. He has more than 24 years of IT Operations experience with a focus on highly-scalable architectures.
Enterprises have taken advantage of IoT to achieve important revenue and cost advantages. What is less apparent is how incumbent enterprises operating at scale have, following success with IoT, built analytic, operations management and software development capabilities - ranging from autonomous vehicles to manageable robotics installations. They have embraced these capabilities as if they were Silicon Valley startups.