devopsy.kinsta.cloud

Tag: enterprise devops

  • Keep Applications Running by Testing Early, Continuously

    Keep Applications Running by Testing Early, Continuously

    Almost every product we buy or use today goes through some form of extensive testing before it’s released on the market; typically, these tests are designed to replicate the worst-case scenarios that a product may encounter under real-world conditions.

    Automobiles, for example, go through extensive hot and cold weather testing in remote locations, and are driven over obstacle-laden tracks designed to push the limits of their durability. Even seemingly mundane objects such as children’s toys are exposed to abusive simulations to ensure that they don’t harbor any potentially hidden and harmful effects.

    On the current landscape, applications are the face of your business, often serving as the battleground where consumer loyalty is won or lost. Given this reality, it seems crazy to think that any applications are released having only been exposed to a minimum of tests. Yet, in the name of getting to market quickly, that’s far too often the case.

    As disciplines including agile and continuous delivery continue to increase the speed at which development teams can release software, it’s easy to put the crunch on testing in the rush to get an update released. But that’s a costly mistake in the long run, as research has shown that it is 50 percent less expensive to find an error in testing than to address the same error once it has reached production, and more than 90 percent cheaper  when addressed in the development/coding phase.

    Given the dramatic cost savings of addressing errors in development, clearly the goal of any organization focused on continuous delivery should be to shift testing left so a greater number of defects are found early in the development process. This is what we refer to as continuous testing, and it’s a huge part of the reason why I am so excited about CA’s acquisition of BlazeMeter.

    Performance load testing should be a core element of any continuous testing strategy because it is a critical factor in determining system reliability. Similar to the worst-case scenario testing that consumer products undergo, performance testing can quickly uncover applications defects that might otherwise go unnoticed. After all, the manner in which a system operates with a few hundred concurrent users may be very different than how it runs with thousands of users.

    BlazeMeter enables today’s development, operations and DevOps teams to conduct this critical performance testing earlier in the development process, saving countless hours and resources. The company is also competing—and winning—in a highly competitive marketplace where it has been pitted against much larger, more entrenched competitors.

    Part of the reason BlazeMeter is winning is its focus on offering a SaaS-based solution that is highly cost-effective and easy to engage. Using this model, customers can try  out the testing software with a few clicks, and then quickly move forward to broadly adopt the system. Another catalyst to its success: BlazeMeter was built using open source tools, such as Apache JMeter, used widely in the development community for performance and load testing. As a result, BlazeMeter can easily run and analyze JMeter and other open source-based load tests—such as Selenium, Gatling and Locust—within a commercial-grade performance testing system.

    This combination of a SaaS delivery model and incorporation of open-source tools, augmenting strong performance testing functionality, make BlazeMeter very complementary to CA’s existing continuous delivery solutions, including its CA Service Virtualization, CA Test Data Manager, CA Agile Requirements Designer and CA Release Automation products.

    At CA, we’re committed to providing the most comprehensive, integrated and open continuous delivery ecosystem, allowing our customers to release swiftly, test agilely and constantly increase reliably. The addition of BlazeMeter will further enable customers test continuously, thereby increasing agility and the overall quality of their software, to ensure that applications don’t break down on the side of the virtual road.

    — Aruna Ravichandran

  • DevOps and the Identity Conundrum

    DevOps and the Identity Conundrum

    “Who am I?” It is perhaps the most basic question of consciousness. The answer could be subdivided by aspects of my life story … my career, my family, my beliefs, my education … the list could continue. But since I am unique, the challenge in this digital age is for me to somehow remain unique, and whatever descriptions are used to catalog who I am, I must remain at the center of them all. If my identity is stolen, how does anyone know, that I am who I say I am?

    This question is fundamental to every interaction I have with the digital world. And unfortunately, every system I interact with looks for me to redefine who I am, over and over again for each of them. I create a Facebook profile, a Twitter profile, a LinkedIn profile … and the list goes on again. But yet another weakness of our digital age is that there is no cross-reference between these systems to ensure I am who I say I am. This phenomenon remains true within DevOps tooling as well.

    The Career Identity Conundrum

    Let’s focus on only one aspect of who I am, my career. Who my current employer is dictates what electronic business systems and networks I should have access to. Switching jobs to another employer changes—or should change—the access I have. But getting more specific, what my role is at my current employer should also have an impact on what tools I have access to, and what I can do within them. And as my role changes, my abilities within a tool should change, as well. If I move from practitioner, to manager, to director, my abilities within a given tool should probably diminish, holding practitioners accountable for actions rather than superseding their responsibility by doing things myself.

    Then there is the area of focus I work on. Business segmentation differentiates my work from product or service “A” in contrast with product or service “B.” My role might be an application programmer, or database administrator, but then “who” I focus on within a company is yet another level of differentiation. The business may prefer that teams of people focused on product “A” are restricted from making substantive changes on product “B.” So two different database administrators need two different levels of access within the same tooling, segregated by line of business or product line to accomplish it.

    The Career Consistency Conundrum

    The problem with my corporate identity in the digital age is that it is fluid, like life. In the course of my career I will change employers at one time or another. But beyond this, I will change roles, and/or areas of focus within the same employer over time. I may be assigned to work a “special project” in addition to my normal duties during my time at a given employer. And where DevOps relies upon several types of tooling to facilitate the continuum, this fluidity in my career makes it difficult to keep up with, and can drive administrative costs quite high.

    For example, if I am an application programmer (normally), I will then have certain abilities within the build, deploy and release tools—likely high ability in build, moderate in deploy and low in release. If I am temporarily assigned as a release manager for a different product/service (in addition to my normal duties), it should radically alter my abilities within the DevOps tools, at least for a short time. But when I return to normal duties, the only mechanism that gets my abilities reset to what they should be is a strong process control system. The tools do nothing to facilitate this (no reminders, no examination of HR systems for roles, no look at each other to see what I am supposed to be).

    An Identity Architecture

    It occurs to me that the constants in resolving these kinds of problems are time and who I am. If I could hold an identification construct that identifies myself in career terms—which employer, which role, etc. and for how long—that identity construct could be employed into every system that accepted it. In effect, it would be the ultimate abstraction of user management, transferring the burden from companies and HR departments to the individuals who know, and need to know, the end user.  While companies would still need to interact with my personal identity construct for verification, assent and record keeping, having all electronic systems accept my ID construct takes all of the work out of programming those interfaces, makes permissions and roles common, and keeps up with life’s fluidity.

    In addition, who I am becomes the same in every system that accepts this construct. I cannot define myself as a release manager in one tool and a test manager in another and an application programmer in yet another to give myself god-like abilities in the DevOps tooling at my company. Each tool would examine the same identity construct I hold and receive from it, my normal duties, roles, permissions, etc. I would have a consistent profile across corporate tooling that would reflect my latest roles and use dates (beginning and end) to validate me against their own records.

    An Identity Lockbox

    The trick is, how do I keep this identity construct from being stolen? I believe this is where biometrics begins to play a key role.  Fingerprint technology is commonplace now, even in cell phones, which are usually chained to us like an additional finger or toe. We rarely go anywhere without them. And when carrying them, we use features such as Touch ID to replace the manual keying-in of passwords. If my identity construct was paired between information likely I alone would have and biometrics tuned only to me (retinal scans, fingerprints, etc.), the pairing could unlock the construct for either use or revision.

    Stealing the construct does little good, as without the pairing biometrics, it could not be used or revised. The applications for an identity construct like this are limitless—everything from securing the right to vote, work and collect social security to validating credit card purchases and opening up new social media accounts.  If Facebook employed (or accepted) this kind of construct, it would be more difficult to create spoof accounts of me, as the unbeatable pairing could decipher who really owns a photo, or document, etc. And looking forward, a standardized identity construct such as this could interact with the emerging world of IoT (internet of Things), where devices could know a lot about me, and know it was truly me.

    Impacts to the Bottom Line

    I am not suggesting some wild end-of-the-world scenario where computers control our every move. We already have that in some form or another (see banks – ha ha).  But I am suggesting that in the interest of reclaiming digital privacy we should be moving the ownership of identity constructs back to the people who own them: us. We should each own our own singular construct, keep it up to date and as filled out or complete as we want to, sharing only what we want to. The chief benefit of this would be an increased difficulty in stealing them from us. We can all skip the 666 tattoos, and instead try to reclaim a moniker of privacy by holding our own digital identities ourselves. Using them like a master key that will open systems we “should” have access to and abilities we “need” to have to perform the work assigned to us.

    The upside to corporations is increased security that requires less on their part to maintain. A single set of records with start and end dates validates IDs used or attempting access. The upside to the software industry as a whole is a common interface for logging into an application with discreet identification. It removes the doubt about “borrowing” an ID if unlocking access requires a biometric pair as well. It would allow every application to abstract user management and make it common. Roles would be abstracted. Permissions could remain unique to each application based on their interpretation of the role.

    Moving to a self-maintained identity construct could be taken further for benefits in other areas of our lives. While we have discussed some of how the career portions of our identity might be subdivided and cataloged, imagine for a moment the benefits of having our heath characteristics attached to the same kind of identity construct. Family records, memberships and associations … pick your classification of how a person is described for who they are. Having a way to retain ownership of those things in the digital age is key to keeping our unique position in the world unique. Losing control of those things becomes catastrophic. Where DevOps benefits from a construct such as this is but the tip of an iceberg compared to the benefits society reaps—or at least, our digital society could reap if we pursued it.

    To continue the conversation, feel free to contact me.

     

    — Kristian Nelson

  • Introducing DevOps Express!

    Introducing DevOps Express!

    The DevOps Institute (DOI) is proud to join industry leaders as a founding member of the DevOps Express. The DevOps Express is a bold initiative between tool providers and others to create a solutions-oriented approach that will make enterprise DevOps adoption easier using popular technologies spanning multiple solution components. Working together, DevOps Express members have committed to improving interoperability within the DevOps stack, and creating a framework for industry partners to develop reference architectures that will be better integrated with better support.

    The 14 founding members of DevOps Express include vendors spanning multiple solution categories in the software delivery process, as well as service organizations providing consulting, training and professional services:

    • CloudBees
    • Sonatype
    • Atlassian
    • BlazeMeter
    • CA Technologies
    • Chef
    • DevOps Institute (DOI)
    • GitHub
    • Infostretch
    • JFrog
    • Puppet
    • Sauce Labs
    • SOASTA
    • SonarSource

    DOI is honored to be a part of this important and innovative program. We believe this initiative represents the industry’s commitment to “walking the DevOps walk” by agreeing to collaborate, align and integrate for the betterment of the market. We are excited that major industry partners are unifying to give enterprises potential starting points for creating a DevOps stack, while also increasing quality and lowering risk. As knowledge, best practices, architectures and models emerge from the work of DevOps Express, DOI will ensure that these are available to the DevOps learning community and embedded into DOI courses, articles and future member benefits.

    The DevOps Express is leaving the station, and DOI is on board! Read the press release for more information about this historic initiative.

  • DevOps and Automation Abstraction?

    DevOps and Automation Abstraction?

    Similarity breeds consistency, giving way to predictability and, thereby, dropping costs of operations and quality from a lower number of incidents and a shorter duration to resolve them. But at the heart of this chain of events is the recognition that we tend to do certain tasks the same way, over and over again, for a given type of technology. Variability then becomes our enemy.  Consistency becomes our ally.  So the question: How do we as DevOps service providers instill a level of consistency in what we do that is not engineer-specific (i.e. only one guy knows how it is supposed to work) and will still scale at the enterprise level?

    From a people perspective, we use teams, whether co-located in person or virtually using the same backbone of tooling over wide geographical separation. From a process perspective, we use governance and education to ensure the same processes and approaches are taken at a fundamental level across different types of technologies. And finally, from a tooling perspective, we use templates or frameworks (or pick your synonym) that allows us to construct a shell that guides the automation construction to be consistent from parent to child. The combination of these three fundamental elements leads to consistency that scales. But is that all?

    What Are We Missing?

    Could there be another fundamental element we have overlooked—namely, abstraction? Case in point: Consider the effect of a drag-and-drop interface versus a typed one to accomplish a given task. Both look to accomplish the same outcome. One could argue the typed text approach offers more flexibility and customization to get the task done. But the drag-and-drop method offers a consistent, simplistic way of doing a similar task, the same way, over and over again. Examining both methods objectively, the drag-and-drop method offers a level of consistency the typed method never could. For the typed one, you would always have to check to ensure punctuation and lack of changes (additions or deletions) to “know” it was the same script as last time. The drag-and-drop method on the other hand, is “canned” or largely unalterable; it may limit customization (by design), but it excels at consistency.

    The drag-and-drop method achieves this consistency by effectively abstracting the typed or scripted code within it from the user who employs it. The user only makes the choice to use it, when desired (or needed); the rest of the mechanics are abstracted from the user. The reason drag-and-drop methods exist is beyond just consistency, however; it is for simplicity. Apple computers would appear to be founded on this idea. For those of you old enough to remember DOS on PC computers, the parallel here immediately becomes clear. DOS was a typed-based command-line operating system (OS) fully capable of operating a PC many years ago. But Apple’s graphical interface made the same functions “intuitive” and forced the PC industry into Windows to stay competitive. Nobody chooses a command line OS like DOS when something as elegant as iOS exists, or Windows (or pick your graphical poison here).

    A graphical OS abstracts core functions from the user, and makes every attempt to make an elegant intuitive packaging of the same functions. Users “get” an iPhone, which accounts for its sales. You don’t need formal education classes or an eidetic memory to use an iPhone. Users effectively have been abstracted from all the typed code it takes to create an OS like this, millions of lines of such code packaged up into swipes, beeps and elegant graphical displays. Keep in mind, at its core this OS abstracts users from variability that might exist if hundreds of companies created their own versions of iOS. The simplicity is paired with consistency, and the quality of Apple is a result (for better or worse). But whatever the quality of Apple is, it is far better than if a wide degree of variability were permitted in the vendors of iOS or the construction of it.

    Extending Abstraction in DevOps

    Now enter DevOps. Containers are a level of abstraction widely popular in our discipline for keeping hardware particulars away from what are typically software engineers. The value of this abstraction is well-understood. My challenge is simply to extend this thinking into the next tier of DevOps tooling. What if the ability to include database DevOps automation was simply a product of drag-and-drop methods that every build tool understood perfectly? Granted, you may have to limit the expression of this idea to say Oracle or SQL Server at first to capture the nuances and particular capabilities of products and technologies in this space. But if someone built a “container” for Oracle, I would wager the choice to use Oracle would rise substantially over its competitors, at least until those containers or abstraction layers were just as effective with other database products.

    The abstraction phenomenon need not be limited to hardware, or as I have proposed to database platforms. It also could apply to .NET or Java development efforts at the top of the stack. The steps needed to take an idea, code it and put it through the build process are going to be largely similar when working in a .NET shop or a java shop (or pick your particular development tool of choice here). Even the top of the stack—that is to say, the development of applications itself—could be a viable candidate for abstraction from the mundane details as it relates to a build construction or a deployment to a given class of environment.

    Creating effective containers for the application layer in effect limits variability, and increases predictability. I realize it has to be technology-type sensitive. The .NET shops have their own container. The java shops have theirs, and so on. The only question is whether we are able to include enough of the common core steps we take to produce a build with a given technology type to form an abstraction construct of value. Over time, this would include every type of technology widely in use today.

    The effort to simplify through abstractions ultimately would result in our ability to include technologies such as WebSphere at our pleasure. It would also allow us to switch out WebSphere for a new competitor using the same abstraction constructs, universally, just by rebuilding all our apps one time. This kind of power is alluring to development teams. It drives application developers and operations engineers to begin to work together to look for the most cost effective technology that can perform a given spec. Being the best at something is no longer a cage from which there is no escape later.

    Technology components would be selected based on performance and cost of ownership (i.e. operations) later. Switching is ultrasimplistic if all we ever used to include it in our build routine was a drag-and-drop style method with universal, well-defined parameters. A customer’s ability to switch products to the best of breed through easy or simplistic means keeps pressure on vendors to actually be the best of breed. If the performance suffers or a new release is full of bugs, developers just switch it out through abstraction (not long, complicated scripts where everything has to go right, including a full moon on the third Tuesday of the month with a Gregorian chant in the background).

    Impacts to the Bottom Line

    The selection of DevOps tooling often is a cantankerous one in large organizations. Debates ensue about flexibility, extensibility and whether a given tool can be customized to accommodate the unique little snowflake of my development teams. Perhaps these debates are headed in the wrong direction. Perhaps instead of prizing and valuing the extensibility or customization a given tool affords, we should be looking closer at how that extensibility is achieved.

    For an enterprise to make an unwitting choice to get into the script business, is effectively stating: “I will be maintaining the scripts I use to construct a build with as much rigor as I maintain the code these scripts are designed to create builds out of.” So, we just doubled our programming staff without realizing it—one half working on the application code and the other half working on the scripting code that “automates” the delivery of a build during construction. While overall speed may be increased, it comes at the cost of doubling already expensive headcount.

    As an alternative, what if enterprise customers were asking tooling vendors how simplistic their tools are to use, and how standardized are their approaches. While we may not enjoy losing a degree of flexibility as we may be unable to customize a drag-and-drop method construct, the payoffs to the business are simplicity of use and scale at an enterprise level. Not only do I refrain from doubling headcount, I can actually free resources to focus on the disciplines and areas they enjoy most instead of performing script maintenance. Abstraction as a construct: From the hardware layer up through the application layer, it may be a driving fundamental that keeps DevOps scaling and lowering the cost of innovation for many years to come—but only if you begin to ask for it.

    To continue the conversation, feel free to contact me.

  • Putting Ops Back in DevOps

    Putting Ops Back in DevOps

    What Agile means to your typical operations staff member is, “More junk coming faster that I will get blamed for when it breaks.” There always is tension between development and operations when something goes south. Developers are sure the code worked on their machine; therefore, if it does not work in some other environment, operations must have changed something that made it break. Operations sees the same code perform differently on the same machine with the same config, which means if something broke, the most recent change must have caused it … i.e. the code did it. The finger-pointing squabbles are epic (no pun intended). So how do we get Ops folks interested in DevOps without promising them only a quantum order of magnitude more problems—and delivered faster?

    The problem is exacerbated when the topic of DevOps comes up, as it is most often a developer doing the talking. And the topics under conversation are things every developer would have substantial interest in and pretty much nothing that would interest the operations part of the equation. Many Ops folks feel as though they have been dragged into this DevOps phenomenon by osmosis, without their consent, and now they are supposed to be reaping huge benefits from it (by magic, as near as anyone can tell). Developers working faster is traditionally not something Ops folks look forward to; rather, it may be their worst nightmare. So, if the advocates of DevOps all tend to be developers, how do we get operations folks to become our evangelists as well?

    QA Impacts on Evangelism

    It begins with quality—not the ethereal concept of quality, but rather the specific responsibility for who owns it. Finger-pointing be gone; developers now own QA. If the software development lifecycle (SDLC) environment is broken, developers own it. Ops can sit back, toast marshmallows and enjoy the show. Developers should be including whatever configuration file changes their application needs as part of the deployable package. So nothing is done manually anymore. This means no one could forget something, as machines do not forget; they do what we tell them. If by chance, some random operations staffer decides to doink with a config variable, the deployment software should simply overwrite the manual change with what is in the deployable package created by the developer. Even malicious changes can be overwritten, so now, all change is included in the development class environment in the one and only deployable package. That is the only package that moves forward.

    If developers own the QA, there is now a shift in the force: The operations team has a new role, one of coach and adviser, instead of doer. The software now is the doer, the developers are the packager and the operations staff are the witnesses of how it works. If it breaks, we all know who must fix it (and who is to blame). But once blame has been permanently affixed, something else changes, namely the culture. Now that the operations team does not take the blame, it remains interested in seeing its operations run without error. This allows operations to take an active “helping” interest in getting things fixed faster. It does not really matter who is to blame, once that argument has been settled; now it only matters if they can make something work. Harmony between factions begins to emerge.

    Scalability Impacts on Evangelism

    It continues with scale. Self-service is the nirvana of your average operations staffer. If the responsibility for provisioning can be moved into a push-button self-serve automation, nirvana will have been achieved. Imagine the offload of repetitious work tasks that consume the life of your average operations staffer. Instead of setting up (and taking down) environment after environment of one class or another for one application or another, requesters can all do it themselves with the push of a button. Even the accounting or financial impact is something the accounting team can guide the user on; operations does not have to worry about the cost of its operations anymore (or, at least, worry less). If too many environments are being provisioned, the accounting team has the power to change the rules and keep it from happening automatically without operations having to be the bad guy.

    At this point, Ops can resume a focus on something it tends to enjoy more: monitoring. Ops staffers enjoy being able to provide real-time reporting on where things stand at any point in time. It is even more rewarding to provide more meaningful information such as who is using this application, what users are doing with it and when are they performing that activity. To monitor that kind of information, operations must partner with developers at the outset of a project to determine what kind of application logs are needed later for monitoring. Without the daily barrage of mundane provisioning tasks, an operations engineer is free to focus on more rewarding (translate: higher skill-level) tasks. The days of changing tapes for the backup may have reached their end (or pick your similar set of mundane tasks which DevOps automation can fully eliminate).

    And Speaking of Monitoring

    It merges into the future. How do you create an operations staffer as a DevOps evangelist? Start by exploring potential that only DevOps can enable. All those nagging alerts that are created when an environment goes down while a deployment is made … all of that could be turned off by the DevOps automation, then turned back on when the deployment is completed. Again, it all would be machine-driven, with no human mistakes anymore, ever. This will begin to cut down “noise” in monitoring/alerting systems into only useful information. However, integrating monitoring systems into the normal DevOps continuum extends beyond just an on- and off-switch.

    Forward-thinking organizations begin to consider testing and monitoring as two parts of the same evaluation discipline. When a test is needed and when a monitoring characteristic is needed now can be determined in total rather than just in a development capacity or operations capacity. A holistic view of what can and what should be evaluated about an application, and how that will be achieved, brings the operations team to the table with the development and testing teams to plot holistic solutions that will live on beyond the development project timelines. Examining monitoring relative to version-controlled artifacts allows for organizational constructs within the monitoring discipline that never were possible before DevOps enabled them.

    The Masters of Hardware Abstraction

    Containers, or similar types of technologies, abstract an application from the hardware details it runs on top of. Technology such as this is a trend in DevOps that greatly simplifies the world of hardware from your average application developer. So who will retain the knowledge about the jungle that lives and breathes underneath? Ops has an extended role in understanding what lives underneath the abstraction layer that lives on top. Over time, only Ops will understand these particulars. They will become the only in-house experts about which cloud provider to use, which sets of physical hardware performs best and under what conditions.

    It is this kind on unique expertise that makes an operations engineer extremely valuable (translate: pricey). It is the kind of knowledge careers are made upon. It is ageism-neutral. Older employees do this today, and they will continue doing this in the future; the only difference will be fewer and fewer people will know how it is done. If the domain of application development is the province of our youth, then the domain of hardware abstraction is easily the province of our more experienced employees. These realities create personal value for our operations teams, and they are only possible in a post-DevOps embrace.

    Impacts to the Bottom Line

    The adoption of DevOps by the Ops portion of the equation is critical to overall success. Passive-aggressive resistance by operations staffers can delay or destroy altogether the value of DevOps. Overcoming this is a first step. But creating operations evangelists goes an order of magnitude further: With active operations staffers becoming internal DevOps evangelists, the entire operations team can begin to look forward at what DevOps will ultimately enable for them. The value they will carry back into development efforts becomes substantial and the entire company benefits. Careers can emerge that were not possible before it—and, just as importantly, so can profits.

    To continue the conversation, feel free to contact me.

  • REP SPOTLIGHT: Daysha DevOps Solutions

    REP SPOTLIGHT: Daysha DevOps Solutions

    DevOps Institute: Tell us a little about your organization.

    Daysha DevOps Solutions: Daysha DevOps Solutions is a leading IT services and solutions company focused on helping companies to deliver their IT projects, transform their capabilities and ultimately to provide value to their customers and stakeholders. Our goal is to help organizations benefit from disruptive technologies, such as cloud computing, Lean/Agile software development and DevOps. We work across a range of industries including financial services, government, aerospace and high-tech.

    Daysha DevOps Solutions has partnered with the best-in-class product vendors to help organizations improve their ability to deliver software quicker, more frequently, with higher quality and less risk. Our DevOps solutions address all stages from project planning right through to deployment.

    DOI: What other topics do you teach or consult on?

    Daysha DevOps Solutions: Daysha bring proven expertise and consults across the wide domain of DevOps. Partnering with vendors such as Atlassian, App Dynamics, Chef and Zephyr, we offer expertise, training and tooling to support all aspects of the DevOps journey.

    Our IT Project Services team consists of experienced IT consultants including project managers, technical experts and business analysts. These can be deployed to help augment your existing IT teams or to provide specific project help, such as requirements gathering, gap analysis and process improvement.

    DOI: What type of interest in DevOps are you seeing in your region?

    Daysha DevOps Solutions: The interest in DevOps is growing, though to be honest, a lot of organizations are wary of it. That said, the same organizations are heavily rooted in traditional waterfall environments. There is a recognition that DevOps is the way forward but also a realization that cultures need to change first.

    DOI: How do you think that DevOps contributes to the business’ value stream?

    Daysha DevOps Solutions: Primarily by delivering value earlier and increasing the visibility of the IT contribution to the business stream.

    DOI: What topic area in DevOps excites you the most?

    Daysha DevOps Solutions: How business can get more value from IT. In other words, turning an IT department into a revenue-generating tool rather than a cost.

    DOI: Why should enterprises and individuals consider formal DevOps Training?

    Daysha DevOps Solutions: It is the first step, and a certified first step, on the road to improving the value of IT functionality.

  • DevOps: The Glue of Workflow

    DevOps: The Glue of Workflow

    The best tool in the DevOps continuum is the sticky wrapper that holds it all together. It is the workflow that binds it and makes sense out of the term “continuous.”  CIOs often are enamored with a build or deploy tool, but it is the workflow tool in every DevOps strategy encapsulating more than one function that is the real hero. Imagine having the perfect test automation scripts but no way to execute them outside of constructing a new build. Or imagine having the perfect CMDB integration scripts but no way to call them outside of the build process. Or even worse, imagine having the need for human approval before a deployment takes place (or is promoted), and no way to integrate it outside of a custom deployment process.

    Lean DevOps Construction

    Attempting to make very few tools perform these functions without a workflow engine ultimately forces automation engineers to create functionality within a tool it was never designed to perform. Conversely, when a workflow wrapper is available, build and deployment processes can remain small, elegant and consistent, allowing the workflow engine to integrate extended functionality into the continuous delivery cycle.  Size of the automation constructs you create does matter: the smaller the better.

    Using Lean methodologies in your DevOps services, it is better to break down automation constructs into the logical functions they are intended to provide. Build automation, for example, should not have to include extensions to turn monitoring functions on or off. Build automation also should not have to worry about the deployment process; its primary singular purpose is to construct a new build. Where that new build is then deployed becomes the single purpose of the deployment process.  Attempting to automate the entire cycle of an application into one automation construct from end to end (instead of smaller blocks that work together) increases both size and risk (as well as length of time to execute) of that one event.

    Dealing with Humans in the Automation

    Human integration is the bane of DevOps processes. Every time you have to pause automation to obtain a human approval, you introduce time delays that cannot be predicted or occur with consistency. Imagine a deployment process that requires a human to press “yes” before continuing. The introduction of a human approval can sit idle on a tooling screen for hours during lunch, or unexpected days off, or vacations (when others are afraid to take responsibility for passing a substandard build, even for further testing). Deployment tools can integrate human responses, but this is not their forte. They are generally ill-equipped to use multiple contact methods, go up the management chain when needed or ping a mobile device when preferred by the user listed as responsible. Workflow tools are ideal for all of these human-contact logistics.

    The challenge during DevOps service construction in utilizing a workflow wrapper is keeping human interaction to the absolute minimum required by outside regulating agencies and still achieve compliance. The alternative is to automate processes with such quality and consistency so that human interaction would merely become redundant and unnecessary. The workflow wrapper is not an excuse to simply automate what human interaction you have today. Instead, it is a highly functioning tool to allow you to redesign more-effective automation processes, limiting human interaction where possible. The goal is to build small, independent automation constructs that work together in a highly efficient manner.

    Hold the Presses

    Communication or notifications also can be handled in a workflow wrapper much better than in individual DevOps toolings. Imagine for a moment that I am a release manager, wanting to know the progress (or rather obstructions to progress) for my new application. To accomplish this notification process, it would have to be embedded within my build process (to know if it passed or failed). The alternative is that my workflow wrapper checks the build logs and can send me notification in the method I prefer (email, text message, an Instagram pic of Thelma and Louise over the cliff, etc.) In addition, I may not actually want to check the status of every build submitted, as that becomes noise after a while. I may want to know only when a build candidate has passed and is ready for promotion to a further testing environment. Since my workflow wrapper would be aware of this, it could automate the notification to me quite easily.

    Now add the consideration of management chain to this notification process. If I am out on vacation (which I expect to be able to do, since DevOps enables my personal life), my manager or my sponsoring executive may want to be notified if my application is not going to production for some reason during my absence. This is a level of automation that most build or deploy tools are simply not designed for. They have no idea who I report to and who that person reports to. But that departmental notification escalation chains can be incorporated easily into a workflow wrapper, and execute as expected while I am away (including pinging my cell phone just in case I need to jump in and fix something).

    Release Management Solutions

    Most release management (RM) or release orchestration (RO) tools have at least minimal workflow capabilities built into their offerings. Whether this capability is enough for your organization or whether you need a more capable workflow engine to wrap around it is a decision only you can make. Most release management tooling is designed to put an elegant wrapper around build automation and deployment automation. It usually contains the ability to segment by line of business or product, as well as role-based access controls (RBAC) for permissions and auditory compliance. And it usually contains at least elementary notification capabilities. What RM excels at are human interaction and tracking progress, and so it does meet the needs of many companies.

    When RM is not enough is usually when the DevOps services you provide begins to extend into ancillary services and secondary automation integration capabilities. Examples include monitoring systems integration, multiple testing tooling integration/evaluation, configuration management database (CMDB) integration and capacity-on-demand environment provisioning.  Highly evolved notification systems tend to require an external workflow wrapper beyond the normal capabilities an RM tool offers. A solid workflow wrapper acts as the glue that can hold disparate DevOps tooling (either from different vendors or performing different functions) together with further super-automation processes above them like an overarching umbrella.

    Impacts to the Bottom Line

    Choosing to offer DevOps services without any form of a workflow wrapper is like going hunting with an excellent rifle and no bullets: a lot of capability that can never reach the potential it was intended for. On the other hand, obsessing about replicating current processes within a workflow tool is like hunting a bunny rabbit with a bazooka: way too much damage caused when trying to keep things small and elegant. The key is to balance the use of a powerful tool (workflow), with Lean thinking in automation processes and constructs. Keep the building blocks small and functionally oriented; limit human interaction; and use workflow for the functions it is best-suited for—connection and communication.

    The technical capabilities a workflow wrapper will add to your DevOps solutions are substantial. Your services will be far more efficient and far more powerful. However, to truly assess the financial impact of a highly functioning workflow system, one must determine the value of time and decision-making. An elegant notification system can keep you informed without sending you countless emails you learn to ignore or flooding your text inbox with data that exceeds your cellular plan. In this way, notifications are meaningful, and you can begin to make meaningful business decisions based on the information you receive, only at the times you need to see it. What is that worth to you and your organization? Only you could really assess that.

    To continue the conversation, feel free to contact me.

     

  • What DevOps Skills are Organizations Looking for?

    What DevOps Skills are Organizations Looking for?

    DevOps is a cultural, philosophical and organic approach toward automating workflow and getting products to market more efficiently and effectively.

    DevOps engineers are in top demand right now. According to studies by Gartner, 25 percent of top global 2000 organizations will have adopted DevOps as a mainstream strategy by the end of 2016.

    DevOps is both a cultural movement and a philosophy … which can make it difficult to define the specific skill set you need a DevOps team to possess in order to function successfully.

    Of course, an excellent way to show fluency in DevOps is by earning a DevOps Institute certificate—for example, DevOps Foundation®.

    That being said, there are some “mission-critical” DevOps skills that organizations are searching for pretty universally right now.

    1. Experience with infrastructure automation tools and fluency in web languages

    Experience with tools such as Ansible, SaltStack, Puppet, Docker, Chef and Windows PowerShell DSC as well as fluency in languages including Ruby, Python, Java and PHP are must-have skills for DevOps pros.

    Organizations are searching for DevOps candidates who are highly proficient in many of these tools and languages and open to increasing their competencies further when given the opportunity to do so.

    2. Expertise in “soft skills”

    DevOps evolved as a way to enhance collaboration across project life cycles and connect front-end and back-end professionals on either side of the software development and operations spectrum.

    When software developers and operations staff (system engineers, systems admins, DBAs, etc.) collaborate effectively, communicate honestly and work as a cohesive team, the software development life cycle (SDLC) is streamlined, risk factors are mitigated, and projects are completed and deployed with a minimum of bugs, quality defects and glitches.

    In addition, it can be useful for organizations to have DevOps specialists on their team who are comfortable in the role of client consultant, able to interact effectively and build positive business relationships with customers while addressing their needs and wants.

    Organizations look for DevOps candidates who are skilled in interpersonal communication, with an arsenal of listening, negotiation, problem-solving and team-building skills at the ready.

    3. Familiarity with CI (continuous integration) tools

    Continuous integration is a DevOps methodology that continually merges source code updates from all developers on a specific software build, notifying the team of any failures in the process.

    This offers a real-time window into the developing software system, allowing immediate and constant engagement of all team members throughout the project lifecycle.

    CI tools DevOps candidates should be familiar with include CruiseControl, CruiseControl.NET, Jenkins, Bamboo, Hudson, ThoughtWorks’ Go, Urbancode’s Anthill Pro, Microsoft’s Team Foundation Server and Jetbrains’ Team City.

    4. Bonus Skills

    Other skills hiring managers are on the lookout for in the DevOps space include:

    • Extensive knowledge of software build cycles
    • Experience deploying code
    • Experience in software architecture
    • Familiarity with application programming
    • Database management
    • System design

    Useful experience and certifications include:

    • Project Management
    • Risk Management
    • Scrum Master

    The good news is that the industry’s need for DevOps team members with diverse and evolving skill sets is in sync with what DevOps candidates want from their workplace. According to the 2014 State of DevOps Report from Puppet Labs, an atmosphere conducive to learning is a primary component of job satisfaction among DevOps engineers.

    About the Author / Robin Borough

    Robin BoroughRobin Borough is President of Omnikron Systems, Inc., which offers IT and management training and IT staffing services. As an advisor to technology professionals and executives for over 25 years, Robin has built a world-class reputation as a “go to” career strategist in the IT industry, one who’s capable of successfully guiding executives and specialists, at any level, through transition. 

  • REP SPOTLIGHT: Glenfis AG

    REP SPOTLIGHT: Glenfis AG

    1. Tell us a little about your organization: Based in Zurich, we offer consulting and training services since almost 20 years. We see ourselves as an independent enabler for the digital transformation, helping our customers getting fit for the digital age. To this end, we use the ‘Glenfis Principle’ – a holistic approach that, alongside theoretical knowledge, attaches particular importance to the mediation of practical skills (competence), which can be used to successfully and lastingly deploy this knowledge in the company or organisation (Implementation).
    2. What other topics do you teach or consult on? Topics include:
      – Cloud & Sourcing
      – Lean, Agile & DevOps
      – Value Chain Service Models
      – Training and Awareness (Cloud, ISO, ITIL, Cobit, Security, Agile, DevOps)
      – Security & Cyber Resilience
      – Change Enablement
    3. What type of interest in DevOps are you seeing in your region? As everywhere the interest of DevOps is rapidly growing, in Switzerland this in not different. For many it’s really to understand in a first step what DevOps is about and why it is relevant for them. In Switzerland we deal a lot with financial institutes with a high level of legacy and regulations, the question is often how to apply DevOps practices in such an environment.
    4. How do you think that DevOps contributes to the business’ value stream? DevOps is all about getting faster and better and this is how it positively influences the value stream. And DevOps does it in a holistic way by looking at the value stream end-to-end, from idealization to $$$.
    5. What topic area in DevOps excites you the most? Dev’s and Ops’ finally talking to each other!
    6. Why should enterprises and individuals consider formal DevOps Training? Before starting any change initiative, it is paramount that everybody gets a common understanding. This is especially true for DevOps, as it includes a wide range of Agile, Lean and ITSM practices. A training or special awareness sessions definitely facilitates this.
  • DevOps: Commoditizing Infrastructure

    DevOps: Commoditizing Infrastructure

    Hardware vendors face a quandary. How do you distinguish yourself as superior from your competitors if you are unable to continue to grow a distinct architecture as your competitive advantage? But this dilemma does not begin and end with only hardware vendors; operating system vendors and virtual machine vendors are on the same horizon. In an effort to “uncomplicate” hardware idiosyncrasies, our industry evolves efforts from open standards to least-common-denominator functionality for a “common” language or set of features, and over time technologies such as containers emerge. If I can abstract my application from the “uniqueness” of hardware vendors, from the complexity of configuration settings, and make only assumptions about basics such as CPU, disk, memory, etc., then I am free to focus on the application and allow my “hardware mitigation technology” to perform its function.

    The Relationship Between App and Storage

    But to accomplish this feat, I must agree to a basic set of features or functions I intend to call, such as making “x” amount of machine memory available to my application. Whether disk or RAM, I am looking to define what my application needs and then expect the container (or hardware mitigation/abstraction manager of my choice) to manage the actual allocation. Then the quandary begins. Asking for 1TB of disk space as an example is generic enough. But does my request include the ability to specify I am looking only for disks that spin at more than 7,500 revolutions per minute, or will I be saddled with 5,000 rpm disks? There is a clear implication in speed for my app.

    Ultimately, as I sit and tune my code because my app has become “slow,” it could be something as innocuous as having its actual execution occurring in a cloud provider who uses the slower disk revolutions as opposed to the faster ones. Worse, it simply could be that the same cloud provider has a batch of the slower ones in one of its data centers where I wind up executing (only on a temporary basis), and I am never fully able to figure out why my app got “slow” for a while. That kind of random bad ju-ju requires the execution of a chicken to fix (I prefer Popeye’s, myself).

    Different storage vendors might have additional peculiarities that make one or the other superior in speed, reliability or performance over their respective competitors. But the container’s main functionality is to provide “disk” to my app. Specifications of specific disk vendors or providers are the problem of the cloud provider, not the app developer, in theory. But hardware refresh can be pricey, and to make a claim that “all our disks” have rpm specifications above 10,000 will be meaningful only for about 10 minutes when the 12,000 rpm models come out. And of course, there are many more architectural designs in the engineering that are intended to boost speed and reliability. If these are not to be ignored, a decision must be made as to “who” has the responsibility to manage their usage (usually the cloud provider), and “who” will complain when things get slow (usually you the customer).

    And what happens when “breakthroughs” occur in a specific technology? Solid-state hard drives, for example, are not exactly new now, but they once were. When you move your app from operating on a high-speed hard drive that spins to a chip-based hard drive the operates at the speed of the RAM it is based on, the difference in speed is an order of magnitude better. The inevitable question emerges, Will my container have the ability to specify RAM-based disks instead of traditional spinning disks, as part of the disk commodity it is providing to my app?

    Since the difference in speed is so great, you would think it would come up with a way. You would equally expect that providing offline storage such as tape (from the age of the dinosaur) would have its own designation in my container structure (not be equated with offline spinning drives due to the speed differential). When you go to make a backup or restore, the difference between tape and hard drive becomes as apparent as the difference between solid-state and spinning drives on app execution. So when a platform evolves, my container mitigation must evolve with it. But to offer the uniqueness of vendor superiority requires my programmers to learn who to request (or what level of hardware specs they must know), which is the whole point of wanting a commodity in the first place: I don’t have to know.

    Impact of Commodity on Other Components

    This same dilemma can be exhibited in CPU vendors. Intel touts its superiority, AMD would disagree, and there may always be an upstart who wants to rival the current leader in any space. Lest we think Intel-based computing is the undisputed champion, quantum computing may upset that assumption (unless, of course, Intel corners that market as well). The point here is simply to ask: how many features, how many specifications, how much do we the programming team need to know about our platform provider to understand why and where our application runs better and worse? In the days before container-style ideology, hardware vendors touted their differences and their uniqueness as the reason they were better. Now what?

    Then comes our virtual machine providers, and eventually our operating systems. If I want to truly abstract from my hardware layer, I must not call an OS-unique command that only Linux or only Windows can do. I must stick to functionality that both OS instances can reasonably understand and accommodate. While this least common denominator is great for extending where my app can run (on multiple types of hardware, in multiple types of OS installations), it has the same effect on uniqueness and potentially on competitive advantage. If the intent is to come up with a one-world OS, I am generally in favor, but our journey there is sure to have certain casualties in innovation that a single OS is suited for and its competitors are not.

    The inevitable question becomes, How far down, or how far up, do we want to form commodity provisioning of computing capabilities? One could argue that the simplicity of the iPhone platform is a user-centric expression of commodity provisioning at the top of the stack. Drag-and-drop programming languages are yet another expression of bucketing computing capabilities into more simplistic expressions (that more people can understand and, therefore, utilize). Commonality and simplicity do increase audience. In many segments of our industry, this is the nirvana of sales to the public.

    Impacts to the Bottom Line

    DevOps focuses on enabling innovation. At its core DevOps is focused on software innovation. Let’s face it—changes to hardware platforms are generally less frequent. If those hardware platforms are married to a particular app (not serving a large number of apps on the same box, same virtual instance, etc.) then at least provisioning can be tuned one to one with the app. But with the desire to turn infrastructure into a generic commodity that application programmers don’t have to think about comes the fact that they stop thinking about them. Over time they will understand less and less about why things become slow, or work better, as the knowledge of uniqueness goes away.

    Depending on your market focus, ubiquity is either your friend (as it touches consumers) or your enemy (if you are the hardware vendor attempting to maintain relevance over your competitors in an increasingly commoditized market). The questions I raise in this article are designed to focus on how to keep our trend toward hardware mitigation from stifling innovation in the very hardware platforms we depend upon. In any case, I welcome your thoughts on the topic.

    To continue the conversation, feel free to contact me.