Category: DevOps Practice

  • Four Ways to Modernize Processes and Measure Performance With APM

    Four Ways to Modernize Processes and Measure Performance With APM

    Change is everywhere and the stakes are high. For 2019, businesses are on track to spend over a trillion dollars on digital modernization, according to a recent study from IDC.

    A crucial part of modernization is the growing number of IT organizations using the latest in dynamic, cloud-scale technologies to develop applications. As a result, technology professionals in the businesses you serve must now work with a much more complex and dynamically changing tech stack.

    When building and maintaining an app, it’s becoming even more common to have hundreds (or thousands) of pieces of code in containers being continually reconfigured and brought in and out of production. And many of these operations take place in customer-facing applications.

    The stakes are high, because if something goes wrong operations could halt. It’s therefore vital to understand the underlying technologies throughout an organization’s IT environment to better equip customers with the tools needed to be successful. Application performance management (APM) tools that simplify stack management, whether it’s on-premises, hybrid or fully cloud-native, provide a level of visibility needed for modern businesses—and they work across multiple cloud environments, such as AWS or Azure.

    As a channel partner, you need to be prepared to help your businesses and their customers through this modernization process. 

    Try the following to help your customers modernize business processes.

    Help Them Realize Software Is Now Business-Critical

    As IT departments move from on-prem infrastructure and a mix of commercial off-the-shelf (COTS) and monolithic custom applications to increasingly adopted cloud-based Kubernetes microservices applications, they’re accelerating the adoption of software at the core of all their business processes. The result? Business is increasingly dynamic and responsive—new applications are built and delivered to market faster than ever. But companies are also at risk now when things don’t go well—that strategic app could degrade or fail.

    All the tech layers underpinning these applications are also becoming more sophisticated, dynamic and interwoven—and making it still harder to administer as they continuously change at an even faster rate.

    Focus Your Customers on Core Competency

    There are plenty of open-source tools out there for your customers to use to build their own monitoring. The biggest obstacle for businesses rolling out their own apps while using an open-source tool is core competency. 

    If, for example, your customer is a wholesale plumbing supply company, is their competency sourcing plumbing supplies or knowing how to write instrumentation code for all their plumbing supply chain applications? Help them focus on what they’re good at and give them tools to manage the rest.

    Perhaps you have a large financial services customer who is spending tens of millions, across multiple years, on a team of outsourced experts to write precisely the code required. This is an extremely time-consuming and costly effort, but financial institutions do this because their needs are highly specific and mission-critical, and the cost of not doing it is even higher. 

    If you look at real-time high-frequency trading environments—where billions of dollars are moved in matters of tenths of a second—you come to understand the stakes justifying these herculean efforts. All of which supports the need for APM tools to help empower the tech pros in-house who monitor and manage these high-speed trading environments.

    At the other end of the spectrum are the small tech companies with a new idea they’re out to promote. But when it comes to most companies, their core competency is often not monitoring and managing their infrastructure and applications. It’s understanding the market requirements for their custom apps and getting those apps to market quickly. At the same time, organizations of all shapes and sizes are still confronting the reality that to successfully deliver modern applications we must shift from pure infrastructure performance metrics to the KPIs that best demonstrate end-user experience.

    Ultimately, many of the organizations described above have either focused on IT as a core competency or, in the absence of dedicated tech teams (at SMBs, in particular), they have outsourced management of their complex, dynamic tech stack and custom application builds. In both instances, APM tools are a necessity and it’s prime time for the channel to deliver those services.

    Be the Most Viable Modernization Partner

    By understanding the needs of modern organizations as they grapple with their complex tech stacks, you can ensure you have the right set of tools for your customers. 

    Provide full-stack capabilities for today’s businesses to manage their applications and keep operations running smoothly. Cater to unique business problems and equip your customers with APM tools based on their needs—advanced logging, trace metrics, performance optimization and full-stack visibility across applications and the compute infrastructure on-premises, hybrid and cloud. Help them check all their functional boxes.  

    Measure Performance with Full-Stack APM

    In all cases, your customers should be measuring performance. Because every company uses a mixture of digital technologies, arming them with full-stack APM will help gain visibility into performance throughout the business. With APM, businesses can see if their system is degrading—and fix it before disaster strikes. That’s the business value for APM—it gives visibility into the complexity underpinning today’s application environments. Full-stack APM provides this visibility, whether the apps are cloud-based, on-premises or hybrid.

    But here’s the reality—not all APM tools are the same. Traditional APM solutions weren’t built for the environment IT departments now have, with the addition of containers and microservices-based applications to their existing monolithic and n-tier/SOA applications. Those solutions were made to manage hundreds or thousands of objects with slower rates of change, not the tens of thousands, or even hundreds of thousands to millions of objects IT works with today.

    Also, note the ephemeralness of container-based microservice applications able to live and die in a matter of seconds or less. There’s no time to automatically install a traditional agent, let alone do so manually. The container’s life span is shorter than the time it would take to do such instrumentation. Direct them instead toward a full-stack APM solution with complete coverage of all application architectures: monolithic, n-tier/SOA and microservices based. With anything less, they’re running at a higher risk of brand damage and revenue impact.

    By being the experts on APM, providing full-stack visibility and measuring performance, your customers will find modernization success.

    — David Wagner

  • Looking Back on 20 Years of Enterprise Java

    Looking Back on 20 Years of Enterprise Java

    It is hard to believe, but enterprise Java has existed as we know it for more than 20 years. In December of 1999, the Java 2 Platform, Enterprise Edition (formerly J2EE, now called Java EE or Jakarta EE) was introduced.

    J2EE built on the “write once, run anywhere” mentality of the Java programming language, but made it enterprise-ready by extending the neutrality and portability with specifications that are better suited to build large-scale applications. It also built on years of work on distributed systems, such as the Common Object Request Broker Architecture (CORBA) and the Distributed Computing Environment (DCE).

    Since its birth in 1999, J2EE has played a powerful role in shaping enterprise applications as we know them today. This article will take a look back at the influential programming platform and what is next.

    First, for context, it’s important to note that the enterprise Java platform is not the same thing as the Java programming language, though they are related. Java, the object-oriented programming language, was started as a project called Oak in 1991 by James Gosling and some of his colleagues at Sun Microsystems. The language is coming up on its 25th anniversary, and is important to note for the history of J2EE. The original goals of Java were to create a language that had a familiar notation (drawing parallels to C/C++) but that had greater uniformity and simplicity. Java was also intended to be assembled as a byte code and then run using a Java Virtual Machine (JVM).

    Java wasn’t publicly released until about four years later, in 1995, from Sun. This came at a pivotal time for the world as we know it: the World Wide Web was rising in popularity, and Netscape announced that it would include support for Java in its web browser. Four years later in 1999, when J2EE was released, the industry was going through yet another critical shift when it came to how the world was using the internet: it was becoming something enterprises were not only thinking about, but realized they needed a strategy for.

    The shift to including Java in the enterprise came naturally because it already had developed a loyal following of developers, both within and outside of Sun. The next few years saw continued innovations in the space, and in 2006, Sun renamed J2EE as Java Enterprise Edition (Java EE). This was the same year that Red Hat acquired JBoss. Later that year, Java was formally open sourced by Sun releasing its core Java technologies under the GNU General Public Licence 2.0 (GPLv2). This was one of the most important steps in Java becoming a collaborative, community driven language.

    One of the other major milestones in Java EE was when Oracle acquired Sun in January of 2010. In the years that followed, the Java EE release cadence slowed considerably. At the same time, the enterprise IT landscape was actively shifting from large, monolithic applications toward lighter and more modular application architectures. Java EE was an enabler of the old way of creating enterprise apps, so it also needed to shift to keep up with the times.

    To meet this need, members of the Java community came together in 2016 to create MicroProfile, now a part of the Eclipse Foundation, which is designed to help optimize enterprise Java for microservices architectures. This shift aligns with the general trend of enterprises moving to smaller and lighter applications and making them cloud native. MicroProfile took into account the needs of the developers while still enabling Java to be used front and center. This played a role in Oracle’s decision to donate Java EE to the Eclipse Foundation in 2017, where innovation around microservices could happen quicker and more efficiently. Java EE has since been renamed to Jakarta EE and has a robust community behind it to support the development of even more innovations in enterprise Java.

    In fact, Java has become such a staple in the creation of enterprise apps that there are now projects and frameworks popping up designed to better support it, such as Quarkus, which aims to help Java developers use enterprise Java for new workloads that take advantage of things like containers and serverless. The Quarkus project aims to give enterprise Java a better cloud-native future.

    Enterprise Java has had a long history, bringing with it many innovations and new ways of thinking and working. I am excited to see what the next 20 years (and beyond) hold.

    — Mark Little

  • LogicMonitor Acquires Unomaly to Advance AIOps

    LogicMonitor Acquires Unomaly to Advance AIOps

    LogicMonitor this week revealed it has acquired Unomaly, a provider of tools infused with machine learning algorithms that make it easier to analyze large volumes of log data.

    Tej Redkar, chief product officer for LogicMonitor, said the acquisition of Unomaly will advance a previously announced AIOps initiative through which LogicMonitor will embed advanced analytics and automation capabilities into its core IT monitoring platform. Rather than requiring DevOps teams to acquire a separate platform to take advantage of AIOps, LogicMonitor contends AIOps is simply an element of the next logical iteration of an IT monitoring platform.

    Unomaly will help LogicMonitor achieve that goal by identifying patterns in streaming log data that are indicative of anomalies that warrant further investigation, said Redkar. Unomaly works by first establishing a baseline for the IT environment. It then records a profile for each log event that includes the event’s structure, sources, frequency patterns and intervals. Similar profiles are then merged into one aggregated profile, with dynamic parameters to reduce the amount of data that needs to be analyzed by several orders of magnitude. If an anomalous event occurs within a rolling 60-second window on a single log source, Unomaly will bring those events together to identify and score a situation based on the type and number of anomalies.
    Redkar noted this approach not only provides more context about the events but it also greatly reduces the amount of log data that needs to be stored. Unomaly is also designed to accept data in any format.

    As IT becomes increasingly more complex, organizations of all sizes need more observability. However, because all the dependencies within the IT environment are becoming too complex to track manually, IT organizations will need to rely more on machine and deep learning algorithms to observe the IT environment.

    Naturally, that increased reliance on algorithms will alter the role of IT operations teams. Most IT operations teams will find themselves supervising algorithms that are surfacing issues and making recommendations, said Redkar. Rather than eliminating the need for IT operations expertise, AIOps will be employed mainly to manage IT environments operating at a significantly higher scale, he noted.

    It will take some time for this transition to play out as issues such as the explainability of AI models are worked out. Some of the lower-level functions within an IT operations environment undoubtedly will be eliminated, so job roles will change. However, many of those functions will be rote tasks that many IT professionals don’t especially like to perform.

    IT vendors are, of course, involved in something akin to an algorithms arms race to infuse AI into their management platforms. In some cases, they will develop these capabilities themselves. In other cases, they will acquire startups to gain access to AIOps platforms. Most IT vendors will be mixing and matching a variety of AI technologies they developed themselves and acquired. Regardless of the path pursued, it’s no longer a question of whether AIOps will be applied to managing IT, but rather when.

    — Mike Vizard

  • The Difference Between Capacity and Scalability Planning

    The Difference Between Capacity and Scalability Planning

    Not only does the tech industry love terms, we love to make them super nuanced. For example SecOps versus DevSecOps, continuous delivery versus continuous deployment, hybrid cloud versus multi-cloud, etc. These terms may seem similar on the surface, but when you dig in they are quite different.

    Here are two more: capacity planning versus scalability planning. Both are critical aspects of keeping applications up and running, but two different activities.

    The reason we invest time in capacity and scalability planning is simple: We want to make sure that system resources such as compute, storage and memory are not the cause of an application outage. It is a response to expected and unexpected increases in application usage, as well as the steady growth of application adoption.

    Here are a few differences between capacity planning and scalability planning.

    Long Term Versus Short Term

    Capacity planning is more focused on the base resources, as it relates to the long-term growth in application traffic. The goal is to have enough resources to handle the steady state of the application without breaking the bank by over anticipating usage. With capacity planning there is a big assumption that the application requires to always have a pool of resources available.

    Automated Versus Static

    Scalability could be a manual task, you see utilization creeping up and you respond with more instances. This is probably more common than not. But I don’t believe it’s the overall objective of most teams. Auto-scaling is the goal, where the system knows on its own when it’s time to spin up new resources. The public cloud providers, instrumentation of kubernetes, etc., help support this. Whereas capacity planning is a more deliberate identification of needs, and then statically setting those resource needs within the cloud.

    Strategic Versus Responsive

    Similar to static versus automated, capacity planning is a more strategic activity whereas scalability planning is a more responsive activity. Usually, scalability comes up during peak usage activities such as black Friday sales or school registrations.

    Capacity planning generally calls for more research and leveraging tools such as load balancers and historic data to understand the best path forward. It also should involve the input from the broader team, especially development to discuss the resource usage of new functionality and application architectures.

    There is a good possibility that scalability planning could be all that is left with some modern applications. The reason this might be true is resource allocation theoretically can be 100% application based, where the resources are always one step ahead of current utilization. In order to embrace this model resources need to be provisioned 100% automatic, which means that all infrastructure needs to be scripted. As more companies adopt serverless components of their application, this is already inherently true.

    Capacity planning is where most operations teams spend their time, but resource utilization is shifting left and scalability planning is becoming more common. Scalability planning has become the responsibility of DevOps engineers, SREs and even developers. The main reason capacity planning will survive the long haul relates to budgets. While the application itself can fully control the infrastructure laid out before it, the IT organization and the organization itself will want to impose an upper limit so there is an indicator of when the cost of running the application on the resources may or may not be an issue. Capacity planning in this case will be purely a cost control mechanism, and negotiated just as any budgets are.

    — Chris Riley

  • Software Supply Chain Attacks: How to Disrupt Attackers

    Software Supply Chain Attacks: How to Disrupt Attackers

    Supply chain attacks—compromising an organization via insecure components in its software supply chain—are a growing concern for organizations. Throughout the past three years, an increasing number of open source software package repositories have been found to contain malware, making it clear that all installation and update pathways for software and library code must have security controls applied to prevent and mitigate supply chain attacks.

    Growing Risks of Open Source Software to the Business

    Digital transformation has made every company a software company. As a result, open source software has grown 75% over the past two years. Despite this growth, few companies accurately track the components used in their code. Most lack the policies, processes and tools to keep up with the choices made by their developers, which introduces risk. In fact, 60% of the codebases audited in 2018 contained at least one vulnerability.

    Bad actors have turned to exploiting these weaknesses to compromise organizations. If production code is infected with malware or vulnerabilities, inadvertently sourced from the repository, it may contaminate all organizations that come in contact with it—whether by using the code already in their SDLC or by launching presumed trusted applications from third parties who failed to validate their own code.

    Attackers are also shifting their techniques to mask malware among large packaged objects using obscure formats we refer to as destructive objects. They infiltrate at various points in the development processes opportunistically, knowing they can infiltrate systems outside a managed operational environment. They take advantage of third-party dependencies and use payloads that can sit and wait until an unsuspecting developer implements their software. Hence, software supply chain attacks are difficult to detect, and often achieve dwell-time of hundreds of days.

    Assessing Supply Chain Surface and Sources

    In order to assess weaknesses and identify what warrants continuous monitoring, we need to understand both the surface and sources. 

    When evaluating surface risks, consider the following questions regarding the development environment:

    What technologies, repositories and packages are in use?

    • Inventory technologies used in development: Python, Ruby, JavaScript, Node.js, .NET, etc. This can also refer to operating systems. 
    • Third-party repositories of code: PyPI, RubyGems, NPM, NuGet, PEAR or PECL, and OS repositories such as DebianRepository, CentOS, Ubuntu, AUR and more.
    • Packages: There can be multiple packages from a single repository. How often are packages updated? How often are new packages added?

    Are there update procedures in place?

    • What are the dependencies for every package? How many other packages are pulled from a single package update, and how often are they updated and/or reviewed?

    Who’s managing the verification processes across all these dependencies? What update procedures are in place if there is a personnel change?

    Once these questions have been answered, they should be addressed regularly. The process must be iterative to be successful. 

    When considering attack sources, it’s important to understand the characteristics of repositories teams draw from in order to understand potential areas of weakness. Third-party repositories rarely infect a big project as they are typically found elsewhere (e.g. GitHub) and have thorough code reviews. Official repositories, unofficial mirrors and internal code repositories represent increasing risk potential.

    Random malicious packages, typosquatting, bad code review and phishing developer credentials to hijack accounts are all less technical ploys used by attackers, but equally dangerous. 

    The Software Supply Chain Challenge

    The size, breadth of formats, trusted third-party and open source risks, and misused certificates have made it nearly impossible to stop malware-infected files and objects with today’s signature based, sandbox and vulnerability-based solutions.

    Threats evade dynamic analysis remaining unknown to defenders or lacking details when detected. The explicitness of signature blacklists misses new or never-seen-before code, and sandboxes or dynamic analysis solutions are resource intensive and unable to scale to the breadth and volumes of formats required. Without a way to inspect large or cross platform archives, installers and source code, it’s impossible to extract indicators of compromise. These destructive objects can also impact SOC triage, response and continuous improvement.

    Rising to the Challenge

    How can you address these risks, not only in the software development life cycle (SDLC), but as SOCs address vulnerabilities that may come through other applications and repositories? How do you evaluate and inspect wrappers, digital certificates, executables, scripts, files and libraries, resources, documents and icons?

    It’s vital to establish security practices within SDLC, from training developers on secure coding practices using open source libraries to factoring in detection capabilities including static analysis, dynamic analysis, software composition analysis and manual penetration testing. Implementing a secure SDLC process ensures that the development effort is protected by these activities, augmenting code reviews and infrastructure analysis.

    Teams can extend security controls into the SDLC with technology that provides deep visibility into all aspects of the supply chain, from open source dependencies through continuous integration and delivery of packaged applications. Capabilities that provide greater application security across code development and deployment activities include:

    • File reputation identifies and classifies “known bad” and “known good” files by applying a file’s unique hash against a database of goodware and malware.
    • Automated static analysis detects and classifies unknown malware in code repositories by deobfuscating and decomposing objects and files without executing, and extracting threat indicators. 
    • Dynamic analysis executes files in a safe environment and captures the behaviors and results of malware, allowing the security team to understand what is going to happen.
    • Software composition analysis analyzes applications to detect vulnerabilities, dependencies and licensing requirements in software.
    • Threat intelligence is served up at various stages of the analysis cycle, and represents evidence-based knowledge including context, mechanisms, indicators, implications and action-oriented advice about existing or emerging threats.

    By incorporating these technologies into the SDLC, development teams can obtain continuous validation across the software supply chain. Further automation, implementing new security guidelines and advancing the activities within the existing framework will allow the enterprise to progress its security measures and close gaps in the SDLC and supply chain operations.

    At the same time, it’s important to recognize that threats can still make their way into the software supply chain, and it’s equally important that the SOC remain vigilant about maintaining a clear triage and escalation process. Continuous monitoring of software repositories should be an integral part of good hygiene processes, and incorporated into best practices applied to operational infrastructure, including the SOC. The SOC serves as a centralized management infrastructure to respond, contain and remediate attacks. This includes aggregating and consolidating threat data, building a case for managing a response which can include actions to formulate triage and incident response plans, and moving beyond SIEM.

    — Tomislav Pericin

  • How to Use DevOps for Compliance

    How to Use DevOps for Compliance

    Picture this: You’ve been working in an organization’s IT department for a couple of years and tasks have become quite a routine. Some documentation here and there, code reviews, end-user training, routine meetings with the developers and so on. You can do literally everything with your eyes closed.

    Then, all of a sudden, the company is going public and you feel like you’ve been thrown into a different dimension. There are new procedures to follow, endless meetings to attend and a ton of paperwork to be shipped. And don’t forget the new compliance regulations.

    When this happens, do you gamble and quit or stick around and accept the new reality? Is there a truly viable option?

    In comes DevOps.

    DevOps means different things to different companies. Some IT experts consider it a fad while others swear of its significance.

    In many organizations, DevOps combines development and operations. With it comes automation, efficiency and more transparency. With DevOps, changes can be rolled out much quicker.

    DevOps can be the silver bullet for organizations looking to keep up with HIPAA, GDPR, PCI SOX and other industry regulations.

    Here are four strategies for using DevOps for compliance.

    Keep Track of Documentation

    A big part of compliance involves documentation. Yes, boring but critical. With a unified development and operations team, you can merge the documentation processes of those who release changes and those who make them. It’s also easier to get everyone on board when it comes to compliance requirements.

    You can use the newfound synergy between dev and ops to avoid documentation bottlenecks by adopting a unified and trackable version control system. Tools such as Git, wiki pages and internal dashboards can be used to harmonize documentation and version control.

    Make sure everyone is on board by conducting routine training and holding meetings involving both dev and ops personnel.

    Leverage DevOps Automation

    Part of the reason why DevOps has attracted so much attention is the automation it brings.

    With DevOps, time-consuming tasks such as monitoring pull requests, internal audits, access controls, code reviews, failovers and code coverage can be optimized through a transparent, unified and automated system. For instance, you can link all deployments, code review and build results in a single process to streamline audits and daily operations.

    DevOps automation not only helps to streamline internal processes but also in demonstrating that you have met all compliance requirements. Things like access control and failover/recovery processes can stifle your compliance efforts if they are not optimized through automation.

    Streamlining Dev Workflows for Compliance

    Most compliance problems stem from messy development workflows that are not helpful for those keeping track of updates. For instance, an update that is put into production without going through the normal stress tests or internal reviews is not helpful. With multiple teams working on different features during the development stage, it’s easy to overlook small updates that could potentially introduce vulnerabilities.

    DevOps helps to prevent accidental compliance breaches emanating from flawed dev workflows. This is achieved through the integration of stress testing into the development process itself.

    With DevOps, you don’t have to wait until an update is ready for production to stress test it. Working with a dedicated compliance team, you can create a compliance blueprint in the form of a testing and logging system to keep track of code that is still in the production stage way before it goes into production.

    Foster a Compliance Culture

    In a non-DevOps environment, it’s common for different teams or individuals to blame each other, refuse to take responsibility or be out of touch with processes that are not in their job description or assignment. To ensure compliance, a bit of team management is required through communication and culture development.

    DevOps makes this process easier thanks to the improved inter-team dynamics, automated processes and increased transparency. It’s easier to merge the dev and ops teams to help identify potential trouble spots and ways of resolving them. The operations staff will not blame the developers when a disaster occurs if they were part of the entire process and vice versa.

    Effective teams always take responsibility instead of looking for a fall guy or starting finger-pointing when something is amiss. Inculcate a culture of compliance in your teams by ensuring that they are all aware of what is required of them and their shared responsibilities.

    From the above, it is clear that DevOps can be the only thing you need to ensure compliance in your organization. However, adopting multiple recommendations at a go can be challenging. Therefore, take it one step at a time and use available tools, such as Git, to implement some of these processes.

    — Ken Lynch

  • Why Is QA so Important in Executing a DevOps Implementation Strategy?

    Why Is QA so Important in Executing a DevOps Implementation Strategy?

    In a rapidly growing global digital landscape, enterprises are facing many challenges. These include changing customer behavior and the need to be in line with the latest technology trends. To address these challenges and to stay up the competition curve, enterprises are adopting a slew of strategies. These comprise expanding the capacity of processes, quick quality checking and delivery of applications and timely marketing of the applications. This is where DevOps comes as a one-stop solution to the aforementioned requirements. 

    When it comes to assuring the quality of software applications, the Agile and DevOps model of testing is favored over the traditional waterfall model. This is because software applications need to be tested across a swathe of platforms—devices, browsers and operating systems. In the DevOps scheme of things, software builds are continuously integrated and deployed in the development pipeline by using test automation. It involves the development and implementation of new features along with the streamlining of processes. 

    What Is DevOps?

    DevOps is an amalgamation of terms “development” and “operations” and is underpinned on four basic pillars—culture, tools, collaboration and practices. Combining processes and philosophies, the DevOps approach helps enterprises deliver quality builds in the SDLC. Here, development and operations teams no longer work in silos but in close coordination with each other. As a result, quality becomes a shared responsibility and a culture of accountability gains ground. DevOps implementation leads to the quick development and deployment of quality builds, faster solving of critical issues and engendering greater trust and confidence.

    Let us understand the best DevOps implementation strategies to derive outcomes such as continuous integration (CI) and continuous delivery (CD). To begin with, getting the QA basics right the first time and every time should be considered as part of the strategy. This is due to the fact that in a pure DevOps ecosystem, the lines between development and QA are blurred.

    Test Automation

    Since the software needs to have an omnichannel interface with third-party applications to perform optimally, the test process should be automated. There should be a smooth QA-DevOps alignment to detect and mitigate glitches early on in the SDLC. Thus, DevOps testing may involve choosing automated tools that are either open-source or commercial. 

    Teams Merge

    To derive DevOps transformation, the integration of the QA team with other technical specialists becomes important. The final DevOps team should adapt a culture wherein identifying glitches becomes a shared responsibility. 

    Metrics

    Since DevOps testing is all about quick identification and fixing of glitches, the metrics should be defined at the beginning. It will help the DevOps team to stay focused on the challenges and requirements. This calls for the QA engineers to setup test requirements into the workflow and guide the team therein.

    Virtualization

    The software application should be tested across a slew of platforms—devices, browsers or operating systems. Since it is well-nigh impossible to test the codes for numerous users (during usability testing), the same ought to be created virtually. The QA team can virtualize every test requirement to emulate the behavior of software components. Moreover, it helps to do away with the need for dependencies and addresses constraints faced in interdependent environments.

    Choose the Right Tools

    To enable DevOps automation, the QA team should choose the right test automation tool. The main criteria for choosing the tool should be the team’s expertise in using it. The tool should offer the ease of writing the test script in a single programming language. It should allow the testing of applications across operating platforms and browsers.

    Continuous Integration and Continuous Deployment

    These are the outcomes of any DevOps methodology. DevOps continuous integration and deployment encompass adding code changes in a repository and creating automated builds. This leads to an early recovery from failures as well as testing and delivery of products within fast turnarounds. Continuous integration based on test automation leverages regression testing and a version control system when a new code is added. Further, DevOps continuous deployment is about the capability to add new features to the existing applications. This makes enterprises follow a user-driven improvement of software and agile approach.

    Conclusion

    With the quality of software applications becoming the final arbiter in making an enterprise successful, taking the DevOps approach is crucial. However, since the whole process is hinged on executing comprehensive quality testing, the QA basics should be done right.

    — Akshaya Choudhary

  • DevSecOps: 10 Best Practices to Embed Security into DevOps

    DevSecOps: 10 Best Practices to Embed Security into DevOps

    For companies that employ the agile approach, DevOps seems like a natural extension. Traditionally, enterprises started with integration, development and test automation early in the product lifecycle. Gradually, the agile delivery team took care of iterative development and monitoring practices that increase code quality.

    Today, organizations work in unison to bridge the gap between development and operations (DevOps). They want to offer a faster market delivery with the least human interaction. 

    But what about security integrations? Is there a way to mitigate vulnerabilities early in the development lifecycle?

    The answer is DevSecOps.

    Exploring the Concept of DevSecOps

    DevSecOps is short for development, security and operations. It brings together people, processes and technology to pursue a shared objective. 

    The objective of DevSecOps is to implement security decisions on the same scale as development and operations and make everyone in the product lifecycle accountable for security. 

    Why Should You Adopt DevSecOps?

    People adopt DevSecOps because they are seeking:

    •  Modern alternative to traditional security engagement.
    • Transparent collaboration and workflows during development.
    • Security that’s built into the product, not applied at the final stage. 
    • Reduced expenses and faster delivery rate. 
    • Faster recovery speed in case a threat is detected.

    Steps to a Typical DevSecOps Workflow

    1. A developer starts by writing code within a version control system.
    2. Any required change is committed to the version control system.
    3. Another developer analyzes the code to identify any security defect that may weaken code quality. 
    4. An environment is created to deploy and apply security configurations to the system.
    5. Next, a test automation suite is executed to evaluate the newly deployed application.
    6. After it passes the automation test, the application is deployed to a production environment.
    7. This new production environment is actively monitored for security threats. 

    While there is no right way to transform organizational culture, below are a few components necessary to sustain a DevSecOps environment: 

    Let Developers Get Security Right: Developers are responsible for security. Therefore, you must keep them on top of cybersecurity best practices through continuous training and learning activities. 

    Promote an Open Culture: Openness in communication within the enterprise environment can drastically improve development and security. One way to keep information transparent is by using metrics and dashboards wherever possible. 

    Get Experts on Board: It is extremely difficult to transition from DevOps to DevSecOps without the supervision of expert security professionals. Hire people who understand security within the development and operations environment and let them train your DevSecOps team for the big transition. 

    Tempted to embed security into DevOps? How do you ensure that the best practices are followed? We have answers.

    The Best Way to Implement the DevSecOps Process

    Gather a single group of professionals (admins, developers, security engineers and testers) that are aware of your product from start to end. They should know your requirements and should be experts in deploying, monitoring and implementing new changes. 

    Once you have your team ready, here’s what you need to do next.

    Plan

    Planning is crucial. Do not just stick to feature descriptions. Instead, go for detailed user stories that include:

    • Functional and nonfunctional requirements (e.g., security and performance).
    • UI and UX designs.
    • Acceptance test criteria.
    • Threat models.

    Develop

    Start by evaluating your existing practices. Choose the best resources to build a development model in coherence with security guidelines. 

    Build

    Automated build tools can do a lot more than compile codes. Use them to conduct test-driven development, enforce quality standards and ensure that the best security practices are implemented through static code analysis. 

    Test

    When it comes to a DevSecOps environment, test automation is not limited to UI-focused Selenium tests. Optimally, your security practice should include the following:

    • Unit testing.
    • Front-end testing.
    • Back-end testing.
    • API testing.
    • Database testing.
    • Passive security testing.

    Secure

    Because development, operations and security go hand in hand, only a few issues are left unattended toward the end of the development process. 

    When vulnerabilities are identified, there is a better chance of determining if they are potential exploitations or false positives. 

    Deploy

    Automated provisioning and deployments can be utilized to accelerate product delivery and add consistency in the development process. Using an infrastructure-as-code tool, one can audit properties across the IT infrastructure and enforce secure configurations in a system. 

    Operate

    Routine maintenance and upgrades should be an indispensable component of your operations team. Leverage infrastructure-as-code tools to patch zero-day vulnerabilities and apply updates to the entire organization’s infrastructure. 

    Monitor

    A continuous monitoring plan should be in action to generate real-time stats of how your system is performing. In case any exploitation is recorded, it can be addressed immediately. 

    Scale

    Traditional data-center operations cannot entirely replace a compromised environment. Today’s ability to scale infrastructure through virtualization and the cloud, while addressing the demands of modern-day IT user base, should go a long way. 

    Adapt

    When it is about sustaining an agile practice, continuous improvement is key. This is also true for DevSecOps practices, as you improve and adapt throughout the software development lifecycle.

    Conclusion

    DevOps isn’t going anywhere, anytime soon. It is the new phase of developing, releasing and updating products in a software lifecycle. 

    That’s why high time security professionals let go of the traditional security stack and embrace security solutions at the speed of DevOps.

    — Deepak Gupta

  • Five IT Ops-tackles that Stifle Business Growth

    Five IT Ops-tackles that Stifle Business Growth

    I was recently asked about the top five IT obstacles that stifle business growth, and I want to help clear a path too often lined with fear, uncertainty and doubt. In the not-so-distant past, IT was all about the tools. Solutions were more straightforward, teams were less globally connected, and the ever-present data deluge was not changing our business landscape by the millisecond.

    With this in mind, I have created a list of the five most common IT obstacles and will pinpoint the single tool you can implement to help alleviate these pain points.

    IT Staff Lack Time to Learn New Technologies

    This is not to slam our tech teams or leaders; this is just the byproduct of condensed customer schedules, tight purse strings and managing the MOOSE (maintenance and operations of the organization, systems and equipment). The demand on IT teams is high, and we don’t always have the opportunity or the resources to restructure operations for a new tool, as upgrading requires learning new APIs, UI/UX and deployment architectures.

    Difficulty Supporting New Technologies Quickly

    It is hard to keep pace with IT complexity and manage it properly. New services, applications and infrastructures are constantly being added and there are plenty of vendors out there that will get you locked into solving a single issue versus addressing your macro problems. While the benefits of upgrading are there, the difficulty lies in understanding the complexity of these systems and how to leverage them most effectively.

    Lack of Support for Hybrid IT

    Hybrid by definition adds complexity, and multi-cloud, on-prem and private/public clouds are only a few ways to make your hybrid dream a nightmare. No matter the combination, understanding different architectures and their components is a must. Additionally, we need to understand how we manage our own data as well as how our vendors are managing it.

    IT Complexity

    We need to know our machines and architectures well enough to focus limited resources on what impacts the business most. IT will always be complex—there’s always something new, and the amount of information to process is insurmountable and exhausting. Adding context to IT data can help you identify the root cause of overly complex systems. The most difficult task will be to understand the technology well enough to know what to do next. 

    Inability to Understand Business Impact in Order to Prioritize Tasks

    Prioritization is by far the most important aspect of IT. There is a lot of noise, lack of visibility, lack of context, and—the squeakiest wheels of them all—legacy tools. Prioritizing means routing the right people to the right problem to get it solved quickly and elevating IT service visibility, health and risk into the business function.

    Let’s Get Digital

    IT pros can start to tackle these challenges through prioritization and then automation, or AIOps—the principal of AIOps being to add context to data, using machine processes to enrich the data and bring it to a business level. Understand what is important to the organization and think about the outcomes important to IT. To do this, you can create a realization plan to tackle the low-hanging fruit and create achievable milestones and outcomes. For example, look for opportunities and create a crawl-walk-run phased approach driven by business priorities. Each organization has different needs and different timelines—and this process can be applied to customers, too.

    Next, take into account how your team does work and focus on automation as a principle within how you do work. One of the biggest impediments to digital transformation is culture. Remove manual processes, capture tribal knowledge and figure out how to repeat this approach in a consistent way. Additionally, absorb feedback and learn from it. This will drive acceleration when done right, and we all know that better digital experiences boost enterprise value.

    Finally, automation is useless if your data is flawed, and accuracy is a key fault for legacy configuration management database systems. Data must be accurate for effective machine-enabled automation. Leverage the tech you have to build an interconnected ecosystem that is fully integrated and automated—and that avoids tool sprawl. Have an open mind to consider new approaches and be brave enough to shed the legacy mindset. Additionally, take into consideration your partners and vendors, and how that team collaborates, to determine your strategy.

    The Light at the End of the Tunnel

    The path for today’s CIO can be unclear. But you can take bite- (or “byte-”) sized steps to put machines to work and leverage processes that deliver on AIOps. By understanding business outcomes, prioritizing automation as a principle and leveraging trustworthy internal and external relationships, you will have more time in the day for more important tasks. I measure outcomes based on customer experiences, and I ensure great customer experiences by running a great system. While your mileage may vary, moving forward is the most important part.

    — Erik Rudin

  • Is COBOL Here to Stay? Five Signs IT is Ready to Modernize

    Is COBOL Here to Stay? Five Signs IT is Ready to Modernize

    With increased demands and challenges around compliance and regulations, plus growing expectations for IT to provide more value-added services, companies are looking for more flexible and collaborative options. Interestingly though, while some IT departments have updated legacy systems, COBOL code has continued to be a mainstay. In fact, COBOL just turned 60 and many are saying it’s here for the long haul.

    There are a lot of reasons that make it challenging—or for some, unnecessary—to move away from the language, but there are also several clear signs companies and IT departments should know that indicate it’s time to make a change.

    Here are five signs IT leaders should pull the trigger on modernizing their legacy environments.

    You’re Constantly Worried About the Risk of Losing COBOL Expertise from Your Team

    COBOL has more production lines of code than any other language in existence, with over 220 billion lines of COBOL today—or around 80% of the world’s actively used code. One of the problems is that many that are well-versed in COBOL language are also nearing retirement, and the amount of COBOL programmers entering the market is much lower than it was 10 years ago.

    Author Glenn Fleishman put it best in his article on the subject stating “the language never died, though its early practitioners have faded away, and the generation of programmers who built systems towards the end of the predominant mainframe era in the 1970s and 1980s are largely near or past retirement age. It’s a slow-moving crisis with no crackling deadline, like Y2K, to focus the minds of Chief Information Officers.”

    Pressure from Business Leaders to Take Advantage of More Agile IT Methods

    Whether it’s cloud, DevOps or microservices, businesses want faster and more frequent IT delivery of new services to customers. In order to drive these results, embracing more agile methods of IT and developing a strategy that can support rapid application delivery is key. Moving to the cloud, integrating with Java or shifting to Linux requires open-based models that can handle legacy COBOL applications.

    You’re Quickly Losing Your Competitive Edge Because of the Reliance on Dated Technologies

    Direct and even indirect competitors are encroaching more and more in the industry and in new deals, and you feel as if your company’s position in the market is slowly declining. This may be a product of competitors’ willingness to open source systems that promote the business agility needed to react far more quickly to changing market dynamics and customer demands.

    If they are modernizing their IT and investing in new technologies quicker than you are, it’s likely they’ll catch up to or surpass you quickly.

    Your Confidence in Your Current IT Environment Is Extremely Low

    No matter the modernization strategy you pursue, you should ultimately feel confident and peace of mind when it comes to your environment today and as you look to the future. Without flexibility, collaboration and a tailored approach however, the business will likely suffer and may be the reason for the growing insecurities.

    For instance, if you’re interested in programming COBOL in some areas, but currently operate in a significantly pure native Java environment, a flexible and manageable solution is key. If you want to generate Java as the compiled object, the result will be inflexible static Java objects, rather than something flexible and extensible — and will require access to the Java source. That source is not nearly as maintainable as the source generated in the COBOL to Java conversion, but can be leveraged in Java-operating environments, and is much more flexible than other alternatives.

    You’re Experiencing Vendor Lock-In

    You’re wedded to an established tech company or consultants on-hand that seem like safe bets, but instead have caused you to miss the mark in being flexible and future-proof–not to mention are likely far over your budget to maintain. While transitioning to a new partner may seem daunting, conducting an assessment of your operational, infrastructure and application environment can provide a more comprehensive picture of the strategy that is right for the business, help manage the process more efficiently and ultimately cut unnecessary costs well before an exact migration or conversion path is decided on.

    Although many organizations have run COBOL without substantial updates and issues for decades, the ability to solely rely on the dated technology is quickly giving way to a growing need for additional languages and more agile systems. If IT leaders are experiencing one or more of these issues now, waiting any longer to address them can result in much bigger problems in the future and considering a modernization strategy may be the better path to success.

    — Cameron Jenkins