devopsy.kinsta.cloud

Tag: software

  • Compuware Extends DevOps Push for Mainframes

    Compuware Extends DevOps Push for Mainframes

    Compuware has advanced its campaign to erase the DevOps divide between mainframes and distributed systems via an update to Topaz for Enterprise Data that makes it easier to generate data from mainframe applications for testing purposes without compromising the security of some of the most sensitive data in the enterprise.

    Company CEO Chris O’Malley said Topaz for Enterprise Data now includes a data masking capability that preserves essential data relationships and characteristics without letting developers see the data being copied.

    Designed to be compatible with Eclipse integrated development environments (IDEs), Topaz for Enterprise Data also automates the extract, transform and load (ETL) process by enabling developers to convert file types.

    O’Malley noted that, at a time when compliance regulations such as the European Union’s General Data Protection Rule (GDPR) are becoming more stringent, it has become more important for organizations to be able to demonstrate that personally identifiable information (PII) has not been exposed during any point in the application development cycle. That’s especially important when it comes to mainframe data, which typically is used to drive transaction processing applications.

    In general, O’Malley said the historic divide between mainframes and distributed systems is narrowing as organizations embrace DevOps processes. Instead of proponents of these platforms battling within organizations for control over specific classes of workloads, there’s more awareness of the need to leverage both platforms to drive a new generation of digital business applications, O’Malley said.

    The challenge is that most mainframe applications are built and updated using waterfall methodologies. Compuware has been developing a series of DevOps tools for mainframe environments that are intended to modernize those processes. As the IT organizations that have mainframes adopt those tools, it becomes easier to federate application development and deployment across mainframes and distributed systems, O’Malley said.

    Of course, this all assumes various teams within the IT organization can lay aside historic animosities. The shift to DevOps has always required as much process and cultural change as it does new technologies. But in the case of IT organizations that have mainframe teams, that shift may take years. The good news is a that a new generation of IT professionals doesn’t have much history with infighting within internal IT organizations. The simple fact is there are classes of workloads that run better on mainframes, O’Malley noted, but that doesn’t mean every workload running on mainframe is ideally suited for that platform—or conversely, that every workload running on a distributed system is ideally suited for that platform.

    Arguably, the rise of DevOps processes might create an opportunity to revisit many platform decisions that were made in the heat of a larger argument. In the meantime, it’s clear that applications integration spanning multiple platforms is the new order of the day. The question now is how best to go about achieving that goal in a way that erases the divide existing between all the platforms that now make up the extended enterprise.

    — Mike Vizard

  • The Human Touch: The Key to Optimizing Your Software Value Stream Network

    The Human Touch: The Key to Optimizing Your Software Value Stream Network

    Software has no intrinsic value until it’s working in production and supporting a customer’s business initiatives. With that in mind, it’s imperative that organizations focus on how they reduce the time to value, not just time to deploy. And that’s achieved through people.

    A common misconception is that technology underpins a software delivery value stream. This is only half true. Tools add immense value and help people to be more productive—whether through advanced functionality (such as the ability to visualize and manage workflow) or by automating repetitive activities (such as test cases and releasing code). All of this boosts throughput. But it’s actually the human touch that drives a product.

    It’s all about how practitioners work together to understand and address a discerning customer’s needs with software. To that end, organizations must ask themselves, “How do we optimize practitioner collaboration?”

    It’s All in the Artifacts

    Collaboration optimization lies in how organizations handle product-critical information—artifacts such as features, epics, stories and defects—that are created for the very purpose of sharing with collaborators.

    Therefore, the follow-up question that organizations should ask is, “What system do we have in place to ensure these artifacts are flowing in real-time, so the information is always up to date, ensuring that all work is always accurate and adding value?”

    Fortune 100 companies have already asked these questions, making a number of significant discoveries:

    1. The software value stream is actually a social network of collaborators who are connected by artifacts—hence, “value stream network.”
    2. This network consists of two different, but equally important, phases: “plan and design” and “build and deploy.”
    3. The network by default is not explicitly connected because the tools collaborators use do not naturally integrate with each other and automatically flow artifacts between them.
    4. This disconnect forces collaborators to waste precious time chasing up information via manual means such as email, status meetings, spreadsheets, tool-switching and duplicate entry.
    5. This manual communication is non-value work that costs organizations up to $10 million in productivity overhead (based on a typical 1,500-person IT department).
    6. Such archaic knowledge-sharing practices significantly compromises the fidelity of data as it goes from one practitioner to the next.
    7. The “plan and design” phase—the part of the software delivery process that determines what product/feature is to be built/fixed—is detached from the “build and deploy” phase.

    Through these discoveries, the last one in particular, organizations came to an important realization: They have no real way of knowing if they’re building the right product because there are six degrees of separation between the people who design the product, and those who build and deploy it.

    The result? Disgruntled customers and a big loss of competitive advantage. To address this, they’ve created a new infrastructure that provides a framework to connect and support both phases.

    By fusing the value of people and technology into a defined value stream network that is visible and traceable, they have a seamless flow of work that they can see, measure and control. They’re now in a position to identify where value is created and lost, enabling them to make informed business decisions to make better products.

    The Software Value Stream Network

    The enterprise software delivery process has long been misunderstood as a traditional manufacturing system that is linear and sequential—thanks in part to the industry’s failed adoption of the Waterfall model. The negative influence and impact of that experiment still lingers today.

    The process is linear in the sense that there are two clear bookends: A product/feature/fix is requested (A) and then that product/feature/fix is made (B). There are also established phases across the production line: conception, initiation, analysis, design, construction, testing, deployment and maintenance. But that’s where any real similarities end.

    In reality, the process is more of a latent network of critical interactions between collaborators. These bilateral working relationships exist at key stages of the software delivery process, such as developer and tester, developer and operations, etc.

    When you actually lift up the floorboards of the process and peak inside, it looks more like a social network connected by the flow of artifacts, which looks something like this:

    Most of these relationships have developed over time as organizations have introduced a higher degree of specialty in key stages across the value stream. This evolution has been vital in helping organizations to:

    •   More deeply understand customer requests/issues
    •   Clearly articulate the requirements/defects
    •   Enhance product management/optimization
    •   Acutely break down requirements into epics and stories
    •   Write more accurate code faster
    •   Automate and accelerate higher levels of testing
    •   Continuously deploy
    •   Introduce tighter feedback loops
    •   Continuously improve and innovate

    While all these new roles, disciplines, purpose-built tools, processes and methodologies have helped different practitioners to perform better, it’s also introduced huge technical complexities. How do you flow those all-important artifacts if the tools are disconnected by design, and when collaborators are working in silos, trapped in “administrivia” hell? It’s tantamount to having a sports car with no gas and a confused driver. Or an airplane flight network with no air traffic control. It’s a banana republic.

    Building the Right Product via Value Stream Integration

    Agile and DevOps illustrate just how vital integration and automation is to this flow of work. Agile brought in prioritization, feedback loops and sprints to build the most important features as fast and accurately as possible.

    DevOps, meanwhile, has accelerated speed of deployment. In that sense, the build and deploy phase is optimized. Automation has work flowing seamlessly between Dev and Ops teams, and eliminated/mitigated cross-team issues, such as miscommunication regarding what products need to be deployed, and when.

    But what’s the point of faster delivery if it’s not what the customer wants?

    We need to consider how wrong features are developed. If you turn to look upstream, you realize that the teams planning and designing products are affected by the same misalignment that used to plague DevOps teams.

    The disconnections between collaborators and their tools in the creative software design process mean that often what’s implemented isn’t right or is delivered too late. In either case, it doesn’t add value.

    But that can be radically changed through sophisticated toolchain automation, which shares artifact data across tools and automates the hand-offs between owners in the “plan and design” stage.

    From the sales to product to PMO to business analysts, by bringing these customer-centric, product-focused teams together, you dramatically improve the product articulation process and the speed at which its performed.

    You build features closer to the customer’s needs. You contain that precious value. And then through automation you can flow that value downstream to developers to create that value. It is as big a revelation as DevOps.

    How is this all done? Enter value stream integration. This process is much more than just connecting two tools, say Jira and HPE QC. It’s about connecting all tools, practitioners, disciplines and processes to define and create a free-flowing network that is automated and scalable. Think of it as the plumbing in a house. If even one pipe isn’t connected, there’s no flow of work (value).

    Value stream integration connects the pipes to:

    •   Automate Information Flow Across Value Stream: It enables the frictionless flow of artifacts, as well as information from events across the value stream. This removes non-value-added work and bottlenecks; increases velocity and capacity; enables automated traceability; and dramatically improves employee satisfaction.
    •   Enable Value Stream Visibility: When managers want to see metrics and dashboards to understand project status, to optimize the process or to ensure compliance, it has been nearly impossible to get a real-time, holistic view across non-integrated tools. Value stream integration unlocks lifecycle data from these application tool silos by automatically compiling lifecycle activity data into a single database. This data can be used to create consolidated, full-lifecycle reports and dashboards, as well as for traceability reporting.
    •   Create a Modular, Agile Toolchain: Value stream integration enables organizations to use the products that best support each discipline while getting the benefits of a single, integrated toolchain. This drives more value from each tool and allows organizations to easily add, replace and upgrade them, creating a proactive environment for innovation. It creates that value stream network.

    Finally … Manageability

    With this network, organizations can finally see, manage and optimize one of the most important processes in their business: the engine that drives their prosperity in a digital-centric world. You cannot underestimate how important it is to have this network, this complete system. This is the state where innovation thrives, and where continuous improvement can be executed. And, of course, where you gain the essential visibility to be confident you’re always building the right product.

    — Nicole Bryan

  • 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

  • Making Software Maintenance Cool Again with DevOps

    Making Software Maintenance Cool Again with DevOps

    What makes DevOps so important? Part of the answer lies in how DevOps encourages more appreciation for and investment in software maintenance.

    Traditionally, the IT industry has been like the construction industry. People who design new things (architects or software developers) are at the top of the value hierarchy, whereas the folks who build and maintain them (construction workers and IT Ops admins) are not held in such high esteem.

    This isn’t to say people hate admins, of course (or construction workers, for that matter). What I mean is that the work of building and maintaining tends to be seen as less creative and exciting—and ultimately less important—than the work of designing new things.

    This is why software developers in the pre-DevOps world got most of the glory. They created new code that did exciting things.

    Meanwhile, admins on the IT Ops team were stuck deploying and maintaining that code—and occasionally cleaning up messes created by developers who wrote bad code. Admins were also the first folks to take the blame when something went wrong.

    This isn’t to say that developers cause all the problems, of course. Some mistakes can be attributed to admins. Others are the result simply of poor communication between developers and admins.

    Still, in general development work—which involves creating new features and innovations—was what was celebrated. Maintenance work performed by IT Ops was less glorious.

    DevOps and Software Maintenance

    One of the most important—yet also most underappreciated—results of the DevOps movement is that it has made software maintenance cool again.

    In addition, DevOps provides more organizational support for maintaining software, while also facilitating the type of communication between developers and admins that leads to better maintenance.

    DevOps does this through principles such as the “you build it, you own it” mantra, which stipulates that whoever writes code is also responsible for deploying and maintaining it.

    Even if your organization doesn’t adopt that particular DevOps practice, it probably still seeks greater collaboration between developers and IT Ops. As a result, when something breaks in production or needs to be upgraded to maintain reliability, developers are involved, too.

    Celebrating Software Maintenance in DevOps

    Despite the emphasis that DevOps has brought to software maintenance in practice, you still don’t hear a lot of talk about maintenance work in the DevOps world.

    In essence, coding is still seen by many people as the coolest type or work that is done in the DevOps world. What DevOps has done is break down the silos separating those who code from those who maintain. It hasn’t necessarily made maintenance itself the object of more excitement.

    It may be time for that to change. Forward-thinking organizations should recognize that software maintenance—which includes tasks such as applying updates, monitoring applications and scaling host infrastructure—is just as crucial for a seamless application experience as the applications themselves. This should become an explicit part of the DevOps conversation.

    — Chris Tozzi

  • Trend Micro Expands DevSecOps Portfolio

    Trend Micro Expands DevSecOps Portfolio

    At the AWS re:Invent 2017 conference today, Trend Micro significantly expanded its reach into DevSecOps by announcing it has acquired Immunio, a provider of agent software that can be employed on a central platform engine to execute security policies on a granular level.

    In addition, Trend Micro announced it is adding support for container image scanning to its portfolio of security products as well by the spring of 2018.

    Mark Nunnikhoven, vice president of cloud research for Trend Micro, says both the Immunio policy engine and the container image scanning technology are now part of the Trend Micro Hybrid Cloud Security family of offerings that the company plans to expand for developers. Those capabilities, in turn, are exposed to developers deploying applications on-premises or in a public cloud primarily through its Trend Micro Deep Security cloud service, a suite of security technologies and threat detection services exposed by application programming interfaces (APIs).

    Nunnikhoven notes Trend Micro has seen a significant increase over the last several years in the use of programmatic approaches to managing security. Most of the shift has been driven by developers who have driven security to the left as part of the rise of DevSecOps. But he says security professionals are also starting to develop programming skills to advance IT security both in the cloud and on-premises.

    Nunnikhoven says the rise of containers is making DevSecOps more challenging. Too many developers are still grabbing containers from registries without checking them for vulnerabilities. As many as one-third of containers may contain known vulnerabilities, he says. To address that issue, Gartner estimates that by 2019 more than 70 percent of enterprise DevSecOps initiatives will have incorporated automated security vulnerability and configuration scanning for open-source components and commercial packages. That compares to less than 10 percent in 2016.

    IT organizations, however, don’t just want to be able to scan container images. Nunnikhoven says it’s clear they want a set of integrated security tools that can be employed to secure both the containers and the hosts they are deployed on. In the case of Immunio, Trend Micro is adding a security technology that can be embedded in applications running on virtual machines or bare-metal servers, as well as containers making up a microservice.

    While Trend Micro has a long history of providing security products to IT and cybersecurity professionals, it and virtually every other security vendor are competing against a host of startups that have embraced DevSecOps to change how security technologies are consumed. In its effort to remain relevant, Trend Micro is expanding its portfolio of products to focus more on developers. Over time, however, Nunnikhoven expects there will be increased collaboration between developers and IT security professionals, as the lines of responsibility for various aspects of security are better drawn.

    In the meantime, however, Trend Micro—like most of the vendors in the IT security industry—is now clearly making a hard shift to the DevOps left.

    — Mike Vizard

  • MongoDB Addresses Host of DevOps Issues

    MongoDB Addresses Host of DevOps Issues

    At its MongoDB Europe conference this week, MongoDB updated its open-source document database with the addition of MongoDB Ops Manager to simplify management of distributed instances of version 3.6 of its database.

    In addition, the company has added a capability that enables all updates to the database to be automatically reflected in the application in real time without having to take the database offline.

    Additional new capabilities include a MongoDB Compass tool to analyze schemas and a governance capability that makes it easier to apply and tune data governance polices before and after an application is deployed.

    The company has added an aggregation pipeline that allows users to perform real-time analytics directly in the database to improve performance. Developers and analysts now can write queries combining data from multiple collections for complex analytics. Its Connector for BI, which can now be deployed and managed by its Ops Manager, has been updated to support this new query capability.

    Finally, in the event of a system failure or network outage, MongoDB says it now automatically will replay any writes to the database when those services come back online.

    Brooks Circhlow, vice president of product for MongoDB, says developers have embraced document databases as an alternative to other database platforms because of their flexibility. Unlike, for example, relational databases, a document database doesn’t impose a schema that must be crafted by a database administrator. But as more instances of document databases proliferate across the enterprise, DevOps challenges start to manifest.

    In fact, Circhlow notes that IT organizations are also making extensive use of cross-replication capabilities across multiple database clusters that they manage or are managed on their behalf via the MongoDB Atlas managed service. In many of those instances, DevOps teams are responsible for both the applications and the document databases they run on.

    MongoDB is also moving to address a DevSecOps issue stemming from a wave of attacks aimed at misconfigured instances of its database. Circhlow says the most widely used installer for MongoDB limits network access by binding to localhost by default. With version 3.6, binding to the localhost is now extended to all MongoDB packages across all platforms. In addition, with new IP whitelisting support, administrators can configure MongoDB to only accept external connections on approved IP addresses.

    Document databases such as MongoDB arguably have been a primary catalyst for DevOps. Once developers began to bypass database administrators by downloading instances of document databases, it became clear that traditional approaches to IT operations were starting to erode. Most organizations would prefer their developers to write code than manage databases, so some new means for managing databases that doesn’t compromise the dexterity that document databases provide developers was required. Once those processes get established, the next question then becomes how to make traditional database administration involving other classes of databases part of that process. Most IT organizations are still working through those processes. But it’s clear database administration will never be the same.

    — Mike Vizard

  • SlashData Report: Developers Influence Tool Selection

    SlashData Report: Developers Influence Tool Selection

    SlashData has just released its “State of The Developer Nation Report for Q3 2017.” Here at Heavybit, a program that helps developer and infrastructure startups take their product to market, we look forward to SlashData’s reports that allow us to keep up to date on the shifts in the developer landscape.

    In 2013, Stephen O’Grady published, “The New Kingmakers: How Developers Conquered the World,” sending shockwaves through the ecosystem about just how important individual developers are when it comes to making technology purchasing decisions in companies.

    SlashData provides compelling data that backs up O’Grady’s book, showing how influential developers are within an organization and how targeting individual developers at organizations is a viable strategy for enterprise sales. The research only includes professional developers in organizations who buy tools or components and exclude lone wolves—developers who work on their own and where a purchase decision is purely personal.

    Key report highlights Include:

    More than 87 percent of developers with a leadership function, no matter how small, as well as two-thirds of front-line coders, are somehow involved in purchasing decisions.

    For developers that are not in a top leadership position, between half and two-thirds are in a position to make recommendations or influence decisions. In particular team leaders (i.e., senior developers) are big influencers (68 percent).

    Thirty-nine percent of developers acquire tools for their personal use.

    The ability for developers to pick and use their own tools shows that they have the power to make their own decisions and a budget to spend (even if it is small). It’s through this personal use that a tool can get introduced to an organization and is the first step in evangelizing the tool to the greater developer community.

    Up to a third of mid-level developer leaders (team leaders and product managers) hold the pen when writing specs for tools (32 percent and 31 percent, respectively), or even get the final word on which tool to adopt (30 percent and 27 percent).

    This fact is even more proof that individual developers at all levels matter. “Even when in a majority of cases developers still need management to sign off on purchases, the days are over when an inadequate tool could be pushed from the top down because it appeared attractive to CFO’s or top brass,” the report states.

    Developer influence, when it comes to making technology decisions in companies, continues to grow. To harness this shift, companies need to focus on creating tools that developers will come to love and evangelize on your behalf within their organization.  

    — Malia Powers

  • DevSecOps and DevNetOps: New Heroes in the DevOps Saga

    DevSecOps and DevNetOps: New Heroes in the DevOps Saga

    The evolution of DevOps is by no means done, but it’s safe to say that there is enough agreement and acceptance to declare it a hero. DevOps has helped glorify IT to the point where it’s no longer preventing business, nor a provider nor a partner of the business.

    Often IT is the business, or its vanguard for competitive disruption and differentiation.

    Splintering the success of this portmanteau hero, we now hear more and more of two trusty sidekicks: DevSecOps and DevNetOps. Lesser known in their adolescence, these tots are still frequently misunderstood, are still forming their identities, and still need a lot of development if they’re to enter the IT hall of fame like their forerunner.

    Just as the terms look, DevSecOps and DevNetOps are often assumed to be about wrapping DevOps principles around security and networking: operators hope to assuage technical debt and drudgery by automating in proficiency and resiliency. For networking, I’ve covered how there is a lot more to that than coding, but to be sure, these sidekicks certainly espouse operators learning how to do develop while DevOps was equally, if not more, about developers learning to operate.

    The Shift Left: SecDevOps and NetDevOps

    As if it wasn’t hard enough to tell what DevSecOps and DevNetOps want to be when they grow up, we’ve gone and given them alter egos: SecDevOps (aka “rugged” DevOps) and NetDevOps. Think about them exactly as the words look—it’s about the shift to the left. Left of what?

    Traditional DevOps practices focus on business-specific applications development. The development timeline is known as a concept to cash, and with all the superpowers of DevOps we try to reduce our enemy—the lead time and repeatable processes between code and cash.

    Security and building infrastructure, like networks, were considered supporting tasks, not revenue-generating nor competitive advantages. Thus, security and networking were far to the right on the timeline with concerns that deal with operational scale, performance and protection.

    Today’s shift left propels security and infrastructure considerations earlier down the timeline, into coding, architecture and pre-production systems. It’s a palpable penny-drop amid daily news of security breaches and infrastructure outages causing technology-defined establishments to bleed money and brand equity.

    Fill the bucket with cash, but don’t forget to forestall the leaks!

    DevOps and Infrastructure: Challenge and Opportunity

    Automation sparks have flown over the proverbial wall into the camp of I&O pros. Operators trading physical for virtual, macro for micro, converged for composed, and configuration for code is proof that the fire has caught security and networking. Controlling the burn now, is key, so that healthier skills and structures arise in place of the I&O dogma and duff. Fortunately, this is precisely the destiny for our newfound heroes, DevSecOps and DevNetOps.

    However, doing DevSecOps and DevNetOps, embracing security and networks as code, we mustn’t be so credulous as to forget the formidable DevOps practices and patterns that need transforming along the ultimate automation journey. Testability, immutability, upgradability, traceability, auditability, reliability and other you-name-it-abilities are not straightforward to achieve.

    Discounting “aaS” technology consumed as a service, a fundamental challenge to innovating SecOps and NetOps, compared to application ops, is that applications are crafted and built; security and networking solutions are mostly still bought and assembled.

    Security and network infrastructure as code is something that needs to be co-created with the vendors. Other than in the cloud, it will take a while before security and networking systems are driven API-first, and redesigned to offer simulation, finer disaggregation into microservices, and orchestration with scale and resilience.

    While this will land first in software-defined infrastructure, there is still a way to go to manage most software-defined security and networking systems with continuous practices of artifact integration, testing and deployment. Hardware and embedded software will be even more challenging.

    Finding Strength in Challenge

    So on one hand, DevOps is evolving with security and networking shifting left. On the other hand, traditional security and networking ops are transforming with DevOps principles.

    Is the ultimate innovation to squeeze out those traditional operations altogether? Does NetDevOps + DevNetOps = DevOps?

    There is a parallel train of thought and debate, with success on both sides. Purist teams cut out operations with the “you build it, you run it” attitude. Other companies such as Google have dedicated operations specialist teams of SREs. While the SRE reporting structure is isolated, SRE jobs are very integrated with that of development teams. It’s easy to imagine the purist approach, subsuming security and networking into DevOps practices, but only if we assume the presence of cloud infrastructure and services as a platform. Even then, there is still substantiation for the SRE.

    Layers below, however, somebody still needs to build the foundations of the cloud IaaS and data center hardware. As they say, “Even serverless computing is not actually serverless.”

    Underpinning the clouds are data centers. And then there’s transport, IoT, mobile or other secure networks to and between clouds. In these areas, it’s obvious there is a niche for our two trusty sidekicks, DevSecOps and DevNetOps, to shake up ops culture and principles. These two heroes can rescue software-defined and physical infrastructure from the clutches of so many anti-pattern evils, like maintenance windows and change controls (ahem, it’s called a “commit”).

    We may not require rapid experimentation in our infrastructure, but we would warmly welcome automated deployments and updates, failure and attack testing drills, and intent-driven continuous response. They will boost resiliency and optimization for the business and peace of mind for the builders.

    Teams operating security, networks and especially clouds, need to honor and elevate DevSecOps and DevNetOps, so that on the journey now afoot, our teams and our new heroes may realize their potential.

    About the Author / James Kelly

    James Kelly is a lead expert architect on cloud and software-defined networking at Juniper Networks. He also serves as a private yoga instructor, and previously, he founded a capital management firm in Ottawa, Canada. Connect with him on LinkedIn and Twitter.

  • Automation: Critical Missing Pieces in the CD Puzzle

    Automation: Critical Missing Pieces in the CD Puzzle

    As enterprises accelerate the frequency with which they develop and release new code into production to meet the ever-mounting demands of their consumers, there’s growing pressure on networking and security operations teams to keep pace with their DevOps counterparts. And it’s not hard to see why. According to Forrester, nearly four out of five business leaders believe it is IT’s responsibility to ensure the network can support the company’s digital transformation plans.

    And yet, 67 percent of businesses believe the network is the bottleneck—and with good reason. The current networks that NetOps and SecOps teams manage are highly complex, distributed entities that have historically been configured and provisioned manually—and often, in silos. Yet, as DevOps accelerates ahead at lightning pace, underpinned by the continuous integration, delivery and deployment (CI-CD) approach, NetOps and SecOps teams are scrambling for new ways to gain speed to more quickly launch, scale and secure applications and code updates in production.

    The Need for Speed 

    Enterprises are increasingly leveraging DevOps principles to execute daily deployments into their multicloud test and production environments. For example, Etsy deploys 80 times per day, while Netflix and Amazon deploy up to thousands of times a day. In this new world order, collaboration, communication and synchronization across development, operations, network and security teams is essential.

    This also means that testing of the network and application services infrastructure must happen concurrently with the application development and testing processes—not afterward, which can dramatically slow down the agile CI-CD process. Similarly, security cannot be retrofitted after the development and test phases are complete. A recent study by Puppet Labs found that high-performing teams spend 50 percent less time remediating security issues when security is addressed at every stage of the software development and delivery cycle.

    New CI-CD Tools Deliver on the Promise of DevOps  

    New innovations in virtualization and programmability of network and application service infrastructure are making it possible to test policies and configurations prior to production—even in highly complex environments. Powered by validated templates and APIs, these network orchestration and application services tools help automate task execution for scale, preserve provisioning and configuration policies for consistency and bolster security, while dramatically reducing management time cycles and the risk of human error. They empower NetOps and SecOps teams to leverage DevOps principles and apply them to network and security during the development, deployment and delivery of multi-cloud apps and code updates.

    Similarly to how software-defined components such as servers and storage are provisioned, network orchestration tools leverage a software-defined infrastructure (SDI) approach to rapidly provision network services across multiple network devices. These tools support flexible application provisioning across physical and virtual environments, help identify and address issues quickly and improve overall network performance. In the CI-CD model, network orchestration helps NetOps and SecOps teams ensure that all production-critical application and network elements—such as availability, core network services, security services and performance—are accounted for and are rolled out in proper sequence and at scale.

    Application services automation focuses on application availability, performance, and security. While automation used to focus solely on simple load balancing, it now also includes a range of solutions that help network teams configure and automate application services during the test phase. These include web app and network firewalling, DDOS protection, application acceleration, WAN optimization, DNS services and TCP optimization, among others. In the dev and test phases of the CI-CD process, automation allows for faster configuration and deployment of network settings and policies. Similarly, in the production phase, automation significantly speeds up and simplifies areas such as policy adjustment and other time-intensive processes by eliminating the need to reconfigure underlying infrastructure. This means that ticket resolution and necessary changes can be completed in a matter of minutes versus weeks. At the time of rollout, application services automation toolsets also help to ensure the infrastructure is ready to perform at peak levels.

    Network and application services automation innovations—the critical missing pieces in the continuous deployment puzzle—work together to ensure the entire DevOps team—including network and security—can deliver and deploy applications with the speed, reliability and security necessary to meet today’s business challenges.

    About the Co-Author / Ranga Rao

    Ranga Rao is Director of Product Management & Solutions Engineering at Cisco Systems, where he leads a team of product managers, architects/TMEs and software engineers to collaborate with partners to define use cases and build software integrations for leading Cisco solutions including Cisco ACI, Nexus 9000 and Tetration Analytics. Ranga earned an M.S. in Computer Science at Stanford after receiving his B.E. from the National Institute of Technology Karnataka. Ranga is also an author of a popular book, Programmability and Automation with Cisco Open NX-OS, published by Cisco.

    — Lori MacVittie

  • 8 Advantages of Using MySQL

    8 Advantages of Using MySQL

    MySQL is a free-to-use, open-source database that facilitates effective management of databases by connecting them to the software. It is a stable, reliable and powerful solution with advanced features including:

    1. Data Security

    MySQL is globally renowned for being the most secure and reliable database management system used in popular web applications including WordPress, Drupal, Joomla, Facebook and Twitter. The data security and support for transactional processing that accompany the recent version of MySQL can greatly benefit any business, especially if it is an eCommerce business that involves frequent money transfers.

    1. On-Demand Scalability

    MySQL offers unmatched scalability to facilitate the management of deeply embedded apps using a smaller footprint, even in massive warehouses that stack terabytes of data. On-demand flexibility is the star feature of MySQL. This open-source solution allows complete customization to eCommerce businesses with unique database server requirements.

    1. High Performance

    MySQL features a distinct storage-engine framework that facilitates system administrators to configure the MySQL database server for a flawless performance. Whether it is an eCommerce website that receives a million queries every single day or a high-speed transactional processing system, MySQL is designed to meet even the most demanding applications while ensuring optimum speed, full-text indexes and unique memory caches for enhanced performance.

    1. Round-the-Clock Uptime

    MySQL comes with the assurance of 24×7 uptime and offers a wide range of high-availability solutions, including specialized cluster servers and master/slave replication configurations.

    1. Comprehensive Transactional Support

    MySQL tops the list of robust transactional database engines available on the market. With features such as complete atomic, consistent, isolated, durable transaction support; multi-version transaction support; and unrestricted row-level locking, it is the go-to solution for full data integrity. It guarantees instant deadlock identification through server-enforced referential integrity.

    1. Complete Workflow Control

    With an average download and installation time of less than 30 minutes, MySQL means usability from day one. Whether your platform is Linux, Microsoft, Macintosh or UNIX, MySQL is a comprehensive solution with self-management features that automate everything from space expansion and configuration to data design and database administration.

    1. Reduced Total Cost of Ownership

    By migrating current database apps to MySQL, enterprises enjoy significant cost savings on new projects. The dependability and ease of management can save troubleshooting time that is otherwise wasted in fixing downtime issues and performance problems.

    1. The Flexibility of Open Source

    All the fears and worries that arise in an open-source solution can be brought to an end with MySQL’s round-the-clock support and enterprise indemnification. The secure processing and trusted software of MySQL combine to provide effective transactions for large-volume projects. It makes maintenance, debugging and upgrades fast and easy while enhancing the end-user experience.

    About the Author / Michelle McLean

    Michelle McLean is VP of Marketing at ScaleArc, responsible for overseeing all of the company’s marketing strategy and initiatives. She has more than 20 years of networking and market positioning experience. Prior to ScaleArc, she held director of product marketing positions at Silver Spring Networks, ConSentry Networks, Peribit Networks and Trapeze Networks, and prior to that, she was director of strategic marketing at Pluris. She previously served as program director at the research firm META Group, providing technology and strategy direction to global 2000 enterprise clients. Before that, she tracked technical developments, networking trends and vendor strategies as a journalist for two leading networking publications, LAN Times and LAN Magazine. Michelle earned her BA in English from the University of California at Berkeley. Connect with her on Twitter.