Tag: open source

  • The Top 10 Reasons to Use Cassandra

    The Top 10 Reasons to Use Cassandra

    The Apache Cassandra database is the right choice of database if you are looking for scalability and high availability without compromising performance for your mission-critical applications. Additionally, Cassandra’s support for replicating across multiple data centers is best-in-class, providing lower latency for users and the peace of mind of knowing that you can survive regional outages. To that end, we’ve compiled a list of the Top 10 reasons why enterprises onboarding and deploying mission-critical applications should use Cassandra (Apache Cassandra, DataStax Enterprise).

    1) Requirement for fast writes: Easily deals with data velocity, data variety and data complexity issues

    Many of the challenges associated with next-generation cloud applications center around data volume and data velocity. Is Cassandra able to handle the speed of data coming into the system? The answer is “yes” based on the amount of data and cluster size. Not only does Cassandra come with this ability out of the box, but there are systems of data pipeline architectures being built around ingestion speed. And to top it off, it scales linearly, making it easy to determine the right amount of capacity based on data flow.

    But, there are also two often overlooked components it provides: 1) data variety and 2) data complexity. Data variety is an alternate way of saying that data coming into one database can come in different forms. An example of this would be sensor input from a heart monitor and sensor input from an IV both for the same patient. The second component, data complexity, extends the previous example. The heart monitor might report 100 metrics twice per second under normal operating circumstances and up to 125 metrics once per second while the wearer is sleeping. This means the write patterns, locations, and frequencies can vary. Cassandra handles these situations gracefully.

    2) Can handle massive data sets

    If there were any questions about whether Cassandra is capable of handling large data sets, there is no need to look any further than the companies using it. They operate at massive scale—Netflix, Hulu, Instagram, eBay, Apple, and Spotify all have Cassandra working in interesting ways as part of their offerings.

    The other way you know Cassandra is up to the challenge is in use case examples. Many organizations use it for applications where data grows in an unbounded way very quickly. These include Twitter clones, a web log analytics data warehouse and telemetry or sensor data.

    3) Homogeneous environment

    Unlike some of the legacy distributed systems, Cassandra does not require outside support for synchronization. All of the required components for basic operation are built in. Since Cassandra also operates in a peer-to-peer fashion, this means that there is no master-slave or sharding setup and that all nodes in the ring are equal. Additionally, there is only one machine type that an administrator needs to worry about.

    4) Highly fault-tolerant

    Cassandra employs many mechanisms for fault tolerance. Since it is masterless, there is no single point of failure. There is also the potential for zero downtime rolling upgrades. This is because Cassandra can support the temporary loss of multiple nodes (depending on cluster size) with negligible impact to the overall performance of the cluster.

    The safety net Cassandra offers extends outside of your data center as well. Cassandra allows you to replicate your data to other data centers and keep multiple copies in multiple locations. This helps satisfy many regulatory requirements in addition to being a part of an strong disaster recovery and business continuity plan.

    5) Proven success across enterprise applications and in many use cases already

    There are already many examples where Cassandra is being used effectively. Banks and other financial institutions are storing large quantities of financial data in Cassandra. Analytics companies are using Cassandra to store web analytics data. Medical companies are using Cassandra to store sensor data and other time series inputs. There are also many companies making use of Cassandra for storing internet of things (IoT) data.

    6) Ease of administration

    Cassandra is a straightforward system to administer. With Cassandra being a masterless system, all nodes in the ring are the same—a homogenous system. It’s fault-tolerant and can support the temporary loss of nodes with minimal impact to production performance. This means that nodes are easy to replace and the requirement to replace downed nodes immediately isn’t as strict.

    7) Custom tuning

    There are a lot of knobs and levers that can be turned to get Cassandra to perform optimally for your workload and environment. You can set it up to operate in a way that is consistent with your workload. For example, if you write lots of log data and read infrequently, then there are configuration tweaks to be made for write-heavy systems. If you write heavily to one data center and then do all your reading from another data center, then you can adjust the settings on a data center-by-data center basis.  This idea of tuning isn’t just available at the application level; you can also tune the JVM and Java settings, including GC and logging levels. Changes can even be made by the drivers at connection time to aid in the performance of your system.

    8) Easy to integrate core applications

    A lot of work has been done on data manipulation and parsing systems to integrate with Cassandra. For instance, the full text search engine Apache Solr has been packaged to work with Cassandra to provide full featured search capabilities to an existing Cassandra database. Apache Spark, a big data analytics engine, also has been plugged in to work on an existing database. There are entire suites of tools that can be integrated or bolted on to increase its capabilities. These include Apache Mahout, Kafka and Zipkin, to name a few. This is important because the more tools you have available to you, the more powerful your data becomes. You also have the ability to gain more insight about your data without having to build and maintain the application systems that were previously required.

    9) Excellent Monitoring Options

    Included in the system of tools referenced in No. 8 are monitoring packages. If you are a user of automated monitoring platforms such as Datadog or Netuitive, you’ll find examples of prepackaged agents to monitor the important parts of Cassandra. You can then tack on your own additions of other metrics that are important to you. This is made possible by Cassandra taking advantage of Java MBeans and exposing them to the client. You can use these to get at much of the internal information Cassandra uses to make its own decisions and decide on its own health. Datastax also offers its own monitoring and control application called Opscenter.

    10) Amazing community

    One of the best things about any piece of software is having a great community of developers and experts available to you for help or guidance. There is a huge yearly database summit put on by Datastax, the primary backer and largest contributor of code to Cassandra. It also sponsors community events all over the world so you can meet and interact with other developers around you.

    For open-source software to be successful, there needs to be an ecosystem that develops around it. In the case of Cassandra, there are consultancies, monitoring and troubleshooting systems, plugins, instrumentation systems and backup systems. That is all a set a competencies that your organization no longer needs to own and can use what the greater community has already created. There are even PaaS companies that will completely take over the management for you, leaving you just the development of your application to focus on.

    Given the sizable number of organizations and people that are a part of the ecosystem and the Cassandra community as a whole, there is no shortage of articles, documentation and people willing to help. A welcoming and helpful community isn’t always a given, but in the case of Cassandra, it’s alive and thriving. This is important because software is always about people.  The more of them that you can interact with that have shared your experiences, the better. It also will be easier to find solutions to your problems having a network of people who might have faced them before.

    There are many reasons why Cassandra could be the right tool for your application. Knowing your systems requirements, workloads and future will help you make the right choice. As you can see, if you do choose Cassandra, you are bound to be in good company.

    — Michael Colby

  • Why Financial Companies Love Continuous Delivery

    Why Financial Companies Love Continuous Delivery

    The other day I was on the American Express website paying bills and browsing around the benefits and services afforded me when I ran across a “who we are” section. It read:

    “We’re a global services company that provides customers with access to products, insights and experiences that enrich lives and build business success.”

    Surprisingly, the term “financial” was missing from the description. This led me to wonder if other financial institutions are evolving how they think about themselves. Here are some other examples:

    • Bank of America: “Here to help connect you to what matters most.”
    • ING: “Empowering people to stay a step ahead in life and in business.”
    • MasterCard: “As a technology company, we connect individuals, businesses and organizations around the world, creating greater opportunities for all.”

    Financial Companies Love Their Customers

    My unscientific assessment of various financial services companies suggests that they are centered on delighting their customers. They are transforming who they are by altering their customer engagement models and essentially becoming better software companies. MasterCard has even reclassified itself as a “technology” company. These companies are transcending the role of transaction engine to offer seamless, intuitive digital experiences for their customers.

    And the proof is in the performance. According to Forrester’s Customer Experience (CX) Index, financial services firms, including retail banks, credit card companies, investment firms and auto and home insurers, are some of the top brands worldwide when it comes to CX.

    You might think that large financial institutions would be digital laggards because of legacy infrastructure, regulatory compliance pressures and overall risk-avoidance. But you’d be wrong.

    In another study, 81 percent of financial services firms said they are embracing digital to redefine their businesses, and 87 percent are on the DevOps bandwagon. Sixty-one percent even said they are disrupting their industry with advanced digital initiatives.

    To stay competitive and improve their customer experience aptitude, financial services firms are undergoing significant digital transformation.

    Getting the Pulse of Fintech Continuous Delivery Adoption

    But how progressive are these firms in terms of their application delivery practices? Working with CA, Gatepoint Research recently surveyed more than 100 IT executives from financial services companies to take the pulse of where they are in continuous delivery adoption. Results can be found in this report and infographic.

    First off, to see if these companies might be considered unicorns or stragglers, they were asked the total volume of monthly deployments in all environments. Forty percent fell at the low end with fewer than 50 deployments per month. Now, lower deployment numbers could mean that these are less agile organizations or that they have fewer applications in general. Somewhat correlative to lower deployment numbers, the survey found that 48 percent currently are not using an application release automation (ARA) solution. Without automation, it’s tough to scale release processes—particularly to keep up with agile development.

    Moving up the spectrum, 41 percent are moderately prolific at 50-500 deployments per month, and then 15 percent are what I would consider rock stars with more than 500 (7 percent of those over 1,000). Those doing hundreds of deployments a month often have agile development teams and more modular applications. They likely have continuous delivery practices in place that push more frequent, iterative deployments left, helping higher-quality applications to move through the pipeline to production.

    The primary application delivery goals for financial services firms for the next 12 months are to get better control of release processes, tools and environments; to reduce risk and failures; and to release applications more frequently. All of these needs typically stem from companies undergoing digital transformation—it feels more chaotic and disconnected, manual processes are breaking under the weight and there’s intense pressure to move faster.

    Compliance was not a top goal, and the majority (83 percent) claim that their current release process is adequate to meet regulatory requirements. However, they did acknowledge that they could improve in terms of knowledge safekeeping and auditability of the release process.

    The data certainly shows that financial services companies are adopting continuous delivery practices in some form and exploring solutions, including many open-source tools, to help them get the job done. They currently are focusing continuous delivery practices on tracking and reporting releases, planning and scheduling releases and automating test deployments. These practices ultimately help financial services companies to release high-quality applications anywhere at any time.

    How Continuous Delivery Helps Fintech Win

    Continuous delivery sits at the heart of many digital initiatives because of what it enables these companies to achieve for their customers:

    • Delivering features and updates that customers need when they need them
    • Delivering applications that meet performance and quality expectations of customers
    • Delivering secure, compliant applications (for external and internal customers)

    Continuous delivery enables continuous devotion to the customer experience.

    Continuous Release: Fast Customer Response

    With continuous delivery, you establish an application release workflow that automatically connects a developer’s update to parallel testing to staging and ultimately to production release. Because of the underlying end-to-end automation technology, these steps can happen quickly, seamlessly and with little to no manual intervention. Some might call it “push button release” or “zero-touch release.”

    It’s a controlled, tracked, governed, collaborative process. Application stakeholders stay aligned as application changes traverse the pipeline. Your customers can have access to fixes, updates and new innovations in days instead of weeks or months.

    Continuous Testing: Building in Quality

    In contrast to the significant time penalties and shortfalls that can happen with manual testing, in the continuous delivery pipeline, testing is shifting left and happening in parallel. Hand-offs and feedback loops are automated and efficient.

    Testing can happen earlier and without delay with the help of test environment simulation. Testing is on target through automatic test case creation, even from requirements. Testing is real-world with on-demand test data generation. And testing is rigorous with developers able to performance test apps at their end. The continuous testing that occurs as part of the process helps to build in quality and ensure top performance before reaching the customer.

    Continuous Compliance: Audit-Ready Processes

    Ensuring applications are compliant and secure is critical for your customers. It’s making sure customer information is safe and that application changes are tracked sufficiently for SOX or other reporting. It’s also about helping out those internal “customers” like auditors to prove compliancy and easily build reports.

    An automated continuous delivery pipeline can track releases, apply role-based governance, orchestrate proper data masking, deploy security policy updates and provide an audit trail for application releases—who did what, when and why. All this data can be collected and reported easily, which saves time and effort for auditors. You essentially stay compliant and secure all the time.

    Customer Satisfaction Through Automation

    Financial services companies are laser focused on using technology to delight and retain customers. And continuous delivery is the application delivery practice that’s underpinning these efforts. The companies that are exceptional at this, with thousands of deployments per month, are using automation tools such as Application Release Automation (ARA). These tools are the backbone of continuous delivery, providing the automated orchestration, governance, tracking and reporting for your pipeline—development through production.

    That’s why I’m not surprised that leading financial services companies make up a large portion of CA’s release automation customers, including Euroclear, GM Financial, ING, Jewelers Mutual and Western Union. Our customers put high value on delivering excellent customer experiences and are implementing modern software delivery methodologies, practices and associated tools to support their efforts. GM Financial recently said it is “the software company that does auto finance.”

    If you are serious about customer satisfaction and staying ahead of nimble competitive threats in the market, you must get serious about end-to-end automation. It’s time to truly embrace the practice of continuous delivery to be able to consistently release applications that are progressive, always compliant and completely customer-satisfying.

    — Patricia Johnson

  • How Open Source Can Help Your CD Chain

    How Open Source Can Help Your CD Chain

    What can you do to make continuous delivery work better? Consider moving to open source software solutions. Here’s why.

    Many DevOps teams already may be using open-source platforms for reasons not related to continuous delivery. They might like the cost-efficiency or interoperability that usually come with open source. Or maybe they just like the open-source philosophy.

    Typically, however, open source is not viewed as a requirement for doing DevOps or achieving continuous delivery.

    How Open Source Speeds Continuous Delivery

    But maybe it should be. Consider the following ways in which open-source code can better facilitate a continuous delivery pipeline:

    • It’s easy to tweak. Because anyone can view and modify the source code of an open-source program, you can change it to work as efficiently as possible. Custom enhancements could make the open-source tools you use work more efficiently within your delivery chain.
    • No vendor lock-in. Most open-source tools and platforms are designed based on open standards. The threat of vendor lock-in is minimal. For that reason, adopting open source helps prevent surprises that could otherwise hold up your continuous delivery pipeline in the event that a vendor decided to stop supporting the tools you are using.
    • It’s well-known. Mainstream open-source tools are widely used. Chances are good that the people who are currently on your team, or will join it in the future, already know open-source tools. That’s an advantage for continuous delivery because it means you won’t have to spend time training staff—and risk introducing delays to your continuous delivery chain while the staff are being brought up to speed.
    • It gives you options. With open source, you usually have lots of implementation options. Want to deploy on Linux? There are about a dozen mainstream distributions you can choose. Want to run your cloud with OpenStack? There are lots of distributions of that, too. Having choice is a good thing for continuous delivery because it allows you to switch easily between different frameworks or tool implementations as your needs change. That agility prevents you from being locked into a specific solution.

    This is not to say that open source is a silver bullet. Achieving continuous delivery requires attention a lot of other factors; it’s not as simple as using a certain type of technology (if it were, everyone would be delivering continuously). But adopting open-source solutions when possible certainly can’t hurt—and it just might help as you seek to deliver software continuously.

    — Chris Tozzi

  • A Holiday Tradition: 2017 Continuous Delivery Predictions

    A Holiday Tradition: 2017 Continuous Delivery Predictions

    It’s that time of year. As the calendar year comes to a close, many of us are following time-honored traditions: making preparations for the holidays, planning some much-deserved time off and enjoying time with friends and family.

    In the business world, the year-end also brings its own traditions, and first among those is making predictions for the coming year. I’m not one to forgo traditions, so in this article I’ll share my thoughts on the upcoming year within the context of the continuous delivery movement.

    To level set, continuous delivery is the most evolved and modern state of software development and testing—and is core to a successful DevOps strategy. Organizations that are able to achieve continuous delivery can rapidly develop, test and release applications—with higher quality and at lower costs.

    Simply put, the ability to more continuously deliver software is one of the biggest advantages to attain in the application economy, where the battleground for consumer loyalty is most often found in the ability to deliver superior applications.

    Now that we know what continuous delivery means, let’s get to my predictions for 2017:

    1. Continuous Delivery Means Continuous Everything

    Continuous delivery is still a relatively new concept, and one that many organizations strive to achieve. As a new concept, it suffers from some of the misconceptions that often plague emerging technologies or trends. Many technology providers latch on to the term and claim to provide “continuous delivery solutions” that in reality only address a small part of the continuous delivery challenge.

    Truly delivering software continuously means that all the tasks within the software development life cycle (SDLC) must be optimized to occur in parallel and continuously. This means development must be continuous, testing must be continuous, and likewise for release and operations.

    2017 will be the year that industry embraces the importance of an end-to-end continuous delivery value stream. In 2016, many organizations began their continuous delivery journey by addressing certain aspects of the SDLC; in 2017 many organizations will begin to realize a truly open and integrated continuous delivery workflow.

    1. Democratization of Continuous Delivery Tools (via the Cloud)

    Optimizing all aspects of the SDLC for continuous delivery, as mentioned above, means that related tools need to be easier to use and easier to access. Developers who have access to testing tools (left-shift) can improve the quality of code they produce. Similarly, QA engineers who have access to design requirements sooner can create more accurate test data and scenarios, earlier.

    However, for this to occur, the tools have to be both easy to access and simple to use. Developers have avoided complex testing frameworks, but with simple, easy-to-use tools available—often in SaaS forms—developers can certainly incorporate testing into their methodologies.

    In 2016, CA acquired BlazeMeter, which pioneered the notion of cloud-based performance testing employing a simple and easy-to-use (yet very powerful) product. We expect to see this trend expand into other tools within the continuous delivery value chain in 2017.

    1. The Industry Embraces Open Source (Really)

    In the past, we’ve noted that commercially motivated technology providers have tried to keep open-source technology “at arm’s length.” There may have been some lip service paid to openness, but in reality many commercial providers felt threatened by open-source solutions that were seen as competitive to their products.

    This perception has already started to change, but I believe 2017 will mark the tipping point where companies will truly embrace open-source solutions as part of their strategy; those companies that continuously resist (pun intended) will be at a significant disadvantage.

    Open source is important for many of the same reasons as the cloud: It is broadly adopted because it creates advantage in time to market, quality and cost effectiveness. Embracing open source—and by that I mean both integrating with open-source solutions and using them as part of a product strategy—only makes good business sense. It helps software development teams meet their objectives in delivering quality software faster, and at lower cost.

    Another year is rapidly coming to a close and we have a lot to look forward to in 2017.

    On the topic of continuous delivery, looking forward means spreading continuous delivery throughout the SDLC, using the cloud more and embracing open source.

    All of those things combined will help us advance the continuous delivery movement together as an industry. Here’s to another year of continuous delivery advancements!

    Don’t forget, you can also take a closer look at the ongoing evolution of continuous delivery and other DevOps-related trends by picking up a copy of my colleagues’ new book, “DevOps for Digital Leaders: Reignite Business with a Modern DevOps-Enabled Software Factory.” If you have some extra time over the holidays, you’ll find it to be an interesting deep-dive.

    — Jeff Scheaffer

  • Four Inspiration-Killing Concepts That Need Redefining

    Four Inspiration-Killing Concepts That Need Redefining

    Software engineering is a creative process, and creativity cannot be measured by the hour. It can be measured only by the value of the contribution. Yet, a majority of companies still measure productivity by hourly contributions. Companies treat the development process as if it still existed in the days of the assembly line, and all we needed to do was to affix 100 widgets a day. This mindset pisses off developers, kills inspiration and causes developers to quit.

    So, how do we measure progress in our companies? How do we ensure that we can increase our probability of success? These are necessary questions for businesses, and it’s easy to see why companies cling to the rules of the past. It’s all we know. And it is a big gamble to change. After all, shareholders and such.

    It will take true visionaries to rewrite the rules. And although many new companies are doing wonders for changing the way we define work, we still have a long way to go. So the question now stands: What does the ideal dev process look like in the future? It might be helpful to attribute new words to the dev process to help us gain better understanding.

    New definitions for the Internet Era

    Task → Contribution

    Approval → Collaboration

    Workplace → Remote

    Workers → Culture

    Task → Contribution

    Remove the worker from the assembly line, and give them a seat at the decision makers’ table.

    This trend has already started in the open-source community. What used to be a to-do or a task is now an “issue” on GitHub or GitLab. If you think about it, task implies, “You got to do this whether you like it or not!” It’s involuntary but necessary involvement; you being creatively engaged with the task is optional. We embraced this unnecessary definition and are justifying it for no reason.

    We have established that creative workers don’t like to be told what to do and how. We should have contribution meetings where creative workers decide what they would like to work on. Unfortunately, many decisions are made in meetings where business owners pre-decide needs and delegate to managers to distribute tasks among engineers. If you want to lose creativity in your team and make everyone feel bad, this top-down approach works exceptionally well. We see the Band-Aid solutions to this top-down approach all over the place now. The manager needed to find ways to motivate workers. How? Ping pong tables! Free laundry! Ice cream! You get the idea. Most creative people see right through that garbage. It’s only novel to inexperienced recent grads who have yet to understand how the real world works.

    You will not have an engaged workforce unless you empower them and let them decide how to give value to the company. The easiest way to achieve this is to communicate transparently to the company what the business requires and give a detailed description as to the reasoning. From there sit back and watch the engineers chime in and say, “Hey, can I do that?” or, “What about this other problem we have?” I believe we could then change the perception from, “This is what I’m expected to do,” to “This is what I’m contributing to the company and I’m passionate about it.”

    Approval → Review

    This change is also apparent in the open-source world, when you submit your changes to a source code repository, your peers can take a look at it and see if they can contribute to its quality. In the past, this process was called “approval” and now is called “review,” where in fact your peer is approving the piece of code you’ve written. Approval implies. “I have authority over you,” whereas review says, “I’m going to help you get this done.”

    Workplace → Remote

    Dave Gray makes some really interesting points about how we make decisions in his book, “Liminal Thinking: Create the Change You Want by Changing the Way You Think.” He suggests that we only have the ability to make theories, judgments and beliefs based on our personal experiences. And even in our experiences we are only able to process a minuscule sliver of the information available.

    picture1David Gray’s diagram of how we come to our understanding of what the obvious choices is in a situation.

    If we apply this idea to the way we feel about our workplace, then we can quickly see the we are reducing the number of creative solutions available to our workforce. If everyone one of your creative workers gets to work from 9 to 5 at the same desk doing relatively the same thing daily,  they will start narrowing their understanding of what is possible. Just imagine what different solutions might arise if your employee is sitting outside at a lake or in a crowded bar. Their experience would change, thus their well of experience deepens, and their concepts of what is possible, multiplies. Make sure your developers experience new things, both as individuals and as teams. This doesn’t just mean offsites for team-building. It means, let them follow their gut, and work from wherever they need from time to time. This doesn’t mean let them go solo and unplug for days at a time. They need to stay plugged into the team and be a contributing part to the culture, but they need to balance that with building fresh perspectives so they can contribute to the collective experience of the whole.

    Workforce → Culture

    Yes, I know. “Culture” is one of those buzzwords that now cause people to roll their eyes so far back in their head that they fall out. But it’s important to know why the concept is important in relation to the old idea of “the workforce.” When management thinks of its developers as “workers,” the developers are immediately dehumanized and turned into pawns. They are expendable and indistinguishable as creative minds. They act out of fear from punishment and rarely take chances.

    We are no longer cogs in the corporate machine. Our ability to take risks can make the difference between being one of the 99 startups that fail, or the one tech company that succeeds. Managing culture as opposed to a workforce means that we can focus on enabling workers to be as creative as possible. We can focus on nurturing collaboration and honest feedback. A healthy culture is one that is transparent and communicative. A workforce could give a rat’s ass about making positive change. A culture is a living breathing thing that everyone contributes to and improves. A culture is owned by the collective. A workforce is owned by a man in a suit at the top of the tower. Screw the man. Power to the people.

    Conclusion

    Now that we have an understanding of why we must redefine our terminology, it’s time to start defining practical ways to make the switch for each term. In my upcoming writings I will start to lay out practical ways to make the switch in your company.

    About the Author / Devrim Yasar

    devrim_yasarDevrim is the CEO of Koding, a San Francisco-based software development automation platform vendor. Connect with him on LinkedIn and Twitter.

     

  • Government Asks: What’s in Your Software?

    Government Asks: What’s in Your Software?

    Multiple agencies across the U.S. government are paying closer attention to the software they are buying. More specifically, they want to know what open-source and third-party components were used to build the software applications. For example:

    Similar moves by the National Institute of Standards and Technology (NIST), Underwriters Laboratories (UL) and the U.S. General Services Administration’s (GSA) 18F Group have also been noted over the past year. The common thread among these initiatives is a need for a Software Bill of Materials.

    According to wikipedia, a “Software Bill of Materials (software BOM) is a list of components in a piece of software. Software vendors often create products by assembling open source and commercial software components. The software BOM describes the components in a product. It is analogous to a list of ingredients on food packaging.”

    What’s in Your Software?

    Nowadays, that question is not difficult to answer. Where software applications of the past were coded from scratch—each one being like a unique snowflake, today’s applications are assembled with reusable open-source and third-party components.  With 80 percent to 90 percent of an application now built from open-source and third-party components, it is easy for organizations to quickly produce a Software Bill of Materials.

    The Same Rules Apply to Software

    You don’t want to purchase spoiled food, buy a car with defective airbags or have a relative receive a defective pacemaker. Modern society would not accept products built this way. The same rules apply to software.

    Recent analysis of 25,000 applications that revealed 6.8 percent (about 1 in 16) of components used by development teams included a known security defect. The defects are known security vulnerabilities in open-source and third-party components used to build the applications. With known defect rates in software manufacturing so high compared to other manufacturing industries, it’s no wonder government agencies are paying more attention.

    The Same Guidelines Apply Outside of the Government

    Industry organizations including the American Bankers Association (ABA) and the Energy Sector Control Systems Working Group (ESCSWG), along with private sector organizations that include Exxon and The Mayo Clinic, are also mandating use of a Software Bill of Materials. Producing a Software Bill of Materials will soon be a common practice across development organizations, just as it is across other manufacturing industries.

    A bill of materials provides a useful ingredient list. For some organizations, that ingredient list serves to inform businesses and government organizations that they are not buying products with known defective parts. Other organizations will rely on the bill of materials as a point of record for what parts were used within a released software application—again, another common practice in manufacturing.

    Just yesterday, I received a recall notice from Toyota informing me that my car had a known defective Takata airbag. Toyota knows exactly what part was used in the car it sold me 10 years ago and tracked me down. The company informed me that it is working on a remedy to fix or replace that defective part in my car.

    Imagine if application developers, using a Software Bill of Materials, could do the same thing as Toyota. Imagine the next OpenSSL heartbleed-like vulnerability is announced tomorrow. How many software practices could immediately identify if they used the specific version of that flawed component in their application. How many of those organizations could track that component down in seconds? How many of them would offer to remediate that critical defect in a timely manner?

    It’s Not Just Rules—It’s Software Supply Chain Optimization

    One of my favorite quotes from “The Phoenix Project” (a must-read novel about DevOps) goes like this: “You win when you protect the organization without putting meaningless work into the IT system. And you win even more when you can take meaningless work out of the system.”

    An average application includes 106 open-source and third-party components. If you select the best components, you can build the best software. Use known defective components and you are introducing waste, rework and technical debt into the system—a.k.a., meaningless work.

    Producing a Software Bill of Materials can help organizations quickly identify what parts have been used in an application—good or bad. In a recent discussion with VMTurbo’s Chief Architect, Sylvia Isler, she noted: “Zero tolerance for risk is also why some customers require us to provide proof that our applications do not contain hidden security or licensing vulnerabilities.” Not only does their zero-tolerance policy improve customer satisfaction, it also helps them by removing meaningless work from their system. Customers are happy and so are their development teams.

    screen_shot_2016-07-29_at_4-53-51_pm

    A Free Software Bill of Materials in 15 Seconds

    There are companies that provide services to help users create a Software Bill of Materials. Sonatype, for example, offers the service for free service. Analyzing a typical application might take 20 seconds, and produces a list of all open-source components identified by their name, version and license type, and listing known security vulnerabilities, adoption rates, age and other attributes.

    If governments and customers are paying closer attention to what’s in the software they are buying, it might just be time to figure out what’s in the software you are building.

    — Derek E. Weeks

  • Keep Applications Running by Testing Early, Continuously

    Keep Applications Running by Testing Early, Continuously

    Almost every product we buy or use today goes through some form of extensive testing before it’s released on the market; typically, these tests are designed to replicate the worst-case scenarios that a product may encounter under real-world conditions.

    Automobiles, for example, go through extensive hot and cold weather testing in remote locations, and are driven over obstacle-laden tracks designed to push the limits of their durability. Even seemingly mundane objects such as children’s toys are exposed to abusive simulations to ensure that they don’t harbor any potentially hidden and harmful effects.

    On the current landscape, applications are the face of your business, often serving as the battleground where consumer loyalty is won or lost. Given this reality, it seems crazy to think that any applications are released having only been exposed to a minimum of tests. Yet, in the name of getting to market quickly, that’s far too often the case.

    As disciplines including agile and continuous delivery continue to increase the speed at which development teams can release software, it’s easy to put the crunch on testing in the rush to get an update released. But that’s a costly mistake in the long run, as research has shown that it is 50 percent less expensive to find an error in testing than to address the same error once it has reached production, and more than 90 percent cheaper  when addressed in the development/coding phase.

    Given the dramatic cost savings of addressing errors in development, clearly the goal of any organization focused on continuous delivery should be to shift testing left so a greater number of defects are found early in the development process. This is what we refer to as continuous testing, and it’s a huge part of the reason why I am so excited about CA’s acquisition of BlazeMeter.

    Performance load testing should be a core element of any continuous testing strategy because it is a critical factor in determining system reliability. Similar to the worst-case scenario testing that consumer products undergo, performance testing can quickly uncover applications defects that might otherwise go unnoticed. After all, the manner in which a system operates with a few hundred concurrent users may be very different than how it runs with thousands of users.

    BlazeMeter enables today’s development, operations and DevOps teams to conduct this critical performance testing earlier in the development process, saving countless hours and resources. The company is also competing—and winning—in a highly competitive marketplace where it has been pitted against much larger, more entrenched competitors.

    Part of the reason BlazeMeter is winning is its focus on offering a SaaS-based solution that is highly cost-effective and easy to engage. Using this model, customers can try  out the testing software with a few clicks, and then quickly move forward to broadly adopt the system. Another catalyst to its success: BlazeMeter was built using open source tools, such as Apache JMeter, used widely in the development community for performance and load testing. As a result, BlazeMeter can easily run and analyze JMeter and other open source-based load tests—such as Selenium, Gatling and Locust—within a commercial-grade performance testing system.

    This combination of a SaaS delivery model and incorporation of open-source tools, augmenting strong performance testing functionality, make BlazeMeter very complementary to CA’s existing continuous delivery solutions, including its CA Service Virtualization, CA Test Data Manager, CA Agile Requirements Designer and CA Release Automation products.

    At CA, we’re committed to providing the most comprehensive, integrated and open continuous delivery ecosystem, allowing our customers to release swiftly, test agilely and constantly increase reliably. The addition of BlazeMeter will further enable customers test continuously, thereby increasing agility and the overall quality of their software, to ensure that applications don’t break down on the side of the virtual road.

    — Aruna Ravichandran

  • To Be Continuous Podcast: Category Creation featuring Martin Casado

    To Be Continuous Podcast: Category Creation featuring Martin Casado

    In this episode of “To Be Continuous,” Paul and Edith are joined by Martin Casado, General Partner at Andreessen Horowitz. He previously was co-founder and chief technology officer at Nicira, which was acquired by VMware in 2012. While at VMware, Martin served as senior vice president and general manager of the Networking and Security Business Unit.

    The group discusses the deeply complicated and difficult process of category creation, with a special focus on technology infrastructure products.

    This podcast is brought to you by Heavybit, a program that helps developer-focused companies take their product to market.

    [soundcloud url=”https://api.soundcloud.com/tracks/283115632?secret_token=s-zX7AW” params=”auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false&visual=false” width=”100%” height=”166″ iframe=”true” /]


    Edith Harbaugh: What do you like about continuous delivery?

    Martin Casado: I think that there’s a broader movement around continuous delivery that is really interesting, which is, traditionally, infrastructure and operations came from an independent group. My first job out of undergraduate was working on simulations code in a national lab.

    I couldn’t control anything about infrastructure. I really didn’t have budget to buy a pencil. You get infrastructure, and you’d have some application to code, and you’d work on that application. We’d fiddle around with our MIG files or whatever, and that was pretty much it.

    The cool thing about the broad movement now, and I think CI/CD (continuous improvement/continuous delivery) is just part of this, is more and more applications, application developers, are actually getting responsibility for operations.

    This is provisioning, this is delivery, this is deployment. That’s a big huge change in not only what technologies get created but who’s consuming it and why they’re consuming it. I think it’s actually one of the more interesting trends right now.

    Edith: This would be a great time for you to introduce yourself.

    Martin: My name is Martin Casado, and I’m a general partner at Andreessen Horowitz.

    Edith: But you did stuff before you were at Andreessen.

    Martin: That’s right. The quick arc, as I mentioned, I used to be a research scientist at Lawrence Livermore National Labs. I spun out of that, did my PhD at Stanford. My research was in networking, so I was part of the team that started software-defined networking.

    I was there for four years, spun out of that, started a company called Nicira where we did software-defined networking. I did that for five years. That was acquired by VMware. I ran the networking security business unit at VMware for almost four years, and four months ago I decided to change and become a VC.

    Edith: So you basically created a category. What drove you to do that? What made you decide to start something knowing that it was so hard?

    Paul Biggar: You’re talking about software-defined networking? For the viewers at home, Martin roughly invented software-defined networking.

    Martin: There’s a whole bunch of people contributing, but I think a lot of the original momentum came from my thesis. You know, I’m going to be totally honest. If I had any idea how hard it was, I never would’ve done it.

    Edith: Really?

    Martin: I think so.

    Edith: I think you would’ve.

    Martin: Well, maybe. But it would’ve been a lot more daunting. I came out of Stanford pretty darn naive, like, “This is going to be easy!” Now, nine years and tons of gray hair later, I just realized that, man, it was a battle. I don’t think I had one-quarter that was easy. Everything was a battle.

    This is the way that I think about it. If you’re an entrepreneur, and you’re going to do category creation, you basically just have two jobs, in addition to product development. And job No. 1 is, there’s going to be some constituency out there you’re selling to, and that constituency, they wake up every morning and they think about all sorts of stuff, but they’re not thinking about your thing, because it hasn’t been created yet.

    That object in the mind space, that object doesn’t even exist in their brains yet. The first thing you have to do is create that object. It’s like Leonardo DiCaprio at “Inception.” You go in, you’re planting an idea in somebody’s head. It has to become a thing, something people think about, something people know and integrate.

    This is from nothing, and that’s hard. For us, it took five-plus years, and it touches every aspect of thought leadership such as analyst relations and technical conferences and broad marketing.

    Paul: So the activities that you’re doing in that category creation are largely marketing and getting people to hear about the activity and learn about it?

    Martin: I think so. I think maybe technologists will view marketing as this pretty shallow thing, but I think you’re exactly right. It’s marketing. But it is often very technical marketing, for example, in the guise of open source.

    In releasing open-source projects, you’re getting people to use it, you’re going to standards bodies, you’re going to conferences. It’s an incredibly technical thing, but in the end, it’s marketing in the sense that you’re actually creating awareness and a market.

    The first thing that you’ve got to do as an entrepreneur is, if you’re doing category creation, nobody’s thinking about your thing. You’ve got to get them to think about your thing, which is a lot of work. In my experience, five to seven years.

    Then the second thing that you have to do, which is just as much work, is then you have to attach a value to that thing. And I think we as technologists, there’s this kind of fallacy that we have where, “I’m going to create this new widget.” Let’s say I create the iPhone.

    Paul: Everyone will know how amazing it’s going to be.

    Martin: Exactly.

    Paul: Just build it and they will come.

    Martin: Yeah, there’s intrinsic value in my widgets. I take my widget, I put it on a sidewalk and someone picks it up. They’re like, “This is amazing. It’s worth millions of dollars!” And that’s totally not the reality.

    The reality is people only see value if they exchange money and they’ve used it.

    And if you’re doing category creation, how do people know what that value is? It’s a very difficult thing.

    Paul: And when you say attaching value, do you mean monetizing? Or is there more to it than that?

    Martin: I meant more the idea. Ultimately, this materializes monetization. Let’s say that you’re my constituency, and I’ve created this new widget. First I need to get you to think that this is actually a real thing. I’m going to call it a new phone. So, you need this new phone. First I need to convince you that you need the new phone.

    Then the second thing I need to convince you is it’s worth tens of thousands of dollars to you because you need to mentally actually attach that value to it. And it turns out introducing new concepts don’t necessarily have value if they’re new concepts.

    Normally, the value comes from, for example, an actual transaction. There’s a psychology around this. Or at least some experience with it, knowing that it’s going to, I don’t think you can just sit back to a couch experiment and be like, “Oh, I think this is going to save me money, therefore it’s worth something.” It really requires a lot of effort to make value.

    Paul: So the category that I see being created, or the one that’s closest to me at least, is this idea of containers and Docker, and more specifically Kubernetes, the idea that there’s this cloud infrastructure over there. The way that I became aware of it is exactly the way you’re talking about it. There’s open source coming out there that you can use and you can hack on yourself. There’s talks up there where people blow your mind.

    Martin: I think that actually this point, and certainly for all the listeners, I think this is one of the most salient points of this decade, actually, which is going to be a weird thing to say. At least an infrastructure’s the following.

    In the past, how did we create mindshare and customer bases? Well, there’s this whole pmm function and this whole sales function. And if you look at the big enterprise companies, if you look at Cisco and IBM and Oracle, really their power is this function. They own the sales channel.

    They have great relationships with the analysts, they’ve got great relationships with the customers, they’ve got certifications and the classes. So anytime they have a new concept, they take that concept and they cram it down the machine.

    As a startup, it doesn’t matter how cool your technology is, the hardest thing is to actually penetrate that channel.

    But when it comes to this new era of open source, now you actually have this hack that’s never existed before, where the buyer is shifting from an operator to a developer. Developers like open source, and you can actually create these concepts by getting open source out there and getting them to use it.

    Paul: We’ve been talking about this sort of thing, just the idea that it’s bottom-up now versus top-down.

    Martin: Not only that, it’s a totally different buyer that’s a totally different aesthetic. I don’t think developers care as much about analysts. I don’t think developers care as much about the 42-long sales dude with white teeth and the boat. I don’t think developers care as much.

    Paul: They won’t even answer his call.

    Martin: Exactly. About the channel, I think they don’t care about complex procurement processes.

    Edith: Having sold software for a little bit myself, if you get into a bigger corporation, you still don’t start to run into that.

    Paul: You get there, because the developers were first asking for it to exist.

    Edith: The longest part of our sale cycle is you get bounced to procurement and legal.

    Martin: Absolutely. I think this is the most important nuance of this argument, is exactly what you said. I’ve always maintained that open source and the developer is replacing marketing and pre-sales, not sales.

    You get credibility to the account, you can get things to technical close and technical validation, you can get account pull. So it’s almost like filling the pipeline, getting the transaction done, I still believe. For a long time, you need to have a professional, direct sales force that will be in there pushing things for procurement.

    Edith: It’s just a lot of work, because you pass the technical evaluation. They’re like, “Okay, go talk to procurement.” And to procurement, you’re a widget.

    Martin: Right, but the good news is, now it’s possible. Where in the past, to get that much legitimacy, to get things to technical close, was very difficult. You didn’t have the certification, you didn’t have access to the buyer, you didn’t have the account rep to make the introduction. You didn’t have any of that.

    Edith: That’s true.

    Martin: And now you do, and now it’s just about actually going through the logistics. And you’re absolutely right, it’s hard, it’s baroque. I’ve called it tribal bloodletting. It’s all of that, but you can do it as a startup.

    Paul: The thing that I think is really interesting is the converse of that. It’s that people who work in open source now are becoming actually incredible marketers. They don’t refer to themselves as such, but they have amazing social media presence.They build up tons of channels, whether it’s mailing lists or just Twitter followers.

    Edith: It’s like everybody recreates marketing. Everybody’s like, “Oh, we don’t need marketing.” Then you’re like, “Well, what is this thing over here where you have an email list?” Oh, that’s not marketing.

    Paul: It’s not marketing because I’m a developer.

    Martin: I really think that those that know how to do this are some of the most valuable people in the entire industry because this is the new entree for products into customer bases. I mean, there’s another kind of potential pitfall here, which is, let’s say you’re using open source for marketing.

    Now, there’s probably $7 billion have been invested in open-source companies and only about a $1 billion worth of returns. I’m not sure if those numbers are true, but I hear them quoted all of the time. But the reality is, a lot of money’s gone into it and not a lot of money has come back.

    The reason is because now, if you’re using open source to do marketing, you’re almost cannibalizing your sales motion. And so for a long time, the only open-source model we knew how to work was the Red Hat model, which is a services company. Only Red Hat’s ever pulled it off. It’s been very difficult.

    But another shift has happened in the last few years is people have figured out that actually you can use open source for marketing, but you don’t have to confuse that with your actual product offering.

    And with the rise of services, you can actually use open source for customer traction. You can monetize the service, and when it comes to services, no discussion of open source or closed source. So I think that we’re actually starting to unlock viable business models where you use open source for marketing.

    Edith: Who do you think does a good job of that?

    Martin: I think GitHub is a great example, right? Git isn’t even built by GitHub. It’s the standard in Linux. But if you look at GitHub, it’s a very fast-growing company that’s based on open source, and so everybody knows about it because of Git. So Git is doing the marketing. And this is just one example, I think there are many.

    Paul: It’s funny that you cite that as based in open source, because almost none of their stack is actually open source.

    Martin: Exactly, it’s a service offering. That’s what I’m saying.

    Paul: When you say service, you’re referring to software as a service, not service as in consulting?

    Martin: Absolutely. I should’ve been more clear. The long-standing question for us, certainly since 1995, is how do you build an open-source company that has the margins of a closed-source software company? Because you’re open source, basically you become a service and support company.

    What has happened in the last decade is exactly what you’re saying: people will realize that you can get account credibility and account traction, account knowledge, through open source.But then you can offer a back-end service offering as a service offering, and monetize that, and it’s often a closed-source stack on the back end of what you’re doing.

    But you don’t talk about open source/closed source as much with service offerings. It’s normally if you’re consuming something on-prem that you think about those things.

    Paul: How do you feel about this? People who are building, let’s say CircleCI as a good model, but there’s a ton of them. Building something that’s a SaaS product, a hosted SaaS product, but that then sells to people who use it in their own VPC and pseudo on-prem sort of thing.

    Edith: Oh gosh.

    Martin: I come from this somewhat traditional world of selling enterprise software. In there, there’s this whole discussion, and I was part of this discussion, of is it on-prem or is it off-prem in general? And I think that you framed this question perfectly. I’ve realized that that’s a false dichotomy. It’s actually not the right question to ask. I think as a service, is it actually an operational model and a delivery model? It doesn’t really matter if it’s on-prem or if it’s off-prem.

    I think that the days of selling closed-source software to companies is done.

    But you can sell them services and you actually can sell them appliances. But if you look at appliances, appliances almost look like services. They’re boxes that have services, and often the upgrade is happening remotely, management is happening remotely.

    I do think that the right model for these companies, I think CircleCI’s a great example of this, you have open source that customers use, you have a SaaS offering, but you also have an on-prem delivery offering as long as you don’t change the operating model, as long as it still looks like a SaaS model somehow, whether it’s a managed service or something like that.

    I think as soon as it becomes shippable software, where you have to manage a heterogeneous set of environments, you have to manage all the day-two ops. It becomes unwieldy.

    Edith: I had a really interesting discussion the other day with the VP of Sales from CircleCI and somebody from Microsoft. CircleCI was basically like, “We love that it’s selling on-prem. It’s helping you.” Microsoft is like, “We’re trying to get off-prem desperately.” So it was not the argument you thought was going to happen.

    Paul: I think it’s probably because of how sensitive the IP is. If you’re talking about something like, well, documents are pretty sensitive, but the source code is very sensitive. And so people are not as happy to ship that off-prem as we once thought was going to be the case.

    Edith: Microsoft’s reasoning was, and this might be the way Microsoft had done it, is they have 10-year maintenance agreements.

    Martin: We have, “If you have a problem, upgrade to the latest version and then we’ll deal with you.” I think that’s kind of what everyone has. There used to be this idea that you’d create a fork and then you’d backport things to that fork or the old version, or something like that.

    I don’t know anyone who’s doing this sort of services, the SaaS with a managed to on-prem version that does anything but “the latest version is the version.”

    This podcast is brought to you by Heavybit, a program that helps developer-focused companies take their product to market. Throughout the program, founders work on developer traction, product market fit and customer development. If you like what you hear, be sure to subscribe to Heavybit’s Podcast Network on iTunes.

    — Malia Powers

  • HashiCorp Vault Enterprise Secures DevOps Infrastructure

    HashiCorp Vault Enterprise Secures DevOps Infrastructure

    HashiCorp, a DevOps infrastructure company known for its Atlas platform that combines a variety of powerful open-source tools, recently announced Vault Enterprise. HashiCorp describes Vault Enterprise as a comprehensive security solution for DevOps infrastructure. Vault Enterprise is the foundation for security in the HashiCorp DevOps infrastructure suite.

    Open source is a virtual necessity for effective DevOps—forming a close symbiotic relationship. I explained in the DevOps and Open Source report published earlier this year, “There are some significant advantages with FOSS (free and open-source software). With a proprietary, closed-source application there are very few people with access to look at the code. Recent incidents with SSH backdoors demonstrate that closed most certainly does not mean secure. When the code is open those types of backdoors can be quickly spotted and resolved.”

    With the addition of Vault Enterprise, the HashiCorp suite is now comprised of:

    • Vault Enterprise – Empowers security teams to collaborate, validate, and enforce security policies
    • Terraform Enterprise – Empowers operations teams to collaborate, validate, and provision infrastructure
    • Nomad Enterprise – Empowers development teams to collaborate, validation, and deploy applications
    • Consul Enterprise – Empowers all teams to monitor the complete stack

    Vault Enterprise is not entirely new. It builds on the open-source Vault to enable security teams to define and enforce security policy and secrets management across distributed infrastructure.

    “The shift to highly elastic, microservice architectures requires a different approach to security. Static network-based security is poorly equipped to handle the dynamic application-centric infrastructures being built today,” said Armon Dadgar, co-founder and CTO of HashiCorp. “Vault Enterprise enables organizations to adopt DevOps practices in their approach to security and keep pace with development and operations teams that are adopting DevOps.”

    Vault Enterprise includes Hardware Security Module (HSM) integration, which enables developers to integrate Vault Enterprise with HSMs using Vault’s simple API rather than more complex HSM interfaces. According to HashiCorp, there are also a variety of enhancements and new collaborative features in Vault Enterprise, including a new UI for managing secrets, health alerts and monitoring and an intuitive workflow for initializing new Vault clusters.

    “Deploying enterprise software to both public and private cloud infrastructure requires a security solution that works everywhere. As we adopt DevOps practices that make our applications and infrastructure more dynamic, we need bullet-proof security,” said John Mitchell, Architect at SAP Ariba. “HashiCorp’s Vault is the only offering that meets these requirements—one workflow across providers and dynamic secrets management.”

    DevOps is a culture and a process—not a silver bullet solution or a single product. HashiCorp understands this while still trying to provide a DevOps infrastructure platform that’s as complete as possible. HashiCorp pulls a variety of effective and useful leading tools together, and delivers them in a modular fashion that allows you to embrace DevOps at your own pace.

    There are plenty of vendors out there creating proprietary tools and platforms. What I like about HashiCorp is how it is harnessing the power of an array of open source tools to provide a whole greater than the sum of its parts. Vault Enterprise is available now.

  • Private Practice: Encryption Exposed

    Private Practice: Encryption Exposed

    In September 2014, Apple made encryption a default with the introduction of the iPhone 6. Then, in February 2016, a Los Angeles judge issued an order to force Apple to help break into the encrypted iPhone belonging to a terrorist involved in a mass shooting.

    Apple had used some of the strongest encryption technologies and practices to protect its users and their data. The encryption technology did not discriminate between lawful and unlawful users. While there were many sides to this issue, it surfaced many important debates on security, privacy and civil rights.

    Peekaboo

    For developers wanting to add cryptographic libraries to their applications, a number of open-source components are available to them. Of course, anyone seeking to add encryption to an application has an important requirement for the privacy and security it provides.

    One of the more popular choices for encryption is known as the Legion of Bouncy Castle Java Cryptography library. According to the “2016 State of the Software Supply Chain” report, records reveal that 17.4 million Bouncy Castle components across all versions were downloaded last year. Of these, 5.8 million (33 percent) were known vulnerable versions of Bouncy Castle.

    peekabo

    It’s a sobering fact, but it’s true. Last year alone, organizations downloaded vulnerable versions of the Bouncy Castle cryptography library 5.8 million times. The defective components downloads occurred across 93,253 unique IP addresses from 13,824 organizations in 197 countries.

    Think Different

    Think about it. The Bouncy Castle project is developed by experts in cryptography. Occasionally, their crypto library is discovered to have a flaw and the project owners rapidly fix and release a new version. If you use the latest versions without known vulnerabilities, your application, your users and your data are protected. If you use the versions that include known vulnerabilities, you have electively declined those protections.

    Two of the critical principles of using open-source components are to use the highest quality components and to select them from the best suppliers. In this case, the Bouncy Castle project does an excellent job of releasing new and improved versions. While flawed versions are still available, those seeking to protect applications, users and data need to use the highest quality versions.

    Which Version Are You Using?

    Determining which versions of Bouncy Castle or any other open-source component you are using is simple. A number of free and paid services are available to help you analyze your application and report a full list of the components, including dependencies, that are used.

    Some of the free services require you to upload your application for analysis while other services are performed on-premises. One example of a free on-premises tool used to create a software Bill of Materials is the Application Health Check app from Sonatype. Another example is the OWASP Dependency Check app. Precision of these tools may vary, but regardless of the tool you use, you should use one.

    More insights on the quality, security, and integrity of open source components used to build modern applications can be found in the “2016 State of the Software Supply Chain” report.