Tag: continuous integration

  • Shift Left Without Fear: The Role of Security in Enabling DevOps

    Shift Left Without Fear: The Role of Security in Enabling DevOps

    It’s the age of DevOps, and we all want to shift left, which refers to the idea of performing processes earlier in the CI/CD cycle. That includes security checks and audits. By starting security operations earlier in the delivery pipeline, it becomes easier to find problems, and teams have more time to address them before pushing code into production.

    The challenge, of course, is building a shift-left security operation that allows you to perform security operations early without slowing down delivery speed. Let’s take a look at how to square that circle.

    Defining Shift-Left Security

    A popular term in DevOps culture is “shift left.” But what does shift left mean? Shifting left refers to the effort by a DevOps team to implement measures to ensure application quality at an early point in the software development life cycle. In the case of application security, this means implementing measures to ensure security concerns are taken into consideration while the application is being developed, rather than at the end of the process.

    The overall goal of shift-left security is to identify and resolve potential vulnerabilities earlier in the development life cycle, when these issues are less expensive to fix. Doing so will help to mitigate the risk potential security concerns pose to both the delivery schedule and your end -users.

    DevSecOps: Integrating Security Into the Development Process

    Let’s be honest: Faster and more frequent development cycles aren’t going away. Slowing delivery speed to analyze and bulletproof the application at the end of the development process is no longer a viable format for implementing security. DevOps and CI/CD need to be embraced and enabled by the security staff.

    For security teams to enable the DevOps process, collaboration is key. Through this collaboration, the process of DevOps transforms into something known as DevSecOps. In DevSecOps, security personnel work closely with the rest of the DevOps organization to help those who create and deliver the application to gain a better understanding of what is needed to address security concerns as early in the development life cycle as possible.

    The following tips serve as a jumping-off point for implementing this collaboration:

    • Make security the responsibility of the entire DevOps team: Impress upon the development and operations staff that security is now the responsibility of the entire organization. Simply addressing potential vulnerabilities post-development will eat up too much time and increase the risk that something will be missed. Buying into this process is an essential part of implementing successful collaboration between the security team and the rest of the organization. An example of this would be impressing upon developers to code with security in mind.
    • Facilitate regular discussions about application security throughout the development process: It is the responsibility of the security folks to keep security considerations at the forefront of a developer’s mind while they develop new features. Use the agile process to your advantage. Backlog meetings can involve security folks to ensure the creation of user stories includes consideration for security concerns. Your daily standup meetings are another place to include security personnel. This will provide security staff with an opportunity to speak up when the work described by the developer requires—or might require—considerations related to security that have yet to be addressed. Doing so will help to ensure the ball is not dropped, allowing for potential issues to be rectified before they even exist.
    • Use test automation and continuous integration to your advantage: When it comes to addressing security concerns throughout the development process, continuous testing is your best friend. And, in cases where it makes sense, the DevOps team should integrate automated test scripts for the detection of security and into their continuous integration process. Such tests can include developer-written scripts to test for vulnerabilities in the code base and tools for static code analysis. Another part of your continuous testing strategy could involve the use of tools for infrastructure monitoring.

    The data produced by these strategies can then be analyzed by security folks. And from this analysis, recommendations can be made to the DevOps team regarding the path forward to close potential gaps in security before they ever reach production and can be exploited.

    Understanding the Role of Security Personnel in the Development Process

    Security folks are often not coders, and development personnel are often not security experts. And while it may be frustrating at times, the solution to managing this disconnect is in the collaboration described above. Situations will arise where developers need to develop with various technologies to build a quality product. It’s possible that these technologies will lend themselves to security concerns that require security expertise. The job of security personnel shouldn’t always be to fight back against the use of these technologies. The security team should act as facilitators—take what development and operations staff intend to do and foresee the potential impacts that innovation will have on security—then take these potential impacts and provide insight into what needs to be done to reduce the risks.

    Conclusion

    In the past, security often was considered as an afterthought in the development of an application and its infrastructure. The movement toward faster development cycles and more frequent application releases has forced development organizations to think about security differently. Nowadays, so much can change in an application in a short time. This has forced DevOps organizations to integrate security into the development pipeline to make security a continuous consideration in the development life cycle. With this integration, the responsibilities of security personnel have shifted. Security teams now need to be enablers of the DevOps culture, empowering DevOps processes with security in mind.

    To see how Symantec CWA can help you shift left without fear, sign up for a free trial to see how it can help secure your cloud.

    — Scott Fitzpatrick

  • GitLab Updates Advance Its CI/CD Platform

    GitLab Updates Advance Its CI/CD Platform

    GitLab has expanded the capabilities of its continuous integration/continuous development (CI/CD) platform to include tighter integration with collaboration platforms from Slack and Mattermost along with the ability to support Docker containers running on Windows.

    Version 11.11 of GitLab adds a caching dependency proxy for Docker images to the Premium edition of GitLab along with the ability to provision an instance-level Kubernetes cluster using instances of GitLab that are managed by an internal DevOps team. Those capabilities are arriving on the heels of GitLab last month announcing its initial support for Kubernetes as a platform on which its CI/CD environment now can be deployed.

    The latest edition of GitLab also adds support for multiple assignees for a merge request capability, which allows multiple members of a DevOps team to manage merge requests within a DevOps pipeline.

    Finally, GitLab 11.11 also provides guest access to releases, extends the add-on CI runner minutes to the GitLab Free edition, supports the OpenID Connect authentication protocol, includes serialized commit graphs and simplifies reviews by auto-resolving a discussion whenever a suggestion is applied.

    Priyanka Sharma, technical evangelist for GitLab, said GitLab is starting to see increased interest in using Docker containers to build applications on Windows. A Windows Container Executor for GitLab Runners capability makes it easier to orchestrate pipelines that include Docker containers destined to be deployed on Windows. Previously, DevOps teams needed to rely on a shell executor to orchestrate Docker commands. This update makes it possible to employ Docker containers on Windows in the same way they are deployed on Linux platforms. GitLab also has improved support for PowerShell, in addition to making available helper images for various versions of Windows containers.

    Sharma said GitLab is starting to see IT organizations that have embraced Windows starting to catch up in terms of enthusiasm for Docker containers. Also, DevOps teams that have embraced both Linux and Windows platforms are looking to apply best DevOps practices to both platforms.

    Microsoft has signaled its intention to continue investing in making Docker containers a core element of its overall strategy. As the work progresses in collaboration with Docker Inc., the need for a CI/CD platform that can support Windows environments will become more acute.

    In the meantime, GitLab continues to focus on making it easier to implement best DevOps practices at scale, Sharma said. As enterprise IT organizations continue to embrace DevOps, many of them soon discover the need for a CI/CD platform designed from the ground up to support pipelines that are being accessed by many concurrent users.

    The decision many of those enterprise IT organizations will have to make is how much they will want to rely on an open source versus closed source platform. The enterprise edition of GitLab is a closed source platform, but the company does make available an open source community edition. While the open source Jenkins platform currently dominates among CI/CD platforms, enterprise IT organizations that have adopted DevOps have shown a willingness to embrace proprietary DevOps platforms that address challenges ranging from the scale of deployments to security and compliance.

    It’s too early to say how the next major CI/CD battle involving the shift to microservices will play out. However, if history is any guide, there should be plenty of room for both open source and proprietary CI/CD platforms.

    — Mike Vizard

  • Open Source Versioning: The Race to Stay Up-to-Date

    Open Source Versioning: The Race to Stay Up-to-Date

    Open source libraries, once shunned as risky and not ready for prime time, are now used extensively across major corporations, including insurers. The reason is simple: In time- and resource-constrained companies trying to stay technologically competitive, it doesn’t make sense anymore to try to reinvent a wheel that’s already been battle-tested. However, having made the commitment to open source code and solution sets, it’s imperative to keep up-to-date with open source library maintenance and updates.

    The Risk of Open Source

    Some active open source libraries are updated multiple times a year. Getting out of date means missing out on newer features. Also, if the gap between upgrades bridges several iterations, some future upgrades may not be backward-compatible, causing functional problems at best and risk exposure problems at worst. On occasion, an out-of-date open source library version can expose a system and a company to attack. In 2017, a major U.S. financial company was hit by a hack that exposed the information of millions of customers. The hackers had exploited a software vulnerability that had been public for a month, but the company had not patched its system in time. There are several other well-known examples of a similar vein.

    Keeping current is not easy. Upgrading may be costly, but falling behind can make it costlier to catch up. The question is, How frequently should one upgrade to the newer versions?

    The Effort and Cost

    One of the reasons companies choose not to upgrade every time there’s a new release is the cost involved. While the open source code itself is free, the effort required in time and resources can be substantial and can take valuable resources away from higher priority business-technology initiatives. An additional concern is that, even though the upgrade is supposed to be backward-compatible, there is no way to verify that without actually performing the upgrade. If there are compatibility problems, then a larger effort ensues involving upgrading, restoring or rebuilding a system. Any large system has to be tested thoroughly after upgrading, and without the help of automated tools, testing can be costly and time-consuming.

    One approach for mitigating these costs and risks is the process of continuous integration (CI) for open source libraries. A good suite of automated testing tools provides a high degree of confidence that nothing has been broken by the most recent upgrade, before it is implemented into any production environment. However, without automated tests that flush out potential issues from upgrading, the risks and costs are high enough that companies have a hard time keeping up and managers become more motivated to delay upgrades than to perform them. That’s why it’s important that companies employ CI and continuous delivery (CD) processes that include robust automated testing.

    Additionally, the use of microservices—an increasingly effective and popular way to construct systems—puts another twist into the efforts and costs of keeping open source libraries up to date. Individually, each microservice might be quick to test. However, if an application has been broken into 50, 100 or even more microservice components, even a small amount of manual work testing each component will add up quickly. Additionally, in an environment that has deployed microservices broadly, there may not be a business need to change some services for months—that is one of the benefits of using microservices.

    The Right Approach to Open Source

    There is a right way to deal with open source library updates that has the benefit of taking advantage of new functionality and code stability in a low-risk, low-effort and low-resource manner as follows:

    Planning: Enterprise and application architects should be vigilant regarding the road maps of any large frameworks that employ open source libraries as a key component to any project or initiative. Proactive identification of open source libraries that may need to be upgraded is key. Likewise, application project managers should make open source library upgrade part of a regular and ongoing project plan. For example, when microservices are involved, they should be classified proactively as services by the libraries they use, as a way to identify the few services that would normally be upgraded first. This has the benefit of providing a few sprints’ worth of feedback before rolling out the upgrades to other libraries.

    Monitoring: Open source version monitoring is essential. There are products that can help to identify and report library versions that have vulnerabilities. Such monitoring can and should be used as part of the CI/CD pipeline and also to monitor artifacts that already are deployed in production. Monitoring processes also can report when newer open source library versions are available, even if the incumbent library has no reported vulnerabilities.

    Automated compatibility triage: It is often too risky to set up production builds to always use the latest version of an open source library. However, separate automated processes can identify new versions, run them through a build and test process and report back the results. If a test fails, the development team gets an early warning that their code is not compatible with the upgrade version. This helps to plan and schedule fixes, and if a vulnerability is discovered in the current version, this kind of proactive planning enables a quicker resolution and turnaround.

    Processes: Strong processes, preferably automated ones, are the foundation of open source versioning. For critical security upgrades, a process must be in place to triage and prioritize identified changes. For other version updates, good processes can help make upgrades easier. For example, a standard and repeatable process may incorporate minor version upgrades into the regular flow of sprint work, thus saving time while mitigating risk.

    Open source versioning can be difficult, but it doesn’t have to be. With automated testing, good monitoring tools and some proactive planning, the costs and risks of staying up to date can be kept to a minimum, allowing companies to reap the benefits of new features and functions.

    — Darius Cooper

  • Best Practices for DevOps in the Cloud

    Best Practices for DevOps in the Cloud

    DevOps is commonly defined as a methodology that combines software development with IT operations. The goal is to shorten a system’s development life cycle while delivering features, fixes and updates frequently in close alignment with business objectives. Putting DevOps into practice is an ongoing experiment for many organizations.

    Developers often struggle with continuous integration (CI) or continuous delivery (CD) performance, testing delays and other bottlenecks. In fact, one survey reported that only 34% of projects finish on time and only 42% come in on budget. Security and development teams must collaborate to keep up with the rapid development life cycle without sacrificing security with every update.

    Enterprise SaaS apps are not distributed like traditional software—they are continuously running services. So, CD is all about updating the service with a set of changes. In public clouds such as AWS and Heroku, this is done through pipeline stages (e.g. dev, test, staging and production). In platforms such as Salesforce, stages become sandbox environments, ephemeral scratch orgs and production instances.

    How can development teams shorten the development life cycle without sacrificing the integrity of the features and updates? In this article you will learn key DevOps practices to achieve predictable, reliable release management.

    Advanced Planning Ensures All Boxes Are Checked

    Agile planning is now de rigueur for enterprise development. It is best used if:

    • The product itself will most benefit from flexibility.
    • Regular face-to-face interactions and collaborations are needed between team members.
    • The end product requires regular updating, monitoring and continuous delivery to the client throughout the life cycle.

    For CD, ensure your user stories are sized correctly and that each story rolls up to an Epic that represents a standalone feature. This enables your team to release bite-sized pieces of functionality that are consumable by users and traceable back to your release plan. Also, define acceptance criteria for use in the verify stage so you know when something is done-done.

    Manage the Source Code, Especially When Working in a Shared Environment

    There are a few practices of app creation that impact CD. First, source code is not the only element of an enterprise solution. Schema, user interface, access control rights and static resources such as icons and images are all part of the creation process and should be managed just as diligently as source code. They should all be checked in to a version control system (VCS) as a single source of truth.

    Second, ensure that developers are making changes in a segregated environment. In some low code platforms, such as Salesforce.com, this becomes a challenge, but even in a database, multiple database administrations (DBAs) can step on each other’s changes when working in a shared environment.

    Functional Testing

    Automated quality processes are difficult to implement, but essential Selenium is a great tool for testing functionality and should be part of your DevOps practice. But there are several verifications that should be made before you get to functional testing. Static code analysis tools, such as PMD, are essential to ensure your development team is coding against a single style.

    Define a team style and enforce its use. Unit test coverage is also essential—incorporate them with a coverage of at least 75%. Finally, after these automated tests pass, implement a manual peer review. Old hands are able to spot opportunities for performance improvement where automated tools may not.

    Changes Should be Released in a Defined Pipeline with Strict Quality Gates

    Packaging for CD is about capturing changes that can be incrementally released into the next stage or environment. Development teams should dedicate a branch for each stage and bundle incremental changes into a promotional branch to leverage the merge conflict detection in your VCS.

    Changes should be released in a defined pipeline with strict quality gates that ensure the verification steps and enforce the order of release stages. Developers should not be able to bypass key stages throughout the development cycle—for example, moving from development to production.

    Focus on making smaller changes, which result in reliable, predictable releases. Finally, be sure to automate promotions. This enables your team to validate the promotion scripts in integration, test and staging before releasing to production, which decreases the likelihood of an unhappy surprise.

    Automate Configuration, Especially for End User Access Rights

    Make testing for proper configuration part of your verification process. Platforms such as Salesforce have powerful profiles and permission sets that enable user access to only the right information. Improper configuration can expose personally identifiable information (PII), credit card numbers or medical health data.

    Monitor for More Than Just Service Availability and Performance

    Most SaaS companies monitor service availability and performance. But excellent companies also monitor data access to detect improper configuration changes and monitor end user feature usage, which gives product managers visibility to their usage.

    — David Brooks

  • CloudBees Allies with Atos to Accelerate DevOps Adoption

    CloudBees Allies with Atos to Accelerate DevOps Adoption

    In a move that should accelerate adoption of best DevOps practices in the enterprise, CloudBees and Atos announced this week that the two are collaborating to advance adoption of continuous integration/continuous development (CI/CD) platforms on the Google public cloud.

    Announced at the Google Cloud Next 2019 conference, the alliance will result in the IT services giant delivering a managed instance of a CloudBees CI/CD platform running on the Google cloud, in addition to providing traditional consulting services.

    Francois Dechery, chief strategy officer for CloudBees, said the alliance with Atos will accelerate adoption of DevOps processes in traditional enterprise IT organizations as Atos consultants engage customers looking to modernize their application development and deployment processes. In fact, many of the principles first pioneered by proponents of agile development methodologies are now being applied to business process management, he noted.

    Atos plans to add a DevOps practice as a complement to its existing processes. Michael Kollar, senior vice president for cloud engineering, said the company expects that, for the foreseeable future, most of their clients will be trying to meld some degree of DevOps and existing ITIL-based approaches to IT services management (ITSM). The alliance with Google will go a long way to accelerating that transition because it will allow Atos to deliver access to a CI/CD platform based on a consumption model that reflects the way public cloud infrastructure is consumed, he said.

    Kollar noted enterprise IT organizations are under more pressure than ever to deliver applications faster as more organizations recognize they are a software company that happens to make something. Most organizations today need to create a superior customer experience through software to differentiate themselves from their competition, he said.

    Many of those companies will need help setting up the processes that will enable them to function as a software company, he added. The biggest challenge, however, is finding a way to meld new ways of building and deploying applications with investments in legacy systems on which the business still depends, he said.

    Naturally, Atos won’t be the only IT services firm to launch a managed DevOps process. But as more IT services firms invest in developing managed services, there will be need for a balance between the managed services provided by IT services providers and cloud service providers such as Google and the IT services that will continue to be managed and delivered by internal IT organizations. The degree to which organizations will rely on external IT services firms for DevOps will be dictated by how mature they are today. But it does not follow that an organization which sees a need to rely on external expertise today will be that position tomorrow. As more organizations develop internal expertise, a managed service provider will need to earn its seat at the table every time its contract comes up for renewal.

    — Mike Vizard

  • 5 DevOps Trends Worth Knowing in 2019

    5 DevOps Trends Worth Knowing in 2019

    DevOps today is more than the buzzword it was 10 years ago. Back then, the idea of combining development with production in your IT infrastructure was not common; the logistics were nonexistent and most of the time businesses decided it was far too much effort.

    However, if the last nine years has taught us anything, it’s that DevOps is worth every penny businesses invest. It helps companies streamline production, keep customers happy and provide agile services to attract new audiences.

    But as with anything in the IT field, there is a paradigm of change. This article discusses some of the top DevOps trends happening now and how to implement them in your own system.

    Automation Will Be a Bigger Focus

    Automation has always been the way for businesses. Whether it’s speeding up the pipeline with machines, providing better response times for angry customers with chatbots or better inventory management with tracking and logging system, automation is behind it all.

    DevOps is no exception.

    But as with everything, there can be too much automation. The best thing to do is break down processes and find simple, redundant tasks that can save time if automated and apply the changes.

    The most important aspect of automating DevOps is to understand the six pillars in the DevOps cycle, which are:

    • Continuous business planning
    • Collaborative development
    • Continuous testing
    • Continuous release and deployment
    • Continuous monitoring
    • Collaborative customer feedback and optimization

    DevOps Assembly Lines: The Next Big Thing

     

    To track the development of your application, we have pipelines. These visually represent the product from its initial stage right through until final development and release.

    However, continuous integration (CI) is no longer the priority focus when it comes to effective monitoring and implementation. Continuous delivery and automation are a major part that businesses have already started delving into in 2019.

    This is where DevOps assembly lines enter the picture.

    Assembly lines are focused on bridging the gap between manual and automated tasks, ensuring there is no redundancy while providing several tools for teams to implement, to ensure apps are hitting the production lines as reasonably quickly as possible.

    Microservices Architecture Adoption Taking Off

     

    Microservices architecture may as well be that new kid in school trying to fit in. These smaller services compound into agile, implementable tools that DevOps teams can use to scale and test software over the course of weeks—not years.

    As you can imagine, this can help some businesses streamline their development and production lines, setting them way ahead of their original production estimates—which is never a bad thing.

    Implementing microservices into your DevOps team can also help companies focus on the runtime and efficient delivery of new development sources, without the hassle of creating dependency errors when something decides to bug out for no apparent reason.

    Security Needs to Step Up

    Cybercrime is on the rise—we all know that’s old news. But as a business, cybercrime can either make or break your sales and weigh down your DevOps team.

    That’s why more companies are hopping onto enterprise security options. Although there are third-party programmers for almost every situation you need, none of them have the same security levels as the tools from the enterprise version provides. Safeguarding both your company and your clientele.

    Riding the Artificial Intelligence Wave

    Finally, we have artificial intelligence (AI) and machine learning (ML). When you think about it, these two elements are literally the sum of everything we want in the DevOps community—the ability to crunch out hours upon hours of menial labor and saving your teams hours to focus on higher-priority tasks.

    The combination of AI, used to predict algorithmic influencers, and ML’s ability to adapt to new situations will be key for DevOps teams to get to the next level in 2019.

    — Gil Artmoore

  • The Linux Foundation Launches Continuous Delivery Foundation

    The Linux Foundation Launches Continuous Delivery Foundation

    The Linux Foundation announced it will provide the home base for a vendor-neutral Continuous Delivery Foundation (CDF) committed to making it easier to build and reuse DevOps pipelines across multiple continuous integration/continuous delivery (CI/CD) platforms.

    The first projects to be hosted under the auspices of CDF, which was launched at the Open Source Leadership Summit conference, includes Jenkins, the open source CI/CD system, and Jenkins X, an open source CI/CD solution on Kubernetes. Both were developed by CloudBees. Netflix and Google, meanwhile, are contributing Spinnaker, an open source multi-cloud CD solution, and Google is also adding Tekton, an open source project and specification for creating CI/CD components.

    Additional projects are expected to join CDF once a Technical Oversight Committee (TOC) is formally named.

    Founding members of the CDF include Alauda, Alibaba, Anchore, Armory, Autodesk, Capital One, CircleCI, CloudBees, DeployHub, GitLab, Google, Huawei, JFrog, Netflix, Puppet, Red Hat, SAP and Snyk.

    Chris Aniszczyk, vice president of developer relations for The Linux Foundation, said that while a lot of progress has been made over the years regarding adoption of CI, the challenges associated with mastering CD have proven more vexing. To address that issue, the CDF will evangelize CI/CD and DevOps methodologies, define and document best practices, provide guidelines and create training materials to better enable organizations to implement CI/CD best practices.

    Kim Lewandowski, a product manager for Google Cloud, said making it possible for organizations to reuse DevOps pipelines is a high priority. Building pipelines is a significant challenge for most DevOps teams; as such, they need to be able to reuse those pipelines across as many CI/CD platforms as possible.

    Kohsuke Kawaguchi, creator of Jenkins and CTO at CloudBees, noted the creation of interoperability standards between CI/CD platforms will go a long way toward achieving that goal.

    It’s not clear yet just how widely the CDF will be supported by the entire DevOps community. While CloudBees provides one of the most widely employed CI/CD platforms, other offerings have started gaining traction, especially among enterprise IT organizations that tend to not have a lot of internal DevOps expertise.

    On the plus side, the CDF should help spur adoption of DevOps best practices even further. Adoption of DevOps processes within most enterprise organizations tends to be uneven at best. One team may be employing DevOps extensively, while the rest of the organization continues to rely on less agile legacy processes.

    The CDF also should play a significant role in enabling organizations to embrace microservices-based applications built using containers. While Jenkins is the most widely relied-on CI/CD platform today, it is built on what is now considered in many quarters to be a legacy Java Virtual Machine (JVM) platform. In contrast, Jenkins X Background an open source CI/CD platform for building and deploying modern cloud-native applications on Kubernetes. The Linux Foundation also plays host the Cloud Native Computing Foundation (CNCF), which oversees the development of Kubernetes.

    It still may take years for IT organizations to fully make the transition to DevOps and cloud-native applications. But in the months ahead, it’s clear the CDF intends to function as a force multiplier in enabling organizations to achieve that goal.

    — Mike Vizard

  • Akamai Extends Scope of DevOps Reach

    Akamai Extends Scope of DevOps Reach

    Akamai today moved to further extend the number of capabilities it exposes via its content delivery network (CDN) that are designed to appeal to DevOps teams.

    Those enhancements include HTTP/2 performance optimizations and the ability to automatically load font libraries, as well as providing access to “middle-mile” logs that will enable DevOps teams to more precisely investigate performance issues and test logic in a local development environment before moving those changes into production.

    Akamai has also re-engineered Control Center to provide more detailed reporting across security, acceleration and delivery functions, and made TLS 1.3 the standard mechanism for establishing connections.

    Finally, Akamai is also looking to advance DevSecOps processes. Its CDN now can optimize or block access to content within a fully integrated virtual private network and domain name system proxy detection service. Akamai’s Token Authentication capabilities have been extended to include coverage for browsers and devices that do not support cookies.

    Ari Weil, vice president of product marketing for Akamai, said these latest extensions are part of an ongoing effort to make the company’s CDN a natural extension of any DevOps process. Developers today often wind up wasting a lot of time and effort writing code to load fonts that now can be automated using via the Akamai CDN, for example. The enhancements should free them to write code that adds more value to the business, he said.

    Akamai is also promising DevOps teams they will see much faster activation times across Akamai CDN, as well as have deeper visibility into application performance issues beyond what most application performance management (APM) tools offer, added Weil. Akamai is especially focused on any application development project where service level agreements need to be both achieved and maintained, he said.

    Thus far, Weil said Akamai is finding a higher level of appreciation for the role CDNs can play in DevOps. CTOs and enterprise architects who are typically held responsible for achieving application delivery goals in particular are now taking notice of CDNs’ capabilities, as most individual developers aren’t usually focused enough on finding ways to automate the routine aspects of building a modern web application, he said.

    Akamai will continue to focus on making its CDN a natural extension of the continuous integration/continuous deployment (CI/CD) platforms on which DevOps processes are implemented, with an eye toward making its CDN a preferred deployment platform for web and mobile applications. It may take while longer before DevOps teams view CDNs as a deployment platform for their applications. Much of the decision regarding what CDN to employ historically has been been left to application owners. But Akamai is clearly betting that if more applications take advantage of CDN functionality as they are being built, there’s a much greater likelihood those applications will be distributed on the Akamai technology.

    — Mike Vizard

  • DevOps Chat: JFrog Acquires Shippable

    DevOps Chat: JFrog Acquires Shippable

    The big news in DevOps today was the acquisition of Shippable by JFrog. This adds a CI/CD solution to the JFrog Enterprise+ platform and further expands JFrog’s end-to-end DevOps offering beyond Artifactory and more.

    In this DevOps Chat, we speak with Shippable CEO Avi Cavale, JFrog CEO Shlomi Ben Haim and JFrog VP of Marketing Ayally Goldschmidt about the thinking behind this acquisition and JFrog’s plans going forward.

    As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

    Transcript

    Alan Shimel: Hey, everyone, it’s Alan Shimel, devopsy.kinsta.cloud, you’re listening to another DevOps Chat. Today’s DevOps Chat has some breaking news. It was just announced this morning—JFrog has acquired or merged with Shippable in a rather, you know, this is big news within the DevOps world, and we’re very, very happy to be joined by the CEOs of both Shippable and JFrog. From Shippable, we have Avi Cavale, and from JFrog, of course, our friend, Shlomi Ben Haim. And joining us from JFrog is Ayalla Goldschmidt, who really runs marketing at JFrog. I’m not sure of your exact title, Yes, Ayalla?

    Ayalla Goldschmidt: VP of Marketing, thank you, Alan.

    Shimel: VP of Marketing—thank you for joining us. So, first of all, to all three of you, congratulations, Mazel Tov as they say in Seattle. [Laughter]

    Goldschmidt: Thank you, thank you.

    Shlomi Ben Haim: [Laughter] Thank you, Alan.

    Shimel: Thank you. And so, you know, Avi, let’s turn it over to you first. I think a lot of our audience is familiar with JFrog, and most of our audience have heard of Shippable, but let’s just lay that right out there. What’s Shippable about?

    Avi Cavale: Shippable is about a modern CI and CD platform. So, our focus is to streamline the delivery—packaging and delivery of software, and that’s kind of where we are focused on.

    Shimel: Fantastic. So, Shlomi, I think I already know the answer, but I’m gonna ask you—why Shippable for JFrog?

    Ben Haim: That’s a great opening question. Actually, Alan, you know JFrog very well. You know that everything starts with the culture, and when we met Avi and the team, it looked like we’d found the brother Frogs in a different company. So, for us, it was just to make sure that the technology and the strategy are aligned. And when we looked at the technology and the next generation of CI/CD that was built by the Shippable team with Avi’s leadership, it was a no-brainer for us.

    Shimel: Absolutely. But the other thing I think we should mention is, you know, JFrog, many people know JFrog from Artifactory, maybe Xray, you know, point solutions that we can call up. Artifactory is a whole platform in and of itself.

    But, really, the big move for JFrog—and if I’m wrong, correct me; Ayalla, you’re the Marketing person—the big move for JFrog was, you know, this JFrog enterprise platform. And, to me, if you’re gonna have an enterprise platform in the DevOps space, you need that CI/CD pipeline kinda delivery capability.

    So, to me, you know, this really kinda helps fulfill that vision of the JFrog platform. Yeah, no, wrong?

    Goldschmidt: Yeah, that is exactly right, Alan. That’s the vision that we have for it. Obviously, we’ll be doing a lot of work here in the coming weeks to clarify the roadmap and the timeline, but you hit the nail on the head. That’s the value that we’re seeing for our customers and what they’re looking to, what they’re asking us for as far as, you know, we love JFrog, we have very happy customers, they love what we do, and they’re looking to take it to the next level.

    Shimel: Excellent. So, let me ask my next question to Avi and Shlomi, and that is, you know, I guess it’s part of the maturation of the DevOps market where all—you know, there are now, everybody wants to offer the whole enchilada. Do you know what I mean?

    Ben Haim: [Laughter]

    Shimel: People aren’t content any more just offering a piece of it, we wanna offer it all, that whole SDLC, we’re gonna help you throughout that life cycle. It seems everyone is pointing towards that, and the money—look, JFrog, it’s no secret, raised $165 million. Some of your competitors have raised also eight figures. That’s where the smart money’s going, towards companies that are building out this end-to-end DevOps framework.

    Avi, is that what you saw at Shippable, and is that what attracted you guys to want to do this deal with JFrog?

    Cavale: Yeah, I think what we are seeing is that there is one thing which is very critical for customers. It’s like—yes, they want the whole enchilada as a single platform, but at the same point in time, they also want a platform that is open, and they want to make sure that they can plug in the tools that they like in certain places.

    So, of course, they want to see the native capability end to end, but extensibility is also super important. And so, what we kind of saw with what JFrog was doing and what we were doing also was that we were being open to everything. I mean, yes, we want to have a standard of how we think about an end to end platform, but we want to be open and make sure we embrace all the practices that developers want to do and extend the platform to DevOps capabilities.

    Shimel: Absolutely. So, Shlomi, Avi makes a very good point here, and that also goes to the heart of JFrog. One of the things about JFrog is that they play nice with everyone, basically, right? You could pick whatever CI/CD platform you wanna work with or whatever—you know, whether it’s Puppet or Chef or the Red Hat software, you know, JFrog works with everyone, so to speak.

    But now, you have an in-house CI/CD solution, so how do you balance that in your go to market?

    Ben Haim: That’s a great question, Alan. I think that what we’ve started to see in the market for more than 12 months now is that DevOps is maturing and the organization and enterprises are looking to get an end to end solution, yet the driving force of DevOps production is still in the hands of the developers, which, obviously, would love to see the freedom of choice and the best of breed options kind of open to them.

    So, you are right. Our universal approach is something that always led us. We always provided our users with the power of choosing their tools pack, and it will still be the case.

    However, on the JFrog platform, what we call the enterprise class, we want to make sure that we take artifacts seriously, from the moment you build it from code all the way to production. And, together with Shippable automation power, together with the integration and the visibility that technology like Shippable can provide to the platform, I think we will be able to combine the two, to allow a better universal approach. So, you can still use your Jenkins, your CircleCI, your other DevOps tool sets. But you will also have a JFrog end to end solution that takes you all the way from code to production.

    Shimel: Excellent. So, Avi, you know, how do you—I’ll reverse, mirror that question back to you, right? How do you see the Shippable team, the Shippable product fitting into that JFrog Enterprise Plus, you know, the Artifactory platform, all of the different tools that JFrog and services that JFrog is putting together—how do you make sure you fit in there?

    Cavale: So, as Shlomi mentioned, right, what is happening is—so, the artifact is something that is immutable, and that’s something that you build and you want to kind of take it through your entire value chain of how you deliver software to your end customers or end devices or whatever they might be.

    The issue is that, if you don’t have the pipes to kind of control that in a high fidelity fashion, you lose a lot of information as you go from stage to stage. Because you’re leaving it up to the customer to make sure all the data is being persisted and you’re keeping all the hooks so that eventually what you’re really trying to do is, you want to be able to go to something that’s running on the end device and be able to track, if there are problems, what are all the pieces that went into actually building that piece of software that is running there?

    So, losing that ability to connect that entire life cycle, all the way from code to the point where it’s running on a device is a very critical piece of DevOps. And what we see is, that kind of, now, our marriage to the whole Artifactory plus Xray and plus distribution, all of those pieces now can be connected through a common pipeline and we’re making sure that we have high fidelity information exchange as things move through this work flow end to end. And I think that’s kind of the critical thing that we are adding to the product.

    Shimel: Excellent. Ayalla, a question for you—you look at, all of a sudden, you’re embarrassed by the riches of JFrog in terms of their product, right, in terms of the product that you have to work with, the products that you can bring to market. But at the same time, at some level, it’s a double-edged sword from a marketing perspective, right? You have so much now, too, that you need to market, that you need—how do you make sort of a holistic message for market that includes all of these pieces and how they fit together and how, if you don’t want to use all the pieces, you don’t have to, either?

    Goldschmidt: You know what, I feel like the luckiest marketing person on the planet. And, you know, Shlomi promised me when I joined this company a little over a year ago that there will be no shortage of news, and he has delivered.

    Shimel: [Laughter]

    Goldschmidt: So, since I’ve joined, the acquisitions, our Series D announcement, and of course, all of the new technologies that we’ve supported along the way, and the most recent exciting edition of support for Go and Go Center, we love all of these audiences and we do actually put in a big effort in tailoring our message to make sure that we’re communicating with a developer first mindset, and that seems to be working for us.

    So, you know, until today at JFrog, everything we’ve built has been through an inbound marketing funnel with an inside sales team. We haven’t had field people knocking on doors, and that seems to be working great for us, and now we’re ready to take it to the next level. But we’ll always remain developer first.

    Shimel: Excellent. Let me—Avi, let me ask you some sort of typical M&A kind of questions. So, is your whole team staying on as part of this acquisition?

    Cavale: Absolutely, and we’re all joining the JFrog family, and so there is really no change to the business and how we are running it. And I usually tell my team that I have a new boss, that’s all—nothing else is changing, and we’re gonna keep marching towards the vision, and all we have is an opportunity to broaden that vision that JFrog brings to the table and we are part of a much bigger family than what we were before.

    Shimel: Excellent. And so, Avi, what do you see particularly as your role going forward, here?

    Cavale: Sorry, was that for me?

    Shimel: Yes, specifically you—what’s your role going forward? Is it just heading up Shippable? I mean, I’ve been in your role, to tell you the truth. I’ve had my company acquired more than once. And, while you still want to maintain your team and run the team, you also need to integrate now, right? You’re part of an executive team at JFrog that has—I will tell you, I think one of the best cultures in the DevOps world or in the tech world, period.

    You know, how do you see yourself? How do you see this changing your role? It’s more than just having a new boss.

    Cavale: I think the way—I’m actually in Israel right now, and we have already started collaborating. So, one of the things that I actually see is that the team is like, it’s all about brainstorming, quick integration. So, my role is to make sure that I’m delivering the products that JFrog’s customers love as well as most importantly the trust that it actually runs the way it needs to be running. And we’ve focused on the CI/CD aspect of it; nothing is changing from that perspective.

    But what I have now is more brains who are kind of helping me think through what we need to actually do so that we are focused on the enterprise and driving towards that, so that’s kind of how I see myself, as part of the team.

    Shimel: Excellent. So, Shlomi, let me ask you, now—what’s next? What worlds are left to conquer? What pieces of the puzzle are missing? What’s next?

    Ben Haim: You know, Alan, I’m sitting here and listening to Ayalla and Avi and this is great. And from people from outside JFrog, they might think that JFrog is trying to complete the pipeline with all kinds of pieces.

    But the one great feedback that I’m getting from the community is that there is no question mark. People understand what are we doing, it all makes sense. Every tier, every brick that we put on the DevOps wall sounds like the right, next logical step.

    But we are the binaries people, and we will stay the binaries people. We will just make sure that this pipe is completed, and when we speak about the liquid software vision, when we speak about continuous update and solving the pain for the DevOps world, we are taking it seriously, and, as you see, we are super determined to complete our mission.

    What next? We have to stay focused, we have to be a great solution to our customers and users as a community. We are very active in the community, providing them with more tools and more capabilities. It is now our responsibility to make sure that Shippable is fully integrated and the user experience is smooth and fun to use, and as Ayalla mentioned, thinking of the developer first and not the full platform story, but the user experience and the fun and simple-to-use solution.

    Shimel: Excellent, excellent. Alright. Guys, we’re about out of time, I think. We’re probably over time. But again, Avi, congratulations. Welcome to the JFrog family.

    Cavale: Thank you.

    Shimel: It’s an amazing culture, and I’m sure you probably already know that, but you’ll continue to find out. Shlomi, my friend, congratulations to you. Keep up the great work. I can’t wait to see you.

    Ben Haim: Alan, thank you.

    Shimel: Thank you.

    Ben Haim: Thank you so much, partner. Thank you so much.

    Shimel: Alright. And Ayalla, always a pleasure.

    Goldschmidt: [Cross talk]

    Shimel: You, my friend, have work ahead of you now. [Laughter]

    Goldschmidt: [Laughter] Yes, I do. The work is just beginning.

    Shimel: Good for you.

    Goldschmidt: Thanks for having us on.

    Shimel: Alright. So, big news today—JFrog acquires Shippable, and another brick in the wall, as Shlomi mentioned. I tend to think of it as more of a Pink Floyd song than any political thing, but it certainly is continuing this DevOps maturation.

    Guys, congratulations. We’ll see you all soon. And for now, that’s a wrap on this DevOps Chat. This is Alan Shimel for devopsy.kinsta.cloud. Have a great day, everyone.

    — Alan Shimel

  • Survey: DevOps Progress Slow, but Steady

    Survey: DevOps Progress Slow, but Steady

    Atlassian has published the results of a survey of 500 IT and software professionals that suggest now is the best and worst of times when it comes to DevOps.

    On the plus side, the survey found that more than half of respondents (57 percent) are encountering fewer bugs and outages after deploying a continuous integration/continuous deployment (CI/CD) platform. Nearly half (47 percent) of those who have adopted a CI/CD platform also report they make changes and receive customer feedback faster. A full 71 percent who have embraced microservices have also discovered it is much easier to test and deploy new software features, according to the survey results.

    However, the survey found three-quarters (75 percent) of development teams face issues with bugs, defects or delays when it’s time to release. A total of 73 percent of software development teams also reported spending 10 percent to 50 percent of their time on updates and upgrades to self-hosted software. On average, according to the survey results, teams rely on 4.3 tools to move code from development into production environments.

    More frustrating, 62 percent of respondents reported they resort to performing manual testing due to insufficient automated test coverage, additional manual processes or a lack of build/deployment pipeline automation. However, among those organizations that have adopted feature flagging to ease management of the application development process, 63 percent report better testing a feature and higher overall rates of software quality.

    The metric IT organizations are employing to measure DevOps success appears a little soft. A full 93 percent of respondents consider customer satisfaction to be the most important DevOps metric, but 60 percent admit it’s difficult to measure customer satisfaction for the features that have been developed.

    Sean Regan, head of growth for software teams at Atlassian, said that while there is clearly much work still to be done, the democratization of DevOps continues unabated. Rather than being limited to a few high IT practitioners, Regan said DevOps processes increasingly are being pushed into the realm of everyday enterprise IT operations. At the same time, many line of business executives are being included within those teams to ensure the software being developed achieves the desired business outcome, noted Regan.

    IT organizations are also starting to apply more engineering principles to the management of IT infrastructure, added Regan. In many cases, IT organizations are discovering a single engineer can be more efficient than 10 systems administrators. However, finding and retaining those engineers is a major challenge. The goal needs to be to create a set of DevOps processes defined by an engineer that are simple enough to be implemented by IT administrators, said Regan.

    Of course, many of those IT administrators today are schooled in less agile ITIL processes. But as ITIL continues to absorb some of the concepts and best practices pioneered by the DevOps community, the divide between engineers and traditional IT administrators should become that much more narrow to bridge.

    — Mike Vizard