devopsy.kinsta.cloud

Category: Doin’ DevOps

How to Navigate App Modernization Strategies for the Cloud

In today’s fast-paced digital landscape, organizations continuously seek ways to innovate and enhance customer experiences while optimizing efficiency. One of the most transformative strategies is modernizing applications for the cloud. App modernization isn’t just a technology upgrade. It’s a holistic business transformation. The cloud’s elasticity and scalability present opportunities to create deeper customer engagement, foster seamless partner integration and unlock valuable data insights. However, this requires a thoughtful approach that aligns with business goals and technological aspirations.

Let’s look at some best practices for modernizing apps for the cloud and navigating potential challenges.

The App Modernization Process

It’s important to determine whether the cost of migration will lead to better efficiency and customer engagement that will yield an increase in return on investment (ROI). This approach allows businesses to address current issues and future-proof their data stacks.

After assessing the cost and ROI considerations, organizations need to follow a systematic process to successfully modernize an app for the cloud. The first step is to evaluate the existing app’s strengths, weaknesses and areas for improvement. It’s crucial to assess an app’s compatibility with cloud platforms and set clear modernization goals.

Following the assessment, design a cloud-native architecture that aligns with the cloud’s scalability, elasticity and distributed nature. This may involve rearchitecting the app to include such cloud-native components as microservices, containers, or serverless computing. Once the architecture is in place, migrate the app’s data from on-premises or legacy databases to cloud-based storage solutions to ensure data availability, scalability and ease of management in the cloud environment.

The next step involves rewriting or modifying the app’s codebase to take advantage of cloud services and APIs. Specific modules or functionalities may need to be re-engineered to enhance performance, scalability and integration capabilities. Perform comprehensive automated load and security testing to verify reliability and performance in the cloud.

Once the modernized app has been tested, deploy it on the selected cloud platform. Implement monitoring and logging mechanisms to gain insights into the app’s behavior, performance and user experience so it operates effectively in the cloud environment.

Navigating App Modernization Challenges

While the benefits of app modernization are significant, challenges can arise during the process.

One of these hurdles involves dealing with legacy constraints. Legacy applications often have complex architectures that complicate modernization. Careful planning is required to update outdated technology stacks and move from a tightly coupled system to a loosely coupled one.

Another obstacle pertains to data migration complexities. Transferring large amounts of data from on-premises systems to the cloud demands meticulous planning and execution to maintain data integrity, security and minimal downtime.

Integration presents another potential difficulty. Modernized apps often need to integrate with other systems, both on-premises and in the cloud. Many cloud vendors offer tools and programs to aid in migrating data. These, coupled with credits to be used as apps are migrated, can significantly reduce costs.

Security and compliance are critical considerations when moving to the cloud. Cloud environments require robust security measures to protect sensitive data, and organizations must comply with relevant regulations and industry standards.

Effective change management strategies are another aspect to consider to ensure a smooth transition for users and stakeholders. App modernization is a business process modernization representing a significant change in business operations.

In-House Vs. Outsourced App Modernization

Choosing between in-house and outsourced app modernization depends on several factors.

First, if an organization has skilled developers with cloud expertise, handling app modernization in-house is a viable option. On the other hand, if a team lacks the necessary skills, it may be more practical to outsource the task to a cloud service provider or a specialized development partner. It should be noted that if the development work is outsourced, it’s important to keep the app business owners involved to ensure that the modernized solutions yield the expected benefits.

Another consideration is the availability of resources, such as time, budget and staffing. App modernization projects require dedicated efforts, and outsourcing becomes appealing if internal resources are limited. By entrusting the project to external professionals, organizations can ensure it receives the attention and resources needed without burdening the internal team.

Evaluating whether app modernization aligns with an organization’s core competencies is also essential. If the application is not directly related to the core business, outsourcing can free up internal resources and redirect them toward more strategic initiatives. This allows an organization to concentrate on areas in which it has a competitive advantage and expertise while still benefiting from the app modernization expertise of external partners.

Pioneering the Future

Modernizing an app for the cloud is a transformative journey that holds the potential to enhance customer experiences, optimize processes and unlock valuable insights. Navigating challenges through meticulous planning, robust testing and adherence to standards are crucial, whether opting for in-house expertise or external collaboration. By embracing cloud-native principles and using advanced technologies, organizations can position themselves at the forefront of innovation, ensuring lasting success in the dynamic landscape of the digital era.

November 1, 2023
Measuring the Progress of the OpenTelemetry Project

The biggest compliment you can pay a technology standard is to say that it is “boring.”

Transport layer standards like TCP and UDP are boring. They are the underlying protocols powering pretty much everything we do on the internet. REST is boring. It brokers trillions of API transactions across the world’s distributed microservices.

Infrastructure standards get boring when they become common infrastructure plumbing that “just works.” They give open source creators and maintainers common foundations to innovate on top of. They give users confidence that their technology choices aren’t leading to dead ends. Look at any major evolution in computing, and it’s always propped up by boring standards.

When OpenTelemetry debuted at KubeCon in 2019, telemetry data for applications in distributed systems was far from boring. Two competing projects—OpenTracing and OpenCensus—were trying to encapsulate best practices around the still nascent distributed tracing discipline. They were “very similar in that they aim[ed] to unify app instrumentation and make observability a built-in feature in every modern application” (Merging OpenTracing and OpenCensus: Goals and Non-Goals). But having two fragmented communities around these two projects made it hard for distributed tracing to move forward—so it was a big deal when the two projects merged and OpenTelemetry was born.

Let’s take a look at how the OpenTelemetry standard is making this all possible.

Standard Semantic Conventions and a Single ‘Mental Model’

Semantic conventions are important to standardize how we describe common operations so that we have consistent telemetry for similar actions. Developers instrumenting applications need to be able to relate to clear semantic definitions to understand how to instrument everything from database drivers to SQL statements and how to consume that telemetry data for analysis.

For example, OpenTelemetry semantic conventions define where in the metadata the process name should be stored, but not what the process name should be. Similarly, if I’m deploying my application on Kubernetes on a cloud provider somewhere, I’d expect my telemetry data to have the Kubernetes pod and namespace it originates from, as well as the cluster and region.

OpenTelemetry also standardizes metadata for labels that span languages. So if I have an HTTP service and request, it doesn’t matter if it is in Java, Python or any other language — with OpenTelemetry, I can just start querying the data without having to think about the language behind it.

It brings a consistent mental model to how the different telemetry data types (traces, metrics, logs) are related: OpenTelemetry gives them the same base, so understanding how a span is modeled provides knowledge that can be reused when understanding metrics and logs. It can be used by any microservice and any HTTP- or gRPC-connected service or device. For any network device, OpenTelemetry gives developers semantic conventions that bring consistency to reporting telemetry data on any type of event. So, any engineer working with OpenTelemetry can compare latencies and queries between services—even if they are written in different languages—because of the semantic conventions.

Protecting Users From Vendor Lock-In

A decade ago, monitoring and logging vendors provided agents to their customers. They didn’t call it observability back then. But they told the market that if you want the best telemetry data, you need to use our agent. Every vendor had its own agent.

Adding these agents was risky and took a lot of time. Once a vendor got its agents into a customer’s environment, they were hard to change and you had to either pay the vendor or your team of engineers to remove that instrumentation in favor of another.

OpenTelemetry really commoditized the telemetry definition in such a way that we don’t need to use agents from vendors anymore. This means users can decide which vendor to use for observability tooling and have the flexibility to switch to different vendors down the line. With OpenTelemetry, they no longer have to instrument applications, restart applications and get into risky operations cycles to change the destination of their telemetry data.

Economies of Community – Scale for Drivers and Integrations

OpenTelemetry has achieved a very large and diverse set of contributors in a relatively short period of time. It’s become the second most popular CNCF project, behind only Kubernetes.

The project is drawing contributions both on the instrumentation side of things, as well as the collection side of things. Specifications are another big area where the project is evolving, including the API/SDK spec, the data model and the OTel protocol (OTLP). Accelerating all of this is the fact that OpenTelemetry has broad participation from the logging, monitoring and observability vendor ecosystem, which comprises many of its largest contributors.

We still have a ways to go. But in the last year, it’s become obvious that OpenTelemetry is so commonly regarded as the standard for tracing data that the language, library and database creators and maintainers are instrumenting for OpenTelemetry. This is the ultimate sign of maturity for any project or standard—when its popularity has created pull from maintainers designing around the spec and using it natively.

What’s Next For OpenTelemetry?

Looking to the future, I think we’re going to see an unintended consequence where OpenTelemetry moves the industry from operational data to more data intelligence. OpenTelemetry makes it much easier to instrument how users are interacting with systems and enables developers to add business metrics and compare those against actual user behavior.

OpenTelemetry also has a great potential marriage with eBPF and related projects like Cilium. These abstractions that make the Linux kernel “programmable” add a pool of much finer-grained telemetry data that can be extracted into logs from applications during run-time.

This all feeds into the concept of “Profiles” that OpenTelemetry is implementing. While distributed tracing emphasizes the horizontal cut of how a specific transaction is running or all the services that are tied through a single request, a profile is a different vertical cut that emphasizes the state of resources like memory, CPU and more at a point in time. Those profiles are collections that are stored continuously and another great slice of telemetry data that will be encapsulated by the OpenTelemetry standard.

October 31, 2023
How to Alleviate Your Observability Challenges

Observability is becoming a keystone of contemporary DevOps practices. Even departments that weren’t traditionally a part of DevOps are seeing the benefits of being brought under the auspices of observability teams. In 2023, however, organizations are finding that the road to adoption is bumpier than expected. Here are seven of the biggest challenges DevOps teams face with observability and some suggestions for mitigating them.

Increasing MTTR

MTTR, or mean time to recovery, is the time it takes to get a system back up and running after an outage or bug. A longer MTTR means more downtime and poorer service for clients. Worryingly, the DevOps Pulse Report indicates that the average MTTR is increasing. This year, 73% of its respondents reported an MTTR of multiple hours; last year’s figure was only 64%.

MTTR often results from an inability to diagnose incidents due to data siloes impairing observability. This can be improved by an observability platform that allows engineers to see the big picture.

Costs of Telemetry Data

Along with increasing MTTR, many organizations have to deal with costs incurred by high telemetry data volumes. It’s a big problem. An IDC survey of 200 companies found that 53% of respondents highlighted the costs of storing log data.

Much of the problem is due to an outmoded tiered pricing model. Many vendors charge per GB of data, so if your data volumes fluctuate, so will your data costs. They also have obscure pricing models, meaning many organizations find it difficult to know what they’re paying for. At Coralogix, we’ve created a new business model that is one-third of the cost of standard log storage solutions.

Tool Sprawl

To understand why this is a challenge, we need to answer the question: What is observability? Effective observability requires integrating data from every aspect of your application. Because many organizations implement monitoring with multiple tools, they suffer from tool sprawl. This has the effect of siloing telemetry data, making it harder to correlate data and extract insights into system performance.

There are a range of options for mitigating tool sprawl, such as thoroughly evaluating a tool’s costs and benefits before including it in your DevOps strategy. The most effective solution is a “single pane of glass” tool that combines insights synoptically on a single dashboard.

Kubernetes Complexity

Elastic reports that organizations are increasingly turning to cloud-based solutions such as Kubernetes for their DevOps. Kubernetes can supercharge organizations with its ability to dynamically scale infrastructure as needed, eliminating the cost overheads of dedicated servers.

However, Kubernetes is complex and comes with its own set of challenges. Kubernetes’ scalable architecture comes from containerization, a paradigm in which applications are hosted in objects called containers. This means that developing in Kubernetes requires the ability to work with a lot of spinning plates.

A good way to combat this is better training in organizations. Additionally, breaking down silos allows different teams to transfer knowledge.

Security Challenges

Kubernetes’ popularity brings security challenges. These can include privilege escalation, where a user manages to gain privileges such as write access, and security misconfigurations, where developers forget to change the non-secure default configurations.

There are several strategies for mitigating Kubernetes security risks. These include scoping roles to particular namespaces, using service meshes, and enhancing security with Coralogix’s Kubernetes Operator.

Beyond Kubernetes, there’s the larger issue of integrating security into an observability strategy, which is becoming a challenge for an increasing number of IT businesses. To counter this, more and more businesses are starting to incorporate observability and security monitoring under a single umbrella. Solutions such as infrastructure and application metrics can enhance security and monitoring.

Scaling Platforms

To meet the challenges posed by rising data costs and increasing cloud complexity, businesses are turning to open-source solutions. These come with their own challenges, however. According to the DevOps Pulse Report, around 30% of enterprises surveyed had problems with infrastructure management, scaling and upgrading relevant components. Because many open-source platforms require specialized knowledge to maintain, businesses have trouble sourcing the skills and expertise for them.

Tools such as OpenTelemetry can make scaling easier by integrating with platforms such as Coralogix.

Troubleshooting Data Pipeline Performance

Implementing observability requires having a reliable and high-performance pipeline for telemetry data. However, organizations using open-source platforms often have trouble monitoring and troubleshooting the performance of their data pipeline. This can impair observability as telemetry data is of lower quality.

Data engineer Abraham Alcantara suggests ten key steps to troubleshoot data pipelines successfully. These include identifying data pipeline software and infrastructure, reproducing and isolating issues and automating issue scenarios. Another strategy is to apply machine learning, such as Coralogix uses.

October 31, 2023
FAQs for Software Testing: All the Background You Need

No matter what type of application you and your team are building, testing is a critical step in the software development life cycle (SDLC) that can not be overlooked. In this article, I’ll answer frequently asked questions about software testing, why software testing matters and suggest best practices to help ensure your application is ready to delight customers by the time it is deployed.

Why Do We Need Testing?

Software testing involves evaluating an application to see if it meets the requirements and functions it was built for. The process includes identifying defects, errors and bugs, along with flaws in user experience. Software testing is so critical because finding and fixing these bugs and issues in the development process means the end product reaching customers works properly and reliably and delivers a high-quality user experience. Additionally, testing during the development process makes bugs easier and less expensive to fix as opposed to making fixes after an application has been deployed.

Overview of Testing Types

Let’s quickly define the common types of software testing:

● Unit Testing: This process evaluates individual components of software to ensure they are working properly.
● System Testing: This involves ensuring an entire application or system meets requirements and functions as it should, end to end.
● Integration Testing: This looks at whether or not different modules of an application or system work properly together.
● Regression Testing: This process revisits previously tested components of software to make sure they work correctly after a change has been made.
● Acceptance Testing: This process determines whether an application meets the needs of end users and is ready to be deployed.
● Usability Testing: This process assesses how user-friendly a customer will find the product.

Creating the Plan

Any solid software testing plan is going to incorporate multiple testing approaches, including manual, automated, user experience, exploratory and non-functional testing. You’ll start by defining the scope for what parts of your application, integrations and functionality you need to test for. Then, you can decide what type of testing methods are needed for each and document these to ensure consistency.

You’ll want to combine code coverage and test coverage to ensure the code for your application is tested thoroughly. The type of tests you prioritize will vary based on different products, and your testing strategy will certainly evolve and grow over time.

Measuring Your Strategy for Thoroughness and Effectiveness

To ensure your testing strategy is thorough and effective, you will need to make sure to test for code, device coverage and all aspects of user experience. The bottom line for the program should be delivering value to the business by making sure the application works as intended for users. To be effective, testing should take place before an application reaches end users, so issues and bugs can be identified and fixed before deployment. To be thorough, testing strategies must be balanced, end-to-end, and look at functionality, usability, accessibility and more.

Effective software testing can be measured in a few ways, including:

● Code Coverage: The percentage of code that is tested.
● Test Case Effectiveness: The percentage of test cases that found defects or bugs.
● Time to Detect and Fix Defects: The time it takes to find and fix issues in an application.
● Defect Density: The number of defects found per unit of code.

Improving Your Testing Approach

Your software testing program should be evolving and improving over time and can improve by:
● Including test-driven development
● Leveraging a shift-left approach
● Using automation where possible
● Benchmarking QA for current projects versus previous ones
● Conducting a cost-benefit analysis

Testing Best Practices

While the below list is not exhaustive, here are some top best practices to keep in mind as you build out a software testing practice at your organization:
● Incorporate the voice and feedback of your customer into product design
● Make accessibility a priority
● Test throughout the entire SDLC, including in pre-production, after changes are made to code, and in-sprint testing
● Maintain a matrix for the different devices using your application
● Prioritize high-quality user experience
● Automate repetitive tests where possible
● Review and adjust testing processes regularly, as needed
● Track and report results to analyze trends and identify areas for improvement
● Balance between leveraging different testing types

Your organization’s software testing strategy directly impacts the quality of the end application you deliver to your customers. Poor usability, accessibility, and reliability of an application can frustrate users and send them to competitors, while high-quality user experiences and application performance can boost adoption and keep customers happy and loyal to your brand. With so much competition, taking the time to build out, adjust and prioritize software testing is critical for modern businesses.

October 30, 2023
A Manifesto for a More Sustainable Cloud Future

I’ve talked about cloud sustainability extensively in these pages previously, but until we start taking tangible steps to collectively reduce our cloud carbon footprint, things are not going to change. Achieving real change comes down to a smarter, more efficient use of resources and establishing a culture of sobriety—both financial and environmental—that flows through an organization. Below, I present the steps necessary for a more sustainable cloud future.

1. Shift the Mindset

First, and arguably most important, there needs to be a shift in mindset that sees IT managers, CIOs and other IT leaders become part of a much broader conversation about how to bake sustainability into the overall IT strategy from the start. In doing so, this offers a path to bring development, finance, ESR and business teams together to ensure greater financial and environmental accountability.

2. Right-Size to Optimize

Regular sustainability assessments can help to identify oversized resources and underused services, which paves the way for smarter allocation. Eliminating unnecessary services and right-sizing instances will help to identify recurring problem areas and serve to reduce carbon emissions. This will create a best practice of optimal resource usage and, consequently, contribute to ongoing savings made to an organization’s bottom line.

3. Embrace Dynamic Scaling

Most cloud providers now offer dynamic scaling capabilities that allow resources to be adjusted according to demand. By embracing these sorts of features, organizations can ensure that resources are used more efficiently while minimizing emissions. This sort of real-time optimization can strike an important balance between performance and environmental responsibility.

4. Fewer Servers Means Less Power Needed

Server virtualization—essentially the process of dividing a physical server into multiple unique virtual servers—offers a clear way of contributing to carbon reduction efforts. By optimizing resources and reducing the physical server count, the consumption of energy can be minimized. Fewer servers mean less power consumption, which directly translates into lower carbon emissions.

5. Only Energy-Efficient Architecture

Platforms such as serverless computing architectures have emerged as a greener alternative to traditional infrastructure, allocating resources only when needed. This creates greater energy efficiency and reduces total carbon emissions. Leveraging these sorts of energy-efficient instance types and hardware, such as ARM-based processors that consume less power than x86-based alternatives, provides a clear way to minimize power consumption and environmental impact.

6. Localization Matters

While the steps above are effective, their impact will be amplified by choosing cloud regions that are based on low-carbon energy sources. For example, regions that are reliant on coal or other high-carbon energy sources should be avoided or used sparingly to minimize environmental impact, but this is not as straightforward as it sounds due to seasonal variations, which might mean that renewable energy sources are subject to fluctuations; the costs associated with storing excess energy from intermittent sources which are both challenging and expensive and the cost of energy trading between regions which can impact carbon footprint.

The truth is that there is no one-size-fits-all solution when it comes to evaluating localization. Assess the energy mix, consider the availability and reliability of renewable energy sources and factor in any seasonal variations or dependencies on fossil fuel-based backup systems. This way, you can make a more informed decision that aligns with your sustainability goals and minimizes the environmental impact of your cloud infrastructure.

7. Align FinOps and GreenOps Strategies

Closely linked to more established terms like FinOps—another framework for managing operational expenditure across an organization, often in conjunction with the cloud and cloud computing—GreenOps is an emerging term that essentially means providing greater cost transparency while promoting a culture of environmental responsibility. The challenge is that making an entire IT ecosystem sustainable requires a step back and all areas of IT to consider their impact on the environment.

This requires collaboration right the way across an organization and with other lines of business which includes areas like HR, marketing, procurement and the accounting departments, all of whom must set business requirements, determine software development and DevOps processes, and adhere to operational principles. Aligning GreenOps and FinOps strategies will allow organizations to start monitoring cloud computing emissions by connecting emissions data directly to their cloud expenses so they can see both the costs to budget and the cost to the environment in the same place.

8. Remember to Turn Off the Tap

Finally, think of efficiency as being the cornerstone of any sustainable initiative, and cloud computing is no different. Optimize cloud instances and you will, in turn, reduce carbon emissions. By evaluating running service instances continuously and strategically and turning off those that are not needed during periods of low demand, organizations can significantly cut down on unnecessary energy consumption. This will not only reduce carbon footprint but also optimize operational costs.

By addressing these complexities head-on, I believe we, collectively, as an industry, have a once-in-a-lifetime opportunity to reduce our carbon footprint and pave the way for a greener, more efficient cloud computing landscape.

October 27, 2023
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.

October 26, 2023
What is Just-In-Time (JIT) Permission Management, and Why is it Essential?

Have you ever experienced the frustration of discovering an unexpected charge on your bank statement for a forgotten gym membership? Perhaps you kept it active “just in case” you wanted to exercise someday. Similarly, always-on privileged access, also known as “standing privileges,” can lead to similar challenges.

Surprisingly, 77% of organizations provide unrestricted access to employees who do not require it. However, maintaining an always-on approach does not necessarily facilitate their work; instead, it creates opportunities for security breaches that can go unnoticed. In fact, in 2022 alone, 55% of organizations fell victim to cyberattacks where hackers exploited privileged credentials, a critical attack vector as identified by Verizon.

This article explores the concept of just-in-time (JIT) permission management and its significance in providing the necessary security and efficiency for access control in organizations. We will delve into various types of JIT management, including automated JIT, and discuss the best practices for its implementation within your business.

Understanding Just-In-Time (JIT) Permission Management

JIT, also known as just-in-time access, is a cybersecurity practice that adheres to the principle of least privilege. It grants users access to resources, such as applications and systems, only for a limited period when it is specifically needed. Once the designated time expires, users lose access to these resources. This methodology not only limits a user’s access timeframe but also reduces the chances of attackers infiltrating your cloud security perimeter.

With the increasing number of applications, services, users and resources in the cloud, 45% of breaches in 2022 were cloud-based, making JIT an essential requirement. While traditional privileged access management (PAM) processes, such as session management, are effective for on-premises environments, JIT is particularly suitable for controlling access across cloud resources.

Types of JIT Permission Management

JIT permission management can be implemented in different ways, including:

Ephemeral: This approach involves creating a one-time account to fulfill the user’s access requirements, which is then disabled or deleted.

Temporary: Users can request elevated privileges on their existing accounts when necessary.

Justification-based: Users must provide a valid justification for requiring privileged access, based on predetermined policies. A privileged account and credentials are created and rotated using a central vault in this “broker and remove” access model.

The Importance of Automated Just-In-Time Access

Managing JIT permissions manually can be akin to playing a never-ending game of whack-a-mole, with constant access requests popping up across your organization. Can you realistically allocate sufficient time and personnel to grant and revoke access throughout the day, especially considering the resource constraints faced by 59% of organizations that struggle to deploy zero-trust?

In contrast, automated JIT platforms alleviate the challenges posed by manual permission management. These platforms validate, monitor and revoke access without requiring human intervention. By offering features such as auto-expiring permissions and comprehensive reporting capabilities, automated JIT platforms empower users to self-serve permission requests while maintaining your organization’s security posture. Entrusting permission management to an automated JIT platform minimizes human error, reduces the attack surface, eliminates bottlenecks and ultimately preserves productivity.

Benefits of Automated JIT

Automated JIT not only eases the burden on your IT and security teams but also provides several other advantages:

Enhanced security posture: Compromised or stolen credentials were the most common attack vector in 2022, according to IBM’s Cost of a Data Breach report. By eliminating the need for standing privileges, automated JIT significantly reduces the risk of privilege abuse and breached identities.

Improved business productivity: With an automated JIT approval workflow, you can bid farewell to manual review cycles, waiting times and human error. You can grant access at scale, tailored to specific tasks, significantly improving operational efficiency.

Compliance adherence: Automated JIT enables you to meet compliance and customer requirements, such as SOC2, by enforcing zero trust and least privilege access. These platforms include auditing and reporting features that provide visibility into all sessions and privileges, ensuring compliance with regulations like SOC2 and PCI-DSS.

Enabling JIT Access: Best Practices

To successfully enable and implement JIT access, consider the following best practices:

Identify and inventory: Begin by identifying the accounts and assets with the most privileges, particularly those belonging to administrators, which pose the highest risk. Implement JIT access control for these accounts first and then gradually extend it throughout the organization.

Use RBAC and ABAC: Utilize role-based access control (RBAC) and attribute-based access control (ABAC) as supplementary solutions to define granular policies and circumstances for elevated access. Categorize accounts, differentiate their rights, and create control policies that users must satisfy to gain access.

Define and enable temporary access: Apart from justification-based access, establish criteria for users requesting temporary access, including which accounts are eligible and the duration of access. Implement time-based controls, such as granting access to specific resources during predefined days and times.

Record and audit activity: An automated access management solution enables you to log all access activities, receive alerts for suspicious behavior, and record JIT-privileged access. Maintaining a comprehensive digital paper trail is essential for auditing, governance, and compliance with regulations such as SOC2 and PCI-DSS.

Assign responsibility: Delegate responsibilities to employees and determine who will review permission requests. Properly training employees on granting and revoking access, especially during critical incidents like “break glass” and “on-call” situations, minimizes the risk of incidents. Automated JIT facilitates configuring access flows for these scenarios, helping resolve incidents promptly and eliminating bottlenecks.

Use short-lived (ephemeral) credentials: Regularly rotate credentials manually to invalidate them, preventing hackers from exploiting stolen passwords. Employ a centralized vault with the highest level of security clearance to manage these credentials effectively.

Employ an automated access management tool: Simplify cloud access management by leveraging solutions like Apono, which enforces an automated JIT approach. By using such tools, you can streamline processes, reduce over-privileges, and ensure that permissions are never overlooked, safeguarding your organization from unnecessary risks.

October 25, 2023
Don’t Forget the One-Offs

I had a rough week last week. We lost a server completely loaded with files and, of the three verified backups, precisely zero of them were valid. If I hadn’t set up the backup and verification process, I would swear that verification didn’t happen or that results were ignored. But I was involved in this one, so I know everything was done right. We do not yet have a root cause analysis done, but we are recovering all that we can to see what needs to be recreated.

This server did not have anything business-destroying like financial data on it, but it did have products–and all of the source code for those products. Restores are one of those things that never happen until they do. And when they do, most of us hope that all goes well. Some of you have that, “Our backup processes are perfect, and we don’t have to worry,” look on your faces. We thought that, too.

This was only one of several, “Oh yeah, forgot that even could be an issue …” items that all dumped on us last week. The fact is that, in the age of DevOps, we have automated the things that happen all the time or are mission-critical (like backups), but there are a ton of one-off things we’ve nearly forgotten about (like restores). That script that changes the permissions on that one folder so it’s right for the application and is only used when the data folder changes? Yeah, those types of things.

We have saved a ton of time in the entire development/deploy/secure/management process; let’s reinvest just a tiny bit of it in cleaning up those one-off items. I am of the belief that we will always have those items, as little critical bits are handled in this manner, customizing things to our organization’s needs. I’m not advocating eliminating these things, I’m advocating gathering them together, hunting them out and getting them into repositories. In fact, for big things, I am even suggesting that a container that can run, perform the task and shut down should be created and then put in the repository. And an inventory needs to be available.

Have you ever stopped and wondered how many hours we have wasted reinventing the wheel because of turnover? I mean, seriously, that complex bit we needed years ago, we need again. Can we grab a script and run it, or do we have to spend staff resources recreating it? Most of the time, we recreate it. Spend that time inventorying instead.

You all are owning the whole DevOps thing, and you should know it. Just about every organization is more streamlined and turning out better apps faster, and that’s all you. Let’s just pick up the corners. I lost my entire week last week over one-off things like that server, and while restores are going to happen, some of the other issues that cropped up could have been a script saved in the past. Of course, if the script was saved on the lost disk …

Keep rocking it, we’re all grateful.

P.S.: For the record, the 2000s-era Dell enterprise servers we have (six of them) just keep clicking along, doing what they do. The SME servers we’ve bought in the last 10 years? Lose motherboards or RAID cards about every four to five years (We have replaced three of them, and we only own two). Shop carefully, my friends.

October 25, 2023
Maximizing Data Insights: How OLAP Empowers Modern Data Stacks

In the era of big data and cloud computing, online analytical processing (OLAP) has fallen out of favor. As modern data warehouses evolved to accommodate larger volumes of data and claims faster processing capabilities, OLAP fell out of fashion as a notion emerged that it would struggle to manage the combinatorial explosion. The focus shifted toward runtime querying engines. Instead of using predefined or pre-aggregated OLAP cubes, many business intelligence (BI) and analytics tools used their own data modeling applications that worked directly with raw data.

However, in recent times, there has been a realization that OLAP, when implemented intelligently, can be highly beneficial even in the context of a massive scale of data and cloud computing. Modern OLAP leverages advanced technologies and optimizations that overcome any previous limitations. Besides being cost-effective, especially for cloud implementations, it delivers real performance advantages.

Modern OLAP systems are designed to handle large datasets efficiently. One of the key strengths of OLAP lies in its ability to provide real-time or near-real-time insights, enabling businesses to make data-driven decisions with greater agility. The multidimensional data model of OLAP cubes facilitates instant query response, empowering users to derive valuable insights from complex data sets without compromising on query performance.

Consider These Advantages of Using OLAP in Modern Data Stacks

Performance: As data volumes continue to grow, OLAP remains a powerful technology to extract valuable insights and unleash the true potential of modern data stacks and cloud environments. OLAP’s multidimensional data model with pre-aggregation cubes enables efficient data processing and analysis, delivering faster insights and sub-second query responses. Modern algorithms further enhance performance, allowing organizations to handle large-scale data workloads without worrying about data explosion problems.

Unique OLAP Capabilities: Some domains, like finance, have an inherent need to preserve crucial OLAP capabilities even with the growing data storage and compute requirements for which they make a move to modern data stacks and cloud environments. Moving to the cloud enables data scalability, addressing the challenges of handling vast data volumes. However, they cannot afford to compromise on essential OLAP functionalities such as advanced hierarchies, like parent-child relationships, and alternate hierarchies with weighted rollups.

These capabilities are indispensable, especially in the world of financial analytics, regardless of how modern and advanced the new data stack may be. By leveraging OLAP in the cloud, organizations can continue to analyze and explore data with complex hierarchies efficiently, ensuring accurate and in-depth financial insights without sacrificing the flexibility and analytical power that OLAP provides.

Cloud Architecture and Cost Effectiveness: OLAP in cloud architecture presents a powerful and forward-looking solution that combines the benefits of OLAP technology with the scalability and cost-effectiveness of cloud computing. By harnessing the cloud’s resources, OLAP can efficiently process and analyze large volumes of data, thus meeting the growing demands of modern businesses.

Once OLAP cubes are constructed and populated, they provide a highly efficient and aggregated representation of the data. These pre-aggregated structures accelerate query performance, enabling teams to access insights in real-time or near-real-time. BI teams can seamlessly integrate existing tools with the OLAP model, fostering a cohesive and familiar analytics environment. It empowers decision-makers to explore data interactively, drill down into details, and gain valuable insights.

One of the primary advantages of OLAP in the cloud is its cost-effectiveness. OLAP technology, being primarily based on pre-aggregation, drastically reduces runtime querying compute cost, as answers to business queries are already pre-computed and stored in an aggregated structure. At querying time, OLAP tools have to look for right answers from the aggregated structure—not the cloud data storage—and return the query response, which results in much less compute cost as compared to runtime aggregation compute cost. It truly enables build once, query many times culture. Apart from this, businesses can leverage the cloud’s elasticity to scale computing and storage resources up or down as their data requirements fluctuate. This adaptability ensures companies can handle peak workloads without overprovisioning and reducing unnecessary expenses.

Universal Semantic Layer: A USL approach ensures consistent data definitions and analytics across the organization, reducing data discrepancies and improving data governance. A common understanding of the data enables better communication among teams and results in a smooth implementation of a data-driven decision-making process.

At the same time, using a USL means that multiple business intelligence tools and reporting platforms can connect to and leverage the same semantic model. Hence, various parts of the organization can continue to work with their familiar BI interfaces while accessing common underlying data.

OLAP lends itself naturally to delivering on a powerful universal semantic layer. The concept of dimensions, measures, hierarchies and calculations forms the foundation of an OLAP semantic model. OLAP semantic models also accommodate complex calculations, custom expressions or formulas required for complex business-specific logic. These components provide a powerful way to structure and organize data, making it more accessible and intuitive for business users who need to derive insights from the data.

If we consider typical sales data, product categories, geographic regions and time periods could be dimensioned. Measures, on the other hand, would be sales revenue, profit margins, quantities sold or any other KPIs. Hierarchies allow data to be analyzed at different levels of granularity. Users may roll up or drill down to view data at different time intervals such as year, quarter, month, day, etc.

USL and OLAP models are designed to shield business users from the underlying complex data modeling and schemas. They can work with filters, dimensions and measures that are business-focused representations of the data using familiar business terms while abstracting technical intricacies. They can view and explore data through intuitive hierarchies, filters and measures aligned with their business processes and KPIs.

Conclusion

OLAP in cloud architecture represents a forward-looking, fast and cost-effective solution. It capitalizes on the cloud’s scalability and pay-as-you-go model to process vast amounts of data efficiently, while its pre-aggregated structures and real-time capabilities empower business intelligence teams to gain valuable insights seamlessly. With its agility, OLAP in the cloud is well-positioned to meet the challenges of the future, providing organizations with a competitive edge with data-driven decision-making.

October 23, 2023
Data Reliability Needs to Shift Left

Data pipelines feed and transform data for consumption and are increasingly growing in complexity. As enterprises continue to add data sources, they run the risk of breaking their data pipelines due to data errors, flawed logic or insufficient resources for processing. The challenge for every modern data team is to establish data reliability as early as possible in the data journey and to create optimized data pipelines capable of performing and scaling to meet the business and technical needs of the enterprise. In the context of data observability, “shift left” refers to a proactive approach that incorporates observability practices during the early stages of the data lifecycle. This concept is borrowed from software development methodologies and emphasizes addressing potential issues and ensuring quality from the outset.

Shifting left involves integrating observability practices and tools into the data pipeline and infrastructure from the beginning. This approach avoids treating observability as an afterthought or applying it only in later stages to identify and resolve data reliability, integrity, and performance issues as early in the development process as possible, minimizing the likelihood of problems cascading downstream.

The Economic Impact of Poor Data

To effectively manage data and optimize data pipelines, it is crucial to detect and address data incidents as early as possible within the supply chain.

The “1 x 10 x 100 Rule” is applicable in a variety of processes, including software development. It states that the cost of fixing a problem increases exponentially, depending on the stage at which it is detected. The rule can be extended to data pipelines and supply chains, where it suggests that detecting and rectifying a problem in the data landing zone (i.e., where source data is fed) incurs a cost of $1, whereas identifying and addressing the issue in the transformation zone (i.e., where data is transformed into its final format) increases the cost to $10. If the problem is only detected in the consumption zone (where data is in its final format and is accessed by users), the cost rises significantly to $100.

Shift Left Data Reliability

The process of identifying data pipeline issues has become more challenging for data teams as data supply chains continue to evolve and grow in complexity, mainly resulting from the following factors:

● Expanding sources: The number of data sources (such as Databricks, Snowflake, Redshift, Teradata and many others) being incorporated into the supply chain has significantly increased. Organizations now integrate data from a wider range of internal and external sources, contributing to the complexity of data management and processing.
● Advanced data transformation logic: The logic and algorithms used to transform the data within the supply chain have become more sophisticated. Complex transformations and calculations are applied to raw data to derive meaningful insights, necessitating robust systems and processes to handle the intricacies involved.
● Resource-intensive processing: The processing requirements for data within the supply chain have significantly escalated. With larger volumes of data and more complex operations, organizations must allocate substantial computing resources, such as servers, storage and processing power, to handle the data processing workload effectively.

By proactively addressing data incidents at an early stage, organizations minimize the potential impact and cost associated with data issues. This not only ensures the reliability and accuracy of data consumed by users but also safeguards the integrity of downstream processes and decision-making. Ultimately, the shift left approach to data reliability promotes efficiency, reduces costs, and enhances overall data quality and trustworthiness.

How Can Data Teams Shift Left?

To effectively shift left in your data reliability solution, certain capabilities are crucial; these include:

● Early Data Reliability Checks: Conduct data reliability tests before data enters the data warehouse and data lakehouse. This ensures that bad data is identified and filtered out early in the data pipelines, preventing its propagation to the transformation and consumption zones.
● Support for Data-in-Motion Platforms: Enable support for data platforms like Kafka and monitor data pipelines within Spark jobs or Airflow orchestrations, which enables real-time monitoring and metering of data pipelines.
● File Support: Perform checks on different file types and capture file events to determine when incremental checks should be performed.
● Circuit-Breakers: Integrate APIs that incorporate data reliability test results into your data pipelines, which can halt data flow when bad data is detected. By preventing the spread of bad data, circuit breakers protect downstream processes from being affected.
● Data Isolation: Identify and isolate bad data rows, preventing their continued processing.
● Data Reconciliation: Implement data reconciliation capabilities to ensure consistency and synchronization of data across multiple locations.

Shifting left your data reliability practices empowers data teams to focus on innovation, reduces costs, enhances data trust and enables agile business processes. Embracing this approach makes data more usable and resilient and delivers a more robust and reliable data ecosystem that supports informed decision-making and drives organizational success.

October 23, 2023