devopsy.kinsta.cloud

Tag: SaaS

  • The IT-DevOps Life Cycle is Like a Pyramid That Keeps Growing

    The IT-DevOps Life Cycle is Like a Pyramid That Keeps Growing

    Don’t let anyone tell you how much easier IT life is these days. It is, in many ways, more fun and productive … but it is not easier. In fact, we’re doing more with less, cubed, at this point. My point is—think of the life cycle as a pyramid. The base is the build++ chain, from VCS to public-facing active protection; the height is the new technologies and systems being bolted on daily—like SaaS tools someone in accounting just signed up for or the new architectures a dev team in a subsidiary just decided to adopt (but which will eventually have to be maintained by IT). And the depth is the completely new capabilities that are required by market forces or regulation – SBOM is the poster child for this group; suddenly, just about every vendor is giving it to you as part of their product.

    No matter which of these axes is growing, the workload is generally growing commensurately. Think about it: If a new product is implemented, it impacts IT’s workload. If a new technology that solves a problem is implemented, it, too, impacts workload. And if a new capability in an existing product is dictated by the compliance team for any reason, this, too, increases workload. This is just the business side, and doesn’t include the fact that most orgs are dropping newly developed applications on a pretty regular basis these days.

    Automation has helped, but it hasn’t solved the problem yet. I believe it can, given time and focus, but for the most part, the demand for new technology to solve age-old problems (“We can’t effectively test” being met with “Here is automated test generation, execution and results filtering”) has been a net increase in workload. Though far smaller than it might have been, it is still increasing. This is true across IT. The test example above applies to app dev and security, with result sets that did not exist six years ago because the process was too expensive in staff hours. It also applies to ops because the processing power to get those tests done – and it is a lot with large test environments – is ops’ responsibility.

    Painting a bleak picture? Nope. Making certain we’re realistic. Trying to ensure that we consider how much we are already doing, and take a chance to implement actual time savers. For example, applying that same test automation to testing (for most orgs, I’m thinking security testing) that was actually being done already will reduce the cost of getting it done. Using SBoM for SCA to contribute to existing compliance saves a lot of time generating that information. Using new coding assistants shortens coding time and (arguably at this point, but inevitably, given the fullness of time) improves code quality, reducing rework, which is costly, even in an agile environment.

    We are growing our capabilities almost daily. I’m just suggesting that, in the process, we backward-apply the good stuff to reduce existing overhead. And as always, this big, complex beast exists and keeps clipping along because you’re there, keeping it fed and stable. Keep rocking it, and save yourself some time by using new technology smartly—there is plenty more to do than whatever you streamline.

    Image source: Photo by Michael Dziedzic on Unsplash

  • Permiso Makes Open Source Tool to Identify Cloud Threats Available

    Permiso Makes Open Source Tool to Identify Cloud Threats Available

    Permiso today launched an open source tool dubbed CloudGrappler that surfaces indicators of compromise in cloud computing environments.

    Based on a cloudgrep project originally created by Cado Security, CloudGrappler detect patterns that Permiso, a provider of an identity threat detection and response platform, associated with tactics and techniques commonly used by various cybercriminal syndicates.

    The tool enables DevSecOps teams to define the data sources they want to scope in a scan of an Amazon Web Services (AWS) or Microsoft Azure cloud. Via a JSON file, DevSecOps teams can access a list of predefined tactics, techniques and procedures (TTPs) that are commonly used to exploit cloud computing environments. DevSecOps teams can also dynamically add queries or a file with multiple queries to scan a specific data set. After scanning, CloudGrappler delivers a JSON report that provides a breakdown of the scan results.

    Ian Ahl, senior vice president for P0 Labs, the research arm of Permiso, said that capability makes it possible for DevSecOps teams to identify issues in cloud computing environments that warrant further investigation before there is a major incident. The primary goal is to make it simpler for DevSecOps teams to determine if they need additional assistance to thwart a potential threat, he added.

    Cybercriminals are, like almost everyone else, creatures of habit and often tend to leverage the same TTPs multiple times simply because they know they’re effective. However, those TTPs also provide clues to their presence in an IT environment. Once discovered, a DevSecOps team can decide if they can remediate the issue themselves or need to tap external cloud security expertise, noted Ahl.

    In general, cloud computing environments may be more secure than most on-premises IT environments. However, the processes used to provision cloud computing environments are often flawed because developers typically don’t have much cybersecurity expertise. Misconfigurations are often rife across cloud computing environments.

    Cybercriminals are also especially adept at stealing credentials to gain initial access to cloud computing environments, which they leverage to escalate privileges in a way that provides them unfettered access to the entire cloud computing environment.

    Adoption of DevSecOps best practices has improved cloud security, but there are still plenty of instances where, for example, a port inadvertently left open has enabled cybercriminals to infest a cloud computing environment with malware that could lie dormant within cloud applications for months before finally being activated.

    There are simply not enough cybersecurity experts available to secure cloud computing environments, so it’s going to be largely up to DevOps teams to secure them. The issue is that in the race to build and deploy applications as quickly as possible, cloud security best practices are either forgotten or simply ignored. Of course, it’s that very carelessness that cybercriminals are counting on to allow them to wreak havoc in an era where the percentage of mission-critical applications running in cloud computing environments will only continue to increase exponentially.

  • Survey: Significant Shift in IaC Tool Preferences

    Survey: Significant Shift in IaC Tool Preferences

    A survey of 350 IT professionals conducted by Firefly, a provider of a platform for managing cloud computing environments, suggests usage of infrastructure-as-code (IaC) tools is evolving rapidly in the cloud computing era.

    For example, more than 40% of the respondents reported that, to some degree, they are already using OpenTofu, an open source IaC tool that was launched as a fork of the Terraform IaC in the wake of changes to the software licensing terms it is made available under by HashiCorp. Well over half said they planned to use OpenTofu in the future. That compares to 60% using Terraform today, but only just over 20% said they planned to use Terraform in the future.

    The licensing changes HashiCorp implemented only affect third-party entities within a third-party platform. However, the survey indicates the number of end users affected by that change is more substantial than anticipated. A full 56% of respondents described the changes made to the Terraform license as disruptive.

    The survey also finds there is a lot more diversity in terms of the types of IaC tools being employed, with both the IaC tools from Pulumi and the open source Crossplane framework being advanced under the auspices of the Cloud Native Computing Foundation (CNCF) also gaining traction. The report finds more than 40% of respondents are also using Pulumi, with well more than half planning to use that IaC tool in the future.

    Crossplane, meanwhile, is now being used by 40% of respondents, with 60% planning to adopt it.

    Conversely, the report also notes the number of organizations planning to migrate away from CloudFormation from Amazon Web Services (AWS) is rising. While well over 60% use AWS CloudFormation today, only a third plan to use it in the future.

    Cindy Blake, vice president of marketing for Firefly, said as organizations employ additional cloud platforms, IT teams are clearly looking for tools that make it easier to centralize the management of multiple computing platforms. That trend will only accelerate as more DevOps teams adopt platform engineering as a methodology for managing the building and deployment of applications at scale, she added.

    In fact, noted Blake, it’s already fairly common for IT teams to use two or more frameworks. The report finds 57% of respondents work for organizations that are using two or more frameworks. Overall, the report finds that more than 64% of respondents have also codified more than half of their cloud assets.

    The number of organizations employing IaC tools to programmatically manage infrastructure is only going to increase, said Blake. The report, for example, found that three-quarters of respondents either already are or plan to use IaC tools to configure software-as-a-service (SaaS) application environments. In the longer term, advances in artificial intelligence (AI) will make it simpler for organizations to achieve that goal. Open source tools such as AiAC, for example, already make it possible to leverage large language models (LLMs) to generate code. Those types of tools will eventually eliminate the need to master specific programming languages to provision IT infrastructure as code, noted Blake.

    It’s not clear how IaC tools within the context of DevOps workflow will evolve, but the one thing that is certain is that the number of types of tools being adopted has never been more diverse.

  • Scrimmage for Control: On-Premises Vs. SaaS in the Observability Super Bowl of 2024

    Scrimmage for Control: On-Premises Vs. SaaS in the Observability Super Bowl of 2024

    Observability means data. It encompasses a set of practices and tools designed to track the performance and health of software applications, providing insights into the “why” behind system behaviors, not just the “what.” At its core are data pillars we’ve learned how to work with and hopefully get the most out of—metrics (quantitative data on system performance), logs (recorded events within the system) and traces (detailed views of request paths through the system) that offer a comprehensive view of the system’s operation in real-time. SaaS is where the industry has been turning towards for the past decade. It’s easy to operate and upgrade and takes away maintenance and manpower requirements.

    But, using a SaaS solution where data is stored on the vendor’s infrastructure can be compared to playing a football game at your opponent’s home field. Your team does not own the field and must play along with conditions that are outside their comfort zone. While your team can still strategize, execute plays and score points, the control over the playing environment, including the surface, lighting and even some rules, lies with the owner of the stadium (in this case, the SaaS vendor).

    You don’t get the home-field advantage and the comfort of your familiar surroundings, and you also can’t control the audience’s shouts and cheers in the stands across the arena.

    Just as a visiting team must trust the host’s management of the stadium and adapt to its conditions, organizations using SaaS solutions entrust their operational data to third-party vendors. They must trust its data protection policies and privacy agreements to ensure that the organization’s data is handled securely and in compliance with relevant regulations.

    And even more importantly, they have to adhere to its hosting costs.

    Let’s Leverage the Home-Field Advantage

    The alternative is clear: While playing on your own field, you, the coach—hell, the entire team—know this field by heart, and you know best how to keep and enforce your own rules.

    Just as a football team controls the ball and decides on the play, having on-premises data means a company or organization keeps its data within its infrastructure, offering direct control over its storage, management and security. The organization decides how to deploy, use and protect this data and even how to manage the tradeoff of data costs.

    The downsides? Playing on your home field at all times means you’re running slower than the world out there. You’re not quick to update your software to the newest common practices and you’re tasked with maintaining another stack—your observability stack—on top of building your product, which serves your users.

    There’s Another Way. Play the Data on the Scrimmage Line

    In football, the scrimmage line is the imaginary line across the field where the ball is placed at the start of each play. This line serves as the point of engagement between the two opposing teams, with specific rules governing how players can position themselves and how the play begins.

    What if we can keep the data on-premise, in the home field, a little like having the ball on our side of the scrimmage line, within our team’s possession and control? We have the ball, and we decide and strategize how to advance the ball or score from the position behind the scrimmage line, but we can still interact with the outside world (or the opposing team) under a set of rules to which we both adhere.

    This is exactly where observability solutions are heading: A combination of the advantages of SaaS—easy to update and maintain value, with an easy way to distribute the solution inside the organization, alongside the advantages of on-premise—data privacy, data control and full transparent and controllable data costs.

    I call this approach inCloud. It is a modern on-premises approach—data in your cloud environment, protected and controlled by the user, but still governed, managed and served with a guaranteed SLA just like the best SaaS offerings out there.

    Just like the scrimmage line in football that provides a clear boundary and set of rules for how the game is played, inCloud acts in a similar way. Data is kept on-premises, allowing the organization full control over retention, privacy and data integrations. And on the other hand, inCloud defines a set of strict rules under which a control plane is allowed to operate and pass the scrimmage line, or past the organization’s cloud borderline, to manage and access the data like a SaaS solution does best.

    So when we sit down to watch the Super Bowl this Sunday—let’s use that halftime show to think about where we’ll be taking our organization’s observability capabilities in 2024. Will the data be in our hands, crossing that invisible scrimmage line? Or will we lose to our opponent’s home-field advantage?

    May the best team win.

  • F5 Looks to Streamline Application Networking

    F5 Looks to Streamline Application Networking

    At its AppWorld 2024 conference this week, F5 announced a software-as-a-service (SaaS) edition of its NGINX application networking portfolio, which are now all available under a single enterprise license.

    Shawn Wormke, general manager for NGINX, said NGINX One will eliminate much of the friction enterprise IT teams currently encounter when implementing NGINX Plus, NGINX Open Source, NGINX Unit, NGINX Gateway Fabric and the Kubernetes Ingress Controller the company provides.

    As part of that effort, F5 is also now making available a unified console across its application networking portfolio that promises to streamline the management of the F5 application networking portfolio.

    Currently available under an early access program, NGINX One creates an as-a-service platform through which enterprise IT organizations can invoke and pay for these capabilities on an as-needed basis, said Wormke. The overall goal is to reduce the total cost of application networking by eliminating the need for IT teams to integrate the various elements of NGINX One on their own, he added.

    In general, application networking has become more complex with the rise of cloud-native applications based on microservices. By reducing the cognitive load required to network those applications, it becomes simpler to make network operations a more natural extension of DevOps workflows, noted Wormke.

    Most organizations have some level of experience with application networking using proxy servers, but as application environments have become more complex, the need for gateways and ingress controllers to provide these capabilities at scale has become more apparent. As a result, more IT organizations are starting to revisit how they are structured. There may always be a need for dedicated networking specialists to manage the physical network underlay, but as other networking services become more integrated with DevOps workflows, responsibility for some networking services is starting to shift further left toward DevOps teams that will either deploy these capabilities themselves or take advantage of a SaaS platform such as NGINX One. The overall goal is to be able to dynamically provision application networking services without having to wait for a network administrator to provision them.

    There are, of course, a lot of approaches to application networking that are now emerging. Regardless of how application networking evolves, however, the rigidity that has characterized the delivery of network services for decades should finally start to fade away. Today, outside of a cloud computing environment, it’s still common for IT teams to provision virtual machines or Kubernetes pods in hours only to wait days or even weeks for network connectivity to be provisioned. As IT environments become more hybrid and more workloads are pushed to the edge, there is a clear need for a more agile approach.

    Each organization will need to decide how best to approach application networking across legacy monolithic applications, microservices and event-driven applications at a time when IT environments have become much more complex to manage. The challenge, as always, is reducing as much friction as possible without unduly raising the total cost of IT to a point where it becomes unsustainable.

  • 4 Things to Consider When Integrating Generative AI

    4 Things to Consider When Integrating Generative AI

    Generative AI has emerged as one of the most influential innovations of the past two decades. ChatGPT gained 100 million users in record time, and new generative AI-powered point solutions emerge every day.

    Considering the current state of VC funding, the surge of investment dollars in AI companies is remarkable. Microsoft’s $13 billion investment in OpenAI and AWS’ $4 billion investment in Anthropic (who themselves just raised a $850 million Series C round) demonstrate the tremendous excitement around Generative AI and how it will shape the future of tech.

    As newer companies like Adept and Cohere are emerging, existing SaaS companies are integrating generative AI capabilities into their products and services. However, in the race to join the hype, many companies are building first and strategizing later. Before diving headfirst into building a generative AI solution, companies should carefully consider a few crucial factors, including model selection, usage tracking, monetization and customer transparency.

    1. AI Model Selection: To Build or to Buy?

    Companies must first consider whether to build a generative AI model from scratch, or whether to use a pre-existing model from one of the major AI vendors. This decision depends on the level of customization and control desired, as well as the resources and expertise available.

    Building a from-scratch model is likely infeasible due to the inaccessibility of the necessary hardware. The GPUs needed for cutting-edge model training and inference are currently only built by NVIDIA, and there is stiff competition and long lead times for any company looking to acquire the product. What’s more, large cloud and AI companies like OpenAI, Google, Meta and Tesla already have built systems with up to 100,000 of these chips. New companies looking to enter the scene would face a steep climb to assemble the infrastructure needed to even begin to compete with the current classes of models.

    Small or new companies do not have the funding or time to invest in building their own infrastructure or generative AI models, so a key business decision is to select the best vendor and model for the use case. While ChatGPT is the most well-known, there are other specialized models that can be better suited for certain use cases. For example, OpenAI’s DALL-E is built for image generation, while Anthropic’s Claude 2 is built to perform better with specialized tasks such as legal and math and to handle long-form inputs.

    Regardless of the AI vendor you choose, you will be charged based on your usage with them, which, by extension, is your customers’ usage. Tracking this usage is critical to your generative AI solution becoming profitable.

    2. Metering AI Service Usage: The Key to Success

    Implementing usage metering for generative AI services is crucial at both the individual user level and at the global or system-wide level. This is because usage tracking is valuable to all business functions and is a critical element of any modern PLG strategy.

    For example, customer-facing teams can leverage usage data to proactively track account health and to contextually recommend new solutions and approaches. Usage history provides valuable intelligence to account teams for up-selling, cross-selling, and contract renewal. Product teams can identify usage patterns and customer segments, as well as areas of friction or improvement for new feature development.

    Usage data also plays a major role in developing pricing plans that align with customer expectations and overall market trends. It can be used to inform pricing plan development and optimization to ensure the rates are sensible for the level of consumption and value being realized. Without tracking usage, this becomes a guessing game or a futile exercise in “gut feel.”

    Usage data is imperative to calculating your internal costs. Vendors commonly charge according to a usage-based model for these generative services–per word, per token or per generation are some common models. In any case, having accurate, granular usage data is a must-have for calculating internal costs and, in turn, customer-facing pricing.

    3. Monetizing Generative AI Services: Usage-Based Pricing Strategy

    In the rush to beat competitors to market and offer generative AI services to customers, do not neglect to lay the groundwork for monetization from day zero. It is much easier and more efficient to build with monetization in mind from the start than it is to backtrack and try to monetize a service once it has been offered, particularly when usage-based pricing is involved.

    Usage-based pricing has emerged as the optimal pricing strategy in the AI domain. This is because service usage varies over time for each customer. These services are priced by the vendors according to a usage-based pricing model. Since the backend costs of the service are elastic, the frontend, customer-facing pricing should also be elastic.

    As a roadmap to monetization, follow these steps:

    -Meter service usage to understand segments and patterns

    -Calculate internal costs of usage using vendor pricing

    -Using the information from steps 1 and 2, build customer-facing pricing

    -Track revenue and margins and continue to iterate with pricing as needed

    4. Customer Transparency: On-Demand Access to Usage and Billing Data

    Prioritizing transparency and clear communication with customers is non-negotiable. Ensuring that usage and billing data can be seen at any point in the billing cycle helps foster trust between the company and its users and eliminates billing surprises when the invoice is delivered.

    Adopting Transparent Communication Builds Trust With Customers

    Invest in creating a customer-facing application, portal or experience that allows for on-demand access to usage and billing data. The beauty of combining this level of visibility with usage-based pricing is that customers are empowered to pay for only what they use while viewing usage statistics on demand and modulating usage as needed in real-time to keep the spend within an acceptable range.

    In practice, usage data is available on a per-query level from the vendor’s APIs. For example, for any generation action, OpenAI will show the precise number of tokens consumed for both the prompt and response, as well as all details around the model type and context needed to identify the per-token rate from the vendor pricing. It is important to collect this data and build a user-friendly way to display it back to customers in an app, portal, or website that allows for on-demand access and browsing.

    Conclusion

    While planning to build a product with generative AI, take all of the above factors into account. Do not make the mistake of racing to deliver a technology solution without also considering the business implications and monetization strategy. With all the hype, excitement and investment around generative AI in 2023, it is akin to a modern-day gold rush. Don’t show up to the gold rush without a shovel.