devopsy.kinsta.cloud

Tag: devops

  • How Artificial Intelligence, Machine Learning Can Help DevOps

    How Artificial Intelligence, Machine Learning Can Help DevOps

    Artificial intelligence (AI) and machine learning (ML) can help the humans in DevOps break free from focusing on simple activities. One aspect of DevOps is automating routine and repeatable actions, and AI and ML can perform these activities with enhanced efficiency to improve the performance of teams and business. There are algorithms that can perform many operations and procedures, allowing those in DevOps to execute their part effectively. This article discusses how DevOps engineers can use AI and ML to their benefit.

    Artificial Intelligence, Machine Learning Driving DevOps Evolution

    Businesses are under a lot of pressure to meet customers’ ever-changing demands, and many embrace DevOps to improve their performance to some extent. However, it can be difficult for many companies to use AI and ML because of the complexity involved. To recognize any benefit with AI and DevOps, a creative mindset may be required.

    The adoption curve of AI/ML may be relatively slow. Only 27 percent of CIOs surveyed by ServiceNow for its report, “The Global Point of View,” have hired employed who have skills in machine learning. But the fact is, DevOps experts may have a lot to gain by adopting even the most basic features of AI and ML. The same survey found that around 85 percent of C-level executives believe AI/ML can offer substantial value in terms of accuracy and rapidity of decision-making, which will lead to improved profitability for the company.

    Tracking and organization in a DevOps environment requires effort because of the complexity involved in the distributed application, which traditionally made things difficult for the team to manage and resolve customer issues. Before the evolution of AI and ML, DevOps team members could spend hundreds of hours and a large amount of resources to identify one point within an exabyte of information. To solve such problems, the future of DevOps is AI-driven, helping to manage the immense capacity of data and computation in day-to-day operations. AI has the potential to become the primary tool for assessing, computing and decision-making procedures in DevOps.

    AI’s Influence on DevOps

    AI can change how DevOps teams develop, deliver, deploy and organize applications to improve the performance and perform the business operations of DevOps. There are three common ways through which AI may influence DevOps:

    Enhanced Data Accessibility

    The lack of unregulated accessibility to data is a critical concern for DevOps teams, which AI can address by releasing data from its formal storage—necessary for big data implementations. AI can collect data from multiple sources and prepare it for reliable and robust evaluation.

    Greater Implementation Efficacy

    AI contributes to self-governed systems, which allows teams to transition from a rules-based human management system. This helps address the complexity of assessing human agents to improve efficacy.

    Effective Resources Use

    AI gives much required competence to automate routine and repeatable tasks, which minimizes the complexity of managing resources to some extent.

    How Can Companies Apply AI and ML to Optimize DevOps?

    Organizations can apply AI and ML to greatly optimize their DevOps environment. For one, AI can help in managing complex data pipelines and create models that can feed data into app the app development process. By 2020, it’s expected AI and ML will take the lead in digital transformation, overtaking IoT.

    However, implementing AI and ML for DevOps also presents a number of challenges for organizations of all sizes. To benefit from AI and ML technologies, a customized DevOps stack is required.

    Open source projects such as the Fabric for Deep Learning (FfDL) and Model Asset eXchange (MAX) can lower the barrier of entry for companies, helping to implement machine learning and making the DevOps process more efficient.

    Application of AI and ML can result in true ROI for a company by optimizing DevOps operations, making IT operations more responsive. They can improve efficiency as well as productivity of the team and play an important role in filling the gap between humans and big data.

    Conclusion

    A company that wants to automate the DevOps have to decide whether to buy or build a custom AI/ML layer. However, the first step is to establish a strong DevOps infrastructure. Once the foundation is created, AI/ML can be applied for increased efficiency. AI/ML can help DevOps teams focus on creativity and innovation by eliminating inefficiencies across the operational life cycle, enabling teams to manage the amount, speed and variability of data. This, in turn, can result in automated enhancement and an increase in DevOps team’s efficiency.

    — Subramonian

  • 7 Signs You’re Mastering Continuous Integration

    7 Signs You’re Mastering Continuous Integration

    A majority of organizations think they are doing continuous integration (CI), yet when asked if they are following key practices of CI such as running tests to validate every build, many of them aren’t. Ask yourself the following: “Are we building our application with every change, or at least multiple times a day? Do we avoid long running feature branches? Do we prioritize fixing broken builds over committing new changes?” If your answer to any of these questions is “No,” then guess what? You are not truly doing CI—and you’re not alone.

    Continuous delivery (CD), a foundation of DevOps, is built on the practices of continuous integration. Accordingly, you have to implement CI properly before you can truly achieve success with CD and DevOps. In other words, you have to crawl before you walk.

    Steps to Mastering Continuous Integration

    To reach business goals, here are the seven practices organizations must do to master CI:

    Automate the Build—the Entire Build—on a Central Server

    This seems like an obvious one—and it is. Sure, prior to implementing continuous integration, organizations either build locally on a developer’s desktop, have a build engineer manually integrate code or have to work through a series of fragile, manual steps that are prone to error. But, surprisingly, many organizations that claim to practice CI still get this one wrong.

    Simply put, your continuous integration build should run a central shared server, be able to run completely unattended and be automated such that the same input will produce the same, same output every time.

    Build as Frequently as Possible

    Teams practicing CI build multiple times per day, ideally triggering the build per change on a pull request, merge or commit. Building per commit enables errors to be found as soon as they are introduced and are more easily fixed.

    The word “continuous” in continuous integration should be taken as literally as possible. Often times when I ask organizations how frequently they build, the answer is one of the following:

    1. We do “push-button” builds, X times per-week
    2. We build both every night, and once per week
    3. We build once per-day at X time

    As you have likely deduced, these are not “continuous” builds. They may be central builds, automated builds or scheduled builds. But those don’t provide the benefit of continuous integration. If a build breaks and you have two days of 30 commits by 10 different developers, you may have to sort through all of that work to figure out and correct the cause of the build. Productivity killed.

    Commit or Merge to Mainline Frequently

    Teams doing CI are likely committing/merging to trunk or main with every change or at least once a day.  If you are maintaining long-running feature branches, for instance, you are not getting the benefit of validating integrated changes frequently. If you branch for a long period, when it is merged, the integration has been delayed and you may be left with conflicts or bugs to fix.

    Build Quickly

    If you are practicing continuous integration, your build likely completes within 5-10 minutes.  If builds take longer (some organizations have five-hour-plus CI builds), not only are you delaying integration and, therefore, valuable feedback, but developers are less likely to commit changes because of the cost to their productivity—or, even worse, they continue to commit against broken code.

    Take time to optimize your build and validation time. This may require you to decompose your CI build process to align with components or teams and then validate the entire integrated application as a separate step in the overall development process.

    Validate the Build

    CI includes validating the changes and resulting built. This kind of testing should be a part of the overall build process. If your only validation is based solely on confirming the software compiles and links, then you are not truly practicing CI. Most teams practicing CI include code scans and unit tests in the CI build.

    Validate in a Production-like Environment

    Mature CI practitioners ensure consistency between the dev, test and pre-production environments. The most mature are using VMs or containers, service virtualization and other techniques to ensure they are performing validation in a production-like environment and reducing the risk of discovering errors downstream in pre-production or production, well after changes were integrated.

    Fix Broken Builds Immediately

    As mentioned, it’s critical that teams find and fix issues quickly so that they don’t move downstream. With CI, processes are set up where builds are validated and committed continuously, so if something is problematic, it’s easier to fix. If broken builds are ignored, the issue will be more difficult to find and fix, but worse is the culture it encourages. CI is based on a quality-first approach. If the build breaks,“Stop the line” and fix the build. Everybody will be better for it in the long run.

    Don’t Forget About Culture

    If an organization can look at these seven signs and say it does all of these things, then it is really doing CI. These may seem simple, but when these principles are combined, the outcome is remarkable.

    Organizations that can’t say they follow each of these principles likely will have problems delivering functional builds regularly. The initiative will fail and team members will become frustrated and revert back to their old ways. Not only will there be a process issue, but also a cultural issue—and this is where many organizations get stuck.

    Teams must change how they work together and they must also make sure they are aligned in their mindset. CI has many benefits for organizations, but don’t forget that it’s actually designed to embrace failure, not eliminate it. Continuous integration creates a system where developers can fail fast, so they can find and fix errors early and quickly.

    Continuous integration is one of the foundational elements to a real DevOps transformation, which everyone knows is a top priority for many businesses today. Getting it right—truly getting it right—is essential to keeping up with modern business needs.

    — Brian Dawson

  • When It Comes to Mainframe Computing, There’s More to Containers Than Containers

    When It Comes to Mainframe Computing, There’s More to Containers Than Containers

    When people in the DevOps world hear the word “containers,” most of the time they imagine the lightweight, standalone, executable Docker binaries that have become commonplace in today’s cloud infrastructure. It might come as a surprise, however, that the world of mainframe computing not only supports traditional Docker containers, but also expands the concepts of isolation and safety into another type of containerization technology called IBM Secure Service Container. For companies running Linux on an IBM Z, Secure Service Container brings a new dimension of security to mainframe computing.

    Mainframe computing already offers a lot of power that is difficult to match in a commodity x86 environment. For example, the IBM z14 mainframe can store up to 32TB of memory. It has a 10-core z14 CPU that can run at speeds up to 5.2 GHz, which is considerably faster than the ~4 GHz of a 4-core Intel i9 processor. With this power, the mainframe can perform 30 billion RESTful transactions a day running Node.js and MongoDB in standard Docker containers. Mix in the versatility and code reuse that running Linux on a mainframe provides, and you get a level of computing power that’s hard to ignore.

    In terms of application development, putting Linux on a mainframe allows applications written in popular languages such as Java, Python or Node.JS to run on an IBM Z system just as they would in a data center full of x86 machines. And the total cost of ownership of a mainframe can be surprisingly  competitive when compared to a commodity system.

    Despite these  benefits, Linux on a mainframe faces many of the same security challenges that other platforms have, both in terms of hardware and software intrusion. The difference is that IBM Z is more secure out of the box and offers a number of additional technologies to address these challenges—100 percent application data encryption, isolated workloads for multi-tenant environments, full lifecycle encryption key management with encrypted keys and tamper-responding cryptographic hardware. But many times, safety boils down the security acumen of the system administrator and the overall security discipline instilled within an organization. Some organizations have excellent security practices. Others are challenged. Regardless of the degree of competency, it is difficult  to lock up a box in a bulletproof manner. This is where Secure Service Container technology comes in to play.

    Working with Secure Service Container

    Secure Service Container combines hardware virtualization, applications and data into a secure, encrypted “container” (partition). The encryption keys are protected in the Secure Service Container partition. Should a key become compromised or attempts are made to tamper with the keys, the Secure Service Container will invalidate the key and the encrypted contents will become inaccessible.

    Once the Secure Service Container is deployed (via the physically secure hardware and firmware), everything inside it is fully encrypted. The boot sector becomes tamper-proof and memory access is disabled. Also, access to the system via SSH is also removed. As a result, hardware and operating system SysAdmins have no direct way to tamper with the environment beyond RESTful interfaces for communication and management.

    Using SSH to administer a system leaves a lot of opportunity for catastrophe: While Linux allows you to limit access to commands according to group and user permissions, just one unsecured executable mistakenly installed in the environment can cause a mishap.

    On the other hand, the only way to access an Secure Service Container-enabled environment is via a set of APIs. Each piece of administrative functionality associated with the Secure Service Container API is represented as an endpoint with an access method. Thus, the advantage of secure access via an API is that work is done over a common interface on a task-by-task basis. A distinct security policy can be applied to each endpoint and associated access method. This is a very fine-grained security model.

    Using an “API only” approach for access means that for all intents and purposes, the system is completely locked down. Even root users and SysAdmins are denied access that is not granted according to the security policy on the given endpoint. Thus, “Snowden-type” attacks are prevented.

    The HSM—the physical device that encrypts and protects keys—is certified to FIPS 140-2 Level 4, which is the highest security standard defined in the Federal Information Processing Standard. Also, the individual Secure Service Containers are isolated to EAL5 and higher levels, giving you near-air gap isolation between containers to ensure that side-channel attacks won’t work. This is industrial-strength security that is designed to meet the needs of extremely security sensitive environments such as banks, power grids, the Atomic Energy Commission and the CIA. Secure Service Container is serious technology for serious enterprises. However, Secure Service Container can benefit any company that wants to dive  into the world of mainframe computing, the costs of which can be surprisingly affordable.

    A New Way of Thinking

    When most people think about mainframe computing, they think of large companies with big budgets to spend on high-priced  hardware. While this might have been the case in the past, today mainframe technology is well within the grasp of smaller companies. Today’s mainframes can be as much as 92 percent lower for total cost of information compared to their x86 competitors. And when you take into account the added agility, scale and security, setting up an on-premises cloud installation using an IBM mainframe as opposed to a rack of x86 machines seems very reasonable.

    The mainframe offers significant benefits besides cost, particularly when Secure Service Container technology gets added to the mix. To start with, running Linux on a mainframe creates a common playing field in terms of application development. Most Linux-based application code can run on a mainframe as well as on a PC. This means that a single Java developer can leverage his or her expertise to write for a variety of environments—PC, Android or mainframe.

    Security Risks by the Numbers

    ●      Cybercrime damages will cost the world $6 trillion by 2021

    ●      The average cost of a data breach in 2017 was $3.6M

    ●      60% of the victims of victims of cyber attacks run the risk of being put out of business

    ●      Every 14 seconds a business will fall victim to a ransomware attack

    ●      Only ⅓ of enterprises are security testing containers intended for production

    The mainframe also offers very large storage, incredibly high computing capability and a unified environment. Both applications and database can live within the same box, diminishing network latency and increasing overall processing speed.

    Secure Service Container technology make security both robust and easier to manage. The “API only” access approach to system administration makes support a secure, standardized undertaking. From a DevOps perspective, the standardization provided by the “API only” approach is easy to automate and you avoid having to accommodate the peculiarities that go with system administration at a lower level of operation.

    Finally, as mentioned above, Linux on IBM Z supports Docker. Integrating mainframe resources with the Docker ecosystem enables high-powered, high-volume, ephemeral computing within a single machine installation. A single Linux on IBM Z installation can support up to 1 million Docker containers. And, because these containers reside on the same machine, they can take advantage of co-location with other mainframe workloads and minimize the impacts of external network latency. As anybody who has worked with a distributed architecture can tell you, a containerized microservice is only as good as its availability. Putting all containers on a single computer reduces the risk of interservice communication failure significantly. This is a very big deal—especially considering the 99.999 percent uptime of IBM Z.

    Putting It All Together

    Containers are fast becoming the foundation of modern cloud computing. There’s more to  containerization however, than creating instances of Docker images. The concepts behind containerization have broad application well beyond commodity based computing. Secure Service Container combines the best practices intrinsic to both hardware and software security to create a Linux-based environment that makes mainframe technology a first-class player in the world of modern cloud computing.

    Given the decreasing costs and increasing benefits of technologies such as IBM Z and Secure Service Containers, mainframe computing can become a significant asset to any company. All that’s really required is taking the time to understand the power available and explore the possibilities at hand.

    Learning More

    You can learn about about Linux on IBM and Secure Service Container at the following resources:

    — Bob Reselman

  • DevOps in the Age of Blockchain

    DevOps in the Age of Blockchain

    The current state of software development results in a lot of redundant efforts. The same functionality is built repeatedly, which is a waste of time and resources for a company. Open source has been a partial solution, but doesn’t fully solve the problem of reliable code upgrades, which are critical for sustaining a high speed of innovation. This especially acute in decentralized networks, where new releases must be pushed to potentially thousands of independent nodes. While blockchain has become one of the biggest buzzwords of 2018, it’s important to explore how this technology will apply to developers’ workflow in the coming years.

    The DevOps culture has been making inroads to fixing this central issue by streamlining and automating the delivery processes. By taking ownership of all levels of the development cycle—increased release frequency, construction, testing, integration—software developers have been better able to keep up with business objectives.

    From a business perspective, the principles inherent in DevOps are great, but they are only the first step. While automation and continuous integration has helped speed up the development process, utilizing blockchain technology can become one way to help make the process both instantaneous and transparent.

    Upgrading Contracts

    A major distinction between a DevOps team in its current iteration and blockchain-era continuous integration is smart contract upgradability. A traditional software-as-a-service (SaaS) company has full control over versions of software it publishes to its servers. In distributed blockchain-based networks, upgrading smart contract code is not that trivial and often is not even supported natively (e.g. in Ethereum).

    Distributed governance is still in the early days, and since every upgrade to smart contracts has to go through the governing procedures it is difficult to come up with a single solution addressing most models. This leads to manual error-prone implementations of smart contract migrations that can cause bugs, financial losses and even inability to make further upgrades. Standards and tools are yet to emerge in this arena.

    That said, it is easy to see how blockchain-based code migrations adds transparency and accountability comparing to centralized systems, where a single entity has full control over the application logic and can alter it at any time without regard for consumer interests. Use of the blockchain in this case is not meant to take over a DevOps team, but rather to integrate with the work of the team and make the process more transparent to all parties involved.

    Supporting Developers

    Not all developers currently have the skill set to create on the blockchain. But this is an issue of interest in protocol-level details, and time. Instead of expecting developers to learn every line of code and configuration used in blockchain applications, we need tools for common use cases in enterprise software so that developers aren’t reinventing the wheel every time. Again, this speaks to the complementary nature of blockchain technologies to DevOps. We want to create a suite of tools to make the DevOps experience even more effortless.

    In the emerging age of blockchain, DevOps still contributes the best practices needed in getting software released. By adding blockchain applications and tools to the development cycle of DevOps teams, DevOps will reach new heights of productivity.

    — Andrei Anisimov

  • Connectivity as Code: Making Network Security DevOps-Friendly

    Connectivity as Code: Making Network Security DevOps-Friendly

    DevOps is all about agility, with fast, short delivery cycles and automation for software development and applications. Enabled by recently introduced technologies such as virtualization, cloud and software-defined networking (SDN), spinning up new servers, provisioning storage in a public or private cloud or even launching whole environments can take just minutes or even seconds. But if that new application, service or environment needs a change in network connectivity or firewall rules to enable it to work, then the pace of delivery can often slow to a crawl.

    Unlike the typical DevOps scenario, in which developers create a CI/CD pipeline that includes running build processes and tests and delivering the new application completely automatically, provisioning new network connectivity usually involves a slow, laborious process. The application developer needs to manually open a change request and then wait for approvals and implementation of the new connectivity flow before proceeding with the DevOps flow.

    The Application Development Security Disconnect

    As part of this, the developer is usually required to provide information about firewalls, zones, subnets and other information related to the underlying network infrastructure in these change requests—information that is not always known or clear to the application developer. On the other hand, the application requirements and context are not always understood by the network security team assigned to implement the changes. This can result in back-and-forth communication between the developer and network security, making the entire process extremely long, error-prone, inefficient and frustrating to both teams.

    The challenge here is building in the necessary checks and balances to ensure that DevOps processes are not rapidly introducing security problems, while equally ensuring that security is not stepping on the brakes and slowing down the organization’s agility. So, how can this be achieved?

    The Solution: Connectivity as Code

    The answer is connectivity as code, a methodology that supports not only automation and agility in the application delivery process but also bridges the gap between application developers and network security teams on an ongoing basis, even after the application is deployed into production.

    Connectivity as code creates an abstraction layer that translates between the two worlds, giving application developers more control over their applications while helping network security understand the business impact of their day-to-day tasks, and thus ensuring business continuity.

    Establishing Connectivity Requirements

    In the first stage of this approach, the application developer describes the application connectivity requirements in a simple machine-readable text file, listing all the logical flows that represent these requirements, including those for the different application environments (e.g. test, development, production, etc.). It is presented as a list of abstract flows that typically include the source (who initiates the connection), destination (who accepts the connection), service and additional information.

    There is no need to know where the servers are located or what the underlying network topology is—such as whether there is a firewall between them or cloud security controls—or even their IP addresses or subnets. Furthermore, there also is no need to know whether connectivity is already available, because it’s also required by other applications.

    The Connectivity Phase

    Once this list is created, a new phase in the DevOps process, the connectivity phase, will automatically take care of things with no further involvement required from the application developer. The connectivity phase is where the actual connectivity provisioning and validation happens, leveraging a network security policy management (NSPM) solution to automate the network connectivity provisioning as part of the DevOps process just like any other configuration or provisioning step in the DevOps pipeline.

    The NSPM solution will read the file before automatically checking whether the connectivity requirements have changed. If no changes were made, the solution will verify that the required connectivity remains in place, and that the application will work correctly. This provides the application developer with the assurance that the necessary connectivity is in place and connectivity-related failures are not anticipated when moving into production.

    Automating Connectivity Changes

    If the connectivity requirements have changed, the NSPM solution will use the connectivity file to provision the required connectivity while retaining it for future reference, so that the application’s connectivity remains intact in the event of future network architecture changes or application or server migrations.

    If one or more of the required flows is currently blocked, a security policy change request process is triggered. Through this process a NSPM will verify that the new flows comply with the organization’s preapproved security policy, as well as security best practices and industry regulations, and will then design and implement the required changes directly on the different security devices on the network, automatically and within minutes.

    If, however, a change request is non-compliant, it will be escalated for approval and, once approved, it will be implemented automatically, thereby saving the developer the need to manually open an out-of-band change request.

    Furthermore, whenever a new version of the application is developed, this list of connectivity requirements is updated by the developer and the connectivity phase will ensure that the new flows are provisioned. With the connectivity phase completed, the DevOps process can securely proceed onto the next phase.

    The Benefits of Connectivity as Code

    Introducing the connectivity-as-code methodology into the DevOps process achieves a range of benefits. These include:

    • Seamless management of network connectivity: This makes DevOps process far faster and more agile, and enables problem-free application delivery, rather than as an external out-of-band issue that requires separate—and manual—handling.
    • Continuous compliance and auditability: Throughout the application delivery process organizations will remain fully compliant with all relevant guidelines, while all changes are fully logged for auditing purposes.
    • Business continuity: Application connectivity requirements are clearly documented and up to date, ensuring minimal disruption to the business even during network, infrastructure or architecture changes.

    Ultimately, connectivity as code bridges the gap between application developers and network security throughout the entire application life cycle, from planning and development through to deployment, production and decommissioning.  It ensures both developer and security teams get what they want: Dev teams don’t have to worry about security slowing them down, and security teams know that risk and compliance checks have been built in to the continuous delivery process, complete with a full audit trail of changes. By weaving network connectivity into the DevOps process, organizations can ensure fast delivery without any compromise in security or compliance.

    — Anner Kushnir

  • Why Digital Transformation Can’t Happen without Experimentation

    Why Digital Transformation Can’t Happen without Experimentation

    A sure sign of a company’s successful digital transformation is when it can leverage data to optimize every area within the enterprise. As Forrester puts it, for a company to realize the return on investment (ROI) of a digital investment, “benefits from digital investments need to be aligned with the business requirements for a specific value chain stage.” All along, data-driven insights need to be tied to measurable gains and real-world business key performance indicators (KPIs).

    The reality, however, is that data-centric principles are easier to apply in some areas of the business than others. The ethos has certainly taken hold in the development world—with its whole culture around DevOps, continuous delivery (CD), continuous integration (CI) and related agile methodologies that emphasize constant, data-driven experimentation and frequent reassessment and adaptation of plans.

    Unfortunately, too many companies drop the innovative mindset once things progress to production and customer rollout phases. In doing so, they fail to spread the ROI from digital investments more fully across the organization. In other words, they fail to mount a genuine digital transformation.

    True digital transformation requires companies apply a stronger, more agile approach to product adjustments across the value chain. Nowhere is this more critical than the need to embrace “full-stack experimentation” to realize business value from the world of data-based product development and testing.

    The Limits of A/B Testing

    Especially in an era when the customer experience sits at the center of the value proposition for most industries, the ability to fine-tune everything about how we bring products and services to market—and how our customers use and feel about those products and services—is mission-critical, especially in the quest for true digital transformation.

    Unfortunately, no matter how agile and data-driven the development phase may initially be, we lose visibility, insight and, most importantly, revenue whenever we fail to infuse those same values into the later stages of production, QA and analysis around how customers are actually using what they buy.

    Perhaps the biggest sign of this is the over-reliance of marketing teams on signals from basic A/B testing.

    Industrywide, A/B testing is the most common approach to experimentation, but it’s far from ideal. A/B testing is typically used by marketing teams to test front-end changes at the user interface-level. It’s limited in its efficacy, as it does not take into consideration the deeper statistical nuances and resultant effects across the application stack—for instance, swapping out code to roll out an entirely new feature to a small set of users and measuring the results of that single deployment across both business and system metrics.

    Worse yet is the false sense of security that can come from the narrow scope of A/B testing. Any outcome can be easily misunderstood as the only improvement possible. That leaves countless other variables and opportunities for ROI unexamined. If Plato remarked, “The unexamined life is not worth living,” what does that say about the unexamined product development process? How do we know if it’s worth building?

    A Better Way

    While A/B testing is still appropriate for some limited uses, leading-edge companies are learning to expand inquiry across the “full stack” of their applications. Full-stack experimentation differs from traditional A/B testing in scope, purpose and the potential impact on a business. It examines not just user interfaces but also execution logic, technical services, APIs and the data infrastructure underlying it all. This fosters a market-driven approach that brings more insight and less guesswork to decision-making.

    To be clear, full-stack experimentation does not optimize part of a product or feature; it is about optimizing the process around experimentation and allowing development to more directly support and inform the evolution of the business. In this way, full-stack experimentation helps gain deeper value from the organization’s use of agile, DevOps and CI/CD so we can garner critical insights into how a product or feature is actually used by customers. More importantly, it measures the impact of every release on important key business metrics—which may be radically different from the developer’s intent.

    Full-stack experimentation unlocks value across the entire data ecosystem. It involves collaboration among the key stakeholders involved in the development of a product or application, from engineers to product managers, as opposed to primarily marketers. You can use full-stack experimentation to answer deeper questions and test deeper assumptions. For instance, does adding the ability to tag friends in a photo increase their likelihood of posting photos in the future? Does this result in more sessions per user and does that ultimately impact the ad revenue generated per user?

    Delivering Digital Transformation to More Companies

    The benefits of full-stack experimentation are well-known among organizations with the resources to build and manage this in-house. Microsoft, Etsy and Netflix, for instance, test everything from multiple angles, sometimes running 50 tests a day or more on a single feature. These companies have powerful instrumentation to capture and analyze the multitude of variables and metrics—including those that may have been unanticipated. This surfaces valuable insights to be quickly spotted and harnessed for value.

    Fortunately, modern software-as-a-service (SaaS) solutions are increasingly saving companies from having to create their own in-house, custom-built systems to get the benefits of full-stack experimentation. Unified platforms now exist that help engineering and product teams accelerate the pace of product delivery and make data-driven decisions without investing valuable development resources to build the tools themselves. Critically, these platforms have robust feature flagging and extensive experimentation capabilities that allow testing to happen well into production and rollout to customers—with strategic and incremental tests to examine and adjust logic, APIs, UX or other elements across the entire application ecosystem.

    On a tactical level, these new platforms make experimentation processes simpler and more accessible to more companies. But the bigger picture is that these new options for full-stack experimentation effectively remove the friction that exists in achieving true digital transformation—allowing more companies to completely revolutionize how they do business.

    — Kavitha Mariappan

  • SDN/NFV DevOps: Release Automation for Network Operators

    SDN/NFV DevOps: Release Automation for Network Operators

     A powerful force is waiting to be unleashed. Software defined networking (SDN) and network functions virtualization (NFV) are already acknowledged as exciting possibilities in the world of telecom and media. Leading providers, such as Verizon Enterprise Solutions and My Republic, along with original equipment manufacturers including Cisco Systems and Ericsson, have unveiled their SDN-based services.

    In the near future, all physical devices in the network will undoubtedly be replaced by SDN/NFV. Analysts predicted millions of additional devices on network because of the internet of things (IoT) and smart home intelligent devices, which necessitates the need to automate release and deployment on the networking layer to deploy components and upgrade patches to both the southbound network components and northbound applications. So far, release and deployment is successful on the application layer, but network administrators will be challenged in the near future to manage the surge in demand without a seamless automation solution to manage new devices on the network.

    In this article, we’ll take a look at various real-life scenarios to build a business case to solve bigger problems in networking—including reducing overall provisioning time, mean time to recover from failure, round-trip time for a packet to enable a usable application or time to free up/repurpose a network resource—that apply to all edge technologies. The solution lies in leveraging DevOps container-based solutions and scaled agile and SDN/NFV controller engine module customizations, and a non-prescriptive approach to products or solutions.

    These technologies are the new beasts in the market, but how can SDN go beyond merely saving money for telecom and media companies? How can it provide an enhanced, immersive digital experience, reduce customer churn rate and create new revenue streams? That is where DevOps steps in.

    The DevOps Approach to SDN

    With mobile, cloud, and IoT creating futuristic applications, consumers require strong underlying network speed and reliability.

    The DevOps solution to SDN/NFV is an ideal means for network operators to transition seamlessly from physical networks to futuristic SDN/NFV networks, to provide uninterrupted digital experiences for users, and to achieve high customer retention. DevOps enables a close collaboration between developer and network operators to eliminate many of the pains of introducing new software and services to market. Similar to the system development life cycle, the automated release and deployment process of DevOps enables frequent and incremental updates of network components in near-real time.

    The symbiotic relationship between SDN/NFV and DevOps is a dream. The software-defined and virtualized network elements remove the hassles of configuring and upgrading the physical networks’ devices. DevOps adds to this agility and programmability to streamline and shorten the implementation cycles, paving the way for automated service delivery. In turn, SDN and NFV create an elastic network environment, managed from a central location, to program and rapidly deploy new functionality on the network.

    Service providers can drastically reduce the time it takes to create and provision those network services, gaining a significant time-to-market advantage that helps them acquire new customers and retain existing ones. In the process, they can achieve higher revenues and cost savings, too.

    Creating New Dimensions in the Customer Experience

    Tech support has moved from phone to video, but before long, a centralized monitoring system will be able to auto detect and self-heal all issues related to virtual assets on the network. This will provide a more continuous experience for customers. For example, in case of any unexpected service interruption, TV channel providers’ AI-enabled systems will be able to record live programs and play back those interrupted periods to their viewers.

    Deploying a vendor-agnostic reliable SDN is a wait-and-watch situation for TV channel operators and telcos. Replacing their physical devices (including the conventional routers and switches) with software-enabled virtual devices will bring down printed circuit board (PCB) replacement costs and other associated maintenance fees. As reliable network bandwidth becomes all the more critical to improving channels’ television rating points (TRP), telecom carriers and TV channel operators are converging.

    Digital operators looking beyond TV and telcos anticipate millions of smart home appliances (such as security systems, microwaves, refrigerators and temperature control devices) controlled through the network by users from any remote location. Network administrators want to apply patches and upgrades to any SDN/NFV device, and to proactively fix any network-related issues without bothering their customers. Consumers may be controlling those home appliances from connected cars using mobile devices, so they may not be available physically to read glowing and blinking lights or to reset undecipherable, hard-to-access conventional modems and routers. Network providers are expected to manage millions of devices and provide uninterrupted service, so this paradigm shift, aided by technology transformation, has become imperative not only to reduce the call volumes of help desks but also to retain customers and acquire new ones. 

    Future-proofing for Technology Shifts    

    It is important to realize that telco carriers and TV channel operators are no longer merely confined to the communication and entertainment industry. With their scope vastly expanding into managing and controlling millions of household devices on their networks, it is imperative to future-proof technology with automated release-and-deployment processes over the network to support those devices.

    Some of the latest DevOps zero-touch release automation (RA) solutions can reduce the overall service provisioning time from months to a few hours. The scope is not just limited to configuring the southbound virtual software devices but may also be required to configure and manage northbound SDN/NFV applications to fulfill the ever-growing market. Having a graphical user interface (GUI)-based orchestration dashboard for network management can enable existing admins to continue without needing to acquire additional, niche skill sets to manage the new, massive networks.

    While release automation has been successful on the application layer, it has yet to prove itself on the networking layer. For SDN/NFV, release automation is just an engine that can be fitted into any controller to do virtual local area network provisioning, virtual management of firewalls and network functionalities management. Since there will be a shift from physical devices, there will be a desperate need to automate release and deployment of software versions on such networks.

    Adopting a DevOps strategy into SDN deployment requires a cultural shift from the traditional “big-lab,” acceptance-testing mindset to the “here-and-now” daily incremental changes in a live network. It calls for engineers to collaborate in managing the critical network-applications relationships. Consulting skillsets might be needed to assess the extent of customization required for legacy systems and to understand which technology solutions can deploy SDN, NFV and DevOps.

    It is clear that this industry will undergo a paradigm shift, and this technology is just crossing the chasm. Early adopters can give themselves an edge by leveraging compelling value propositions.

    — Ramesh Ganapathy

  • Best Practices for Application Security Testing in the Era of DevOps and AI

    Best Practices for Application Security Testing in the Era of DevOps and AI

    Application security testing is no easy feat. And yet, it’s usually the first topic that most articles about application security address. The reasons are simple: As the pace of application development techniques (and their inevitable vulnerabilities) evolve, AppSec personnel have found themselves caught between the desire to keep pace with their management of security testing requirements and their ability to allow the developer teams to operate in the modern, fast-paced ecosystem of DevOps and artificial intelligence.

    To better understand the best practices for conducting AppSec testing in the era of DevOps and AI, it is important to first appreciate the technologies available to us, that allow us to do so.

    At the heart of the modern application security testing,  there are five main technologies to be aware of:

    1. Static application security testing (SAST)
    2. Dynamic application security testing (DAST)
    3. Software composition analysis (SCA), third-party code
    4. Fuzzing
    5. Penetration testing

    These five technologies account for the bulk of most of the activities around application security testing. However, many aspects of application security testing are rapidly changing, including efforts to incorporate automation and artificial intelligence into the equation.

    By including automation or AI, for example, code testing is allowed to be released in rapid fire sequence, with production use approvals baked inline through automated logic and decision-making. This idea of continuous integration/continuous delivery (CI/CD) can lead to a widening of fractures between the security and development teams. Therefore, DevOps users today need the ability to program their code and test it through automated code scanning techniques before pushing the code into secure staging environments.

    To successfully conduct application security testing in today’s era of advancing developer operations through automation and artificial intelligence, there are three critical best practices to keep in mind.

    1. The Earlier, the Better: Introduce appSec testing into the software development life cycle early on for maximum results: Regardless of the type of testing being conducted, waiting until the very end of the development process will only create more work. Users will either end up with more bugs than they could feasibly fix or find themselves a part of an overworked AppSec team as they attempt to document and deliver on discovered vulnerabilities and code flaws. Statistically speaking, code changes that happen later in the development life cycle are also more costly to the business.
    2. Conduct testing of business-critical applications as often as possible: When deciding which assets are next in line for application security testing, one should consider the applications and systems that are of critical business value to the organization’s revenue stream. Think of these systems in particular as the “crown jewels” for the majority of attacker motives, since they define the amount of money a given organization will procure for that day and, if attacked, could disrupt the business in myriad other ways.
    3. Test for third-party code security and interoperability flaws as you would your own software: The growing complexity of modern applications means there is a need to leverage open source or third-party components. As this is the case, these components must also receive the same level of scrutiny as the applications in one’s own enterprise. All third-party code referenced in the software delivery process must also be checked by performing software composition analysis for security and interoperability flaws.

    While the pace and techniques for AppSec testing will undoubtedly continue to advance, and while there are some AppSec testing techniques that may never become obsolete, it is imperative to ensure that one’s system for maintaining application security testing always adheres to the best practices to preserve a secure software environment for the future.

    — Anthony Lauro

  • Reinventing Talent Acquisition, DevOps Style: 7 Ways to Become a ‘Destination Company’

    Reinventing Talent Acquisition, DevOps Style: 7 Ways to Become a ‘Destination Company’

    Just as brilliant drummers have their pick of bands, top cloud-native developers and project managers can be choosy about their employers. They’re the rock stars of the business and they know it. If you’re not a “destination company” like Amazon, Facebook or Google, how do you entice top talent to work for you? And if you’re being wooed, what are the tip-offs that you’ll be valued?

    We’ve been asking ourselves the same questions, and in this article we’ll share an approach that’s working for us. Your company can become more of a destination company in today’s “seller’s market” by applying a DevOps mindset to the way you recruit, hire, onboard and retain talent.

    Begin by Imagining the End State

    DevOps teams define success criteria upfront so that everyone shares the same goals. Knowing the end state when you start is just as important for becoming a destination company. So begin by imagining what your talent acquisition organization would look like if it were the world’s best. (Even if you fall short of our goals, you’ll still be better than before.)

    To help seed your list, here are some of our ideas:

    • Knowing the best places to find people with the right skills—or the right aptitude.
    • Creating a concierge-like experience for candidates from the first contact. The idea is to make them feel welcome, valued and in the loop. More about this later in the paper.
    • Making an offer no more than two weeks after first contact. Talented people don’t stay available for very long. A swift offer gives you a hiring advantage—and sends a message to the person that you value them.
    • Fostering a culture that makes it easy for new hires to integrate into their new team, adopt the DevOps work style and feel connected to your company’s big picture—and want to stay.

    Create a Concierge-like Hiring Experience

    The key is to make the hiring process so welcoming at every step that it sways top candidates to work for you rather than their other suitors. Just as you do when developing software, focus on the experience. For example, since some engineers don’t like social interviews and questions that start, “Tell me about a time …” don’t do it. Instead, test candidates on the job they’ll perform. Ask developers to code so you can measure their speed, aptitude and empathy for users. Ask product managers to design a product that you’ve outlined in vague terms. Assess how well they:

    • Draw out requirements from stakeholders and users.
    • Create a screen flow for the app—a good demonstration of empathy.
    • Describe the architecture at a high level so you can judge whether they understand what’s feasible. The description doesn’t have to be highly technical.
    • Propose release milestones (minimum viable products) that reflect a logical build-measure-learn cycle. For example, MVP 1 might not include a login.

    In our experience, candidates either love this process or hate it. In the latter case, we have a good clue that they wouldn’t have much fun working with us.

    Look beyond skills. Technology is evolving quickly, so a candidate who can figure out the right path may be more valuable than one who knows a trendy programming language. We home in on candidates who can parachute into a situation, contextualize quickly and figure out the right next steps. That takes a combination of speed, aptitude and empathy.

    How can you assess whether a person has empathy? Good question. Our view is that if they have empathy for their teammates, they’ll most likely have empathy for our end users as well.

    Schedule a Pair Day

    A pair day is an awesome way for a candidate to experience how you work. Here’s how we do it: The candidate joins us for morning standup and chooses a team. During the course of the day the candidate pairs with other engineers to deliver real customer value (stories from a backlog). This gives team members an opportunity to assess the candidate’s skills and work style in an actual work setting—and observe whether the candidate is loving it. At the same time, candidates can experience the team culture firsthand.

    Immediately after pair day, we hold a short meeting to decide on next steps. Typically we conduct a Roman vote: Yes, let’s hire the candidate now, or no, not a good fit. We’re looking for individuals who raise the bar for the team as a whole. Rock stars. If the team is willing to fight for a candidate, that’s a good indication the person is a great fit and a bar raiser.

    Recruiting: Learn from the Numbers

    Cast a wide net initially, including talent channels such as tech meetups, college outreach and internships. Remember that you’re connecting with real people and the goal is to build relationships. Phony ads and mass-marketing strategies send the wrong signals. We’ve seen good results from hosting meetups—a great way to start informal conversations where you and the candidate can learn something about each other.

    To identify the best talent sources, measure:

    • Resumés submitted
    • Percent of applicants that went to the second round (testing)
    • Percent tested candidates who had a pair-day interview
    • Percent of pair-day interviews that resulted in an offer
    • Offers accepted

    A note about full-stack developers: finding them is difficult. The same goes for product managers who can work on a DevOps team. We know we’ll have to kiss a lot of frogs to find these unicorns (pardon the mixed metaphor). To increase our chances of finding rare talent, we measure our recruitment activities and conduct A/B tests every step of the way—from job descriptions to talent sources. For example, our data shows that in some cities meetups work better than career fairs; in other cities, it’s the opposite.

    When the data tells us that a recruiting activity doesn’t work in a particular market, we try something else. This, too, borrows a page from DevOps: Focus on data and the user need rather than clinging to subjective opinions about what works and what doesn’t. Openly share all of the data about sourcing and onboarding with your DevOps teams to get their input. The goal is continuous improvement.

    Break Down Organizational Boundaries

    Creating an engine to attract and onboard talent requires breaking down organizational walls. For example, sourcers and recruiters who are out in the field need a clear way to collaborate with the team members who conduct technical interviews.

    Organizational change is never easy. We’re approaching it in the same way we get code into production. That is, we bring people together into cross-functional teams and ask them to work together toward a shared goal. Giving everyone a common goal avoids finger-pointing. Everyone has an incentive to do what’s right for the company and the candidates rather than just their team. And gaining more empathy for the other functions’ challenges helps team members come up with better ideas for creating a world-class recruiting and onboarding experience.

    The cross-functional team should include a technical recruiter, executive recruiter, someone who runs meetups, someone in charge of onboarding, a technical screener and other people involved in the interview process. As it is for DevOps, the goal for hiring and onboarding is to go fast. That takes great communication and transparency.

    Don’t Try to Boil the Ocean: Start Small

    It’s not feasible to change the entire talent acquisition organization in one go. Better to start with a few teams and run mini experiments. When a new process improves hiring or onboarding speed or increases retention, scale it across the organization. And when a new process fails, do what DevOps teams do: Fail fast, share the failure so that everyone can learn from it and continuously improve.

    Take care to select the right people to spearhead the transition. Look for people who are open-minded and have a good understanding of how the organization works today. If you’re into 16Personalities, you’re after Explorer types—those who have “a self-reliant mix of enthusiasm, quick thinking and ingenuity.” In our view, the right people for the transformation should see it as a short-term experiment because transformation should take on a life of its own, not remain the pet project for a few.

    Roll out the red carpet for the cross-functional teams that spearhead the transformation. Limit other work for these team members: this needs to become their entire job. Celebrate each team’s success. The goal is for the first teams to model DevOps-style talent acquisition for their peers to ignite transformation throughout the company.

    Don’t Stop After You Make the Offer

    Consider pairing new hires with a buddy to integrate them quickly into the team. And to retain top talent, be proactive about offering new opportunities and training. Developing a tool that tracks lifetime project assignments, as we did at Cognizant, will help you identify the people who would benefit from and appreciate these opportunities.

    Adopting the DevOps-style of talent acquisition we described isn’t easy. It takes new processes, cross-functional teams, data collection and analysis and transparent communications. The payoff: becoming more of a destination company for the rock stars who create great software—and earning their loyalty by making them feel valued.

    This article was co-authored by Sam Harrison.

    — Brian Roche

  • DevOps’ Role in Developing a Robust and Secure IoT Framework

    DevOps’ Role in Developing a Robust and Secure IoT Framework

    Creating a secure IoT infrastructure is a challenge for developers, requiring a holistic approach. It requires a dynamic framework that is capable of collecting data from a cloud back end as well as directly from the embedded hardware.

    Supporting this secure environment is another challenge, requiring the development of complex systems capable of deployment in a timely and cost-effective manner. This is where the relationship between DevOps and IoT proves invaluable.

    In this article, we will take a close look at how DevOps adds value to the development of a robust IoT framework. We also will examine ways in which DevOps can help in creating a secure and efficient framework for IoT app development.

    DevOps and IoT Framework

    DevOps, with its focus on reducing delivery cycle times, can increase the speed at which IoT systems can be integrated and function in a seamless and secure manner. Seamless integration can be achieved through a combination of secure app development and operational quality assurance checks.

    The DevOps methodology is rooted in the agile philosophy, which attempts to bridge the gap between different technical roles that traditionally worked in silos within the same department in IoT app development.

    Using the right tools and practices, DevOps can help in creating a framework for IoT that can overcome challenges relating to the large-scale app deployment. It can help in infrastructure positioning and monitoring. Companies that have adopted DevOps methodology have reported a 38 percent increase in growth due to additional revenue sources.

    Let’s take a look at some of the ways the DevOps framework can create a secure and robust environment for IoT app development resulting in increased productivity and revenues.

    Application Reliability and Efficiency

    One of the main functions for DevOps is to improve application reliability and efficiency—there is less need for coding and increased focus on rule-based automated configuration of key connected components. With DevOps, the app development team can identify red flags and improve operational excellence. With monitoring tools such as Log-entries, Nagios and Icinga, the team can use DevOps processes to remove latency and develop an efficient and robust IoT infrastructure.

    DevOps comes with source code control of the software applications that execute in the data center. This means developers have access to the source code, which makes their job easier. The source code reduces the complexity caused by cloud connectivity, automation and virtualization.

    Applications deployed through DevOps recover 96 times faster from failures and reported to have 440 times faster lead time for changes. Deeper collaboration between operations, quality assurance and development teams result in an ongoing feedback that helps increase IoT application reliability.

    Security by Design

    An important component of DevOps is security by design, which helps improve the security of connected systems in a DevOps environment. In security by design, the system allows continuous security testing in real time, which helps improve the security of devices connected in a network.

    The security-by design approach also formalizes security controls and implements them at each stage of the IT operations. As a result, software developers can spend time efficiently developing security controls in a consistent way instead of manually building and patching individual scripts.

    The DevOps approach to IoT application development can also help in gaining insights into the usage and performance, which can help in further refinement of the design delivery pipelines. This will lead to improved security and quality architecture of IoT environment.

    Faster Release Cycles

    Around 21 percent of respondents in a survey of 300 senior managers had stated that DevOps integration increasingly lead to meeting application delivery deadlines. The DevOps metrics lead time is used to measure how quickly the app is deployed after starting work.

    DevOps integration with IoT will result in the following benefits:

    • Developers can work on different components of an application simultaneously, which allows faster completion of activities.
    • Quick release cycles allow IoT apps to be pushed live without much delay.
    • Fast release cycles enable the app development team to build IoT applications using separately deployable services that lead to quality app deployment.

    Continuous Integration and Continuous Delivery (CI/CD)

    DevOps framework helps overcome interoperability problem related to IoT app deployment and operations. Most systems required for IoT app integration are already running in the framework that helps in quick deployment. Businesses can choose the process to automate from staging to production using tools such as Jenkins, GitLab and TeamCity. CI/CD allows developers to respond more quickly to market demands by proactively monitoring the processes.

    The approach results in faster resolution time and release of quality IoT application. Research by CA Technologies found that organizations that adopt DevOps find 21 percent increase in software delivery and 18 percent reduction in time to market due to an efficient CI/CD pipeline.

    Infrastructure Automation

    Infrastructure automation save systems administrators and IT resources time on manual tasks and remove the possibilities for human error during IT configuration, patch management and performance tracking. By scripting almost every command, developers can significantly reduce input requirement of administrators. Increased automation also provides stability as the system is no longer prone to human error on input. Repetitive tasks are a prime candidate for automation, as these are the most likely areas where people make mistakes.

    DevOps methodology makes it possible to automate the infrastructure in multiple cloud platforms. For this purpose, developers can use tools such as Spinnaker and Terraform. Terraform is useful for defining and managing the DevOps infrastructure, while Spinnaker is more useful for managing the infrastructure after code release and deployment workflows.

    DevOps framework also helps automates allocation, de-allocation and monitoring of both cellular and cloud resources, which ensures quality of service (QoS) for applications that control connected devices.

    Effective Validation

    Using endpoint validation can help in evaluating how data flows between different components. Testing of the components in the DevOps environment is done using scripts written in Python, Go or Groovy. The infrastructure testing involves stimulating the environment to test security and other components of the IoT app.

    The app development team also can make use of infrastructure as code to test configuration and environment automation. The configuration is tested using tools such as Chef, Ansible and Puppet. In addition, virtualization tools such as Vagrant or container technology can be used to test the environment automation.

    A Comparison of IoT with and without DevOps

    IoT with DevOps

    IoT without DevOps
    1. Implementing DevOps framework to IoT app development results in 21 % reduced security risk.

    2. DevOps can lead to faster deployment of IoT apps. The updates to IoT apps can be deployed every few days, and even many times in a day.

    3. IoT apps with DevOps practices can result in shorter lead time due to the reduced complexity of the development systems.

    4. With DevOps, the IoT application development team has reported a 51% increase in productivity.

    		 1. 71 % of respondents have said that security breach is a large challenge for IoT development outside of DevOps framework.

    2. Lack of DevOps can prevent fast feedback mechanism.

    3. Without DevOps, lead times can be longer. This will result in time and cost inefficiencies.

    4. IoT app development without DevOps presents productivity issues. There are few standards for app development and deployment that results in decreased productivity of the team.

    Conclusion

    DevOps tools and practices help businesses achieve efficiency when it comes to IoT app development. DevOps improve the validation of automated processes across multiple cloud vendors in a secure environment.

    Looking forward, DevOps integration with IoT will become increasingly popular as it can reduce costs and improve revenues significantly for app developers.

    — Subramonian