devopsy.kinsta.cloud

Category: DevOps in the Cloud

  • Building an Open Source Observability Platform

    Building an Open Source Observability Platform

    Enterprises are under constant pressure to ensure their IT infrastructure and applications are available throughout the year. The complexity of modern architectures (containers, hybrid cloud, SOA, microservices, etc.) is constantly growing, generating vast volumes of unmanageable logs. We need intelligent application performance management (APM) and observability tools to achieve production excellence and meet the availability and uptime goals. These include analyzing application health, performance and user experience. Adopting machine learning techniques to identify anomalies and behavior patterns will help detect the root cause early and meet customer service level agreements (SLA).

    The APM and observability tools market is undoubtedly hot. These tools ingest multiple telemetry data feeds and are powerful analytics platforms providing critical insights into application and infrastructure health, including system performance. The software development teams that adopt observability are much better equipped to release their application code iteratively. As per “MarketsandMarkets” research, the market size of observability tools and platforms is expected to grow from $2.4 billion in 2023 to $4+ billion by 2028 at a compound annual growth rate (CAGR) of 11.7%.

    What is Observability?

    Observability is the ability to collect data about the distributed applications, infrastructure and communication among its internal and external components and services, allowing teams to debug their systems diligently. It enables the site reliability engineering (SRE), software engineering and operations teams to analyze the customer impact and triage a service outage. Observability and monitoring are sometimes used interchangeably. Observability (proactive) makes the data accessible and allows you to ask any system question to know how the code behaves more deeply. Monitoring (reactive) is the task of collecting and displaying that data and the ability to determine the system’s overall state.
    Observability can be further broken down into three key pillars: Logs, traces and metrics, which are essential for SRE observability.

    • Logs help us diagnose the issues and tell us why they happened.
    • Traces help us isolate issues and tell us where they happened.
    • Metrics help us detect the issues and tell us what happened.

    Market Tools, Capabilities and Challenges

    Gartner’s magic quadrant for APM and observability has identified 20+ vendor products offering APM and observability capabilities, including self-hosted, vendor-managed or SaaS deployments. These products provide multiple features, including application performance metrics, monitoring and alerting on events, traceability, anomaly detection and vulnerabilities, etc.

    An enterprise business application comprises homegrown applications (such as .NET, Java, Python, SQL, NoSQL DB, etc.), third-party/off-the-shelf products (such as Salesforce, HubSpot, etc.), and integrations (such as Stripe, PayPal, etc.). Homegrown applications are hosted in an on-premises data center or by cloud vendors like AWS, GCP, or Azure. The off-the-shelf products are SaaS-based or integrated via APIs. There are highly distributed applications spanning tens and hundreds of nodes, services and instances.

    • Too Many Tools: Enterprise applications use various tools for monitoring application health and performance (such as New Relic, Data Dog, etc.), Error logging (such as Splunk), and cloud vendor-provided tools (such as CloudWatch). These products overlap in functionality and maintaining and managing these tools (procurement, learning curve, etc.) can be cumbersome.

    • Unpredictable Data Volume: Imagine the volume of observability data (logs, traces, metrics) collected based on the application traffic, usage, dependency on external products, etc. The amount of data storage required to consolidate these data feeds can quickly grow out of control.

    • Pricing is Complex: These vendor products also offer different pricing models such as charge per host (such as Splunk, Data Dog, Dynatrace), per-user (such as New Relic), per-ingestion (such as SumoLogic, AppDynamics). The complexity of pricing models makes it challenging to compare total cost of ownership (TCO) among vendors and determine the right tool that fits your requirements and budget.

    Why Choose Open Source Observability Platform?

    Open source-based observability tools aim to provide a standard, vendor-agnostic approach for ingesting, transforming and sending data to an observability backend. The open source observability tools can be an alternative to save on licensing costs and consolidate multiple APM tools with the tool that fits your requirements and budget.

    However, maintaining open-source systems may require efforts to set up and maintain and will add to your initial operational cost. But in the long term, you will save on licensing fees and avoid vendor lock-in and contractual agreements.

    Gartner predicts that, by 2025, 70% of new cloud-native application monitoring will use open-source instrumentation rather than vendor-specific agents for improved interoperability, and 70% of new cloud-native applications will adopt OpenTelemetry for observability rather than vendor-specific agents and software development kits (SDKs).

    Scale Observability Using the Open Source Ecosystem

    The open source landscape for observability is quite dynamic. There are multiple Cloud Native Computing Foundation (CNCF) open source tools for observability and monitoring. This post will primarily focus on the OpenTelemetry framework and LGTM technology stack.

    OpenTelemetry:
    The “too many tools” challenge described above brings up a new struggle in telemetry data collection. Each tool vendor has its own APIs, SDKs, agents and collectors for logs, metrics and traces. We need a unified telemetry collection using the OpenTelemetry framework to create and manage telemetry data such as logs, traces and metrics.

    The OTEL project under the auspices of the CNCF offers a unified set of vendor-agnostic APIs, SDKs, and tools for generating and collecting telemetry data and exporting it to various analysis tools. You get one API and SDK per programming language to extract your application’s observability data, a standard collector, a transmission protocol (OTLP) and more.

    LGTM:
    The most popular open source-based observability and monitoring is implemented using the LGTM technology stack.

    In the LGTM stack, we leverage:
    • Loki for log aggregation
    • Grafana dashboards for telemetry visualizations
    • Tempo (or Jaeger) for trace aggregation
    • Managed Prometheus for metrics aggregation

    Conclusion

    Observability is about complete visibility across your systems and tying business metrics with technical data. Monitoring is about understanding if things are working correctly, and AIOps is about getting meaning from that visibility. Observability and monitoring are critical to ensure the smooth functioning of applications and meet customer SLAs. In conclusion, by investing in open source OTel frameworks and LGTM tools, SRE teams can effectively monitor their applications and gain insights into system behavior and potential issues. These tools offer cost-effectiveness and customization to suit specific requirements. It promotes vendor neutrality, which can be critical for avoiding vendor lock-in.

  • Survey Sees Cloud Developer Environment Adoption Gaining Momentum

    Survey Sees Cloud Developer Environment Adoption Gaining Momentum

    A global survey found that while 95% of developers and business leaders are familiar with cloud development environments (CDEs), the reasons for adopting one vary widely. The survey polled 223 developers and business leaders working for organizations with more than 2,000 workers and 250 developers.

    Conducted by Coder, a provider of a CDE, the survey, for example, found that while 15% cited optimizing the developer environment setup process as a reason for adopting a CDE, another 14% cited making management tasks such as onboarding or improving remote access easier.

    Coder CEO Rob Whiteley said while CDEs clearly improve the productivity of application development teams and improve security by reducing the amount of source code running on notebook and desktop workstations, organizations looking to adopt CDEs need a significant amount of cultural resistance. Application developers have historically set up their own development environments on their own local machines. That approach, however, means that in addition to making it more challenging to collaborate also requires organizations to spend significant time and effort locking down each endpoint being employed by their developers, noted Whiteley.

    In fact, those issues are why many platform engineering teams formed to centralize the management of DevOps workflows are implementing CDEs, he added. The ultimate goal is to establish a set of guardrails while still enabling developers to self-service their tooling requirements, noted Whiteley.

    In fact, many DevOps teams have already built a homegrown version of a CDE that they currently maintain. Coder and other providers of CDEs are making a case for using a platform supported by a vendor rather than devoting resources to supporting a custom CDE, said Whiteley.

    As DevOps workflows continue to evolve in the age of artificial intelligence (AI), it’s only a matter of time before more organizations embrace CDEs, he added. The sheer volume of data that developers will be working with will make it impractical to continue to use local machines to build applications, said Whiteley.

    Regardless of the motivation for adopting CDEs, significant cultural changes are coming to DevOps workflows that need to evolve as application development continues to become more distributed. In the post-COVID-19 era, it’s now not uncommon for application development teams to consist of IT professionals working in different time zones. That creates a pressing need to leverage cloud services to provide the level of collaboration those teams need to achieve.

    It’s not clear how many CDEs have been deployed, but as the pace at which applications are being built and deployed continues to accelerate, the days when organizations could allow each developer to maintain their own development environment are coming to an end. Organizations need to determine as quickly as possible whether the code being created will actually run in a production environment. The more time spent trying to reconcile differences between development environments and the production environment where the application runs, the longer it will take to complete any given project.

    Unfortunately, time is the one thing that most DevOps teams no longer have the luxury of spending on application development initiatives that, in addition to multiplying, are also becoming much more complex to manage with each passing day.

  • Best Practices for Configuring MySQL Replication

    Best Practices for Configuring MySQL Replication

    MySQL provides several replication configuration options. However, ensuring it is done correctly may take time and effort, with considerable choices. Replication is a crucial initial step to enhance availability in MySQL databases. A properly designed replication architecture can significantly impact the accessibility of your data and prevent potential management complications. This article will delve into best practices for replication, covering local and long-distance scenarios.

    Active and Passive Setups

    When using active/passive mode for replication in MySQL, one server acts as the source while others serve as read-only replicas. The replicas can handle read-only queries, but all writes must be directed to the source. This configuration distributes the load across all replicas. Still, in the default asynchronous replication mode, there might be a delay between when data is written to the source and when it’s available on the replica. Keep this in mind while designing your application.

    Alternatively, the active/active configuration allows multiple servers to handle both read and write operations. While it may seem beneficial to have two servers for write requests, each server still needs to process the query workload of the other, making write distribution less effective. Additionally, MySQL lacks native conflict resolution logic, so conflicts can quickly arise, making it challenging to determine the true source of data without significant data loss when a rebuild is necessary.

    I recommend using the active/passive configuration for replication and sharding if you require higher throughput from your database.

    Enable GTIDs

    Global transaction identifiers (GTIDs) are unique IDs attached to transactions in a replicated environment. By default, replicas track processed records in the binary log file of a source database. However, this method is fragile if the source crashes and logs need to be restored.

    With GTIDs enabled, each transaction receives a UUID-based ID, allowing replicas to determine if a transaction has been processed. The GTID is a UUID representing the source server, followed by an auto-incrementing ID (e.g., 14a54b2f-2ad0-43b6-b803-72b5d7151d3b:1). As transactions occur on the source, the UUID remains the same while the ID increases. When a replica processes a transaction, the GTID or GTID range (e.g., 14a54b2f-2ad0-43b6-b803-72b5d7151d3b:1-10) is stored in the gtid_executed table.

    This process significantly reduces the risk of data becoming unsynchronized due to unprocessed or excessively processed transactions.

    Replication Modes for Optimal Configuration

    MySQL offers two replication modes that behave differently and should be understood to ensure optimal configuration for your environment. By default, MySQL employs asynchronous replication, where transactions are sent to the source, read by replicas and processed independently without source validation.

    Alternatively, MySQL supports semi-synchronous replication, enabled as a plugin. In this mode, transactions are received by the source and processed by replicas, but the source waits for at least one replica to accept the transaction before responding. Semi-synchronous replication provides greater data consistency, though it introduces some overhead in response time.

    With semi-sync mode, there are additional options that can be adjusted. By default, the primary server waits 10 seconds for a replica with semi-sync mode enabled to acknowledge the transaction. If data consistency relies on semi-sync, consider increasing this timeout value to ensure guaranteed consistency.

    It’s important to note that these modes can be mixed and matched. For instance, you can configure one replica with semi-sync and another without, ensuring that one specific server always has an up-to-date copy of your database while other replicas catch up at their own pace. This approach aids disaster recovery by easily identifying the best candidate for recovery.

    Understanding the distinctions between these modes will help you make informed decisions that align with your business needs.

    Optimize Replica Instances With Separate Log Storage

    Replica instances in your environment rely on the binary logs of the source for accurate information, as mentioned earlier. These logs are stored on the same disk as the database by default. However, this setup can overwhelm busy databases due to high throughput, including database manipulation and reading binary logs for replication. To address this, storing the binary logs on a separate disk from the database is recommended.

    This approach offers performance benefits and cost savings in cloud environments where free volumes have strict IOPS limits.

    Monitor Replication and Metrics in Managed Clusters

    Monitoring is crucial for all infrastructure, including replication. With monitoring, it is possible to know if data is being replicated after configuration. SolarWinds database performance (formerly VividCortex) and Prometheus are popular solutions for monitoring replication and other metrics in managed clusters. Regardless of the chosen solution, it is essential to promptly notify the appropriate individuals when issues arise and address them before they escalate.

    Create a Failover Plan for Minimizing Disruptions

    Inevitable software or hardware failures necessitate failover planning to minimize potential disruptions. Utilizing replication offers resilience by ensuring multiple servers house your online data simultaneously. Therefore, your team must possess a well-prepared strategy should the primary data source fail. The following example outlines an unplanned failover process:

    ● Ensure the downed source remains offline to avoid unexpected replication issues.
    ● Identify and remove the read_only option from the chosen replica that will serve as the new data source. If using semi-sync, select the replica previously configured with the plugin and source.
    ● Update your application to direct queries to the newly promoted source.
    ● Modify the remaining replicas to start replicating from the new source.

    Optimize Cross-Region Replication

    Cloud providers typically provide services across multiple geographic regions comprising several data centers. These data centers, known as availability zones (AZs), are strategically located within the same region but far enough to withstand disasters. Replicating databases to different physical locations is recommended but requires careful consideration. Replication introduces additional latency due to the distance the data needs to travel. Fortunately, latency between AZs is generally low, with AWS claiming single-digit millisecond latency within the same region.

    In contrast, there is significant latency between regions. For example, at the time of writing, the latency between us-east-1 and us-west-1 was reported to be over 60ms by Cloudping.co. Replication across regions results in replication lag, which is the time difference between data being written to the source and being written to a replica. This lag is even more pronounced when replicating across longer distances.

    Asynchronous mode should be used for replication across regions to avoid unnecessary delays for applications making requests.

    A comprehensive understanding of replication configuration options is crucial. However, it is equally important to determine the optimal configuration for these options. This can significantly impact your MySQL cluster’s operational efficiency and data-serving capabilities.

  • DevSecOps: 5 Tips for Developing Better, Safer Apps

    DevSecOps: 5 Tips for Developing Better, Safer Apps

    The cloud is rapidly becoming a major battleground for cyberattacks — and the cost of a breach has never been higher. According to IBM, the average cost of a breach was $4.5 million, and according to the CrowdStrike 2023 Global Threat Report, there was a 95% increase in cloud exploits in 2022, with a three-fold increase in cases involving cloud-conscious threat actors. The acceleration of cloud-focused threat activity and its effects has made security a key priority across organizations – especially DevOps teams.

    Security in the Cloud is a Shared Responsibility

    Security teams are accountable for protecting against risks but cannot be the only ones. Each team must try to communicate why their part of the development lifecycle is important to the other teams in the pipeline. With the growth of cloud-native applications and the demand for faster application delivery or continuous integration/continuous delivery (CI/CD), the use of containers is increasing widely. Complex security issues arise as businesses adopt containerized and serverless technologies and cloud-based services.

    Application developers have a tricky balance to maintain between speed and security. In DevOps, security used to be an issue addressed after development — but that’s changing. Now, developers who previously had to code right up to the last minute — leaving almost no time to find and fix vulnerabilities — are using shift-left capabilities to ensure that code with security vulnerabilities is not moved into production.

    When security is considered at every step in the pipeline, it ensures developers find and address issues early on and reduces the cost of downstream fixes. DevSecOps helps developers find and remediate vulnerabilities earlier in the app development process. Vulnerabilities discovered and addressed during development are less expensive and faster to fix. Automation of testing, remediation and delivery ensures stronger software security without slowing development cycles. The goal is to make security a part of the software development workflow, instead of having to address more issues during runtime.

    Below are five key tips for developing apps with security and efficiency.

    1. Automate Security Reviews and Testing.

    Every DevSecOps pipeline should utilize a combination or variation of tools and features like those listed below. A good automated and unified solution will provide broad visibility and address those issues as they arise, while alerting, enforcing compliance and providing customized reports with relevant insights for the DevOps and security teams.

    SAST: Static application security testing to detect insecure code before it’s used

    SCA: Software composition analysis to detect library vulnerabilities before building

    CSA: Container scanning analysis to detect operating system library vulnerabilities and mitigate risk

    IaC scanning: Infrastructure-as-code scanning to detect vulnerabilities in infrastructure

    ASPM: Application security posture management to detect application vulnerabilities and risks once deployed

    2. Integrate With Developer Toolchains.

    Streamline and consolidate your toolchain so developers and security teams can focus attention on a single interface and source of truth. The tighter the integration between security and app development, the earlier threats can be identified, and the faster delivery can be accelerated. Seamlessly integrate with Jenkins, Jira, Bamboo, GitLab and other cloud security solutions to allow DevOps teams to respond to and remediate incidents faster within the toolsets they already use.

    3. Share Security Knowledge Among Teams.

    DevSecOps is a journey enabled by technology but a process that starts with people. Your DevSecOps team should share lessons learned and mitigation steps after resolving the compromise. Some organizations even assign a security champion who helps introduce this sense of responsibility for security within the team. Be prepared to get your teams on board before changing the process, and ensure everyone understands the benefits of DevSecOps. Make security testing part of your project kickoffs and charters, and empower your teams with training, education and tools to make their jobs easier.

    4. Measure Your Security Posture.

    Identify the software development pain points and security risks, create a plan that works well for your organization and your team, and drive execution. Ensure you track and measure results such as the time lost in dealing with vulnerabilities after code is merged. Then, look for patterns in the type or cause of those vulnerabilities, and make adjustments to detect and address them earlier. This introduces a shared plan with integration into the build and production phases.

    5. “Shift Right” as well as “Shift Left.”

    Detection doesn’t always guarantee security. Shifting right and knowing how secure your applications and APIs are in production is just as important. By leveraging ASPM to uncover potential vulnerabilities in the application code once they are up and deployed, teams can find potential exposure in their application code that could allow backdoor access to other critical data and systems.

    The bottom line is that while security and development used to be separate, the lines are now blurring to a point where security is becoming more integrated with the day-to-day job of developers. The benefit is that the modern practice brings together teams across the company to a common understanding, which drives business growth. DevSecOps requires teams to collaborate and enable the organization to deliver safer applications to customers without compromising security.

    Security is not meant to be a red light on the road to your business goals or slow down your software development. It is to enable you to reach those goals safely with minimal risk.

  • Navigating the Maze of SSDLC Models: A DevOps-Centric Analysis

    Navigating the Maze of SSDLC Models: A DevOps-Centric Analysis

    In the rapidly evolving world of software development, the integration of security into the software development life cycle (SDLC) is no longer a luxury but a necessity. The concept of secure SDLC (SSDLC) has become pivotal in ensuring the creation of software that is not only functional and efficient but also secure from the ground up. With a plethora of SSDLC models available, such as Microsoft’s security development lifecycle (SDL), the OpenWeb application security project’s software assurance maturity model (OWASP SAMM), and others, it’s crucial for organizations, especially those embracing DevOps, to understand their distinct characteristics. This article provides an insightful comparison of these models, highlighting their strengths, weaknesses and applicability to various project types, underpinned by relevant statistics and research findings.

    Microsoft’s Security Development Lifecycle (SDL)

    Microsoft’s SDL, introduced in the early 2000s, is a security assurance process designed to reduce software vulnerabilities and address compliance requirements. A notable aspect of SDL is its emphasis on security training for developers, a practice that has been shown to reduce the introduction of security flaws by up to 30%. The SDL framework includes security-focused activities such as threat modeling, code reviews and security testing throughout the SDLC.

    Strengths: SDL’s structured approach is well-suited for large-scale, complex software projects. Its comprehensive documentation and detailed guidelines are beneficial for organizations seeking a thorough security framework.

    Weaknesses: The extensive nature of SDL can make it cumbersome for smaller projects or teams that adopt rapid development cycles typical in DevOps environments. Its prescriptive nature may also stifle agility.

    OWASP’s Software Assurance Maturity Model (SAMM)

    OWASP SAMM offers a flexible and prescriptive approach to integrating security into software development, making it particularly attractive for organizations adopting DevOps methodologies. SAMM focuses on continuous improvement and can be tailored to an organization’s specific needs.

    Strengths: SAMM’s flexibility allows it to be easily integrated into various development processes, including Agile and DevOps. It supports incremental implementation, a critical factor given that 60% of companies are adopting some form of DevOps practices.

    Weaknesses: Its less prescriptive nature can be a double-edged sword, potentially leading to inconsistencies in implementation. Organizations without a strong security background may find it challenging to interpret SAMM’s guidelines effectively.

    Comparing SDL and SAMM in a DevOps Context

    When viewed through a DevOps lens, SDL and SAMM cater to different organizational needs. SDL’s structured approach is ideal for large enterprises with well-established development and security processes. However, its rigidity may clash with the dynamic, iterative nature of DevOps. In contrast, SAMM, with its adaptability and emphasis on continuous improvement, aligns more closely with the principles of DevOps. It allows for faster integration and adaptation in a fast-paced development environment.

    Other Notable SSDLC Models

    Beyond SDL and SAMM, other models like the V-Model, Agile SDL and BSIMM (building security in maturity model) also offer unique perspectives. For instance, the V-Model’s linear and straightforward approach is well-suited for projects where requirements are well-defined and unlikely to change, a scenario less common in DevOps-focused organizations. Agile SDL integrates security practices within Agile methodologies, making it a viable option for teams that balance rapid development with security considerations. BSIMM, based on real-world data from over 100 organizations, provides a benchmark for companies to measure their secure SDLC practices against industry standards.

    Tailoring SSDLC to Project Needs

    A one-size-fits-all approach does not work in the realm of SSDLC. The choice of model depends largely on the organization’s size, the nature of the project, compliance requirements and the existing development methodology. For instance, one survey indicated that 45% of small to medium-sized enterprises prefer flexible models like SAMM due to their limited resources and need for agility.

    The Role of Automation and Tooling in SSDLC

    Irrespective of the chosen model, the integration of automation and tooling plays a pivotal role in the successful implementation of SSDLC in a DevOps environment. Automated security testing tools, for example, can identify vulnerabilities early in the development cycle, a practice that has been shown to reduce the cost of fixing security issues significantly.

    Evolving Security Challenges in the DevOps Era

    As the software development landscape continuously evolves, so do the security challenges, especially in the context of DevOps. DevOps practices, which focus on integrating development and operations to enhance agility and efficiency, also bring unique security considerations. The rise of microservices architectures and containerization, for instance, has introduced complexities in managing security at scale. Data suggests up to 70% of organizations using microservices have faced security incidents due to misconfigurations.

    In this context, SSDLC models must evolve to address these new challenges. For example, incorporating security into container orchestration tools and ensuring secure service mesh configurations are becoming increasingly important. Furthermore, the integration of security into continuous integration/continuous deployment (CI/CD) pipelines, a hallmark of DevOps, demands that SSDLC models be adaptable enough to automate security checks without impeding the speed of deployment.

    Bridging the Gap Between Security and Development

    A critical aspect of SSDLC in a DevOps environment is bridging the gap between security and development teams. Traditionally, these teams have operated in silos, often leading to security being considered late in the development process. This misalignment can be costly. Research has reported that identifying and fixing security vulnerabilities post-deployment can be 100 times more expensive than addressing them during the design phase.

    To mitigate this, modern SSDLC models are increasingly advocating for a ‘shift-left’ approach, where security considerations are introduced earlier in the development process. This approach not only reduces the cost and effort associated with addressing security issues but also fosters a culture where security and development goals are aligned. Tools like automated security scanning and threat modeling are instrumental in this regard, enabling developers to identify and rectify security flaws early.

    The integration of SSDLC into DevOps is not just about selecting the right model but also about adapting to the evolving landscape of software development and cybersecurity. By understanding and addressing the unique challenges posed by DevOps practices, organizations can create a more secure and efficient development environment. Whether adopting Microsoft’s SDL for its structured approach or OWASP’s SAMM for its flexibility, the key lies in tailoring the SSDLC model to fit the organization’s specific needs, culture and project requirements. As we move forward, the convergence of security and development will continue to be a cornerstone in the journey towards creating resilient, secure software.

    Conclusion

    The landscape of SSDLC models is diverse, each with its strengths and weaknesses. For organizations embracing DevOps, the choice of SSDLC model must align with their culture of rapid development and continuous delivery. Microsoft’s SDL offers a robust and structured approach, ideal for complex, large-scale projects. OWASP’s SAMM, on the other hand, provides the flexibility and adaptability needed in a fast-paced DevOps environment. Ultimately, the decision should be guided by the organization’s specific needs, project characteristics and security objectives, ensuring that security is ingrained in the software from inception to deployment and beyond

  • Controlling Cloud Costs With Efficient Ramp Plans

    Controlling Cloud Costs With Efficient Ramp Plans

    A mix of rapid migrations to the cloud and complexity over usage and costs has companies desperately trying to reduce waste and gain control over their spending. Making matters worse is a volatile economy that has decision-makers on edge, considering cost-cutting measures and placing a priority on locking down revenue.

    Without a formal FinOps or cost optimization strategy in place, it’s easy for companies to see cloud expenses snowball out of control. In fact, analysts from Gartner report that organizations that do not employ cloud cost optimization can overspend by up to 70%. That said, ramp plans are becoming a vital tool for containing cloud resources.

    Still, while this strategy can show how to effectively grow your environment and increase workloads, the way a ramp plan is carried out is key to its success. The following looks at what companies should do to succeed with ramp planning accompanied by some strategic advice for handling unique needs that may arise.

    Ramping Up

    A ramp plan, at its most rudimentary level, is data tracking toward how your organization consumes cloud resources versus what it commits to with a cloud service provider (CSP) or reseller. By committing to spend a set dollar amount, you can get healthy discounts or other incentives. As an example, a 50% increase in consumption by the end of the year might earn a 10% discount from a CSP on compute workloads. But there is risk: A company is still obligated to pay that figure, even if it uses far fewer resources than it committed to.

    Still, just as you don’t want to spend money needlessly, CSPs—even high-volume hyperscalers like Amazon AWS and Google GCP—would rather see customers get what they need and grow their footprint. For some organizations, the answer is bringing in a partner to help forecast spend. Questions regarding what is needed, past usage, anticipated growth, potential for acquisitions and more need to be answered. You also have to examine such things as product and service offerings. For instance, a subscription app you offer could catch fire and bring in customers—but you’ll need to plan accordingly so the resources will be in place to meet this demand.

    Compiling and projecting this all isn’t easy, but this type of data is needed so you can develop a ramp plan and budget effectively. In the past, this process required time-consuming manual research, a host of spreadsheets and sophisticated algorithms. However, technology has been developed to automate, drive and scale this process. For some businesses, the ideal is to find a partner with this capability in-house and a depth of expertise to use it correctly.

    Processes and Partners

    Ideally, a ramp plan should be developed before a commitment is made. It should be reviewed on at least a quarterly basis with the C-suite and appropriate technical executives and then revised as necessary. On the whole, CSPs like to sign customers to contracts extending more than a year, with three-year terms being typical.

    Working with a third-party partner, reseller or directly with a hyperscaler comes down to personal preference. Big companies, much like hyperscalers, tend to have a lot of bureaucratic processes and requirements. So, if you want a tactical agreement with AWS, you may have to buy tactical support. You may get a good financial incentive in exchange, but the cost of enterprise-level support could offset that.

    Partners and resellers of cloud services, on the other hand, help hyperscalers scale their businesses, so they often have special arrangements that lower support costs. The development of ramp plans is usually less when going through a third party versus registering with a CSP. These services are often designed for smaller companies that larger CSPs don’t have time to handle. Third parties tend to provide tailored services more in tune with customer needs, including more flexible usage, optimization and security. These partners tend to negotiate more effectively than customers themselves because they better understand the ecosystem and which levers to pull.

    Measuring Success

    It’s not easy to measure and track the success of a ramp plan. Beyond understanding and meeting your commitment—and getting the most from cloud spend—the best measure is profitability. Are you just eating costs or acquiring new customers? Is your efficiency boosting or lowering your margins? It’s even possible to apply unit economics to assess if you’re making money on the resources being used.

    Making a commitment and ramp planning should involve more than financial incentives. Maybe there’s some other strategic aspect you want to achieve? From service-level agreements to support, a lot of things can be woven into a commercial contract. Benefits can come in various forms, but when they’re added together, you can take success in the cloud to a whole new level.

  • Flox CLI Tool Makes Managing Custom Developer Environments Simpler

    Flox CLI Tool Makes Managing Custom Developer Environments Simpler

    Flox today made generally available an open source command line interface (CLI) for a namesake tool that enables developers to more easily spin up multiple custom development environments.

    At the same time, the company revealed at the 21st annual Southern California Linux Expo (SCALE 21) that it is now providing access to FloxHub, a free repository for sharing development environments across teams.

    Flox is based on the same declarative framework used to invoke the Nix package management and configuration tool. It allows developers to create environments that contain everything they need to build software, including automatic creation of a software bill of materials (SBOM).

    Ross Turk, head of marketing and developer relations for Flox, said that approach provides developers with a framework for managing multiple development environments that they can spin up using the same methods commonly used to invoke the package managers versus having to master a less familiar approach to manage development environments, he added.

    That capability makes it simpler for developers to both replicate development environments across machines and, when needed, dynamically switch between projects in a way that can be continuously audited by a centralized DevOps team. Instead of requiring a DevOps team to apply the same rigid standard environment across all development projects, each developer is still free to customize their environment based on their personal preferences.

    In addition, developers trying to fix a bug can also now easily reproduce the development environment they were using at the time they were writing the code they needed to review.

    DevOps teams are increasingly finding themselves caught between competing agendas. Many IT leaders are driving the adoption of platform engineering methodologies to centralize the management of DevOps workflows in the hopes of increasing developer productivity and reducing total costs. Conceptually, developers would prefer to have more backend processes managed by those teams, but not to the point where it forces them to use a development environment that has been defined for them. Each developer typically prefers to customize their development environment as the project evolves.

    Arguably, one of the primary reasons developers embrace DevOps is that it gives them more control over their development environments. The challenge is that as each team defines its own DevOps workflow, organizations often later discover they are licensing redundant DevOps tools and platforms.

    In the meantime, it’s not clear to what degree platform engineering might boost developer productivity. It no doubt will reduce the amount of time developers spend managing backend processes, but having that extra time doesn’t directly equate to better code being delivered faster. Writing code is as much an art as science, so it creates levels of inspiration that don’t always occur whenever a developer starts to write code. Instead, platform engineering creates more opportunities for inspiration to strike because they are not spending time on other tasks. At the very least, it should provide more time to run tests on the code that is produced.

    One way or another, as application development continues to evolve, most organizations will find the middle ground that best suits their needs. The challenge now is reducing the amount of time between now and when that goal is eventually achieved.