devopsy.kinsta.cloud

Tag: serverless

  • 5 Serverless Challenges of DevOps Teams and How to Overcome Them

    5 Serverless Challenges of DevOps Teams and How to Overcome Them

    Serverless is a cloud computing execution model where the cloud provider dynamically manages the allocation of machine resources. The term ‘serverless’ might be somewhat misleading as it doesn’t mean servers are not involved. Instead, it means that developers no longer have to think about servers, even though they’re running on them.

    The idea is to abstract the infrastructure away so that developers can focus solely on the code. Functions, the units of code, are triggered by a variety of events, including HTTP requests, database events, queuing services, monitoring alerts, file uploads, scheduled events (cron jobs), and user sign-ups or in-app activities.

    The Importance of Serverless for DevOps Teams

    Serverless computing brings a paradigm shift in how applications are built, deployed and managed, directly impacting DevOps teams. The core advantage of serverless for these teams is the significant reduction in operational overhead. With serverless, the cloud provider takes responsibility for running the server, ensuring its reliability, and scaling the infrastructure. This frees DevOps teams from the routine tasks of server provisioning, maintenance, and patching, allowing them to focus more on optimizing the application’s code and business logic.

    However, this shift also demands a change in mindset and approach. DevOps teams must adapt to a more granular, event-driven architecture that serverless promotes. They need to design systems thinking about individual functions and how they interact, instead of traditional monolithic applications or even microservices. This requires a deeper understanding of the cloud environment and its services, as serverless functions are often tightly integrated with other cloud services like databases, message queues, and API gateways.

    Moreover, serverless computing introduces new challenges in areas like security, monitoring, and cost management. For instance, the ephemeral nature of serverless functions can make traditional monitoring approaches less effective, and the dynamic scaling can lead to unpredictable costs. DevOps teams need to develop new strategies and adopt specialized tools to address these challenges. Despite these issues, the benefits of serverless – in terms of agility, scalability, and potential cost savings – make it an increasingly essential tool in the DevOps arsenal, particularly for organizations looking to innovate and deploy rapidly in a cloud-centric world.

    5 Serverless Challenges of DevOps Teams and How to Overcome Them

    1. Complexity of Monitoring in Serverless

    A main challenge in the serverless world is the complexity of monitoring. Unlike traditional architectures where you can monitor physical or virtual servers, in serverless, you need to monitor individual functions. This can be tricky as you may have hundreds or even thousands of functions running simultaneously.

    To effectively monitor serverless architectures, you need to go beyond traditional methods. You need tools that can provide insights at the function level, such as AWS CloudWatch or Azure Monitor. These tools allow you to monitor metrics like execution time, error rates, and invocation counts for each of your functions.

    But monitoring is not just about gathering metrics. It’s also about understanding the relationships between your functions and other components of your system. For this, you need distributed tracing tools like AWS X-Ray or OpenTelemetry, which can provide a detailed view of how requests flow through your system.

    2. Managing Lambda Cold Starts

    One of the most common serverless challenges that DevOps teams face is cold starts. A “cold start” refers to the delay that occurs when a function is invoked after being idle for a while. This delay can significantly impact the performance of your applications, especially those that rely on real-time processing.

    The first step to managing Lambda cold starts is understanding what triggers them. Typically, a cold start happens when a new instance of your function is created, which can be due to several reasons, such as an increase in traffic, the deployment of a new version of your function or after a function has been idle for too long.

    To overcome this challenge, there are several strategies you can employ. First, you can use provisioned concurrency, a feature offered by AWS Lambda that allows you to keep a specified number of function instances warm and ready to respond to invocations. Another strategy is to design your applications to be resilient to cold starts by implementing retry logic or using asynchronous invocation when possible.

    3. Security Concerns in Serverless Architectures

    Security is a top concern for any DevOps team. In serverless architectures, you have less control over the underlying infrastructure, making it more difficult to ensure the security of your applications.

    The first step to securing your serverless applications is understanding the shared responsibility model. In a serverless environment, the cloud provider is responsible for securing the infrastructure, while you are responsible for securing your code and configurations. This means you need to pay extra attention to things like input validation, error handling and secure configuration practices.

    Another key aspect of serverless security is managing permissions. Each of your functions should have the least privileges necessary to perform its task. This can be achieved by using identity and access management (IAM) services provided by your cloud provider.

    4. Managing Third-Party Dependencies

    Managing third-party dependencies is another challenge that DevOps teams often face in serverless architectures. These dependencies can introduce vulnerabilities into your applications, affect the performance of your functions, and even increase the cost of your serverless deployments.

    The key to managing third-party dependencies is to minimize their use. Only use dependencies that are necessary for your application and regularly review them to ensure they are still needed. You should also keep your dependencies up-to-date to benefit from the latest security patches and improvements.

    When using third-party dependencies, it’s also important to understand their impact on your functions. You can use tools like AWS X-Ray or Google Cloud Trace to monitor how these dependencies affect the performance of your functions.

    5. Cost Management and Optimization

    While serverless can be cost-effective, it’s easy to rack up high bills if you’re not careful. This is because in serverless, you pay for every invocation of your functions, even if they result in errors.

    To manage costs in serverless, you need to monitor your usage closely. Tools like AWS Cost Explorer or Google Cloud Billing can provide insights into your spending and help you identify areas for optimization.

    You can also optimize costs by designing efficient functions. This means writing code that executes quickly and efficiently, minimizing the use of third-party dependencies, and managing the concurrency of your functions.

    In conclusion, while serverless technologies offer many benefits, they also present unique challenges for DevOps teams. By understanding these challenges and employing the right strategies, you can effectively manage and overcome them, ensuring the successful delivery of your serverless applications.

  • Cutting Costs, Boosting Efficiency: The Economic Benefits of Framework-Defined Infrastructure

    Cutting Costs, Boosting Efficiency: The Economic Benefits of Framework-Defined Infrastructure

    In a world that’s constantly modernizing, developers are at the forefront of progress, embracing cutting-edge tools that match the pace. Industry-standard practices like infrastructure-as-code (IaC) are getting an update: Framework-defined infrastructure (FdI) is an approach to deploying applications that is quickly gaining popularity among developers, where the deployment environment automatically provisions infrastructure derived from the framework and the applications written in it. For developers, this serverless architecture means more reliability, increased productivity, top-of-the-line security and reduced costs.

    To modernize development practices, understanding the role of framework-defined infrastructure in defining and automating infrastructure—and its impact on the development experience in open source frameworks—is crucial.

    The Evolution From IaC to FdI

    Infrastructure-as-code (IaC) is the industry-standard practice for provisioning infrastructure in a repeatable and reliable way. Framework-defined infrastructure (FdI) is an evolution of IaC, where the deployment environment automatically provisions infrastructure derived from the framework and the applications written in it.

    In the early days of servers and the internet, we SSH-ed (or worse) into individual machines, running install scripts or even configuring production software using graphical user interfaces to provision infrastructure. As the web scaled, it became clear that this approach wouldn’t scale with it, and together with the DevOps movement, IaC became the best practice for provisioning infrastructure. The code in IaC represents a version-controlled description of the desired state of the infrastructure—which, when executed, will create the described system state. However, as the web continues to scale, developers must apply new processes and architectures to increase the efficiency of their workflows.

    Enter framework-defined infrastructure.

    Framework-defined infrastructure abstracts over cloud primitives such as servers, message queues and serverless functions, making them mere implementation details of the frameworks’ concepts. Frameworks use well-established patterns to provide structure and abstraction to applications, making them easier to write and understand by managing the high-level application flow while the developer writes code within the hooks provided by it.

    Framework-defined infrastructure takes advantage of both this inversion of control and the predictable structure of framework-based applications like Next.js to automatically map framework concepts onto the appropriate infrastructure without the need for explicit declaration or configuration of the infrastructure.

    Optimization for Serverless Environments

    Since framework-defined infrastructure lets the framework itself define the production behavior, local development can just use the framework’s own tooling, while production infrastructure is automatically configured to be a scaled and optimized representation of the same underlying behavior.

    IaC uses machine-readable files, which developers can version much like software, to provision infrastructure such as physical servers, virtual machines and higher-level services like databases or applications. Serverless architecture—which, despite its name, still uses servers—eliminates the need for developers to manage specific physical or virtual servers.

    Serverless products still require developers to define and deploy their respective serverless primitives, much like more traditional infrastructure. For example, in the archetype of serverless products, AWS Lambda, developers need to create a lambda function and deploy code to it.

    While serverless architecture greatly simplifies managing production infrastructure, the systems that run serverless code are often complex and proprietary, which can cause problems with local development. In a worst-case scenario, local development isn’t possible, and developers must test local changes by making comparatively slow deploys to the production infrastructure. In a best-case scenario, developers must create a local simulation of the complex serverless stack, which must stay up-to-date with the production environment. Framework-defined infrastructure completely eliminates this problem, as it is capable of automating the process for users.

    Framework-Defined Infrastructure and Immutable Deployments

    These days, application code is developed almost exclusively within version control systems such as Git. IaC maintains infrastructure definition in either the same or a sibling version control system. However, production infrastructure itself can only represent limited points in time of the infrastructure’s version history. This is fundamentally incompatible with framework-defined infrastructure, which expects that production infrastructure directly maps to the framework code at the same commit hash.

    Immutable deployments solve this impedance mismatch between an application’s and the infrastructure’s version history. Instead of deploying onto a limited number of infrastructures, immutable deploys create a completely new infrastructure for every single deployment that is ever made. For developers, this means lower IT complexity and failures, improved security, and easier troubleshooting, given there are fewer chances for unpredictable behaviors or unintended consequences of code changes.

    Naturally, immutable deployments are impossible in a world where infrastructure is mapped to finite physical resources. However, in a serverless world, where unused infrastructure can scale to zero, immutable deployments become possible to perform, as unused deployments do not take up physical compute resources beyond the baseline storage needed for their contents.

    Conclusion

    It goes without saying that framework-defined infrastructures rely on IaC as the ultimate infrastructure interface and, hence, could not work without the amazing work of its community. In order to modernize, it’s imperative for developers to leave behind infrastructure constraints and embrace a world where scaling applications becomes effortless, enabling them to optimize efficiency without sacrificing performance. For developers growing frustrated with scaling issues or the burdensome process of their development process, widespread adoption of framework-defined infrastructure is key to improving the developer experience.

  • 8 Hot Takes: Will We See a Monolithic Renaissance?

    8 Hot Takes: Will We See a Monolithic Renaissance?

    Is the DevOps world slowly backing away from microservices and to a monolithic renaissance? After years of proselytization about the benefits (Flexibility! Resilience! Support faster release speeds!) of microservices and serverless architecture, there are signs of a potential backlash against the singularly fragmented microservices architectural approach.

    The argument in favor of rolling back to monolithic architectures feels similar to the cloud repatriation debate. Just as with a lot of cloud-first transformations—often in lockstep with them, actually—many organizations moved headlong toward microservices without a case-by-case business or technical rationalization for the change. As the shiny newness of microservices has dulled under that approach’s daily exposure to real-world deployment and business challenges, the monolith isn’t looking so bad in a lot of situations.

    The monolithic versus microservices debate boiled over the last few weeks in the wake of the publication of a case study earlier this month from the Amazon Prime Video team. The analysis from Marcin Kolny, senior software development engineer for Prime Video, reported that his team was experiencing scaling bottlenecks in its audio/video quality inspection tooling, which was architected as a distributed system using serverless components. By rearchitecting the tool as a monolith, they were not only able to increase scaling capabilities but drastically reduced the infrastructure costs around that tool.

    “Moving our service to a monolith reduced our infrastructure cost by over 90%,” Kolny wrote.

    The announcement elicited a fair degree of hyperbole on the topic, but it also spurred a very organic airing of the pros and cons of monolithic, microservices and serverless architectures.

    The following are 10 different perspectives spurred on by this online debate from a range of CTO and engineering experts. Some of them are diametrically opposed to one another, many are overlapping in their opinions. But as a body, they point to the general (and very pragmatic) consensus that there simply will never be a one-size-fits-all approach to software architectures.

    Microservices a Siren Song for Complication

    “It’s clear that in practice, microservices pose perhaps the biggest siren song for needlessly complicating your system. And serverless only makes it worse. Replacing method calls and module separations with network invocations and service partitioning within a single, coherent team and application is madness in almost all cases.”

    —David Heinemeier Hansson, creator of Ruby on Rails and CTO at 37signals (maker of Basecamp and HEY)

    Architectures Aren’t Good or Bad

    “Application architectures are neither good nor bad, nor are they appropriate for every use case. Organizations need to step back and consider carefully what it is they’re trying to achieve and which architecture might best serve that need instead of choosing the most “modern” architecture because, well, it’s in vogue.”

    —Lori MacVittie, distinguished engineer in office of CTO at F5Networks

    Distributed Architectures Will Suit AI-Driven Future

    “In the ongoing debate between monolithic and serverless architectures, it is important to acknowledge that both approaches have their merits and considerations. Monolithic architectures have been prevalent in large human-centric organizations due to their management advantages and historical use cases. However, as the world continues its rapid progression towards a more AI-driven future, the landscape is shifting towards architectures that embrace fluidity, autonomy, and distribution.”

    — Reuven Cohen, veteran CTO and entrepreneur, mentor for TechStars

    Monolithic and Serverless Each Have Pros And Cons

    “Over the last 15 years, everyone has wanted to move to serverless microservices-based horizontally-scaled architecture – but it is not ideal for every application’s specific needs.  As with any choice in life and in business, there are always tradeoffs;  you must evaluate and choose the appropriate architecture based on your business and technology needs. Another important dimension to this is workforce skills for application architecture.

    —Hemang Davé, client technical leader and CTO at Kyndryl

    The Amazon Rearchitect Wasn’t Even Truly a Monolith

    “The problem is that they called this refactoring a microservice to monolith transition when it’s clearly a microservice refactoring step, and it is exactly what I recommend people do in my talks about serverless first. I don’t advocate “serverless only”, and I recommended that if you need sustained high traffic, low latency and higher efficiency, then you should re-implement your rapid prototype as a continuously running autoscaled container as part of a larger serverless event-driven architecture, which is what they did. If you built it as a microservice to start with, it would probably take longer (especially as you have to make lots of decisions about how to build and run it) and be less able to iterate as you figure out exactly what you are trying to build.”

    —Adrian Cockcroft, longtime DevOps advocate and veteran architect with stints at eBay, Netflix, Amazon, and Battery Ventures, among others

    One Tool as a Monolith, Maybe, But Not All of Amazon

    “Microservices, while duplicative and inefficient from a compute standpoint, allow you to release stuff really quickly, which is a tradeoff that most organizations at scale are willing to make.

    Microservices exist to reduce communication pathways—not to solve technical scaling challenges. At a certain point, teams stop functioning due to the communication overhead. A seven-person team has 21 communication pathways, whereas a 100-person team has 4,950. I work with large retailers selling billions of dollars a year online, and putting everything into a single monolith just doesn’t work. Could the entirety of Amazon.com be deployed as a single monolith? No way.”

    —Kelly Goetsch, chief strategy officer at commercetools

    Architectural Tension Always Exists Between Speed and Maintainability

    “Speed to market and speed to develop does not always equate to long-term scalability and maintainability. You must actively balance your investments across these two critical pillars to build a viable product. Active rebalancing and reconsideration of the stack and technology mix for your FinOps and BizOps context is both art and science.

    Cloud-native distributed systems paradigms are here to stay. The Prime Video folks have mistakenly labeled a properly factored, highly coupled data-intensive processing step a monolith—it’s at best a rocky outcropping in their distributed microservices forest. “

    —Ajish George, managing director of cyber data & analytics for State Street

    The Shiny Thing is Not Always the Best Thing

    “The news that AWS discovered that serverless and microservices aren’t for everything is surprising. Not because it didn’t work out for that use case; but because the wrong use cases have been so well-known for the serverless/microservices pattern and should have been obvious to Prime Video. It’s worth remembering: That shiny new thing isn’t necessarily a better way of trapping mice. Right tool for the right job.”

    —Doug Vanderweide, director of cloud architecture for Avanade

  • Running Serverless in Production: 7 Best Practices for DevOps

    Running Serverless in Production: 7 Best Practices for DevOps

    Serverless in production refers to the deployment and use of serverless architecture in a live, production environment. In this context, serverless refers to a cloud computing paradigm where the cloud provider manages the infrastructure and allocates resources as needed to run and scale applications and services.

    In a serverless production environment, applications and services are broken down into individual functions triggered by events, such as API requests or changes in data. These functions are executed in response to these events and the cloud provider is responsible for managing the underlying infrastructure, including servers, storage and network resources.

    In this article, I’ll describe some of the key use cases of serverless in production and provide important best practices DevOps teams can use to run serverless in production safely and effectively.

    Use Cases of Serverless in Production

    Serverless technology has emerged as a popular choice for delivering various applications and services in production. Here is a brief overview of serverless in production for four use cases.

    Microservices

    In a microservices architecture, an application is divided into small, independent services that can be developed, deployed and scaled separately. Serverless allows each microservice to be deployed as a separate function, triggering the function only when needed and scaling it automatically based on demand. This results in a cost-effective and flexible solution for microservices, as the user only pays for the exact amount of computing resources used by each function.

    IoT Devices

    Internet of things (IoT) devices generate large amounts of data, which need to be processed and analyzed in real-time. Serverless functions can process IoT data as it is generated, allowing for real-time analytics and decision-making. With serverless, the processing and analysis can be scaled dynamically, handling spikes in data volume without the need for infrastructure management.

    Multimedia Processing

    Multimedia processing tasks, such as image and video compression, often require significant computing resources. With serverless, these tasks can be performed as functions triggered by events such as the upload of a new image or video. The serverless functions can scale automatically to handle large amounts of data, reducing the costs associated with infrastructure management and increasing efficiency.

    This function-as-a-service (FaaS) is often used for storing and processing user inputs and other data types. For example, FaaS can be used to execute specific processes according to the category of media uploaded by the user. It’s easier to build these services because the developer can write one function that is applied to multiple processing tasks. 

    APIs for Mobile and Web Applications

    APIs are an essential component of many web and mobile applications, providing access to the underlying data and services. Serverless functions can build and deploy APIs, providing a cost-effective and scalable solution. The functions can be triggered by incoming API requests and automatically scaled based on demand, allowing for fast and reliable API access for users. 

    FaaS is especially useful for RESTful applications and event-driven architectures. Containers are also useful for performing processes like API calls, but serverless functions are best suited for highly fluctuating volumes of traffic.

    Best Practices for Running Serverless in Production

    1. Monitor the Serverless Environment

    Serverless monitoring refers to the process of monitoring serverless applications and infrastructure, including serverless functions and event-driven computing services, without the need for dedicated servers or virtual machines. In a serverless architecture, computing resources are dynamically allocated and managed by the cloud provider, so there is no need for organizations to manage and maintain their own servers.

    Serverless monitoring involves monitoring various aspects of serverless applications and infrastructure, including function execution, resource utilization and performance metrics. The goal of serverless monitoring is to identify and resolve issues that may impact the performance and reliability of serverless applications and to optimize resource utilization for cost efficiency.

    By implementing serverless monitoring, organizations can ensure that their serverless applications and infrastructure are performing optimally and that they can quickly identify and resolve any issues that may arise. This helps to improve the reliability and cost-effectiveness of serverless computing and enables organizations to take full advantage of the benefits of serverless architecture.

    2. Implement Authentication

    Serverless authentication refers to the process of authenticating users and applications in a serverless architecture, where computing resources are dynamically allocated and managed by the cloud provider. In a serverless authentication model, authentication is managed through cloud-based services and APIs without the need for dedicated servers or virtual machines.

    By implementing serverless authentication, organizations can ensure that their serverless applications and services are secure and that users are only able to access the resources that they are authorized to access. This helps to improve the security of serverless applications and services and reduce the risk of security breaches.

    3. Ensure Security with API Gateways

    API gateways provide a centralized point of control and security for incoming API traffic. API gateways allow for the implementation of authentication and authorization mechanisms, such as OAuth, to control access to serverless functions. This ensures that only authorized users and clients can access the functions, reducing the risk of unauthorized access.

    API gateways can also manage incoming API traffic, such as rate limiting and request filtering, to prevent overloading the serverless functions and protect against denial-of-service (DoS) attacks. They perform real-time threat detection, identifying and blocking malicious traffic before it reaches the serverless functions. This includes protection against other common attacks such as cross-site scripting (XSS) and SQL injection.

    Finally, an API gateway can enforce encryption for incoming and outgoing API traffic, ensuring that sensitive data is protected in transit. 

    4. Assign Appropriate Roles to Functions

    With serverless, there can be many resources that must be handled, making management potentially complex. Creating minimal suitable roles for each function makes management easier, enhances security and reduces the attack surface of the serverless architecture. This approach means that the least privilege principle is applied, where a function only has the minimum permissions required to perform its intended task. It reduces the risk of unauthorized access to other parts of the infrastructure, such as sensitive data or other functions.

    The right roles ensure that functions are isolated from each other and run in their own security context. This helps to prevent the spread of any security incidents, as well as ensure that the compromise of one function does not affect the security of the rest of the system.

    5. Ensure Dependencies are Secure

    It is common for serverless functions to have dependencies from various repositories like Maven and PyPI. These dependencies may contain known vulnerabilities which can be exploited by attackers. Securing application dependencies is important to prevent security incidents and ensure the reliability and availability of the serverless architecture.  

    This involves tracking and managing the dependencies used in the serverless applications. This helps to ensure that dependencies are used in a consistent and controlled manner, reducing the risk of conflicts or compatibility issues. By regularly monitoring and updating dependencies, organizations can ensure that their serverless architecture is secure and reliable.

    6. Sanitize Inputs to Prevent Injection Attacks

    Serverless applications often use data inputs from users or events. This data enables functions such as data streaming, but the user-supplied data can also pose security risks. Sanitizing event inputs helps to prevent injection attacks—these occur when an attacker injects malicious code or data into a serverless function through the event inputs. 

    By sanitizing inputs, organizations can remove or modify potentially malicious inputs, preventing the attacker from injecting malicious code into the function. One important form of sanitization is input validation—validating that the inputs conform to a specific format or type, such as checking that a string is a valid email address. This helps to prevent attackers from injecting malicious code into the function by ensuring that the inputs are in the expected format.

    Sanitizing data is only one aspect of a defense-in-depth security strategy, which involves implementing multiple security controls to protect against attacks. It is also important to enable data escaping for SQL and noSQL databases. Likewise, the data provided by events shouldn’t be used to evaluate code at runtime or spawn system processes. 

    7. Secure Data in Transit

    Securing and verifying data in transit helps to prevent data breaches and ensure the confidentiality, integrity, and privacy of data transmitted between different parts of the serverless architecture. Here are some guidelines for securing and verifying data in transit:

    • Use HTTPS: This is a secure protocol for transmitting data over the internet. By using HTTPS, organizations can ensure that data transmitted between different parts of their serverless architecture is encrypted, preventing unauthorized access to sensitive data.
    • Implement SSL certificate verification: Verify the identity of the certificate owner and the authenticity of the certificate. This helps to prevent man-in-the-middle attacks, where an attacker intercepts and alters data transmitted between the server and the client.
    • Enable signed requests: These involve adding a digital signature to a request, which is then verified by the recipient. This helps to prevent tampering with data in transit and ensures the integrity of the data.

    Conclusion

    In conclusion, running serverless in production requires careful planning and execution to ensure the security and reliability of the architecture. By following the best practices described here, DevOps teams can reduce the risk of security incidents and ensure the reliability and availability of their serverless architecture. These include:

    • Monitoring the serverless environment
    • Implementing authentication
    • Deploying API gateways
    • Creating minimal suitable roles for each function
    • Securing application dependencies
    • Sanitizing event inputs
    • Securing and verifying data in transit 

    Additionally, regularly monitoring and updating dependencies and implementing a defense-in-depth security strategy can help organizations ensure the security and reliability of their serverless architecture over time. 

  • Codenotary Extends Dynamic SBOM Reach to Serverless Computing Platforms

    Codenotary Extends Dynamic SBOM Reach to Serverless Computing Platforms

    Codenotary has extended the reach of its platform for automatically generating software bills of materials (SBOMs) to serverless computing platforms running software constructed using functions.

    Codenotary CTO Dennis Zimmer said because serverless apps are dynamically created, it’s not possible to generate SBOMs using traditional approaches. The TrueSBOM platform makes it possible to create an SBOM in real-time by adding one line to the source code of any application. The TrueSBOM for Serverless edition of the platform now extends that capability to the serverless computing frameworks made available in the cloud by Amazon Web Services (AWS), Microsoft and Google.

    That approach makes the SBOM a part of the application itself rather than a text file that is stored separately, he noted. Each time an application is updated or a scanner discovers a new vulnerability, a new SBOM is automatically generated, added Zimmer.

    Awareness of the need for SBOMs has skyrocketed since an executive order issued by the Biden administration made it clear that federal agencies would require them from software providers starting next year. Many enterprise IT organizations are likely to follow suit as part of a larger effort to better secure software supply chains in the wake of a series of high-profile cybersecurity breaches.

    Most internal DevOps teams already have a good handle on what software components are used within the applications they deploy. The issue is that the organizations that use that software can’t easily verify what components are being used, noted Zimmer. That’s problematic because an organization may prohibit deployment of a specific software component because of a known vulnerability. TrueSBOM allows organizations that use an application to maintain control over their software environment regardless of what software artifacts are used to build closed or open source components, Zimmer added.

    It’s unclear how most organizations will operationalize SBOMs now that more of them are being created. Ideally, organizations should be able to approve only software with components that have been verified as secure.

    As SBOM mandates become more stringent, the number of application providers that are anxious to comply with rules for securing software supply chains should increase. The issue now is finding a way for both the developer and consumer of that software to streamline a verification process that, in its current form, is too cumbersome to manage effectively. As a result, many organizations are now putting together dedicated teams made up of cybersecurity professionals and software developers to manage SBOM processes, said Zimmer.

    Of course, there is a massive amount of code that has already been deployed that today doesn’t show up in an SBOM. While many emerging applications—created using artifacts such as functions and containers—are likely to be increasingly instrumented to dynamically generate an SBOM, the number of legacy applications that might need to be similarly instrumented is several orders of magnitude greater. As a consequence, the amount of effort required to generate SBOMs for every application in use might be greater than teams first anticipated.

  • Cisco Adds Open Source Tool to Validate Serverless Functions

    Cisco Adds Open Source Tool to Validate Serverless Functions

    Cisco has launched an open source project, dubbed FunctionClarity, that makes it possible to verify signatures before code is deployed in a serverless computing environment.

    Vijoy Pandey, vice president of emerging technologies and incubation at Cisco, said that one of the application security issues that has emerged in serverless computing environments is the lack of validation capability to verify code signatures prior to deployment. As more organizations employ serverless computing frameworks, the overall software supply chain becomes less secure, he noted.

    FunctionClarity includes a command line interface (CLI) tool to invoke a verification function that can be deployed on the Amazon Lambda serverless platform to address that issue; support for Microsoft Azure and Google Cloud serverless platforms is planned, he added.

    The FunctionClarity project aims to close that gap by employing either a keyless approach using open source sigstore tools or a traditional encryption key, noted Pandey.

    The FunctionClarity project is the latest extension of a Cisco OpenClarity initiative that includes an existing project for securing application programming interfaces (APIs) using a service mesh, dubbed APIClarity, and a tool for detecting and managing software bills of materials (SBOMs) and vulnerabilities in container images and filesystems dubbed KubeClarity. All three projects are part of an ongoing Cisco effort to contribute code to the open source community that, while essential, does not provide a lot of differentiated value for any one vendor, said Pandey.

    The FunctionClarity project arrives at a time when concerns over the security of software supply chains is on the rise. Many of the software security issues that organizations are encountering stem from the simple fact that developers can provision cloud infrastructure without any kind of meaningful cybersecurity review. Code signing, within the context of a larger set of DevSecOps workflows, is now starting to gain traction to better ensure secure software supply chains. The challenge is that as more code winds up running on serverless computing platforms, a need to extend the reach of whatever approach to code signing an organization adopts becomes more evident.

    In general, the open source community is collectively trying to respond to an executive order issued by the Biden administration that required federal agencies to implement a series of steps to better secure their software supply chains. One of those measures includes wider adoption of code signatures to ensure the authenticity of code being incorporated into applications. The challenge is that incorporating code signatures into DevOps workflows has historically not been a trivial process to implement. Most recently, a free sigstore cloud service launched that promised to make it easier to achieve that goal.

    It’s not clear how widely or even how rapidly code signing will be adopted, but enterprise IT organizations are paying close attention to how federal agencies are responding to the executive order. Many of the tools and processes defined by those agencies will inevitably be copied by enterprise IT organizations that have thus far made limited use of code signing to verify the authenticity of software components. The challenge now is finding a way to achieve that goal without slowing down the rate at which modern software is developed.

  • Momento Launches Elastic Cloud Caching Service

    Momento Launches Elastic Cloud Caching Service

    Momento this week emerged from stealth to launch an elastic Serverless Cache platform that promises to improve the performance of applications running on databases deployed in the cloud while simultaneously reducing costs.

    Fresh from raising $15 million in seed funding, Momento CEO and co-founder Khawaja Shams said Serverless Cache gives IT teams access to a serverless computing framework for accessing cache memory that can be used to improve the interactivity of applications.

    Cache is, of course, already widely employed to improve the performance of applications running on databases in the cloud. However, organizations today are required to provision excess cache memory to address performance workload peaks. That approach, over time, conspires to increase the total cost of cloud computing, he noted.

    A serverless cache makes it possible to more easily share an elastic pool of memory that can be invoked in seconds via an application programming interface (API) that is itself invoked by adding five lines of code to an application. The Momento cache service can then handle millions of transactions per second that can be spread across multiple applications, said Shams.

    The Momento Serverless Cache service also automatically manages hot-keys, maintains high cache hit rates and keeps tail latencies low.

    Organizations that are already using Momento on either the Amazon Web Services (AWS) or Google Cloud Platform (GCP) include CBS, NTT Docomo and Wyze Labs, Shams said.

    In general, there’s a lot more scrutiny of cloud costs in the wake of the economic downturn, noted Shams. More IT teams are starting to take note of the fact that various cloud-native platforms enable them to more efficiently consume cloud resources, he added.

    The simple truth is that far too many organizations are managing cloud resources in much the same way they managed on-premises IT environments. Capacity is being dedicated to virtual machines to ensure application availability with even less regard for cost because the perception is that the cloud makes it easy to throw hardware resources at any issue. The challenge is the bill for those cloud resources tends to add up at the end of every month. Cloud database services, in fact, are among the most expensive to consume, noted Shams.

    It’s not clear how much organizations will optimize the consumption of cloud resources in the weeks and months ahead, but it’s clear more supervision is going to be required. Organizations have historically let developers provision resources in the name of agility with little to no regard for cost. Now that finance teams are looking to, at the very least, make sure cloud resources are optimally consumed, there will undoubtedly be more reviews of cloud spending patterns.

    In the meantime, many organizations may also decide to accelerate the rate at which they are embracing cloud-native technologies to optimize that spending. One of the more compelling attributes of Kubernetes clusters and serverless computing is they make it easier to scale compute resources up and down as required to eliminate the need to overprovision cloud infrastructure. The challenge, of course, is that the cost of acquiring and mastering those technologies remains significant.

  • Alleviating Developer Workflow Headaches by Moving to the Cloud

    Alleviating Developer Workflow Headaches by Moving to the Cloud

    Leaders in tech make one common mistake when it comes to serverless and cloud computing: They want to migrate their current environment exactly as it is to the cloud. That’s about as limiting as planning a flight path along the road network and deciding the route based on street-level traffic. You can do it, but everyone’s going to look at you like you’re crazy.

    Keeping that ‘lift and shift’ mindset prevents developers from seeing the real ROI of cloud computing and serverless technology. Instead, we have to challenge our traditional ways of thinking.

    Redefining How we Think About Software Development

    The traditional definition of software is anything that makes the hardware do what we want it to. We use operating systems to control internal functions as well as peripherals. We use application software to direct our computers to execute commands. So we tend to think of software as programmatic, needing specialized programming languages to develop. But the most popular functional programming language isn’t Erlang or Haskell or Lisp. It’s Microsoft Excel, if you can believe it, with over 750 million users.

    Every Excel spreadsheet represents someone’s software; it makes their hardware process data in a way that’s valuable to them. In a similar way, the “systems” we build on the information technology side are just more software. And cloud computing gives us a new range of powerful tools so we can build bigger systems faster than before.

    What are Cloud Computing and Serverless Computing?

    Cloud computing largely references data centers and data storage. Serverless computing is one piece of cloud computing. It lets developers create software without managing infrastructure. In the end, it increases productivity, speeds up product delivery, optimizes resources and keeps developers focused on the end product rather than infrastructure maintenance.

    Once deployed, serverless apps respond to demand, scaling up or down as needed. So when a serverless function sits idle, it costs nothing.

    Key Benefits of Cloud Computing and Serverless Computing

    There are many benefits of cloud computing and serverless frameworks. By far, the one leaders are most excited about is cost control and increased ROI. It’s also one that leaders most often miss.

    Increase ROI With Cloud Computing and Serverless

    The number-one way to increase ROI with serverless frameworks and cloud computing is to avoid building anything from scratch. Invest in open-minded research. Sometimes you need to build something yourself, but often there’s a way to shift some of the burden away from your team. 

    An easy example is functions. The first thing most developers think of when they hear “serverless” is functions. But the functions running code are just a tiny piece of the puzzle. Serverless technology allows development teams to hand off as much work as they can to cloud platforms like Azure, Amazon Web Services (AWS) and Google Cloud Platform (GCP). 

    Just like someone wouldn’t buy a field, till it, plant wheat, water it, thresh the wheat into flour, bake bread and toast it to make a piece of toast, developers shouldn’t write their own code when the building blocks already exist in their cloud platform. Take, for example, Azure’s Durable Functions feature. This feature manages stateful workflows so teams don’t need to explicitly create, store and retrieve the progress through your data’s workflow in some other place. This process is so common to the systems that teams build that the cloud providers made it available without needing us to write lines of code. It’s like instant toast delivered to your door!

    The more a team can leverage already-made code, the more time they get back on their schedules and the more money goes back into the team’s budget, something we can all appreciate!

  • Pulumi Extends Infrastructure-as-Code Reach

    Pulumi Extends Infrastructure-as-Code Reach

    At its online PulumiUP conference, Pulumi announced it will make its Pulumi CrossCode translation technology available to third parties and DevOps teams. The technology was developed to integrate a wide range of programming languages with its infrastructure-as-code (IaC) platform.

    The company also announced it has added support for YAML—widely used to configure Kubernetes environments—as well as any variant of Java. It already supports .NET, Node.js, Go and Python programming languages.

    Finally, Pulumi also added packages for Oracle Cloud, Databricks and EventStore that simplify deployments on those platforms. The company already provides similar integrations for Amazon Web Services (AWS), Microsoft Azure, Google Cloud, Kubernetes, Auth0, CloudFlare, Confluent Cloud, Datadog, DigitalOcean, Docker, GitHub, Kong, MinIO, MongoDB Atlas, PagerDuty, Snowflake, Spot by NetApp and SumoLogic. There are also now components that provide support for container applications, Kubernetes clusters and serverless applications along with an AWS Cloud Development Kit (CDK).

    Pulumi has been making a case for an IaC approach that enables developers to use programming languages they already know to provision infrastructure as an alternative to having to deploy and master tools such as Terraform.

    The Pulumi CrossCode translation technology the company developed is now being made available to any organization that wants to add support for another programming language. It converts any infrastructure-as-code format, including Terraform, CloudFormation, Azure Resource Manager and Kubernetes configuration, to any programming languages supported by Pulumi.

    Pulumi CEO Joe Duffy said the goal is to extend the overall reach of the translation technology the company created to simplify provisioning any type of infrastructure.

    While many developers use tools such as Terraform, the need to limit misconfigurations is driving many larger enterprises to revisit their approach to IaC to improve software supply chain security, noted Duffy. Today, Pulumi claims more than 2,400 organizations have adopted platforms that enable developers to provision infrastructure and apply guardrail policies to reduce errors. That approach prevents developers from making configuration mistakes that can lead to exfiltration of data via, for example, a port that has been accidentally left open, he added.

    Too many developers assume that their cloud service provider is securing both the underlying platform and how it is configured only to discover later that it was their responsibility to validate those configurations. Security teams, meanwhile, can’t keep pace with the rate at which cloud infrastructure resources are being provisioned without some ability to apply policies that enforce rules for provisioning that infrastructure within the context of a larger DevSecOps workflow.

    Ultimately, the goal is to employ automation to resolve these issues once and for all as more organizations adopt DevSecOps best practices. In the meantime, the challenge is doing so in a way the average developer will accept and embrace. Otherwise, they will continue to find ways to work around security teams in the name of productivity, regardless of how insecure the underlying IT environment might become.