devopsy.kinsta.cloud

Category: DevOps Practice

  • How App Stores Are Addressing Fragmentation in the Linux Ecosystem

    How App Stores Are Addressing Fragmentation in the Linux Ecosystem

    According to DistroWatch, 273 Linux distributions are currently active, with another 56 dormant and 521 discontinued. While some of these have shared underpinnings, it still makes for an extremely varied landscape for companies and developers.

    It means developers must create multiple versions of their applications to be able to provide their software to all Linux users or just address a fraction of the market. Also, developers require multiple versions of build tools, which inevitably results in significant resource overhead.

    Desktop application distribution is complex across all operating systems in general; in Linux, this is further compounded by such fragmentation and inter-dependencies both in the packaging and distribution of software.

    For example, Fedora uses the RPM packaging format, while Debian uses the .deb format. Moreover, packages built for one version of a Linux distribution are often incompatible with other versions of the same distribution and need to be built for each version separately.

    Developers need to satisfy all these requirements at the same time to be able to successfully offer their products to their users, which can be difficult with limited resources.

    In a way, the choice of distribution and subsequent promotion of Linux software is a chicken-and-egg problem. Initially, companies and developers must decide what parts of the Linux desktop system they want to target. Then, once they have their products available to end users through one or more of the distribution channels, they still have to invest in separate efforts to promote their applications and capture usage.

    Unfortunately, there is insufficient data to assist in the selection and optimization of either the distribution or the promotion process. Linux software developers generally lack sufficient immediate visibility to the usage and popularity of their software.

    Traditionally, there have been multiple dimensions to how creators distribute their software: official websites, where companies and developers offer software downloads on their own domains; code repositories such as GitHub, GitLab and SourceForge; and application repositories in which Linux-based operating systems typically provide software through self-hosted storage locations.

    To achieve the highest level of penetration, software developers will often distribute their applications using some or all of the above methods. Likewise, most users will utilize multiple methods to obtain software they need. While this gives developers more freedom in how they deliver applications to the end-users, it creates additional fragmentation.

    In recent years, there has been significant effort to address the fragmentation in packaging and simplify the distribution of software through the establishment of software centers, in which some Linux distributions offer store-like destinations with a graphical frontend, software ratings, screenshots, descriptions and other user-focused data that allows better search and discovery.

    Currently, there are three of these in the Linux space—AppImage, Flatpak and snaps. They each approach and handle the various aspects of usability in different ways.

    AppImage and Flatpak technologies are architected to primarily support GUI desktop applications. Snaps are designed to work with servers, cloud infrastructure and IoT devices, in addition to desktop applications.

    Spotify, a snaps publisher, is an example of a company benefiting from this approach. On one hand, it requires the Spotify engineering team to maintain both the snap and the traditional Deb package. On the other, the snap version is significantly easier to release, which has also helped with the simplification of the Deb release, as well.

    The primary reason is the ability to use easy rollbacks, which have already been used. This feature removes uncertainty that a possibly broken version of the Linux desktop client application might be pushed out to the users. Spotify engineers first release the snap version, and after ascertaining that it works and behaves correctly, they build the Debian package, too. Snaps allows the Spotify team to more closely follow the weekly cadence of releases they have for the Windows and Mac versions.

    The emergence of self-contained packaging and distribution mechanisms addresses a major problem in the Linux application ecosystem–the difficulty in establishing a successful business model because of the packaging and distribution challenges. The new formats reduce the fragmentation, as they minimize the number of permutations developers need to support for their applications.

    The shift toward centralized application stores that are not specific to any particular Linux distribution offers higher discoverability and better consistency in the user experience.

    Developers need fewer resources to support multiple target platforms, which allows them to focus their efforts on the core product, with the understanding their software will be available to the wider desktop audience, without having to depend on distribution-specific dependencies.

    Since the aspects of new, refined models of promotion and distribution in Linux are still relatively young, we see improvements but there is still opportunity to develop and adopt better, data-driven practices.

    As this field continues to evolve, the store model will help drive growth and usage of the Linux desktop, offering software developers a refined, more tangible experience than ever before.

    — Martin Wimpress

  • An Inside Look at GitOps

    An Inside Look at GitOps

    At a time when variations on DevOps abound, get ready for the latest: GitOps. This new term promises to bring some order to what can be operational chaos and empower operational teams to leverage best practices learned from their developer counterparts. It’s early days yet for GitOps, but here’s what we think you need to understand about this new facet of DevOps.

    What is GitOps?

    Everyone we spoke with has a slightly different perspective on GitOps, but this is our take: In its most basic form, GitOps is infrastructure and operational procedures defined as code, and living in a source control system, such as Git. Git becomes the single source of truth for what is running in production (or staging, or development).

    Declarative systems, such as Terraform, AWS CloudFormation and Kubernetes help enable this practice; but operations is much more than Infrastructure as Code. True operations requires a way to plan, review and approve moves, adds and changes to the infrastructure. It also requires well documented procedures, or runbooks, to be successful. This is where GitOps differentiates itself. We believe GitOps is the full operations lifecycle of infrastructure management, living as code in a git repository.

    GitOps may be used for managing both application deployments and base infrastructure made up of systems needed regardless of the applications deployed (i.e. networking, security, etc.). Both will follow the same procedures to plan, review, approve and release code into production. Done right, GitOps will let engineers constantly apply updates to infrastructure meet all the needs of the applications in a continuous delivery format. The version control system ensures everything is recorded and visible and an audit trail keeps teams compliant. GitOps will make it easy to revert problematic changes, becoming a single source of truth about what is happening in the system from both the software development and infrastructure perspective.

    What Technology is Required?

    In order to kick off GitOps, you’ll use a Git-based version control system. Then you’ll need the ability to create a declarative cloud infrastructure, using something such as Terraform and Kubernetes, with the help of Helm or Flux. Because both Terraform and Kubernetes are declarative systems, they make it simpler to create and deploy infrastructure as code in a manner that is both replicable and transparent. And you’ll also want to implement a solution such as GitLab that wraps operational procedures around these tools. GitLab, being an end-to-end DevOps solution can manage the backlog of requests, assign those requests to the appropriate subject matter expert to create the change in Git, facilitate the review and approval process, and kick off the execution of the changes using its flexible CI/CD system.

    While it is possible to achieve this sort of workflow by using different solutions to merge and ship code to Kubernetes, GitLab is certainly a straightforward path to GitOps. It allows developers and operations administrators to work from the same source of truth and with a common set of procedures and tools.

    What Are the Benefits?

    In the DevOps world, GitOps is perhaps unique in that it can potentially benefit both operations team members and developers. For starters, GitOps aims to address the sometimes cave-like nature of operations (a single person working largely in isolation) by taking all of the best practices from software development and letting them loose on the deployment side.

    Full oversight, architectural review, project management and all the other pieces of the process are brought together in GitOps in an effort to end ops versus everyone else and get all the stakeholders involved in the process. The basics don’t change–an ops engineer will still create an infrastructure–but that will just be one part of a much larger process that everyone can contribute to and collaborate on. No more worrying about an engineer creating a cloud infrastructure that can’t be replicated; with GitOps everything is tracked making repeatability easy. Suddenly it will also be simple to answer the “what changed?” question because no one will have to hunt for an answer. The bottom line is a successful GitOps program will benefit the actual bottom line because operational processes will be dramatically streamlined.

    Possible Challenges

    With any collaborative effort, change can be tricky and GitOps is no exception to that. It is usually easier to create one-offs and not follow a process, so the first thing to consider about GitOps is it will require discipline from all participants. It will be vital for teams to write everything down.

    At GitLab we live and die by this thanks to our culture of collaboration, but we know it’s not necessarily something that comes naturally to any individual or organization. It will be vital for everyone on the team to record what’s going on in merge requests and issues. The temptation to edit something directly in production or change something manually is going to be difficult to suppress, but the less “cowboy engineering” the better GitOps will work.

    If GitOps sounds like something your organization might benefit from, our best advice is to start small. Pick a tiny area to begin with, get a win and then build on that. At GitLab we call that iteration and it’s worked well for us.

     

    This article was co-authored by Priyanka Sharma, director of technical evangelism at GitLab.

    — Brad Downey

  • Before We Burn the Martech Silo

    Before We Burn the Martech Silo

    There’s an ongoing debate about where marketing technology (martech) should sit in an organization. Does it live with the CMO, the CIO, the CXO–a hybrid strategist with both IT and marketing background–or some collaboration? As technology use grows, it’s tempting to move martech under another role. Before we burn the martech silo, like how McDonald’s, Uber, Mastercard and others are doing, let’s look at the implications for DevOps teams.

    A recent article in PR Week cited a University of Texas study claiming “only 40% of a corporation’s marketing-related activities today report to the CMO.” Martech is being siphoned off into other areas–sometimes slowly, sometimes abruptly. It’s because the tech outweighs the marketing, at least in the eyes of the C-suite.

    In March 2019, McDonald’s announced they were acquiring Dynamic Yield for $300 million. Dynamic Yield rose to fame as one of the leaders in omnichannel personalization. Translation: they watch visitors searching, viewing and ordering. Then, they show those related results to other visitors. With the deal closed, McDonald’s announced they were eliminating their CMO position and creating an SVP of martech reporting to the CIO. Automating the customer experience with in-store kiosks and mobile app ordering is their top priority.

    Another case where mobile app ordering dominates, Uber clobbered both its CMO and COO in June 2019, right after going public. Their rockstar CEO said he wants to be more involved in day-to-day operations. Uber rolled non-martech functions into a VP of marketing communications. For Uber, martech is the product–an automated experience connecting riders and eaters with drivers. Everything else is branding and communications.

    There’s a third org chart option: the CXO, or chief experience officer. More digital customer interaction is forcing a partnership between technology and marketing insight. Mastercard hired its first CXO earlier this year, bringing in a veteran from the digital marketing industry.

    What do these three moves have in common, besides moving martech out of traditional marketing?

    • All have powerful, ubiquitous brands with huge recognition.
    • Their core product shouldn’t change much moving forward.
    • Personalization shapes their offers using global and local trends.

    Here’s the thing: Marketing automation automates what marketing knows. When the current and future requirements are clear, evaluating martech tools is easier. Moving martech out of branding, advertising and communication to IT sounds reasonable until you realize what you don’t know.

    The martech silo often houses hunters, not farmers. Marketers have different metrics. They discuss impressions, and click-thru, and time viewed, and calls-to-action, and conversions. Strategy and content often have more impact on results than the delivery technology. In a fast-moving environment with many product or service offerings, what works once may not work elsewhere. Creativity comes into play, with cycles of learning.

    In today’s SaaS model, marketing can pick a cloud-based tool and explore possibilities with minimal IT support. That’s good, until data and process accumulate, needing a bigger silo. Be careful. Burning the martech silo can be far worse for the organization than leaving it alone, even with all the shadow IT downside. No matter who does it, picking tools for a martech suite before understanding requirements is a formula for disaster. Without integrated marketing experience, IT is set up for failure. It can cascade into marketing failure and finger-pointing.

    For a fluid marketing environment, a CXO is best suited for the job. They speak the language of both sides, along with representing external customers and their experience. If your organization doesn’t have a CXO, modeling a DevOps team responsible for martech in that image is the next best option.

    DevOps solves the problem of speed marketing needs in making changes. Teams also have deep experience in maintaining applications and overseeing security IT wants. Many teams already have a product marketing person managing their software requirements. What a martech DevOps team needs is people with customer and digital marketing expertise. This include creative writers, graphics artists and advertising and social media specialists.

    If that sounds like a problem without a CXO running air cover, you’re right. Budget and headcount come from somewhere. Both the traditional marketing team and the IT team want input, perhaps even control. The key for a martech DevOps team is behaving as if the silo had disappeared, no matter what the org chart says. The DevOps leader should keep everyone informed, managing up and across. It usually means creating different presentation views, one for marketing, one for IT and maybe one for the CEO. Make sure everyone gets answers to their questions in their language.

    We’re going to have more martech moving forward. Creating effective martech DevOps teams is a priority, even without sweeping C-level reorganization. Don’t just burn the martech silo–reclaim the pieces that work for both marketing and IT and build the right team around the customer experience. If you need help getting started on a bigger martech mission, let’s talk marketing strategy.

    — Don Dingee

  • There’s No Silver Bullet for 5G Deployment

    There’s No Silver Bullet for 5G Deployment

    When it comes to 5G, a common mistake is to think there is a silver bullet for successful deployment. Often operators assume there is one magic remedy that if introduced to their network, will see them succeed. For example, automation is a key pillar of the 5G era; end-to-end automation maximizes the efficiencies and responsiveness of 5G. However, it would be a mistake to assume there is one method of automation that leads operators to successful 5G deployment. There are a vast range of automation areas and use cases such as network slicing and DevOps that can play a key role.

    But first, the key point about there being no silver bullets was part of the reason Nokia commissioned Analysys Mason, a global research organization, to assess and index operators’ maturity and readiness for 5G transformation. With 5G deployment, there are a number of available automation options that need careful consideration.

    While the Index made a number of significant findings on operators’ readiness for 5G and provided guidance for how to align technology investments, one of the most intriguing sections was on DevOps. In short, the Index found DevOps, as a key part of network automation, will enhance the impact of 5G on customer experience and service agility, but on the whole is not being adopted.

    Key Findings from the 5G Maturity Index

    The 5G Maturity Index showed it is paramount operators invest in a variety of digital technologies that can enhance the impact of 5G, including artificial intelligence learning as well as new processes such as DevOps. The following are the most vital findings of the research:

    On Automation

    • The 5G world will be characterized by the co-existence of physical and virtual infrastructure for a foreseeable future–without automation, the cost of managing functions across the two worlds will be crippling for operators.
    • Even when there is a vision for end-to-end network automation, business process automation is not clearly tied to network automation and is often in its infancy.

    On DevOps

    • Only 32% of network operators are using or are planning to use DevOps by 2020 as means to improve consumers’ experiences.
    • A significant 35% of network operators have no plans to use DevOps at any point.
    • The level of confidence in DevOps is low.
    • DevOps is becoming the norm in cloud and data center environments, but they are only slowly extending into network services.

    Why Deploy in a DevOps Mode?

    It’s clear that network operators are not yet deploying in a DevOps mode on a major scale. But what are they missing out on? DevOps has been proven, in the cloud environment, to support rapid and flexible service creation–an important goal for operators. At the heart of DevOps is continuous integration, delivery and deployment. The process enables collaboration throughout the entire development pipeline from concept and building to deployment and testing.

    Furthermore, the continuous testing and feedback loops of DevOps enable teams to consistently provide up-to-date and reliable software to customers. This enhances the consumer experience and creates new revenue streams for operators. While operators should consider adopting DevOps, it’s equally important they view it as a part of the automation process–one of the key supporting structures to the building, but not the only one. Together with other vehicles for automation, DevOps is a building block for faster time-to-value and paves the way to an agile 5G environment.

    Conclusion

    DevOps has a critical role to play in meeting 5G networks’ requirements for faster time to customer and improving the customer’s experiences. What is crucial is that operators remember:

    1. There is no silver bullet to overall automation, a menu of complementary options is needed.
    2. DevOps is a critical part of this menu, because of its ability to create efficient processes which ultimately leads to a greater user experience for businesses and their customers.

    It’s critical to align digital technologies carefully to an overall transformation strategy with clear objectives–DevOps will be a critical element of this, but do not be tempted to fall for the tale of the silver bullet.

     

     

    This article was co-authored by Stefan Kindt, technology marketing at Nokia Software. Kindt heads the operations automation and DevOps marketing. Prior to his current role, Stefan was leading the cloud market development at Nokia where he was responsible for the market positioning of Nokia cloud to enterprises and communication service providers. With more than 20 years of experience in the ICT and telecommunications industry, Stefan has extensive knowledge in the data center as well as the telco space, with global market insight and first-hand experience from Asia and Europe.

     

    — Volker Held

  • 5 Steps to Ensuring Validity of Your Business-Critical Data

    5 Steps to Ensuring Validity of Your Business-Critical Data

    Bad data can lead organizations to make mistakes. If your organization isn’t continuously ensuring data is accurate, you can never be sure the business decisions you’re making are smart.

    So, how do you continuously validate your business data without consuming excessive resources? The answer starts with your data professionals, who are entrusted with massive volumes of internal, customer and partner data. A breakdown in database performance can consume valuable time finding a fix. Also, data that’s not properly tested and validated can lead to poor business decisions. IBM estimates poor quality data costs the U.S. economy $3 trillion per year.

    Understanding where to implement data validation tests is a vital step to ensuring accurate data. Data testing is traditionally a development-focused initiative that involves testing smaller units of functionality and asserting what the expected results will be within a development or test database environment. Data validation, on the other hand, focuses on production databases and involves validating larger processes. These processes can include Extract, Load, Transform (ELT) and Extract, Transform and Load (ETL) batches, data and application integration, vendor data feeds and data exports for partners.

    While data validation appears to be a massive undertaking, making small but important changes now will set you up for future success. Consider these approaches to incorporate testing and validation into standard database platform operations.

    Conduct Unit Testing

    Test small units of functionality in isolation from other parts of the system. Your database management team will be able to offer temporary or mock-up data stores that will allow data professionals to test smaller subsets of data.

    Conduct Integration Testing

    Verify units of functionality combine to produce useful results. This will mean taking a careful look to make sure data gets from point A to point B with the intended transformations. Breaking down these processes into bite-sized pieces is the key to testing business rules throughout integration processes.

    Automate Testing

    The keys to building quality test plans include being able to standardize tests, repeat them on a schedule or within a continuous integration/continuous delivery (CI/CD) pipeline and make testing results transparent to stakeholders. Developing an automated process is fundamental to taking a proactive approach as you incorporate testing and validation into regular processes.

    Monitor Production Databases

    Don’t stop at testing and validating data only when updates are deployed. Validating that data is correct should be an integral, ongoing process and will ensure confidence in the data.

    Validate Movement

    Validate counts, balances and totals anywhere data is transferred from one system to another. Monitor that values fall into expected ranges, domain values are adhered to and data heuristics are met. Also, evaluate validation results over time to determine overall data health. Is the data optimized for business needs? Are there holes in the efficiency process that should be addressed immediately? Leverage historical validation results for baselines to identify exceptions and determine a path forward for continuous monitoring processes. Make sure you have the needed capabilities for ongoing testing, validation and monitoring processes for your database environments.

    The journey to a proactive approach to database testing—and away from a traditional reactive or ad-hoc approach—will come with its challenges. Bad data affects companies of all sizes in all industries. Once you understand where to implement data validation tests and start following these best practices for testing and validation, you’ll be well on your way to stopping bad data from compromising your organization’s ability to make sound business decisions.

    — John Welch

  • Better Together: Why Software-Development Toolmakers Should Embrace Integration

    Better Together: Why Software-Development Toolmakers Should Embrace Integration

    It’s getting harder for businesses that are building technology tools to get attention, traction and ultimately widespread adoption. You can’t just launch an amazing new developer tool and hope developers will find you; providers need to zero in on a specific use case that empowers developers while also ensuring those developers will still have access to the broad ecosystem of other tools they need to do their jobs.

    The more forward-thinking companies in enterprise SaaS, public cloud computing and artificial intelligence are increasingly partnering with companies they might once have considered competitors to elevate the presence of all their brands among end users. By meeting in the middle, and integrating with a common-ground platform, providers join their customers where they are, on the platform that makes the most sense for them.

    Instead of forcing customers to choose, providers can take advantage of powerful network effects, where their tools become more valuable because they’re part of a network. It’s one of the oldest concepts in computing: Metcalfe’s Law states the value of a network is equal to the square of the number of users on that network.

    But building that network yourself can be time-consuming and costly, as many of those who’ve done it alone have discovered. That construction project can easily distract providers from their own core competencies, forcing them to spend time and resources on essential but undifferentiated development work.

    Network Effects

    The mobile side of tech has been operating under these principles since the launch of distribution platforms such as the App Store and Google Play, which introduced mobile developers to millions of potential customers. Those customers want seamless connections between their favorite apps and services to streamline their digital lives. They don’t want every app developer to create their own marketplace with incompatible payment methods, unfamiliar interfaces or strange hoops to jump through.

    The explosion of enterprise software vendors enabled by cloud computing and software-as-a-service models has created similar patterns. Cloud-native developers have embraced distribution channels such as the AWS Marketplace as the best way to find their customers, and enterprise companies such as Box and Dropbox are making integrations with rival products and office productivity tools (like G Suite or Office 365) an important part of their product strategies.

    “What seemed unfathomable merely a decade ago is now becoming commonplace as Fortune 500 companies are mixing and matching best-in-class technologies—from upstarts to cloud mainstays like Salesforce, Workday and ServiceNow—to power their business,” said Aaron Levie, Box CEO.

    But the work required to enable those integrations is substantial.

    Growing companies focused on building best-in-class tools for developers don’t always have the in-house expertise required to strike partnership deals with platforms and support customers with a world-class billing system. Likewise, end users often need to do their own due diligence when considering whether or not a promising new development tool will play nicely with their existing tech infrastructure.

    Go to Market

    Marketplaces are the best way to solve these problems. Service providers need distribution and integration with other development tools to reach end users, and end users want the peace of mind of knowing they’ll be able to properly evaluate a tool under consideration through a certified clearinghouse.

    Companies can certainly build API-level integrations on their own for one-off partnerships or integrations where performance isn’t a major requirement. However, when performance is vital, such as with databases or infrastructure monitoring tools, a more deft touch is required.

    These seamless, low-latency connections are only going to become more important in a multi-cloud world as companies use the power and scale of Kubernetes to build tech infrastructure that spans several different cloud providers and perhaps even their own on-premises servers. True service interoperability will require common frameworks to make sense of all those connections and allow developers to mix and match their favorite tools to create the technology stacks of the future.

    Enterprise software silos are a thing of the past. The future of software development will rely on tools that blend the best available services—no matter where they were born—and link developers, service providers and platform companies in flexible and dependable ways.

    The companies that figure out how to integrate best-of-breed software development tools with the leading platforms and services of our time will win. If you’re just starting out, let someone else handle the complexities of integration and distribution while you focus on creating the best developer tool you can.

    — Jevon MacDonald

  • 5 Best Practices for Managing Open-Source Components

    5 Best Practices for Managing Open-Source Components

    In today’s connected world, software development environments focus a lot on faced-paced development. Organizations that adopt agile development practices such as DevOps and use Open-Source (OS) software and components to their advantage have a much better chance of keeping up with demand and shorten the Software Development Lifecycle (SDLC).

    However, incorporating OS components into applications does not come without risks, as they often contain bugs or vulnerabilities, and are highly exposed to exploits. In this article, we will cover what is Open-Source Software (OSS) and OS components, discuss the importance of security for open source and cover five best practices for managing open-source components.

    What Is Open-Source Software?

    Open source refers to any software with accessible source code that anyone can modify and share freely. You can head over to the Open Source Initiative (OSI) and see a detailed list of criteria for the definition of OSS. While OSS allows many more modifications over proprietary software, you must still accept the terms and conditions defined in its license.

    Some estimations suggest OSS adoption saves $60 billion dollars for consumers per year, while about 96% of all commercial applications contain some components or elements of OSS.

    The Benefits of Open-Source Components

    Open-source components are software units that meet the definition provided by the OSI. Modern development environments put a lot of pressure on developers to build and deploy applications more quickly. To successfully achieve their goals within short software release cycles, developers frequently use OS components.

    The Importance of Security for Open-Source Components

    OS components are incorporated into the vast majority of software and applications. Even though they allow developers to be more efficient and get more done, they can also introduce new vulnerabilities and jeopardize the integrity of the entire code.

    Since OS components are developed in a distributed system, they are often more vulnerable to exploits than proprietary code. Some of the reasons for this are:

    • Distributed development: Compared to a distributed OSS developed by many individuals, it is much easier to track and manage a code developed in-house and ensure you follow policies and protocols.
    • Fast release cycles: OSS development is much quicker and agile, which means that very often, by the time a new software release passes all the quality and vulnerability checks, it has already become obsolete with the release of a newer cycle. This makes it almost impossible and in most cases useless to run the necessary tests and ensure the safety of using the code.
    • Lack of quality standards: OSS elements do not pass the same quality and standard checks as proprietary code. Thus, unless you evaluate each OS component before implementing it, you can often incorporate low-quality code that is exposed to vulnerabilities, lowering the overall quality of your code.
    • The double-edged sword: When members of the open-source community discover a vulnerability, they publicly share the details of the problem in online forums to help developers learn about the risk and how to patch it. Unfortunately, this solution is often a double-edged sword. While this is a step in the right direction, it exposes the details of the vulnerability to threat actors as well, who can exploit it against systems that have not yet patched the vulnerability.
    • Lack of security measures: The problem with OSS is even greater for smaller companies, who prefer to use it to save time and resources but lack the necessary security measures to ensure the components they are implementing are secure enough to be implemented into the code.

    Now, let’s take a look at the five best practices for OS components management.

    Form a Policy

    Establish a clear policy on how to incorporate and manage OS components. This step will give usage guidelines to your developers and ensure OSS elements are incorporated responsibly without damaging code quality. Additionally, if you are facing problems with OSS elements, this policy can act as a playbook and give instructions to your security teams on how to handle the threat.

    Carefully Choose Software

    It is important to choose the right software for you. While it might be tempting to use many kinds of software and enjoy all their possible benefits, you have to consider your requirements and ensure the software you use can answer all your demands. You should consider the amount of support you require and the risks you might face. One of the most crucial aspects is how secure the software is. A good way to measure the software’s security is the Open Web App Application Security Project (OWASP) dependency-check, a utility tool that identifies project dependencies and checks if they contain any open-source vulnerabilities.

    Track and Update OS Components Regularly

    Track your OS components throughout the entire product life cycle and ensure transparency to find critical security vulnerabilities. Updating OS components versions frequently is typically the best way to deal with bugs and vulnerabilities.

    Forking

    One of the best features of OSS is (as long as you keep up with the policies) you can modify the source code and customize the software to fit your needs. Thus, you can take software intended for specific use-cases and modify it to provide a better solution for your situation. However, this process can be intensive and take effort and time. Thus, before you attempt forking, consult with other community and team members to ensure you have the right idea and execution.

    Use Automated Tools

    Cybersecurity is highly time-sensitive—the first moments of dealing with an attack are the most critical. Automated tools, such as Security, Orchestration, Automation and Response (SOAR), can help you identify threats quicker and make mitigation efforts much faster to minimize and dramatically minimize the attack’s potential damage to your system. You can also use automated tools to enforce policies and check your OS components for vulnerabilities, making the process much faster and more secure.

    Wrap Up

    OSS and OS components have many advantages for developers and facilitate agile development. However, the flip side of their ease of use is the danger they pose in terms of open-source vulnerabilities. To mitigate this risk, you should incorporate the right practices for managing OS components into a clear strategy. This will allow you to enjoy all the benefits of OS components without exposing your application, network and systems to unnecessary risks.

    — Ilai Bavati

  • Why COBOL Still Matters After 60 Years

    Why COBOL Still Matters After 60 Years

    In the world of DevOps, the Agile Manifesto and countless other application delivery frameworks, one has to wonder how an anachronism such as the programming language COBOL (common business-oriented language) has managed to remain relevant. After all, COBOL has its roots back in the 1940s, and was built upon Rear Admiral Grace Hopper’s work on the FLOW-MATIC programming language (a text-based programming language). Hopper, who worked as a technical consultant on the FLOW-MATIC project, is sometimes referred to as the grandmother of COBOL.

    Last century, COBOL quickly became one of the most used programming languages in the world and it is still quite popular, claiming more lines of code in active use today than any other programming language. It offered a huge advantage over the other programming languages of the era. One that can be summed up as portability. From the outset, COBOL was the first popular language designed to be operating system-agnostic. In other words, it could be run on numerous different systems with little change made to the source code. What’s more, as a text based language, COBOL used English words and phrases to make it easier to understand and also made it somewhat self-documenting. 

    While much of the programming world has moved onto JavaScript, Python, PHP and even C and C#, COBOL can not be ignored. It continues to evolve and remains relevant, even in the age of the cloud. Simply put, it still has some chops to it. Take for example:

    • COBOL is a Language of Business: It is still used by the majority of major banks and insurers. The language can be found in widespread use across numerous other sectors, such as retail, healthcare, government and automotive. For most of those businesses, no other programming language has displaced COBOL and it remains as the back-office business language of choice.
    • COBOL is Extremely Portable: From the outset, COBOL was designed to be operating system agnostic, meaning the same applications developed under it could run unchanged across many different platforms. That allows COBOL developers to focus on building applications, instead of worrying about the intricacies of operating systems. That fuels DevOps and agile by allowing developers to test and deploy across a wide range of supported platforms.
    • COBOL Continues to Evolve: It supports and integrates with numerous platforms and works with operating environments such as Linux, mainframes, Windows and UNIX. What’s more, COBOL also integrates with Java, C#, Docker containers, mobile, .NET and JVM as well as Azure and AWS cloud environments. It can be used today to build cloud, containerized and managed code apps. And continues to evolve to meet the challenges of the future.
    • COBOL is Easy to Learn and Understand: It was created with the objective of making it easier for programmers to work with computers and each other. That objective has translated into a language easy to learn and understand by using English phrases and commands. The readability aspects of COBOL make it self-documenting, along with an ease of use not found in other languages. What’s more, the language costs less to maintain and its readability means it is easier to maintain.
    • COBOL is Future-Proof: It has continually evolved and now works with industry-standard IDEs, meaning programs can code with COBOL using familiar tools that support teams. COBOL developers are able to use the language alongside contemporaries, without having to forgo the latest IT tooling and processes.

    While many in the DevOps world sell COBOL short, there are many reasons why the language remains popular today. It continues to meet the needs of business and embraces many of the changes the cloud and new techniques can throw at it. COBOL is even now embracing APIs, micro services, the cloud and distributed platforms, making it a worthwhile tool for business today.

    — Frank Ohlhorst

  • Cloud Security: Self-Healing Infrastructure With Fugue

    Cloud Security: Self-Healing Infrastructure With Fugue

    Misconfiguration is the No. 1 cause for data breach in the cloud. Fugue helps to eliminate data breaches, as it fixes anything that gets drifted by providing baseline drift detection and automated remediation. Fugue is all about cloud security. It identifies security risks and compliance violations and ensures they’re never repeated.

    During this interview, Josh Stella, co-founder and CTO of Fugue, explained how his company offers developer-friendly tools that tell you if you are “breaking a rule and how to fix it,” providing visibility and control for all DevSecOps teams. With the self-healing cloud infrastructure, Fugue corrects misconfiguration and works on a whole configuration without having to write code or automation scripts.

    Check out the interview below, which also includes a demo of how the technology works by Stella himself.

    — Alan Shimel

  • The Bedrock of Digital Transformation

    The Bedrock of Digital Transformation

    Trends come and go. I’m old enough to have been persuaded, twice, about the good sense of flared jeans. I had a space hopper. I had a Betamax video player. Fads and cool ideas are a constant white noise, vying for our attention. Some will stick, some won’t. And that’s true in technology. No-one admits to owning a C5, but plenty of us built PowerBuilder and Delphi apps. A few of us tinkered with Smalltalk.

    But genuinely smart, enduring ideas find a way of sticking, of evolving, and adapting. No-one these days thinks of a phone as a wired device stuck to a wall which you could only use if you asked someone to connect you. And no longer do you have to employ anyone to run in front of you with a flag as you drive your motor car. Like cars and phones, good ideas endure and in the world of computers and IT, the COBOL language is no exception.

    Very few organizations of any size are not being impacted by today’s digital era and the seismic changes being seen in the market place. Entire industries have been disrupted beyond all predictions in the last decade or so. Indeed 88% of the Fortune 500 have dropped off that list in the last 50 years, as those who fail to keep up with the pace of change are being replaced by those who can adapt.

    But adapting isn’t easy. Making fast progress toward new digital objectives is often hampered by practical barriers that are individually difficult to solve, particularly in the case of the existing technology landscape already in place. Things such as vendor lock in, complex business processes, interdependent apps and data, inefficient delivery processes, technical constraints and skills issues.

    Additionally, the technology landscape is forever changing, but only growing in complexity. Today, large global enterprise businesses typically run a hybrid environment, which is a consequence of adopting multiple waves of technological advancements over time. Each individual advancement offered opportunity and progress, but eventually results in a highly complex and inefficient technology environment. Most organizations are pursuing digital transformation programs with a view to reduce complexity, create better flexibility and reduce total cost of ownership.

    There has been tremendous value created in business applications and data and there is a lot to be gained in digital transformation by leveraging that value as much as possible, in transforming it with the minimum cost and risk. Much of this value is encapsulated in systems built some time back, and which have evolved with the business. Oftentimes, using COBOL technology. COBOL was invented way back when, but has adapted to support ongoing business technology demands and rigors.

    Having an appreciation for where your organization is today, along with an awareness of what needs to be achieved in regard to the required updates, the process used and the infrastructure considered, can assist with plotting the pragmatic steps to develop a plan that delivers transformational value. With some of the most critical systems being written in COBOL, these core systems continue to power a variety of fundamental processes in modern business.

    The risks of ripping and replacing systems are measured as an average IT project failure rate of 71%, which amounts to a $1.7tr cost in a single year. These are dreadful numbers and no organization wants to waste that sort of time and money and reputation. There is now a growing realization, from many years of experience in those more radical transformation projects, that their success rate is relatively low, planned costs and timescales typically grow exponentially, and the risks to successfully continue business during such a transformation are unacceptably high.

    Enter stage left a more pragmatic approach: modernization. This concept prioritizes on protecting the value of what companies already have, exploiting advancements in technology to deploy and integrate applications in new ways and to surface and integrate data in new ways, with the minimum change to what already exists. Creating portability and operational independence for applications and data is becoming recognized as the fastest and most future proofed path to building a platform for digital transformation. Market influencers such as Gartner and IDC have commented on it, and most of the global systems integrators are industrializing their modernization practices to support companies successfully transform. So what is the underlying technology acting as the catalyst for this modernization and transformation?

    COBOL enters its seventh decade of helping run great chunks of the world’s largest IT systems entirely thanks to its staying power; its adaptability.

    COBOL’s endurance owes a lot to its original design that make it readable and portable, meaning it can be picked up by new staff quickly, and deploy wherever it is needed. What kept it in such demand owes more to the ongoing evolution of the language itself, and the tooling surrounding it. COBOL works alongside, integrates with and supports containers, cloud, JVM, .NET, JSON/REST, micro services, modern IDEs and other technology typically associated with more contemporary names. COBOL technology plugs directly into a DevOps toolchain that is adopting continuous delivery practices for some of the economies’ most important IT systems.

    COBOL is, in fact, a 2019 technology; just with a 60-year heritage.

    Next time you pick up your mobile to make a call, or sit in your car to drive to work, ask yourself how you feel about how old that idea is.

    — Derek Britton