Welcome!

SDN Journal Authors: Liz McMillan, Yeshim Deniz, Elizabeth White, Pat Romanski, TJ Randall

Related Topics: SDN Journal, Microservices Expo, Containers Expo Blog, Agile Computing, @CloudExpo, @DXWorldExpo

SDN Journal: Blog Feed Post

Devops: Model First, Automate Later

Modeling should be the first step for devops when automating a deployment process

Modeling should be the first step for #devops when automating a deployment process

When I was a young software developer I had an interview at a large transportation company. This was when object-oriented principles were still the "thing" and Java hadn't quite yet become the language du jour - but it soon would. Sitting in a rather large conference room with a fairly nice white board I was asked to perform a fairly simple (or so it sounds) task: model a zoo.

Like the much discussed interview puzzle questions of many technology giants today, the exercise was not so much about getting it right (you really can't model an entire zoo in software during an interview) as about providing the interviewee with insight into whether or you not you understand the basic principles of modeling an environment. Are you able to identify the major "objects" and, more importantly, their relationship to other objects in the system? Are you cognizant of the minor objects that interact with the major objects, and what role they play in daily operations? Can you correctly point to not only the attributes of but the role performed by each object?

These are the kinds of questions you answer when you're actually modeling a system, and it's not unique to software development. In fact, it's probably one of the more important aspects of devops that may often be overlooked in favor of focusing on individual tasks.

I had a chance to talk with Dan Gordon at Electric Cloud about "Fail-safe Application Deployments" before the holidays and in reviewing Electric Cloud's white paper on the topic I was reminded how important modeling is - or should be - to devops.

You might recall Electric Cloud conducted a survey in June 2012 of app developers, 50% of whom said they have missed an application release date because of issues arising in the deployment process. When asked why that was, a majority (69%) pointed to the complexity of the deployment flows combined with the continued practice of manual configuration (62%) in the process as the culprit.

We know automation can help reduce deployment time and ultimately address errors by enabling more testing more often, but automating a poor or incomplete process can be as disastrous as not automating at all. It's as dangerous to automate a poor or incomplete process as it is to encrypt application data with SSL or TLS and ignore that encrypted malicious code or data is still malicious. What devops needs to do beyond adopting the agile methodologies of development to improve the deployment process is to adopt more of its principles around design and modeling.

Modeling as a Pre-Requisite

One of the five steps to fail-safe application deployments in Electric Cloud's paper on the topic is automation, of course, but its not just about automation - it's also about modeling. It suggests that the automation technology chosen to assist devops should offer a number of modeling capabilities:

It should offer extensive process modeling capabilities. There are three essential models to
consider:
• Application – the ‘what’
• Environment – the ‘where’
• Workflow execution – the ‘how’
The environment(s) should be modeled as well, with details such as:
• Server configuration
• Associated parameters
• Environment configurations

Of course Electric Cloud's solutions offer such modeling capabilities. While being able to translate a model into a concrete implementation is always a bonus, it's more important to go through the modeling exercise than anything else. Whether you're using a tool capable of modeling the model, as it were, or you're using scripts or custom developed systems is not nearly as important as actually modeling the deployment process and systems.

Being able to recognize the minutia in a deployment that can often be forgotten is the first step to eliminating missing steps in the deployment process that can cause it to fail. Applications are not islands, they rely on other applications, services, and networking to be deployed successfully, and it is often the case that configurations rely upon IP addresses or other configuration options that must be addressed late in the process - well after the actual application is "deployed" on its platform. Modeling the "objects" in a deployment - as well as their relationships - will help ensure that as the process is automated those relationships and dependent tasks are not overlooked.

Modeling doesn't have to be a formal exercise. Though many developers use UML tools or other formalized processes to conduct modeling exercises, devops should feel free to discover tools or processes for modeling that best fit their needs.

A rather large conference room and a whiteboard can be a revealing tool, after all.

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.

CloudEXPO Stories
When building large, cloud-based applications that operate at a high scale, it's important to maintain a high availability and resilience to failures. In order to do that, you must be tolerant of failures, even in light of failures in other areas of your application. "Fly two mistakes high" is an old adage in the radio control airplane hobby. It means, fly high enough so that if you make a mistake, you can continue flying with room to still make mistakes. In his session at 18th Cloud Expo, Lee Atchison, Principal Cloud Architect and Advocate at New Relic, discussed how this same philosophy can be applied to highly scaled applications, and can dramatically increase your resilience to failure.
DevOpsSummit New York 2018, colocated with CloudEXPO | DXWorldEXPO New York 2018 will be held November 11-13, 2018, in New York City. Digital Transformation (DX) is a major focus with the introduction of DXWorldEXPO within the program. Successful transformation requires a laser focus on being data-driven and on using all the tools available that enable transformation if they plan to survive over the long term.
With more than 30 Kubernetes solutions in the marketplace, it's tempting to think Kubernetes and the vendor ecosystem has solved the problem of operationalizing containers at scale or of automatically managing the elasticity of the underlying infrastructure that these solutions need to be truly scalable. Far from it. There are at least six major pain points that companies experience when they try to deploy and run Kubernetes in their complex environments. In this presentation, the speaker will detail these pain points and explain how cloud can address them.
Machine learning provides predictive models which a business can apply in countless ways to better understand its customers and operations. Since machine learning was first developed with flat, tabular data in mind, it is still not widely understood: when does it make sense to use graph databases and machine learning in combination? This talk tackles the question from two ends: classifying predictive analytics methods and assessing graph database attributes. It also examines the ongoing lifecycle for machine learning in production. From this analysis it builds a framework for seeing where machine learning on a graph can be advantageous.'
Daniel Jones is CTO of EngineerBetter, helping enterprises deliver value faster. Previously he was an IT consultant, indie video games developer, head of web development in the finance sector, and an award-winning martial artist. Continuous Delivery makes it possible to exploit findings of cognitive psychology and neuroscience to increase the productivity and happiness of our teams.