devopsy.kinsta.cloud

Category: DevOps and Open Technologies

Editorial Calendar for February 2016

  • How Encryption Innovation Will Power Cloud Privacy for Developers in 2024

    How Encryption Innovation Will Power Cloud Privacy for Developers in 2024

    For developers, the surge in cloud computing adoption has brought both new opportunities and challenges. On the one hand, developers are turning to cloud services for data storage, processing and accessibility due to their flexibility, convenience and cost-effectiveness. And because the cloud takes care of these infrastructure and operational concerns, it’s allowing developers to focus on coding, innovation and delivering value to end-users. It also allows companies to scale more easily when their market grows or when new hardware becomes available.

    However, this paradigm shift has led to the accumulation of vast volumes of sensitive data on remote cloud servers—including personal, health, financial and proprietary business information. As the volume of sensitive data on the cloud continues to grow, it has naturally raised mounting security concerns, from data breaches and cyberattacks, to unauthorised access and the complexities in complying with specific industry regulations, such as GDPR or CCPA.

    For some, having to rely on the cloud provider to maintain robust security practices and data protection has also led to hesitancy in sharing data, both within and between organizations. This not only limits the potential for data-driven collaboration, research, and innovation—essentially halting progress in fields like health care, science, and social sciences—but businesses of all types and sizes could miss opportunities for cost savings, scalability, and efficiency if they’re not willing to adopt innovative technologies. There are also cases when companies are forbidden to do something by law because of privacy, again causing roadblocks.

    All of this has meant that up until now, maintaining data privacy while making the most of cloud computing has been somewhat of a balancing act for developers and companies. Companies want to fulfill their clients’ needs, while developers have to find technical solutions that provide the level of privacy required.

    Traditional Encryption methods Vs. Fully Homomorphic Encryption (FHE)

    Currently, there are several technologies and practices employed to protect data in the cloud, one of the most commonly used being traditional data encryption, which provides protection only during data transmission and storage.

    However, when data is processed, it must be decrypted—at which point it can expose data to eavesdropping, rendering it susceptible to potential threats. The aim of FHE is to ensure that the computations can be carried out on cloud-based machines while the data itself remains encrypted. With FHE, the data is really encrypted end-to-end: not only is it encrypted during transport and storage, but also it is encrypted during computations. It is only when the data or results are sent back to the client side that they are decrypted.

    This means that in the event of a data leak, the exposed information would be rendered meaningless without the decryption key, which stays securely in the hands of the owner. In other words, neither the cloud provider nor any potential spyware on the cloud machine would have the capability to decrypt the encrypted data.

    This approach, which ensures sensitive data remains encrypted throughout its entire life cycle on the cloud, even during processing and analysis, significantly enhances data security and privacy.

    Current Limitations and FHE’s Future Developments

    While developers using traditional cloud services previously had to decide whether to use the cloud with some privacy concerns or forgo its benefits altogether, with FHE we are starting to see a possible shift in attention from users’ reliance on the cloud provider to a more user-controlled approach.

    As FHE becomes more widespread, users gain the ability to make their computations over any cloud provider, even those they may not fully trust. This means the upfront costs of building new cloud platforms can be lowered by providing only FHE computation.

    While the encryption of data ensures that computations are secure and no unauthorized access or breaches can occur, this new tech is not without its limitations. For the enhanced security FHE offers, there may come a trade-off of longer execution times. Presently, we are mainly reliant on CPUs for computations. However it’s worth noting that as the technology advances and hardware accelerators become available, the execution time is expected to improve in the future. In fact, we anticipate that by 2026, FHE implementations will see a considerable increase in speed, potentially by factors of 100x or 1,000x, expanding the applicability of FHE to a wider range of use cases.

    Other benefits currently being worked on include usability. FHE had a reputation of being very complex and so used to be reserved for those with cryptography PhDs. By developing open source tools and extending the community’s knowledge around FHE, the aim is to democratize FHE so that anyone can use it, companies can experiment free of charge and check if it fulfills their needs.

    Looking to the future, privacy will likely remain high on the agenda for almost everyone. Thankfully, with new encryption technologies rapidly developing in terms of speed and usability, developers look set to achieve this, ensuring their cloud-based applications and services are as secure as possible.

  • Lineaje Allies With Persistent Systems on Open Source Software Remediation Service

    Lineaje Allies With Persistent Systems on Open Source Software Remediation Service

    Lineaje this week revealed it has partnered with Persistent Systems to provide a managed service for remediating open source vulnerabilities that leverages artificial intelligence (AI) technologies.

    Persistent is extending an existing open source software maintenance service by incorporating a Lineaje platform that makes use of machine learning algorithms to analyze software bill of materials (SBOMs) to provide recommendations for fixing code and surface remediations such as updates that should be applied.

    Lineage CEO Javed Hasan said Persistent Systems is augmenting that capability with a dedicated team of specialists that IT organizations can contract to maintain open source code along with previous investments the managed service provider has made in large language models (LLMs) that add generative AI capabilities.

    Options for the services range from simply identifying issues that an internal IT team should address to a white glove offering through which Persistent Systems ensures all open source components are continuously updated.

    In the wake of an executive order issued by the Biden administration that requires federal agencies to better secure their software supply chains, more attention is being focused on the inherent cybersecurity risks associated with employing open source software to build applications. Many open source projects are led by a handful of maintainers that often lack the time and skills required to ensure the components they employ have not, for example, been compromised by malware that might find its way into downstream applications.

    Those maintainers are not being paid, so cybersecurity patches to open source software might not be readily made available, and even when they are, many organizations lack the skills and resources required to apply them in a timely manner. The majority of known vulnerabilities within application environments are still unpatched. Many IT teams are also reluctant to upgrade components for fear of breaking applications that have dependencies that are often difficult to track.

    It’s not known how much of the open source software that many developers routinely incorporate into their applications might contain vulnerabilities that could be exploited, but the level of technical debt that has accrued over the last several decades is considerable. While only a small percentage of those vulnerabilities have been exploited, cybercriminals are becoming more adept at discovering them.

    Hopefully, more contributions to open source projects will improve the overall state of application security, but in the meantime, it’s clear organizations will need to rely more on AI to drive DevSecOps workflows as ever-increasing amount of open source software continues to be relied on to build applications, said Hasan.

    The challenge, of course, is identifying which vulnerabilities, if exploited, will have the biggest impact on the organization. After all, at this point, it’s not possible to defend every application so the focus needs to be on prioritizing remediation efforts based on their actual severity rather than a general rating.

    In the meantime, DevSecOps teams would be well-advised to have incident response plans in place for remediating breaches involving both known and zero-day vulnerabilities that, in addition to being all but inevitable, can now be exploited within minutes of being discovered.

  • Evolution of Toil Identification and Mitigation – A Classic SRE Challenge

    Evolution of Toil Identification and Mitigation – A Classic SRE Challenge

    Ingo Averdunk, leading architecture and solutions for cloud service management and site reliability engineering for IBM Cloud, contributed to this article.

    Christine White, architect at IBM Consulting, also contributed to this article.

    When many people think of operations, they often associate it with manual, labor-intensive work. This is because operations traditionally encompass a wide range of activities that involve managing and executing tasks related to producing, distributing and maintaining goods and services. Information technology (IT) is not different: Manual work has traditionally been a significant component of various tasks and processes. Examples are server maintenance, software installation, troubleshooting and network configuration, which historically required manual intervention and human expertise. Much of the work is inherently repetitive by nature, time-consuming and prone to errors. We call this work “toil”, the kind of work tied to running a production service that tends to be manual, repetitive, automatable, tactical, devoid of enduring value and that scales linearly as a service grows.

    Toil

    This toil has always been there. And toil leads to burnout, increased errors and reduced scalability. Only how we have addressed it has changed. While toil remains, toil mitigation has evolved.

    In the beginning, toil was addressed through labor arbitrage. Between 2000 and 2010, we leveraged labor arbitrage to reduce the cost of manual work by outsourcing and out-tasking activities to near-shore and later off-shore countries. When there is a problem, the person who can solve it steps up. Then, to manage it better, we started to do workload or work item management. You have systems, like prioritized backlogs, and we started putting a structure on how we solve these problems. But still, it was all resource-based; everything was resource-intensive. And that is why the engineers became more of the subject matter experts (SME). Being a subject matter expert took time, and being critical to operations became exhausting. And the repetitive manual activities required took time and effort they didn’t have.

    As issues became repetitive, we started thinking about scripting. We evolved from a complete labor arbitrage mentality to writing spot scripts. Engineers began to use scripts to solve a small part of the most oppressive problem.

    Tools started to be developed to enable and automate some of the work. Organizations purchased tools, and education of the tools commenced. It became important to be an SME in your area and an SME of the tools in your area. However, the tools were specific to certain functions and features that they provided, and the software development life cycle (SDLC) had a lot of nuances that many of the tools did not capture. So even when the tools helped, it created this mass of white spaces that could not be integrated easily. Tools were very format-specific and didn’t have the flexibility end to end integration. Newer problems emerged as formats were different, speeds were different, and other differences manifested. Even as this initial approach was an improvement over the labor arbitrage mentality and reduced the amount of manual effort required, it often resulted in complex and brittle systems that were difficult to maintain and debug.

    Automation

    From 2015 to 2020, automation became more prevalent. On one side, the cost levers of labor arbitrage were reduced, and due to low skill, quality suffered. Thanks to technological advancements, automation in various flavors became a viable alternative: Runbook automation, robotic process automation, etc.

    Aligning tool isolation with SDLC nuances required an end-to-end automation philosophy. We need to do automation across the board. Toil elimination was a goal of end-to-end automation, and that obsession led to SRE thinking and the principle of capping operational load. An SRE spends only 50% of his time on operational activities, and the other 50% on “engineering” (improvements): Identification and elimination of problem areas, improving and integrating tooling, etc. And thus, the genesis of the next wave of reliability engineering principles began.

    Parallel to this, adopting DevOps and Agile practices as well as cloud computing enabled IT teams to define and manage infrastructure and application configurations through code, allowing for automated provisioning and scaling. Applications are designed for reliability and instrumented for observability, providing insights into the production use. Traditional organizational barriers are broken down and teams cooperate across the entire SDLC with a shared goal that balances velocity and quality.

    The new focus on leveraging cloud-native technologies and practices to build scalable, flexible and resilient systems allowed SRE teams to adopt cloud-native technologies such as Kubernetes, containers and serverless computing to build systems that are designed to be highly available, fault-tolerant and easy to maintain.

    Toil mitigation and the SDLC lifecycle have evolved from reactive handling of problems to a proactive approach to operations, where alerting is maturing, and other sophisticated instrumentation is implemented. A proactive approach underlined the importance of observability and monitoring. SRE teams are using observability tools such as Prometheus, Grafana and New Relic to monitor their systems in real-time. The ability to identify potential issues before they become incidents emerges.

    AI Infusion

    The next step is being more prescriptive and predictive. That calls for a good bit of AI infusion. We have historical knowledge management systems that will tell us what went wrong, how it went wrong, how it got resolved and how long it took. We can augment that knowledge base with publicly available and curated knowledge.

    Starting in 2020, AI and machine learning are being used in IT for tasks such as anomaly detection, predictive maintenance, risk assessment and automated incident response, reducing the manual effort required for monitoring and maintaining systems.

    AI systems can learn from all this and not only predict issues, but when issues happen, they also auto-resolve. An extension of AI, Generative AI, will disrupt this event more. Prediction of a problem will also lead to the generation of executable runbooks and playbooks, which are agnostic to specific types of automation or automation tools. New challenges such as data quality, model training and explainability have arisen simultaneously and human intervention is still required until we can reach a certain comfort level. There will need to be a manual effort to look at Generative AI proposed solutions, approve them and prove the solutions in lower-level environments, before applying them into production environments.

    In the next 18 – 36 months, we will see that morph into risk-taking, where Generative AI will become digital operations. If we look at an Ops team or a SRE team, there are different personas, and we firmly believe that those personas will be assisted by an AI bot. These bots will participate in daily standups, and they will learn. They will participate in issue-resolution processes, and they will learn. They will start participating in retrospectives, and they will learn. This “AI persona” will become a digital worker in a highly integrated digital team. The manual tasks that once were solved through AI are now becoming complex decision-making processes. We are entering the 4th wave of automation improvements using Generative AI.

    Be Prepared

    Just as the invention of fire, tires, the printing press, the telephone and the lightbulb, what we do with this advancement will greatly shape our future. We must be prepared. And the best way to be prepared is to upskill our practitioners with newer technology skills like AI. The upskilling needs to include all the core and peripheral benefits and concerns to help them manage and improve upon the current day. We need to clarify roles amongst practitioners so there is not an “I’m being replaced by a bot” mentality, and most importantly being open-minded about the possibilities, building on those possibilities and embracing risk rather than fighting it!