devopsy.kinsta.cloud

Author: Limor Wainstein

  • Serverless Computing: Taking DevOps to the Next Level

    Serverless Computing: Taking DevOps to the Next Level

    Serverless computing enables you to outsource information, thus freeing teams to focus on front-end work. Organizations choose serverless when they look for faster and easier ways to release updates and patches. DevOps teams often use serverless when they are looking to automate infrastructure tasks. However, each provider offers different capabilities, and each service does require a level of training pre-adoption.

    What Is Serverless Computing?

    Serverless computing is a method that outsources infrastructure and infrastructure tasks to external providers. Organizations choose serverless computing because it enables development and operations teams to focus on the front-end of products and services.

    There are a few traits that distinguish serverless infrastructures from traditional cloud automation models:

    • Serverless computing services eliminate user responsibility for the management or operation of infrastructure.
    • Serverless computing services enable users to run code on-demand according to requests or event triggers. Infrastructure use scales transparently based on how many requests or events occur.
    • Serverless computing is pay-for-use and can be used to ensure that users pay only for actively used resources.

    The benefits of serverless in enterprise environments include:

    • Better control over production deployments.
    • Faster and easier updates or patches.
    • Increased productivity and easier release rollouts.

    Popular Serverless Computing Services

    All three major cloud providers offer serverless computing services. Below you can learn about these services and how each operates.

    AWS Lambda

    AWS Lambda is a service for serverless computing with other AWS services or via API. It can be connected to applications or run as standalone code. When using Lambda, users pay for active compute time although instances can be reserved to ensure their code runs with menial latency.

    Lambda can be triggered by a variety of AWS services, including Kinesis and DynamoDB. It can be monitored through Amazon Cloud Watch. Common use cases for Lambda include data processing, stream processing, machine learning and application backends.

    Azure Functions

    Azure Functions is Microsoft’s serverless service. You can use it for end-to-end development, including building, testing and deploying code. Functions can be used with a variety of Azure services and integrate with Visual Studio and Visual Studio Code for easy use.

    In addition to Functions, Azure offers Logic Apps, a service for creating visual design workflows and orchestrating Functions activities, and Event Grid, a message routing service to integrate Functions with other Azure services.

    Google Cloud Functions

    Cloud Functions is Google Cloud Platform’s functions as a service (FaaS) (i.e. serverless) offering. It can be used in the cloud or with hybrid deployments and it includes built-in monitoring, logging and debugging features.

    Cloud Functions supports a variety of environments including Cloud Run, Kubernetes and other Knative-based environments. Use cases for Cloud Functions include integration with third-party services, application backends, real-time processing, virtual assistants and machine learning.

    Why Serverless for DevOps

    If you are already using a DevOps approach or are considering adopting one, serverless can be a good option. Many DevOps teams, especially those operating in the cloud, are already working with modular components managed via a pipeline. Moving these modular services to serverless can enable teams to eliminate some of the tasks related to pipeline management and focus on development and deployment.

    This capability is especially valuable for teams that are just getting started or are looking to switch to DevOps practices. Serverless systems can enable teams to get started with development and testing right away on a comfortable scale. Then, as productivity increases, the serverless infrastructure can smoothly scale with minimal to no effort on the part of operations.

    Another benefit of serverless infrastructures is the ability to easily enable DevOps automation. With serverless, you can deploy your pipeline without hosted solutions. You are only responsible for “glue code.” This infrastructure is flexible and you can easily modify it as needed using infrastructure as code (IaC) solutions and automated events.

    Despite these benefits, there is a potential downside to serverless. Your DevOps team does not have the same visibility into or control of the functioning of the infrastructure. While you can integrate monitoring, teams are limited in how much of the infrastructure can be customized or manually affected.

    How Serverless Can Take DevOps to the Next Level

    There are several ways serverless deployments can be leveraged to improve DevOps productivity. Below are a few examples to consider.

    Infrastructure as Code

    Provisioning infrastructure is often a significant portion of deployment processes. Many applications use a variety of serverless services as building blocks through all stages of development and release. Making sure that these services are correctly connected and configured is key to a successful deployment.

    IaC can help users accomplish these tasks smoothly by leveraging declarative languages and tools such as Terraform. With these solutions, users can version your infrastructure along with their code, keeping tasks in sync and deployments consistent.

    Flexible Deployments

    With serverless services, infrastructure is immutable. Any changes result in new instances being spun up and activated. This means both old and new versions can run simultaneously.

    This immutability can be used to perform flexible deployments that are not possible or are much more difficult with traditional infrastructures; for example, canary or blue-green deployments. With serverless infrastructure, users can switch from one version to another with minimal fear of service interruptions and the ability to easily rollback updates.

    Distributed DevOps

    Serverless services can enable DevOps teams to work across a variety of environments and locations with minimal impact on others. These services allow the distribution of workloads at scale and can ensure that infrastructure is always available.

    The catch is that greater distribution and the ephemeral nature of serverless can make infrastructure much more difficult to monitor effectively. To account for this, teams need to ensure centralized monitoring with real-time alerts. Teams should also periodically audit infrastructure availability and performance to ensure that resources are functioning as expected.

    Conclusion

    Serverless computing enables DevOps teams to eliminate time and cost on the back end. Each serverless provider offers different services that can help achieve different capabilities. The main capabilities are provided via the use of functions, which enable the automation of infrastructure. However, in most cases, teams do need to learn how to use functions to properly configure customized IaC workflows. Once teams understand how to use the software, they can create flexible deployments and a distributed DevOps pipeline.

  • How Secure is Open Source for DevOps? 5 Considerations

    How Secure is Open Source for DevOps? 5 Considerations

    Open source libraries and frameworks have important roles to play in a DevOps culture that emphasizes shorter development life cycles, collaboration and innovation. However, it’s vital not to neglect the security of these open source components.

    This article discusses the use of open source in DevOps and gives you five things to consider in terms of the security of any open source project your teams might want to use in your software builds.

    Open Source and DevOps Overview

    Proprietary applications, many of which are developed within organizations that have adopted a DevOps approach, feature an average of 257 open source components per application. Furthermore, the average percentage of codebases that are open source within proprietary apps stands at 57 percent. It’s clear that open source fits well with DevOps in how it can help deliver quality software that can be rapidly updated and improved.

    In addition to the increasingly popular use of open source libraries and frameworks to deliver ready-made software components, quite a number of tools used in DevOps are actually open source. Examples of open source DevOps tools include Docker and Kubernetes.

    It’s crucial that development teams focus on security when using open source code, components and tools. Several of the most high-profile IT security and software breaches of recent times have resulted from vulnerabilities in open source components.

    To adequately combine security, open source and DevOps, there is a pressing need to shift left and secure the software development life cycle (SDLC), starting from the earliest stages of development.

    DevOps Open Source Security Considerations

    The Need For Security Automation

    An important driving force in achieving the aims of DevOps is to automate as much as possible. DevOps automation strategies include the use of technologies such as virtual machines and containerization to repackage applications into reusable blocks, many of which contain open source code. This high level of automation dramatically shortens the SDLC.

    However, because of this automation and the pace at which code changes and updates occur, security teams are easily left behind, and they might miss out on identifying open source vulnerabilities. InfoSec teams need to figure out ways of automating several of the most important security procedures, such as configuration checks, code analysis and vulnerability scanning. By introducing greater automation into security checks, it’s less likely that DevOps practices will lead to releasing software containing vulnerable open source components. Faster time to market combined with high-quality, secure code is the ultimate goal.

    Securing Open Source Using Open Source Tools

    Given that open source code forms the majority of the footprint of modern proprietary codebases, it makes sense to focus on the security of these libraries and frameworks first. Somewhat ironically, open source tools provide a good way to improve open source security in DevOps.

    For example, teams can use open source software management programs such as JFrog Artifactory to create binary local repositories of open source software libraries and code. These repositories give teams a single place from which they can use the latest versions of open source code that they have deemed to be secure.

    OWASP dependency-check is another useful open source tool for security teams that checks which components an application uses and whether such components contain known vulnerabilities.

    Incorporate Open Source Code-Checking Tools Into Development

    Part of the idea of shifting security to the left involves developers overcoming the inherent tendency to focus solely on application functionality without considering security. While training materials exist that teach the basics of secure apps, developers might find the material somewhat esoteric, particularly if it’s targeted toward InfoSec teams.

    One way to overcome developer resistance and shift security to the left is to integrate some open source code-checking tools into development environments. Tools such as Brakeman or Rubocop are freely available, and they can rapidly check code for common vulnerabilities.

    Hackers Targeting Open Source

    One of the difficulties with the increased use of open source is that hackers and cybercriminals are always aware of components that contain vulnerabilities. The hackers can then use this knowledge to specifically target companies developing software using those components.

    Cybercriminals know that DevOps emphasizes faster time to market, and they are always lurking to find those organizations that have become lax in their IT security checks. The Equifax data breach happened precisely because the company used a vulnerable version of the open source Apache Struts framework. The Equifax case exemplifies the potential danger of open source components in organizations where DevOps and InfoSec are out of sync.

    The Need for Policy and Governance 

    For DevOps and open source to work together to deliver secure software, there is a real need to create dedicated open source policies by DevOps organizations. When developers are given free rein to use open source libraries and frameworks without monitoring or documentation, vulnerabilities creep into applications and future trouble awaits.

    The first step is for organizations to recognize their reliance on open source before forming a governance policy that stipulates how to manage open source inventories to reduce security risks.

    Wrap Up

    Going forward, it’s clear that the open source model offers many advantages to DevOps teams in terms of achieving their goals.  Additionally, several open source tools can even enhance the security of the applications developed in DevOps. However, it’s prudent to understand the security concerns that lie at the heart of open source and shift security left so that any vulnerabilities can be found as early as possible in the SDLC.

    — Limor Wainstein