devopsy.kinsta.cloud

Category: Doin’ DevOps

  • There’s no One-Size-Fits-All Data Mobility Strategy

    There’s no One-Size-Fits-All Data Mobility Strategy

    Whether you’re a Fortune 500 enterprise or a fledgling startup, there’s one thing every business can expect to confront: Change. This is resoundingly true when it comes to data management. Even greenfield operations will, sooner rather than later, need to change how and where they leverage their data. After all, every business—including those launched with the most cutting-edge technology—is built on a series of choices and compromises. As technologies and business priorities change, so should your data mobility strategy.

    In a world of ever-changing variables, what’s the right data mobility strategy? There is no one-size-fits-all solution. It does, however, help to start with a solid foundation on which to build your strategy.

    With the right platform that allows for flexibility and change, it’s time to build the structural framework for your data mobility strategy. When creating the framework for your data mobility strategy, there are a few considerations to keep in mind, including your desired use of on-premise storage, your hybrid cloud strategy and “supercomputing” capabilities, and the storage area network (SAN) needed based on your organization’s needs. Let’s review what they might mean for you:

    Developing a Hybrid Cloud Strategy

    The reality is that the hybrid cloud is now achievable for most organizations. According to Flexera’s 2023 State of the Cloud Report, 72% of organizations have embraced a hybrid cloud strategy. Your data mobility strategy should reflect that.

    With a proper hybrid cloud environment, the user experience should be seamless regardless of where your data exists, whether that’s on-premise, in a private cloud, or in the public cloud. As the potential for more dynamic resource allocation grows, your data mobility strategy inherently becomes more critical. Data mobility, in effect, now equates to computing mobility.

    Leveraging the “Supercomputer” in the Cloud

    Data mobility becomes even more imperative as entities gain more opportunities to take advantage of “supercomputing” capabilities.

    The computing power that exists in the cloud now is tremendous, and thanks to modern dynamic cloud pricing, even smaller organizations can tap into it. According to one estimate, the cloud-based high-performance computing market should reach $55 billion by 2030, growing at a CAGR of 7% from 2023 to 2030.

    So for example, if you’re a FinTech startup, you could pay by the minute to leverage high-performance computing capabilities to test your trading algorithm. Previously, these powerful capabilities were only available to the biggest customers — think NASA — and came with astronomical costs.

    On-Premise Solutions Aren’t Going Away

    Even as cloud services and capabilities become more accessible and more valuable, on-premise operations aren’t going to disappear. Customers have all kinds of reasons for keeping data on-premise, whether it’s for compliance purposes, costs or the desire to leverage existing infrastructure. Certain workloads, meanwhile, simply don’t make as much sense on the cloud.

    The reality is that even the most compelling alternatives couldn’t eliminate on-premise operations, because business ecosystems and industries evolve organically. Think about it: Many businesses still use landlines, and workers still use desktop computers. Nearly half a century after marketers first coined the term the “paperless office,” it took a full-blown pandemic to push our collaboration tools to the point where we are finally, basically, paperless.

    Fiber Channel and iSCSI

    When it comes to data mobility, how does an organization decide whether to adopt fiber, iSCSI or both? As organizations manage workloads that require low latency and other networking capabilities, they’re going to be investing heavily in this area.

    Traditionally, a significant amount of data management is fiber-channel-based. With iSCSI, an organization doesn’t need to invest in separate physical infrastructure, such as switches or cables. Moreover, iSCSI has become more attractive to entities moving workloads to the cloud. A whole range of products, from Pure Storage, NetApp and even cloud platforms like Microsoft Azure, offer iSCSI-based storage in the cloud. Your data mobility strategy should consider how to move from fiber channel to iSCSI and back again.

    Change is the Only Constant

    Ultimately, no one can predict all of the major technological innovations that will impact their business down the road. To stay nimble, you need a data mobility strategy that you can execute with the team you have — whether their primary expertise is in storage, networking or elsewhere. This can be especially challenging in large organizations, with teams that have to meticulously plan their projects and stay accountable for their budgets. Now more than ever, it’s important to have a solid foundation on which to build a strategy that fits your needs.

  • Will ChatGPT Replace Human Software Developers? Probably Not

    Will ChatGPT Replace Human Software Developers? Probably Not

    Since the release of ChatGPT, there has been a great deal of hype around generative AI and how companies can leverage it to cut costs and democratize software and application development. Naturally, with discussions of cost-cutting and democratization come whispers about what will happen to software developers.

    This is a real and valid concern, but software developers’ skills, expertise and creativity are still very much needed.

    While generative AI and AI code generation tools like ChatGPT have shown some promise and potential benefits, they are still in their infancy—like many other innovative technological advancements. We also don’t know what scenarios they may present down the road or their true abilities when the technology matures. For instance, how will it integrate with other technologies? We don’t know what will happen when a ChatGPT-generated line of code breaks or needs to be changed. We don’t know if it can provide a novel solution to a unique problem or what security threats it will present.

    Given these unknowns, technology executives should think twice about replacing experienced and creative technology talent, such as software developers, with AI code generators.

    Will ChatGPT create novel code to solve a unique problem never encountered before? Probably not.

    A Tale as Old as Time (Or at Least a Decade)

    The technology industry has been searching for and developing new ways to make certain software development tasks much easier and more streamlined for years. One example of this is low-code/no-code.

    The notion of simplifying application development and replacing software developers with laypeople (citizen developers) has been around for more than a decade now, as low-code and no-code solutions have grown more popular. These solutions have promised that companies don’t need technical talent to get their software and app projects off the ground.

    However, if you look at the impact of these solutions today, their use can result in large amounts of technical debt and almost always require the skill of experienced software developers.

    The reason? Building complex software and applications is extremely difficult; it’s an art.

    Low-code and no-code solutions have their rightful place and can make things easier if a company is looking to launch a simple app or static web page. These solutions can increase the pace of development and time-to-market and enable everyday people without any development skills to facilitate them. However, they are not actually a complete solution and often overlook aspects of development that a human software developer would typically address. Without a skilled expert involved, low-code/no-code platforms often can’t solve a unique problem a company has.

    So, how does this relate to AI code generators like ChatGPT? Here’s how.

    A Similar Situation—With One Key Difference

    When thinking about their place in the development process, AI code generators are not that different from low-code or no-code solutions. The thinking is that they will also enable non-technical individuals to create software and applications with ease.

    Yet, there is one key difference—they promise expertise, too. But is the expertise coming from the AI code generator or the person piloting it? The answer is simple; it is not from the code generator.

    There have been examples of companies and individuals that have tried using ChatGPT to build code, and they have appeared to be successful. However, without the input of the individuals using it, it never would have been able to create the code on its own unprompted.

    This means that the expertise of skilled, human software developers is still very much needed, especially when building intricate software and apps that require complex functionality such as optical character recognition (OCR), internet-of-things (IoT) connectivity and more.

    A Future With Software Developers

    Because of the expertise still required to create elaborate and innovative software and applications, AI code generators will not replace software developers anytime soon, if ever.

    The technology used in these tools is still in its infancy, presenting many lingering questions and potential challenges. We will see this confirmed by the trials and tribulations experienced by the few companies and executives attempting to replace software development teams with tools such as ChatGPT.

    Knowing AI code generators follow a similar path as low-code and now-code solutions, companies and executives should use them as developer enablement tools. These tools should complement the work of software developers by empowering them to focus on the complex tasks software and apps today require.

  • The Path to App Modernization: Benefits, Pitfalls and the Route to Success

    The Path to App Modernization: Benefits, Pitfalls and the Route to Success

    There are many reasons an organization may find itself on the path to considering the risky journey of application modernization. It could be to gain an edge or to build a more competitive positioning, or a business could have a legacy system running on infrastructure that is no longer viable, leaving them no other choice. But the conundrum for organizations still resurfaces when considering app modernization; they must select one of these two routes: Either “the failure rate is high, and failure is simply not an option” or “Everyone is still doing it, so let’s forge ahead.”

    The Benefits of Choosing Application Modernization

    Whether an organization chooses this path out of necessity or ambition, modernizing an old IT environment can deliver several benefits, ranging from reducing outdated hardware and software to creating new value through innovation. Specifically, the key benefits are:

    ● Reducing technical debt and improving the underlying infrastructure: Improved security, operations, reliability and scalability.
    ● Decreasing expenses: Lowering the cost spent on expensive hardware and software improves the utilization of resources, thereby decreasing the total cost of ownership of technology operations.
    ● Accelerated time to market: Modernized IT and product development gain value from technological improvements that decrease the time it takes to develop and deploy new products and services.
    ● Agility in the market: Modernization enables an organization to react to changes at an accelerated rate, providing a competitive edge in the market.

    Choosing the Best Path to Application Modernization

    There are different paths to modernization, each with its own focus. On the one hand, there’s the infrastructure aspect of building your platform engineering practice versus adopting a service approach with a platform-as-a-service (PaaS). On the other hand, there is the actual process of modernization with options like refactoring, re-platforming or rewriting your systems, either in-house or through outsourced services. It ultimately starts with modernizing the relationship of the application with its infrastructure and changing some assumptions.

    Once you have a baseline, running everything else should come from a cost-benefit analysis. A scalable, well-managed monolith is valuable despite its age. Ensuring horizontal scalability and a robust backup strategy are key to effectively managing mutable data.

    First, understand the blockers in your current implementation that would complicate a shift to the cloud. Or identify where the result may not deliver any value.

    There are very common anti-patterns that remain anti-patterns, whether on the cloud, running on managed hosting or on-premises. Identifying them allows you to start absorbing technical debt regardless of whether a move to the cloud happens as intended.

    Anti-patterns to look out for are:
    ● Weak separation of code and configuration: You want to be able to run many parallel instances of each application as separate environments. Telltale signs are hard-coded URLs and service credentials. The dependency is the capability of running ephemeral preview environments that are quick to launch and quick to destroy, such that you know that you are “cloud ready.”
    ● Weak separation of the read/write domain from the read-only domain: In a cloud deployment, you want a build step that creates immutable artifacts that are not modifiable in production, and you need to know where all the actual data resides. Older applications tend to “believe” they own the whole disk.
    ● Manual configuration of services: You should be able to run “stock” services without any manual configuration in case the need for a specific database configuration arises and signals the likelihood of an application issue that requires debugging.

    Simply packaging a Docker container or a VM image and deploying to an IaaS won’t create any benefit and only increases costs. The first step to success is a thorough clean-up and update of the documentation to start the process.

    The one basic rule to follow is the ability to run an arbitrary number of instances of every element. Achieving this will allow everything else to flow. There is no need to rush to transform all Crons into “separate workers” and break the monolith into microservices. But the proof that it is possible now exists.

    The Best Approach to Application Modernization: In-House or Outsourced

    A mixed approach between in-house and outsourced is often optimal. There are many elements to consider. If you have a minimal in-house understanding of what the cloud imposes as constraints, you may be tempted to go for the simplistic lift-and-shift approach. Outsourcing everything can lead to huge amounts of lock-in.

    There are ways to cut corners that could simplify and accelerate the initial project, but this could increase the costs down the line. There needs to be a level of abstraction where using a PaaS is a winning proposition and can provide quite a bit of abstraction at no cost.

    Without control, the project may end up as something that “runs on the cloud” without the actual benefits. But there are many ways to do that.

    The Right Mindset Will Help Avoid Pitfalls Along the Way

    By neglecting constraints and skipping the necessary preparation, the costs may escalate. Running big chunks of hardware continuously versus using small ephemeral resources as needed typically leads to significantly increased costs over time. Full rewrites often go wrong when trying to obtain all the benefits immediately.

    A simple four-step approach for success is:

    ● Start with modernizing the relationship of the application with its infrastructure and changing assumptions.
    ● Identify and address the blockers in the current implementation–this makes a shift to the cloud less complicated and enables a smoother transition.
    ● Set a baseline that allows everything else to run from a cost-benefit analysis. Ensure horizontal scalability and implement a robust backup strategy to effectively manage mutable data.

    Accepting that app modernization will be a journey and that the initial implementation is a slightly more scalable and resilient version of the original. This is often a better mindset that leads to a more effective process.

  • Unused Code: Proving a Negative

    Unused Code: Proving a Negative

    We have a ton of code that is no longer being exercised. We really don’t talk about it much, but it’s out there. From feature flags shutting off code to API versioning making an interface obsolete, it’s just hanging around out there. Like an albatross. Waiting for someone to misuse it. Or, to address the more pedestrian concerns, confusing people new to the codebase. But that code is not contributing a thing.

    Easy example. You are on version 3.2 of your API. Version 2.1 is not called by anything, but the code is still hanging out there. It is not that 2.1 cannot be called, but that it is not currently called. The problem with that is that new devs have to work through what’s current, and since 2.1 and 3.2 probably share 95% of their code bases, what portion of that code base is unused? And the API is sitting there, waiting for someone to penetrate your network and find malicious uses for it.

    Proving a Negative

    But here is the problem: Identifying that a bit of code–be it an API, a method, just a few lines in an if statement, whatever–is never exercised is terribly difficult and, in highly complex environments, borders on the impossible (it is never impossible, assuming IT owns all of the code that could exercise that bit). The old adage about proving a negative absolutely applies. We can–and testing tools in both the functional and security spaces do–generate a list of code that is exercised, or identify code that isn’t being exercised. But not a list of code that is never exercised. That functionality in test tools is super useful, because it helps prioritize issues that are being used a lot and leaves the ones not seeing a ton of traffic for later resolution.

    But I’ll say that in most organizations, that’s no longer far enough. The cruft in your code causes problems, and you need to clean it up. If you’ve worked in IT for any length of time, you’ve been through the “Oh, that bug is because the developer called something no longer used” scenario at least once. And it is a straight-up waste of time.

    So here is my proposal. Test tools generate a list of what isn’t called from systems under test. Pick one–security testing or functional testing–and require it for any bit of code, no matter how small, to go into production. That means that the system knows about all source code and thus knows definitively if a bit of code has been exercised.

    Clean Up as You Go

    Is that a tall order? Yes. Testing isn’t free. But given a scenario where you reduce technical debt by eliminating excess code, I think it will pay for itself. And that is not counting the security posture improvement that reducing the code base implies.

    You’re running the systems that present your organization to the world, so you may as well do some due diligence on yourselves. Keep making cool new stuff and upgrading the old, but clean up as you go with some form of monitoring, this or a more procedural one, so the quality is high and the excess is low.

  • Generative AI and Software Testing Tools to Manage Technical Debt

    Generative AI and Software Testing Tools to Manage Technical Debt

    It is easy to take a pessimistic view of generative AI and large language models (LLMs), especially when a growing list of AI experts and public figures have voiced concern about their potential to lead to dire consequences—even to human extinction. But we must also consider how these same technologies might mitigate these risks. There is no doubt that we are living in an accelerated cycle of technological progress and repercussions. However, the intelligence, speed and agility of AI—and particularly machine learning (ML)—may be just what we need to roll with the punches.

    As the speed of development outpaces our ability to mitigate potential risks posed by the systems we build, we are set on a path to accruing massive technical debt—the ever-increasing costs associated with modernizing code later rather than sooner. Too often, organizations in the private and public sectors are reluctant to pay off this debt, choosing an “if it ain’t broke, don’t fix it” mentality toward software maintenance and security. The problem is that as technology outgrows and outpaces our critical infrastructure systems, the potential for catastrophe escalates.

    Machine Learning: A Tool for the New “Space Race”

    Automated testing has proven superior in regression testing, especially in visually recognizing potential issues at the pixel level. If, for example, an important element of your interface is missing from the screen after an update, a visual test script can identify that faster than a human can. AI (and in particular, machine learning) generates test plans that provide more comprehensive coverage of the system under test and more practical coverage.

    Traditional testing methods usually begin with a broad and hypothetical analysis of user interactions. Test engineers begin by casting a wide net to cover the many possible user engagement scenarios they imagine. In contrast, AI-assisted systems learn from actual user interaction, building script libraries that focus on known points of weakness and vulnerability. It also does this at speed and scale. This technology is going to be essential to software test engineers as they inevitably find themselves unable to keep up with the abundance of code generated from LLMs using traditional testing methods.

    Technical Debt is Inevitable but not Unsolvable

    Every new iteration of software has the potential to introduce unforeseen problems ranging from glitchy bugs to catastrophic failures. The risks of releasing new software vary immensely between applications: It’s one thing if the latest release of your music streaming app crashes and quite another if the system that runs the regional power grid fails. One will result in unhappy customers; the other, the potential loss of life.

    The most critical systems (e.g., financial, transportation, safety, medical) are more likely to get frozen in time. Once a stable iteration is released, companies are generally not keen to make changes unless absolutely necessary—beginning the cycle of technical debt accumulation that grows until that debt is paid off by modernizing the code.

    Deciding when to pay off technical debt has always been a matter of weighing pros, cons, costs and benefits. But sometimes, such as in the case of an epic failure, that decision is forced. Both the risk of breaking the system and the cost of modernization compel developers to leave well enough alone. Meanwhile, the longer a system remains unchanged, the more isolated, outdated, and obsolete it becomes, setting the stage for failure.

    By introducing generative AI technology to the development stack along with other tools for authoring, compiling and testing software, developers will soon find themselves driving in the fast lane. With the security of knowing that code can be produced rapidly and released safely, owners of aging legacy systems will be more likely to modernize software sooner, helping them to pay off technical debt more quickly. That, in turn, could lead to increasingly rapid software development and release cycles, more work for developers, and more innovation. Such a workflow could very well become the embodiment of accelerating change, taking us from an “if it ain’t broke, don’t fix it” mentality to one where we anticipate the need for new code and avoid future catastrophic failures, or for that matter, human extinction.

  • Implement Object-Level Encryption and Policy With OpenTDF

    Implement Object-Level Encryption and Policy With OpenTDF

    With an exponential increase in data being generated, stored and shared online, the issue of data security no longer belongs to IT alone. Software and application developers have been put on notice along with business owners and legal teams worldwide to not only maintain data privacy but to build more secure products. There’s no easy solution. However, there are resources readily available for devs to build security into the fabric of their products. One is called OpenTDF, an open source project that lets you integrate encryption and data policy controls into your new and existing apps to safeguard your data, and the sharing of it, for you as well as your users.

    What’s TDF, and Why Should I Use OpenTDF?

    TDF, the “trusted data format,” was originally developed by the United States National Security Agency (NSA). It’s an open standard for object-level encryption that keeps data protected and under the data owner’s control, wherever it’s created or shared. TDF includes cryptographically secured metadata that ensures consistent policy control throughout the data life cycle. Picture this: You can grant, revoke or “turn off” data access at any time, even if the data has left your network or application.

    OpenTDF is an open source project that evolves the open TDF specification and provides a blueprint for getting started. There are a multitude of example applications that demonstrate the implementation logic, as well as streaming video and IoT use cases.

    The OpenTDF project is based on Kubernetes and OCI containers, and there is a quick start guide to get you up and running with a development environment. The quick start process will install supplemental services like Keycloak as well as project-specific services like key access service (KAS) and Abacus (an ABAC front end for configuration and management of attribute-based access control). Once you’ve completed a quick start installation, you’ll have a basic OpenTDF cluster with a Keycloak identity provider, PostgreSQL data store and a single entry point at localhost with an Nginx ingress controller.

    There’s an architectural diagram available on GitHub to see all of the services and service interactions.

    Several SDKs are available for building on the OpenTDF framework, including JavaScript, Python, C++ and Java. The client SDKs generally include basic examples for identity auth and creating a TDF-protected encrypted object.

    Take OpenTDF for a Spin: Secure Remote Storage

    Have you ever wondered how to make data access secure and simple? Using OpenTDF, developers can create that experience for their users. Let’s walk through a sample web application that uses OpenTDF to encrypt and upload data to cloud storage.

    The application we’ll be using is called OpenTDF Secure Remote Storage. It’s a react-based example that shows developers how to create encrypted data streams. These streams allow you to upload and download files from S3-compatible remote data stores while maintaining data protection. You can even remove encryption if needed.

    To make things easy, we’ll be using OpenTDF’s client-web SDK, which authenticates against Keycloak using OpenID Connect (OIDC). Keep in mind that this example runs on your local machine. It’s not designed for cloud or enterprise services.

    Prerequisites: You’ll need an S3-compatible storage object, like an Amazon S3 bucket. (You can create one for free here.)

    Set it Up

    First, install two CLI tools: Kind and Tilt. These will be used to deploy the OpenTDF services to your local machine. If you’re on macOS, you can install them with a simple Homebrew command: brew install kind tilt.

    Next, you will need the sample code on your local machine. You can either download the zip or clone the OpenTDF GitHub Repository using the following command: git clone git@github.com:opentdf/opentdf.git. This will create a directory called “opentdf” in your current location.

    Now, navigate to the root directory of the sample application: cd opentdf/examples/secure-remote-storage. To deploy OpenTDF, you’ll need a local Kubernetes cluster. Use the Kind CLI to create one: kind create cluster --name opentdf.

    Finally, start the application using Tilt: tilt up. This will launch the necessary OpenTDF services.

    Steps to Run the Application

    1. To begin, go to http://localhost:65432/secure-remote-storage in your web browser. This is where the Secure Remote Storage webpage is hosted.

    2. Now, it’s time to log in. Use the following credentials (defined in the bootstrap’s config file):
    ○ Username: user1
    ○ Password: testuser123

    3. Then, choose a file from your computer to upload. It can be anything – a text file, a PDF, or an image. Let your creativity flow! If you don’t have a file handy, no worries. You can download an image by right-clicking on it and selecting “Save As” from this link.

    4. Next, tell the application where to store your encrypted file. Provide the necessary JSON object that defines your S3-compatible object store. You can refer to the prerequisites for more details. (Optionally, you can save the configuration for future uploads. Just give it a name and click “Save.” This way, you won’t need to define the object store again in the future.)

    5. Now, it’s time to encrypt and upload. Click the “encrypt and upload” button, and watch the magic happen!

    What’s happening behind the scenes? When you click “encrypt and upload,” the application uses the OpenTDF API to convert your selected file into a .tdf file. It applies AES-GCM encryption and attaches access controls to ensure that only authorized users, like you (in this case, testuser123), can access the data. Even if your data store is public, your data remains secure.

    6. Ready to view and download your uploaded file? The table on the webpage lists all the files you’ve successfully uploaded. Each file has a download button next to it. Click that button, and the hosted file will be downloaded and decrypted on your local file system.

    Excited to explore more? Now that you’ve seen OpenTDF in action, you can dive into the source code of this application. Use this sample application as a starting point to integrate OpenTDF into your own secure applications.

    What Else is Possible With OpenTDF?

    From a secure webcam app to a privacy-forward menstrual tracking app and more, the possibilities are endless with OpenTDF and the future is in developers’ hands. By building on OpenTDF, the valuable data flowing through your applications will be protected forever.

    Learn more about OpenTDF at openTDF.io, and get the full quick-start guide, including more detailed instructions and other sample apps at the OpenTDF GitHub.

    Cassandra Zimmerman, technical product manager at Virtru, contributed to this article.

  • The Great CentOS Linux Migration: How We Got Here and What’s Next

    The Great CentOS Linux Migration: How We Got Here and What’s Next

    The recent news regarding Red Hat’s decision to limit access to the source code of their Red Hat Enterprise Linux (RHEL) distribution has garnered considerable attention. In order to understand the ramifications and subsequent changes, it is important to look back at CentOS, its historical alignment with RHEL and the options moving forward.

    CentOS Then and Now

    Starting in 2004, right from its inception, every iteration of the commercial RHEL offering triggered a corresponding release of CentOS. These iterations mirrored RHEL, albeit with modifications to eliminate the Red Hat branding and other minor updates. The presence of open source CentOS Linux facilitated swift installation of a free RHEL variant, rendering it accessible for diverse purposes spanning from development to production environments.

    In January 2014, Red Hat joined the CentOS project. Under a new CentOS governing board, they became the main sponsor and driver of the CentOS project. They continued to be an open source downstream alternative to RHEL.

    On December 8, 2020, the CentOS project and Red Hat set a new end-of-life (EOL) date for CentOS Linux 8. They shifted focus and investment into a new Linux distribution, CentOS Stream, with a rolling release model. EOL means that the community stops releases regardless of the severity of a bug or a vulnerability. Today, CentOS versions 6 and 8 are already EOL, and version 7 is the last, with EOL set for June 30, 2024. This announcement immediately sparked new projects to fill the CentOS gap. New open source projects such as Rocky Linux and AlmaLinux took off quickly, gaining contributors, sponsors and users.

    Fast forward to June 21, 2023, when Red Hat announced it would no longer publicly publish RHEL on git.centos.org.

    Previously, the source code was accessible to all, and it was used by various RHEL-compatible alternative open source projects such as Rocky Linux and AlmaLinux. It also affected other distributions, including Oracle Linux, which was a RHEL derivative for many years. All of these open source Linux distributions offered an alternative for applications; they were equally compatible with both free open source Linux and the commercial RHEL offering.

    According to the 2023 State of Open Source Report, 15% of all organizations and 20% of large organizations globally still have CentOS Linux deployed in their environments. Organizations have to move off EOL CentOS 6 and 8 and, in less than a year, off CentOS 7. Running EOL versions of any software can pose a substantial risk and cause failure in IT internal and external compliance. New vulnerabilities are constantly disclosed, and without updates or patches to CentOS, it is critical to plan for the “Great CentOS Linux Migration.”

    CentOS Migration Planning and Challenges

    Migration can be challenging. If organizations have legacy applications, they might encounter significant challenges making them work properly on a different Linux distribution. Even a small change in the individual packages that form the Linux distribution can impact and delay testing. While every application is different, and many are not dependent on low-level Linux functions, others could be significantly impacted. The number of CentOS deployments and applications has an exponential impact on the migration efforts. Evaluating different Linux distributions also takes time and will depend on the use cases, the skills developers have within each organization and the results of testing. The actual installation of a new Linux distribution is the easy part—the testing of all the layers on top of the operating system is what will take time. Some might be straightforward while others will require significant changes. Those are the reasons why it is helpful to stay with compatible distributions that will minimize the migration challenges.

    As organizations navigate the CentOS EOL and the migration period, it will be helpful to find options to extend CentOS long-term support. This means finding the expertise to generate patches that address newly disclosed high-severity vulnerabilities post-EOL. In other words, organizations must expand the community’s long-term support to address security.

    Wait for What’s Next

    The biggest question about alternative distributions is how closely they resemble RHEL. Are they going to continue to be bug-for-bug compatible? Or are there enough differences to no longer consider them application-compatible? The Rocky Linux Enterprise Software Foundation announced its plan to access RHEL source code and its intentions to continue to be bug-for-bug compatible. AlmaLinux OS Foundation announced a different approach. It is working with the CentOS Stream community while maintaining binary compatibility. This means not strictly bug-for-bug but focusing on applications to continue to be compatible.

    It is possible we’ll see other potential changes from Red Hat with regard to the access to RHEL’s source code. Today, it’s only available to customers under a commercial license agreement.

    The big test will be the next minor version, RHEL 9.3. It will be interesting to review the corresponding 9.3 versions of Rocky Linux, AlmaLinux, Oracle and others, including SUSE, who announced their intention to offer an open source compatible Linux distribution. The analysis and comparison of how applications run with the new minor version will reveal how close they are to RHEL.

    To mitigate uneasiness, organizations have to plan and test alternatives. Finding post-EOL support and patches will allow organizations to have a runway for migrating CentOS to different Linux distributions.

    As everyone in the industry with CentOS deployments waits for the next release or the next few releases, extending long-term support becomes a very viable solution. It is wise to make sure security and IT compliance aspects are addressed. Perhaps more open source Linux distributions will appear in the near future and offer another alternative to CentOS Linux.

  • 3 Ways to Achieve Faster App Development Without Compromising Security

    3 Ways to Achieve Faster App Development Without Compromising Security

    Bringing products to market quickly, efficiently and safely is key to brand success, and elite DevOps teams minimize the lead time for changes by quickly and efficiently moving new products and software updates from concept to deployment. DevOps teams often measure lead time in hours, not days, weeks or months, which underscores the centrality of speed in today’s hyper-competitive online environment. Customer experience and brand loyalty are constantly changing as new products and services come to market, and DevOps teams are under immense pressure to stay as agile and efficient as possible. Increased technology development velocity can lead to heightened security risks. As of early 2023, as many as nine out of 10 companies have detected security risks in their software supply chain. This is why companies cannot ignore the rising number of attacks targeting software development teams.

    High-profile incidents at SolarWinds, NetBeans IDE, Kaseya and Codecov demonstrate the risks facing software development teams at every company.

    These threats exploit the continuous integration and continuous delivery (CI/CD) process to sneak harmful software into authentic applications and install risky and harmful components whenever possible.

    The risk of code injections makes safeguarding internal and external dependencies crucial. If not appropriately protected, compromised software pipelines can lead to data leaks, code tampering and system exploitations, putting the entire business at a heightened risk.

    Simply put, DevOps teams must maximize development speed without compromising security. This is an undoubtedly tall order, but one that’s achievable with the right processes in place. Here are three strategies DevOps teams can implement immediately to reach this goal.

    Streamline Privileged Access Management

    Streamlining privileged access management is vital for enhancing cybersecurity in DevOps teams, particularly with the growing threats to software supply chains. This requires adopting stringent security practices, including temporary access permissions that can be granted and revoked as needed—a strategy ideal for managing temporary services in DevOps workflows.

    This approach facilitates automatic management of access privileges, including revoking password permissions when team members leave the organization or project and thorough scrutiny of who has access to what.

    At the same time, enforcing least privilege access, a principle that aims to minimize the attack surface by eliminating unnecessary permissions and adjusting overly broad ones, is also essential, reducing the chances of account hijacking or theft of static API keys.

    Similarly, zero standing privileges are also essential, relying on just-in-time access management that ensures minimal active permissions at any given moment, enhancing security by reducing potential vulnerabilities.

    Leverage AI Solutions for Security

    The cybersecurity AI sector is soaring alongside escalating cybersecurity threats to DevOps teams.

    Deloitte expects cybersecurity AI solutions to become a $19 billion market by 2025, as the technology’s “ability to adaptively learn and detect novel patterns can accelerate detection, containment and response, easing the burden on SOC analysts and allowing them to be more proactive.”

    AI can help DevOps teams detect and prevent cybersecurity incidents by quickly identifying and monitoring applications at risk, ensuring greater resilience in their DevOps processes through CI/CD, applying analytics to streamline data challenges, and identifying potential hot spots before they escalate and present real risks.

    AI can also help combat alert fatigue within security teams, reduce analyst workloads and cut down on false positives, saving valuable time. According to a 2022 IT industry study, 60% of respondents receive more than 500 cloud security alerts every day, and alert fatigue is “causing critical alerts to be missed at an alarming rate.”

    By leveraging AI for cybersecurity, DevOps teams can enhance their defensive posture without diluting their team’s impact, allowing them to best balance speed and security in the app development process.

    Enable Communication and Collaboration in DevOps Teams

    In the realm of DevOps, success relies not only on implementing the right tools and technology but also on fostering an adaptive culture that encourages seamless communication and collaboration among team members.

    Effective communication forms the bedrock of this cultural shift. By establishing clear lines of communication, development and operations teams can better understand each other’s challenges and perspectives. Open dialogues can foster mutual respect and create a shared understanding of common goals, thereby encouraging a collaborative problem-solving approach.

    Meanwhile, fostering a collaborative culture is equally vital. When teams collaborate effectively, they can identify and resolve issues more quickly, improve the quality of the software, and accelerate delivery times.

    Embracing Speed and Security in App Development

    Achieving faster app development without compromising security is a complex yet achievable goal in today’s competitive environment.

    By investing in streamlining privileged access management, leveraging AI and fostering a culture of effective communication and collaboration, DevOps teams can enhance both speed and security.

    To be sure, in the face of escalating cyberthreats, speed and security are not mutually exclusive but, rather, two sides of the same coin. By implementing these strategies, DevOps teams can navigate this delicate balance, accelerating development timelines while ensuring robust security.

  • Stop Leaking Secrets!

    Stop Leaking Secrets!

    Merriam-Webster defines a secret as something kept from others or shared only confidentially with a few. Modern software development teams use software secrets such as passwords, tokens and API keys to properly set up, protect and maintain development environments and delivery pipelines and to enable programmatic access to services such as AWS Buckets or Azure Blob Storage for cloud-native apps. Yet, while secrets are critical for modern software to function, they are difficult to manage across delivery stages. All too often, software teams trip over the complexities and inadvertently leave these secrets exposed in both public and private software repositories.

    Potential exposures can stem from many factors: Plain text passwords, weak cryptography, flawed CI/CD or packaging automation and compromised developer accounts or malicious insiders. Whatever the cause, bad actors are regularly scouring repositories and application binaries for hard-coded secrets they can exploit. Look no further than the CircleCI and CodeCov incidents, where exposed secrets left these organizations vulnerable to adversaries intent on attacking software supply chains.

    Rethink Secrets Prioritization

    According to GitGuardian analysis, 10 million new secrets occurrences were exposed on GitHub in 2022, a 67% increase compared to the company’s 2021 findings. As software becomes larger and more complex–with open source, third-party and commercial components–the number of detected secrets will only increase, creating a different challenge: Prioritization for remediation.

    Regrettably, teams lack a scalable means to understand which detected secrets developers can’t or shouldn’t remediate. Today, teams must manually sift through potentially thousands of detections and understand their context to triage these threats. Gaining context means discovering where secrets reside (in your code, in a software dependency, in the documentation included with your software) and understanding their purpose (to access resources, to enable user testing, to enable intrusion detection).

    As teams consider how to simplify and automate the prioritization of secrets, important questions to consider include:

    ● What secrets are your developers responsible for protecting? For example, secrets used to access internal CI/CD pipeline technologies. Depending on permissions, leaking these secrets enables malicious actors to change automated build processes with no one being the wiser. Similarly, API credentials to access data or services needed for their code to function. Leaking these secrets gives malicious actors programmatic access to those APIs, which can be a gold mine of customer data or further compromise the environment.
    ● What secrets are worth protecting? There are some you may be responsible for but which are not worth protecting. For example, to facilitate automated software testing, developers typically publish API keys and certificates in public repositories alongside their applications or in documentation bundled into release packages or software containers. Since these testing “secrets” are designed to be commonly shared, they should not be encrypted or protected.
    ● Which detected secrets are not actionable? For example, developers typically cannot manage secrets in third-party or commercial components and dependencies within software. Instead, these exposures represent a third-party risk management problem. Another example is canary secrets added to software by security operations; remediating these secrets hampers intrusion detection.

    Once teams have established their secrets definitions, building a process to identify and prioritize them comes next.

    Managing Secrets

    Any organization involved in software development should have clear rules for handling and incorporating secrets into code and for communicating that process and those rules to developers. Here are secrets best practices every organization should take into consideration:

    ● Promote developer best practices — and monitor compliance: Secrets leaks are more likely to occur in development organizations that lack clear guidelines for properly managing secrets in their code and easy-to-use tools to implement those guidelines. DevOps teams should formulate policies based on an understanding of how secrets are generated within their development environment, how those secrets are protected once deployed and how (hopefully) they are eventually cycled out of use.

    ● Revamp how applications use secrets: Design applications in a way that eliminates the reliance on access tokens that reside in code. Use technologies like OAuth OpenID Connect (OIDC) tokens that allow developers to authenticate users without directly exposing user credentials in code. Reduce the risk of abuse by using multi-factor authentication, leveraging identity and access management platforms and setting IP ranges that limit inbound connections for APIs to known addresses or address ranges.

    ● Establish end-to-end security: Misconfigurations in CI/CD tooling or release oversight can result in the inclusion of secrets during final builds that might otherwise escape notice during a code audit. Consider implementing binary analysis to extend visibility into leaked secrets beyond raw code and into software packages and containers ready for release. This capability can detect exposed secrets resulting from build or packaging automation.

    ● Streamline secrets prioritization: Noisy scanning results create a ton of triage work just to weed out false positives (e.g., widely distributed testing keys or network credential placeholders) before remediation can start. Automating some of this triage with relevant file intelligence saves countless hours of effort and ensures developers focus on addressing actual risks.

    No Silver Bullet

    Unfortunately, there is no “silver bullet” fix for software supply chain risks and attacks, nor for leaks and exposures. Instead, organizations need a holistic approach that includes scoping the problem, addressing short-term risks posed by leaked credentials and then extending changes in all processes with an eye toward taking the toil out of identifying, prioritizing and remediating secrets leaks—and therefore preventing potential supply chain attacks before they can happen.

  • From DevOps to the Future: The Evolutionary Leap to Platform Engineering

    From DevOps to the Future: The Evolutionary Leap to Platform Engineering

    The paradigm of technology development never ceases to amaze. Over the past few decades, we’ve witnessed an unbroken chain of progress from traditional IT to Agile methodologies, from cloud computing to microservices and now, another leap is on the horizon. Enter the age of the platform engineer, a role that is swiftly emerging as a logical evolution of DevOps culture.

    From the Roots: Understanding DevOps

    DevOps revolutionized the way teams design, build and deliver software. With its advent, we saw the amalgamation of developers and operators into a single team, fostering a culture of collaboration and integration. The core idea was to tear down the traditional silos and ensure seamless interaction between different stakeholders in the development process.

    This unique approach has proven its mettle over time, bringing about shorter development cycles, higher deployment frequency, more dependable releases and quicker resolution of issues. DevOps set the stage for continuous delivery, integration and monitoring, thus speeding up the digital transformation of many organizations.

    The Evolution: Birth of the Platform Engineer

    As we delve further into the era of cloud-native technologies, containers and service meshes, the demands on the DevOps methodology have evolved. To cater to the increasing complexity and scale of modern infrastructures, we witness the emergence of a new breed of professionals, aptly titled platform engineers.

    This role is not just a renaming of the traditional DevOps engineer; it is an evolution. Platform engineers build upon the foundational practices of DevOps but go beyond by embracing a holistic view of the technology stack. They focus on creating platforms that provide a unified, consistent, and efficient environment for development and operations teams to work within.

    Platform Engineering: The Core Components

    Platform engineers possess a skillset that spans software development, infrastructure management, system operations, and, importantly, a deep understanding of the business context. They are entrusted with the design, construction and management of the underlying platforms supporting the deployment and scaling of applications.

    A significant part of the platform engineer’s role involves creating self-service infrastructures that empower teams to deliver software independently and efficiently. This can involve building and managing internal toolchains, maintaining cloud-native infrastructures, designing service observability systems and ensuring high levels of automation across the board. 

    The Future is Here: Embracing Platform Engineering

    The rise of the platform engineer signifies a shift towards more scalability, resilience and efficiency in managing modern tech ecosystems. It’s about leveraging technology to its fullest extent and creating a platform that is more than the sum of its parts. 

    As the technology landscape continues to evolve, the transition from DevOps to platform engineering may soon become the norm. It’s an exciting prospect, promising a future where innovative platforms can seamlessly integrate and orchestrate the complexities of the modern digital world. After all, in this era of rapid digital transformation, those who adapt will thrive. 

    In conclusion, the platform engineer role is not replacing DevOps but evolving from it, extending the principles that made DevOps so successful to meet the challenges and opportunities of the new tech era. As we continue this exciting journey into the future of software development and delivery, there’s no doubt that platform engineering will play an increasingly important role.