devopsy.kinsta.cloud

Tag: governance

  • Cloudera Calls for MLOps Standards Initiative

    Cloudera Calls for MLOps Standards Initiative

    Cloudera put out a call this week for the IT industry to define a set of open standards for machine learning operations (MLOps) and machine learning model governance that could be universally applied.

    Santiago Giraldo, senior product marketing manager for data engineering for Cloudera, said the idea is to create the equivalent of a set of best DevOps practices to create the equivalent of a set of best DevOps practices for employing machine learning models employed by artificial intelligence (AI) applications that will serve to foster portability, interoperability and explainability.

    In the absence of such standards, most AI models are essentially black boxes optimized for specific platforms that many organizations are reluctant to adopt because no one is quite sure how they operate. Furthermore, it’s not all that feasible right now to integrate multiple AI models built using different classes of tools.

    At the same time, Giraldo said the further down the AI path organizations go, the more they realize the AI models they are building need to be either updated frequently or outright replaced as new data sources become available. Most AI models are trained to respond to specific events based on access to a finite set of data. As new data sources are introduced, organizations are discovering the accuracy of recommendations being made by an AI model start to degrade. In fact, only a limited number of AI models are making it into production environments today largely because they didn’t scale as expected.

    Cloudera is already moving down the MLOps path with Apache Atlas, an open source framework designed to integrate data management across explainable, interoperable and reproducible MLOps workflows. Now Cloudera is inviting the industry, including competitors, to collaborate on a broader set of metadata specifications that Anduago said is more a call to action than a specific proposal.

    It’s unclear precisely how such an initiative might be managed. There is no widely recognized consortium initiative focused specifically on MLOps. Thus far, the closest thing might be The Deep Learning Foundation, an arm of The Linux Foundation that connects organizations working on innovative technical projects focused on AI and machine learning.

    Despite all the hype, it’s apparent that AI is still in its infancy in terms of practical use cases. Most organizations can’t afford to hire the data scientists required to build AI models, let alone find them. Even when they do, the competition for AI talent is so fierce that organizations are also finding it difficult to retain that talent. Giraldo said the goal should be to make it easier not only to build AI models but also slipstream them into both new and existing applications.

    Obviously, many of the best DevOps practices that have already been defined can be applied to AI models. The next big challenge might very well be educating data scientists on how to work more closely with developers to build, test and deploy AI models with applications at scale. In the meantime, the existing DevOps community might want to do as much as possible to help prevent a nascent MLOps community from reinventing some wheels that might already exist.

    — Mike Vizard

  • 5 Ways DevSecOps Can Manage Software Supply Chains

    5 Ways DevSecOps Can Manage Software Supply Chains

    The unbridled use of open source components within the software supply chain is on a major uptick, according to new research. Even as this surge in open source dependencies fuels faster innovation, the study shows that it comes with high cybersecurity costs, as the number of breaches related to these components is similarly on the rise.

    However, the numbers also indicate there are some clear practices used by the best DevSecOps teams to minimize the risk while maximizing the speed and agility that third-party components offer.

    Sonatype and research partners from IT Revolution and Galois made a thorough analysis of download patterns, software component makeup and DevSecOps behaviors around open source components and third-party libraries for the “2019 State of the Software Supply Chain Report.” Their analysis found that the rate of open source component releases has picked up by 75% in the last two years and that download requests from teams using these components have risen 68% year over year.

    Most tellingly, the study showed that among modern applications today, 85% of the average code base is comprised of open source componentry. Not only are the majority of applications using open source components and libraries, but also they depend on them heavily.

    “The practice of assembling open source component releases into the form of an application screams of efficiency. Developers no longer need to code every line from scratch,” according to the report. “Developers can download component releases in seconds that deliver new capabilities, built by experts outside of their organizations who make their code freely available to others.”

    Perhaps not coincidentally, the study noted a parallel rise in breaches associated with open source component use. Last year 1 in 4 organizations suspected or verified they experienced a breach related to open source components in the last 12 months. That’s a slight improvement over last year’s stats, which had it pinned at 1 in 3 organizations. But since 2014, that rate of breaches has risen by 71%.

    The trouble is, many of the components developers download and integrate into their code are full of dangerous vulnerabilities. For example, just over half of all JavaScript package downloads contain known vulnerabilities, with 1 in 3 rated as high vulnerabilities. One in 10 of those flaws were rated as critical.

    The point the report hammered home is that not all components are created equally. There exists a certain class of well-run open source projects that release updates more frequently, update problematic vulnerabilities faster and remediate flaws more quickly. It is up to DevSecOps teams to systematically manage components, so they leverage more of these high-quality open source projects and try to avoid the riskier open source dependencies.

    “Management of software supply chains is not simply ensuring quality at velocity. Our supply chains are being attacked by adversaries in new and creative ways,” according to the report. It found that organizations that actively manage their supply chains are able to reduce the proportion of vulnerable components by 55% compared to those who do not.

    The report found several software supply chain practices contributed to this reduction of risk, with the following five standing out as the most impactful:

    Develop a governance program: Foundational to this is having some sort of open source governance or standards policies in place, according to the report, which noted that among the best DevSecOps organizations at managing risky components, nearly 3 in 4 have such policies in place.

    Have a process for evaluating and adding new components: As a part of that open source policy, the best teams have standardized processes for how developers add new open source components. This includes how these components are evaluated, approved, standardized and so on. The exemplary organizations are 11 times more likely to use this kind of process for new dependencies.

    Proactively remove problematic components: New vulnerabilities are discovered every day, so simply evaluating a dependency upon its first inclusion in an application can only take an organization so far. The best organizations also take the initiative to look for potential sources of open source vulnerabilities in existing code. That includes proactively seeking out and removing known vulnerable dependencies, as well as reducing the attack surface of the code by eliminating open source dependencies that aren’t being used. The best organizations are 9.3 times more likely to do so.

    Aim to always use the latest versions of components: It should go without saying that the latest version of any given component has the least vulnerabilities. The report showed that component releases that are 3 years or older have a 65% higher defect rate compared to newer components. Exemplary organizations strive to use the newest updates of all of their open source components and are 6.2 times more likely to do so than other organizations. That doesn’t happen accidentally—these teams are 10 times more likely to schedule update dependencies as part of the daily work of DevSecOps teams.

    Use Enforcement Automation: Just having a policy in place is not enough—organizations need to enforce the open source standards to reduce risk meaningfully. The study showed that DevOps practices combined with automated enforcement of policies increase developer adherence to standards by 150%. The exemplary teams with the lowest open source defect rates are 12 times more likely to have automated tools to track, manage and/or ensure policy compliance of open source dependencies.

    All of these best practices add up to less risk from components, as well as less pain for DevSecOps teams, who are three times less likely to consider the process of updating components as painful.

    — Ericka Chickowski

  • Software Liability Goes Global

    Software Liability Goes Global

    This month, France turned up the conversation on software liability for manufacturers who place known defective software components in their products. But, they are not the first.

    Software Liability in France

    According to Lukasz Olejnik, lawmakers in France just suggested a desire to “put the security liability in hands of product suppliers. In other words, making companies responsible for the security of products they put on the market—for as long as the products are commercially available.”

    He continued: “The strategy then mentions that one of the solutions could be to release source code and documentation after an end of support date. The strategy itself mentions taking this discussion to the international level. This will be interesting.”

    You betcha, Lukasz.

    (If you can read French, you can find the 166-page proposal here).

    Software Liability in United Kingdom

    The need for improved cyberhygiene in the UK reached new heights in 2017 following large-scale ransomware attacks on its nation’s hospital system and an increased focus on software liability. According to the UK’s National Cyber Security Strategy 2016-2021 report, “Businesses and organizations decide on where and how to invest in cyber security based on a cost-benefit assessment, but they are ultimately liable for the security of their data and systems. Cyber attacks are not necessarily sophisticated or inevitable and are often the result of exploited–but easily rectifiable and, often, preventable–vulnerabilities. In most cases, it continues to be the vulnerability of the victim, rather than the ingenuity of the attacker, that is the deciding factor in the success of a cyber attack.”

    Shedding a spotlight on the cyberhygiene and software liability, Britain’s Information Commissioner’s Office (ICO)—the country’s data regulator, said a hacker exploited a well-known security flaw on a Gloucester City Council website months after the vulnerability had been widely reported on and updated component versions had been made available. The ICO fined the Gloucester City Council £100,000 in June 2017 for not preventing a cyberattack exploiting the OpenSSL Heartbleed vulnerability.

    Software Liability in the United States

    Last August, Sens. Mark R. Warner (D-VA) and Cory Gardner (R-CO), co-chairs of the Senate Cybersecurity Caucus, along with Sens. Ron Wyden (D-WA) and Steve Daines (R-MT), introduced bipartisan legislation called the Internet of Things Cybersecurity Improvement Act of 2017.

    According to a fact sheet released at the time, “While ‘Internet of Things’ (IoT) devices and the data they transmit present enormous benefits to consumers, the relative insecurity of many devices presents enormous challenges. This legislation is aimed at addressing the market failure by establishing minimum security requirements for federal procurements of connected devices.”

    The proposed legislation requires vendor commitments:

    • To ensure devices don’t contain known security vulnerabilities when shipped;
    • To ensure proper disclosure of new security vulnerabilities discovered within their devices; and
    • To prepare remediation plans for any IoT device where known vulnerabilities have been discovered.

    While the legislation is clearly aimed at consumer protections and privacy, it also focuses on quality, safety and regulatory standards applied to every other major manufacturing industry (thou shall not ship products with known defects).  The legislation specifically calls for vendors selling IoT devices “to provide written certification that the device does not contain, at the time of submitting the proposal, any hardware, software, or firmware component with any known security vulnerabilities or defects.”

    Software Liability in the European Union

    When the innovation race is being run without proper oversight, getting to the finish line safely will require greater (and faster) care. That’s set to be a major challenge for organizations developing software under the forthcoming EU General Data Protection Regulation (GDPR) in May 2018.

    Article 32 of the GDPR states that organizations must “implement appropriate technical and organizational measures” to “ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services.” When combined with Article 25, which mandates that data protection measures be implemented “by design and by default,” it’s clear that privacy and security must become ingrained in every element of IT infrastructure.

    If you fail to follow these rules and known software vulnerabilities end up inadvertently helping hackers steal sensitive consumer data, you could be on the hook for seriously big fines: up to €20 million, or 4 percent of global annual turnover, whichever is greater.

    Software Liability in Germany

    In July 2017, a consumer advocacy group in Germany has filed a law suit against a retailer in Cologne that sold an inexpensive smartphone made by Mobistel. The Mobistel model Cynus T6 was sold in Media Market stores for just 99 euros. Sounds like a great deal, right? Not so much. You see, the phone’s software came with 15 critical and known security vulnerabilities that were not disclosed to the consumer at the time of purchase.

    Instead, these security flaws were later identified by investigators from the Federal Office for Information Security (BSI).  Unfortunately for Mobistel and Media Market, consumer advocacy groups tend to fight back when manufacturers and retailers sell products to consumers without disclosing “essential information” such as known security defects in a smartphone.

    Although the complaint is at an early stage, it points to the possibility that companies manufacturing software applications could be held liable for selling defective products to consumers—in exactly the same way that auto makers have long been held liable for defective parts in cars.

    Think You Aren’t Shipping Vulnerable Software?

    Think again. According to Sonatype’s “2017 State of the Software Supply Chain Report,” 80 percent to 90 percent of a modern application is now assembled from open source and third-party components. Therefore, “It is incumbent upon development organizations to practice good hygiene when consuming open source components. Teams with suboptimal hygiene inevitably consume open source components with critical vulnerabilities. Last year, 5.5% (1 in 18) components downloaded from internet-based open source repositories contained known security vulnerabilities.”

    What does this mean for you? If you have not been paying attention, the chance that software your organization is building contains a known software vulnerability is nearly 100 percent.

    The Writing is on the Wall

    Organizations failing to manage software supply chains, who are unwittingly releasing vulnerable applications into production, will face increased liability due to gross negligence.

    The writing is on the wall. Are you prepared?

    — Derek E. Weeks

  • Malicious Intent: Open Source Developers, Please Protect Your Users

    Malicious Intent: Open Source Developers, Please Protect Your Users

    For the second time in just a few weeks we’re seeing the fallout of missteps taken by publishers of open source components. It was just recently that I wrote about the GitHub id of go-bindata being highjacked. We don’t know for certain if the intentions were malicious, but the risk was obvious.

    Even more recently we find that credentials were compromised for an npm component called conventional-changelog and a malicious version was uploaded that allegedly included a Monero cyptocurrency miner. Anyone who built or installed an npm package depending on the malicious package is now potentially running a miner and worse, potentially distributing it to their downstream users or customers.

    A few months ago people were laughing at a parody of a similar situation describing credit card harvesting via a compromised package. It’s not so funny anymore, is it?

    Open source developers typically thrive in creating something used by millions or billions of other people. This is the fuel that drives us and knowing that you’ve contributed, even in some small part, to the lives of millions of users is amazing.

    Conversely, knowing that you’ve accidentally inflicted harm on those users through careless practices is probably devastating. Yet, seemingly not enough people are thinking about this beforehand while it’s preventable.

    We open source developers and package maintainers are finding ourselves at the frontline of the new battle. Attackers have recognized the power of open source in terms of broad distribution and are seeking to use that against us.

    We must not let them ruin the reputation of the things we’ve built—or, worse, the entire open source ecosystem.

    If you’re an open source contributor or package maintainer: Pay attention to your own digital security as you would if you were protecting millions of others. Because you are.

    — Brian Fox

  • Is DevOps Transformation a Holy Grail?

    Is DevOps Transformation a Holy Grail?

    Both development and operations teams are popping up in enterprises all over the world, and even though DevOps programs are still in the early stages, our ultra digital world calls for even more software applications. This is why many analyst and consultants alike believe that, in the near future, DevOps will be even more powerful than legacy IT. DevOps will be something businesses of all sizes will not be able to live without and the sooner you initiate the DevOps transformation, the better.

    Why DevOps Transformation?

    One of the most exciting aspects of DevOps is enacting technology practices and architecture that help organizations create an agile and continuous product flow, from development to testing, operations and all the way to deployment while increasing stability, reliability and security at the same time.

    More importantly, adopting DevOps can enact changes in the culture of your business, such as allowing teams to work more quickly with more independence. Back in the days before DevOps, deploying even a minor update, upgrade or bug fix would involve literally hundreds of developers doing weeks worth of work.

    Today’s top-performing businesses and DevOps adopters are deploying much faster, and the products they release generally have greater reliability. Still not convinced that DevOps is the holy grail? Consider the following.

    Focus on Speed, Not Cost

    Do you want to achieve the same capabilities of Amazon and Netflix? Of course! Who doesn’t? It’s easy to make an excuse that they have a lot of money to spend, but, when we look deeper, companies that achieve DevOps success are more focused on optimizing speed, not cost. Organizing and optimizing for cost creates functional silos for networking and database people, server admins and many others.

    When you optimize for speed, you are willing to cultivate talent from within, increase engineers’ salary and send them to conferences. You would not necessarily do these things if you were simply optimizing for cost. There are a whole bunch of techniques we can use to optimize for speed, such as using small, cross-functional teams that can deploy value to the customer independently without having to rely on hundreds or, in some cases, thousands of people.

    Best of all, you don’t have to be a big conglomerate to make this transition. Even small and medium-sized businesses can choose to optimize for speed, break down silos and get their product to market faster. After all, this is what DevOps is all about.

    Software Speed vs. Quality

    Businesses that rely on developing and deploying software to support or supply their customers often are faced with choosing speed or quality. If you go to market before your competitor(s), you could be cutting corners in terms of testing and quality assurance, which can ruin your launch. However, if you wait until your code is perfect, you could end up lagging behind in the race for the next big breakthrough. Fortunately, the DevOps approach can resolve this dilemma while improving the bottom line.

    Way back in 2015, the “State of DevOps Report” collected the DevOps health and habits of more than 20,000 tech professionals and found that top performers using DevOps show more agility and reliability in their releases and they were twice more likely than non-DevOps users to exceed productivity goals. In the roughly 800 companies that had a stock ticker symbol, the top performers had an almost 50 percent higher market capitalization growth over three years. This indicates that DevOps is great for IT performance as well as organizational performance.

    What everything boils down to is that all modern businesses are increasingly more reliant on technology when it comes to acquiring new customers and bringing value to those customers. It is becoming increasingly apparent that agility and speed are key attributes for companies who want to win in today’s marketplace.

    DevOps Transformation Guide

    With all of the benefits listed above, you are probably eager to get started with DevOps. Here is a simple step-by-step guide to assist you in your DevOps transformation.

    1. Conduct an Enterprise Readiness Audit – The highest probability of a successful DevOps transformation is when it is championed from the very top. The participation of business leaders is just as vital as operations, security and development teams. To get everyone on the same page and to ensure that your DevOps transformation gets off to a good start, seek assistance from an experienced, external consultant or coach. The purpose of this first step is to get executives to buy in, create mutual goals and get an understanding of what an Agile-DevOps program looks like.
    2. Create a DevOps Center of Excellence (CoE) – One of the most important things you must do here is designate an Executive DevOps lead with enterprise authority. There is no use in creating this Center of Excellence at the incorrect organizational level. It must be spearheaded by someone who has the support and trust from all branches of the organization including delivery and vendors.
    3. Create a Program Governance – Such a program will include creating a communications plan, an enablement program as well as establishing program KPIs. In terms of making a cultural impact on your organization, this is perhaps the most important step. The roles and responsibilities of practitioners will change with Agile and DevOps and it is vital that they understand collaborations between structures where historically animosity could have existed so they can break down these organizational silos. The KPIs will also need to be transitioned from individual metrics to holistic customer business results.
    4. Create a Project Intake Process – Project intake really sets the tone for how successful each new sprint that comes into the program will be. What matters here is not the tools and process, but rather the proper sizing of the tools and process. There is a need to fit for purpose when selecting accelerators, toolchain and development methods. Once it is created, the communication of the intake process needs to be disseminated across the organization. Keep gathering feedback and and continuously evolve and mature based on this feedback.
    5. Identify and Initiate Pilots – To achieve the highest probability of success, apply this step to a specific portfolio of applications or a domain solution. The purpose here is to create a value-stream map of a specific application with company wide participation on all levels. This needs to be done with the necessary amount of detail to identify manual and automated processes, end-to-end process tooling and the people and skills that are involved.
      The next aspect of the intake project is the collaboration between the subject matter experts from the Center of Excellence with the project team. The goal is to advise on “to-be” processes with proper tooling, reusable assets and automation. As the application goes through the development and test cycle, be sure to identify and capture the KPIs for the program in order to compare with existing KPIs.
    6. Scale Your DevOps Program – This final step involves taking feedback from the pilot metrics and scaling them by taking different application portfolios and running multiple release trains. It is not enough to merely do automated deployments and daily builds. The last, but by no means least, piece of the DevOps puzzle is constant feedback and optimization.

    Key Takeaways

    • To keep up with top-performing businesses and stay alive in today’s ultra-competitive, fast-paced environment, implementing DevOps is an absolute must. DevOps is not solely reserved for giant enterprises such as Amazon and Netflix and can be implemented in any-size organizations.
    • In the not too distant future, DevOps will become something businesses of all sizes will not be able to live without. To reap all the benefits DevOps has to offer, the sooner you make the transition to DevOps, the better.
    • With DevOps, there is no longer a reason to choose between speed and quality when deploying your software. When implemented properly, DevOps will allow you to deploy software with both agility and reliability increasing your customer base and the bottom line.
    • The step-by-step approach mentioned above can and should be implemented in any flavor and variety that best suits each individual organization’s needs and constraints.  Pay particularly close attention to large gaps or excessive deviations as they are red flags which will need to be corrected.

    About the Author / Stanislav Ivaschenko

    Stanislav Ivaschenko is a certified AWS solutions architect at Squadex with more than 10 years of professional experience in building, delivering, supporting and optimizing a broad range of software applications. From bare metal to the cloud, from monolith architecture to microservices his expertise and experience help to meet business needs for startups, mid-sized companies and large enterprises. He has experienced a large number of DevOps and infrastructure related tools, services and management practices.

  • The Beauty of Inheritance Architectures

    The Beauty of Inheritance Architectures

    Spoiler alert: This article is not about inheriting your great-grandparent’s estate. It is rather about how embedding the principles of inheritance into the architecture of your chosen DevOps toolset can yield exponential results. And yes, I realize that you, the customer, have little to do with what a vendor builds its tooling architecture upon. However, you, the customer, can vote with your feet, to search out products that offer features such as inheritance, rewarding vendors that have it and punishing those that do not. The simple question to address here is, Why should the customer care?

    Like anything that can grow, sustainability on scale is a key concern. How much will it cost me when I am maintaining 6,000 applications on this particular DevOps toolset, as opposed to the six applications I started with? You can also infer maintaining a higher number of technologies as having the same need. For example, if I need to maintain three different types of databases, two different middleware, four different hardware platforms on “x” different versions of operating systems … you get the idea. The larger the application portfolio (in sheer numbers of apps), or the more technically complex the portfolio (in sheer numbers of technology components in an app), eventually will drive you to worry about how easy it is to maintain these applications within your chosen DevOps toolset.

    The capabilities of your chosen set of DevOps tooling will govern the costs of both the initial adoption of your services as well as the ongoing maintenance of the application portfolios you serve. It is hard to sell the value of DevOps to the business when it begins to see a one-for-one increase in DevOps engineering staff for every new application or technology venture under consideration. However, one of the chief culprits in driving large DevOps support staff organizations boils down to the lack of an inheritance architecture in the tooling that was originally selected.

    Setting a Common Language

    So before we discuss how inheritance will benefit us, first let’s agree on a common vernacular of what an “application” is. When you say the word “app” to someone, you get a wide variety of responses on what that means—from something that sits on your phone to a cluster of things that sit on the mainframe. Let’s begin by examining what an “app” is by the effort it takes to onboard and then maintain it on our DevOps sets of services (regardless of platform).

    Consider for a moment the hierarchies by which we could describe software constructs. It is relatively easy to discuss how software works in terms of hierarchy. First, at the lowest layer, we could describe having multiple technology components (or the lowest level of a particular piece of technology that must be addressed in a build). Next, assembling these components together forms the picture of what a single application looks like. Finally, assembling multiple applications that have a common symmetry or common purpose together form a system or series of apps.

    An imperfect but quick example could be the Microsoft Org Chart component of its Office application(s). For purposes of example we will argue that Org Chart, Clip Art Manager and Equation Editor are all components of the application Microsoft Excel. To build a new version of the application Excel, we would have to deal with each of these individual components that, once assembled in our build, would create a new version of Excel. When you combine more of the apps—Excel, Word, Outlook and PowerPoint—you get the system, or series, called MS Office. (And, yes, I know this is a less than ideal example, but it is meant only to illustrate a point.)

    Assessing the Work Effort

    The reason for discussing software in this way allows us to begin to discuss the level of effort to automate it. By addressing the work effort to automate each component (by type), we can begin to estimate how long it will take to complete “the automation of software.” For example, if my homegrown application has a source code component, a configuration file component, a database component and a middleware component, then I have four components I must automate (or include in the build and deploy process) to assemble a new version of my application.

    This gives us a “least common denominator” language for assessing how much effort it takes to automate a given app. I have seen most common applications have only two to three components. But I have also seen several apps that, due to their unique architecture and construction, have 30 to 50 components a piece. Obviously, it is easier to automate an application with only three components than one with 50 components. The other factor we need to apply on the ease of automation is whether I have encountered this particular component technology before in my prior automation efforts.

    Let’s say, for example, that the application I am estimating contains Java component(s). If I have encountered Java automation prior to this, I should have constructed a template for Java type component automation that I can use for a situation just like this one. In this situation a familiar technology component is far easier to automate than a new one (or, rather, new to me). However, if this is the first time I have ever seen Java, then it may take me a bit longer to construct the template I want for this app, and for future apps I encounter, that also use this technology type.

    The Beauty of Inheritance

    Here is where inheritance begins to play its critical role. If my DevOps-build construction tooling includes inheritance, then I could construct a “master” template or framework for each type of technology as I encounter it. A master template for SQL databases or Oracle or DB2, as an example. Or, I could make a master template for WebSphere or SharePoint types of technologies—one master for each kind of programming language we have in my shop. You get the idea.

    Having done this allows me to have a limited number of master templates, in which I can maintain all the critical steps and processes my company wants me to do for a given technology type. If different business organizations or development organizations need a variation, they can create a “child” of my master and vary it according to their own needs. As long as the linkage is maintained to my parent/master template, I can make the big, overarching changes driven by corporate mandate, and the business unit can continue to vary items to their unique needs.

    Having inheritance in this instance allows me to roll out changes to an entire organization, such as, for example, a security patch or process, for a given technology by simply adjusting the master template of that component. Inheritance automatically flows my change down to all the “children” of my master and possibly to all their “children,” should the need arise. The alternative is having to go through the specific automation of each application that has the targeted technology component and updating it manually, hoping I don’t miss one, and hoping the steps I may need to adjust do not break the old automation instead of alter it the way I needed.

    Imagine having a WebSphere subject matter expert able to adjust every client application that uses your corporate installation of WebSphere by simply adjusting one master template. Or having a network guru, or database expert, be able to do the same for all applications that use their particular technology component all at once. Inheritance preserves the real-world need of having limited alterations of the same technology type within the same company, flowing down changes from parent to child.

    Having a one-size-fits-all is simply not practical. Using copy/paste requires repeating updates to each impacted template or framework manually. But having the ability to create offshoots from a main, and not lose the connection to the main, allows corporatewide alteration from a central point of control. The costs of maintenance or administration are formidable; inheritance can reduce them. This allows a much higher ratio of applications or technology components supported by a much lower number of engineering staff.

    A Wider Impact for Inheritance

    Inheritance is keenly useful in release orchestration software as well. Most vendors offer the cut-and-paste approach: you copy the last the release you did, alter it slightly and use it again. That might work for some organizations. But having an inheritance feature creates entirely new dynamics on how a release is constructed for a given line of business and how corporate governance can be implemented with minimal effort. In this case, a corporate master release template can be constructed, and child releases can inherit from the master all the main governance required without risk of omission.

    I realize inheritance architectures might not be at the top of your list when evaluating DevOps tooling solutions. But I would submit it is a strategist’s job (if you need one, let me know, I am looking 🙂 ) to point out how long-term sustainability can be greatly benefited by this architectural feature—even if the vendor would love nothing more than to steer you away from it. If you already have committed to a tooling solution, you may want to bring this up at your next vendor features performance meeting. If not, you should at least consider what having it means to your internal cost structure, and what not having it will add to the true cost of ownership of any proposed solution.

    To continue the conversation, feel free to contact me.

  • Defining What DevOps is Not

    Defining What DevOps is Not

    It’s not often that my emails turn into full-blown conversations on DevOps. But when it happens, it’s a great time to take advantage of the insights. John Purrier of Automic and I recently discussed DevOps sustainability. Both of us think that sustaining a modern delivery chain and adopting it are two very different things. However, most only consider the latter. And because of that, in two years (or much sooner), they will find themselves in the exact same place they started—in an environment that is unable to adapt, rooted in habit and suddenly the old guy on the block.

    (more…)