devopsy.kinsta.cloud

Category: Blogs

  • Life as Art

    Life as Art

  • Why AIOps Is Critical for Pandemic Business Recovery

    Why AIOps Is Critical for Pandemic Business Recovery

    As businesses worked to stay afloat over the last year, innovation in many areas fell behind. Business leaders struggled to understand the short-term and long-term impact the COVID-19 pandemic would have on their business, while employees worried about losing their jobs and customers scrambled to rearrange budgets. As we near the end and can finally see light at the end of the tunnel, business leaders are looking for ways to get back on track.

    Artificial intelligence for IT operations (AIOps) is the solution many businesses need to free up resources and return their focus to innovation. The data speaks for itself—the AIOps market was valued at $13.51 billion in 2020 and is expected to grow by more than 200% to $40.51 billion over the next five years. AIOps presents several benefits to enterprises, like automating mundane tasks, providing actionable reporting and improving risk management.

    But before IT leaders jump headfirst into adopting AIOps, there’s still one common misconception they must address: AIOps isn’t a solution, it’s a long-term strategy. AIOps simply cannot be viewed as a band-aid on the road to recovery. To truly maximize the benefits and bring innovation back to the center of business focus post-pandemic, teams must view AIOps as a long-term strategic investment.

    For IT teams looking to adopt an AIOps strategy, consider these three takeaways to jumpstart the journey and maintain it in the long term.

    Find a Partner to Offer Market Insight

    On the road to recovery, IT leaders may not have the time or bandwidth to truly invest what it takes to implement a robust AIOps investment strategy—let alone where to start. But working with a trusted, experienced partner who does have the time and resources to map out a plan and who keeps a close eye on market trends can help ease any struggles that IT leaders may face.

    A strategic partner can also help teams identify what tools IT teams already have in place that will support an AIOps strategy and which will stand in the way of it. Through a comprehensive tools rationalization process, IT teams have a better grasp of what tools they have in place, which are performing overlapping capabilities (in other words, increasing unnecessary costs) and what tools they still need to support their AIOps journey.

    The right partner can plot a path forward for IT leaders and give them peace of mind knowing they have an expert in their back pocket at all times.

    Identify Use Cases

    Use cases for AIOps may have changed over the course of the last year depending on a company’s place in the market, product focus and future growth plans. But as companies bring innovation back to the forefront, they must reevaluate their use cases for AIOps. If you’re an IT leader looking to invest in AIOps, ask yourself ‘Why?’ and determine precisely how AIOps can support that end goal. Your trusted partner can help by giving a different perspective that IT leaders may not have, simply because they are in the weeds day in and day out.

    Build a Plan and Execute

    With the right tools in place and a partner by your side, it’s time to lay out your complete AIOps investment plan with actionable steps in place. Consider the use cases you determined and your short- and long-term goals for AIOps as a starting point. Remember—this isn’t a plan with a definitive endpoint, but rather a strategy with definitive milestones that can help keep the business up and running and customers happy while maximizing internal processes.

    As IT leaders look ahead, they can regain confidence and feel empowered to bring innovation back to the business. No longer should they feel like they’re drowning in incidents and constantly putting out fires. With a long-term AIOps plan in place, IT teams are equipped to thrive post-pandemic and come out on the other side stronger than ever.

  • Modernizing Continuous Integration

    Modernizing Continuous Integration

    In the duality of continuous integration/continuous delivery (CI/CD), CI focuses on build automation. Leveraging CI practices for software delivery is normal for most organizations and can be seen as a solved problem. However, the demand for increasingly distributed applications has risen with the expansion of microservices, and development teams have the expectation that every commit should be a build.

    Continuous integration has, surprisingly, become an unexpected bottleneck with these expectations. To begin modernizing CI, it’s important to first understand some of the challenges. Let’s dig in.

    Challenges of Continuous Integration

    Given that build and release candidates follow advancements in development technology closely — such as new languages, packaging and paradigms in testing the artifact — expanding the capabilities in continuous integration implementations can be challenging. With the introduction of containerized technology, the firepower and velocity required to build greatly increased.

    Scaling Continuous Integration Platforms

    The infrastructure required to run a distributed CI platform can be as complex as the applications they are building because of the heavy compute requirements. Consider how much a local machine’s resources are tied up during a local build and test cycle. Now, multiply that by the number of folks on a team or in an organization and you start to understand just how much compute power is being used. Distributed build runners are just one area that can be complex, and managing when new build nodes are spun up and spun down can depend on the platform/end user.

    Keeping Up With the Technology Velocity

    The adage of “the only constant in technology is change” is true. New languages, platforms and paradigms are to be expected as technology pushes forward. The ease of including new technologies in a heterogeneous build or accepting new testing paradigms, however, can be difficult for more rigid CI platforms. These legacy platforms were designed for only a small subset of technologies. With legacy or rigid approaches, the dependency management required to maintain technical velocity becomes a significant burden.

    What it Takes to Modernize Continuous Integration

    The simplest way to change continuous integration practices and platforms is to take what I call the four-pillar approach: platform infrastructure modernization, engineering efficiency strategy, test optimization and rapid pipeline development. Making strides in any of these pillars will put you on the path toward modernizing your continuous integration platforms and practices. Making strides in all of the pillars will set up your DevOps teams for significant success.

    Platform Infrastructure Modernization

    The location where the actual builds and packaging take place (e.g. build nodes/runners) do most of the heavy lifting and have a fairly elastic workload nature. Builds (e.g. a JAVA JAR build) and packaging (e.g. a Docker Image Compose) are compute-heavy tasks. Once the build and packaging are complete, the runners can sit idle. This shows the importance of having an ephemeral build node. The build node spins up during the task, then spins down or is destroyed after the build task is done, so as to not drain resources.

    Engineering Efficiency Strategy

    A core tenet of engineering efficiency is meeting your internal customers where they are. For software engineers, this means being as close to their tools and projects as possible. Like many modern pieces of application infrastructure, shifting left to the developer means being included in the project structure in source code management (SCM).

    A common disconnect in CI platforms is dependency management. Over the past decade, for software engineers, this problem has been solved with package or build tools such as Maven, Gradle and NPM. Engineers need to simply define implicitly or explicitly what they need, and the dependencies will be resolved. Continuous integration tools can suffer from a disconnect, since we are leveraging several tools that potentially don’t have a common syntax. So, again, it’s important developers have close oversight on all the tools they need to complete their projects to reduce this friction.

    Test Optimization

    While initial confidence in getting tests into the CI pipeline expands, more tests — and sometimes inappropriate test coverage — is introduced by the ease of integration with the pipeline. An even harder problem to identify and rectify is flaky tests. A flaky test is one that both passes and fails periodically without any code changes. This becomes a twofold problem: increasing execution time and lack of confidence with flakiness. The most logical solution to avoid these issues is adding test optimization. A modern continuous integration solution should be able to visualize pipeline order, timings and overall execution to help identity (and eventually rectify) excessive coverage and flakiness.

    Rapid Pipeline Development

    Software is an exercise in iteration. The lower the barriers to entry for iteration to occur, the more gains in engineering efficiency and agility are achieved. Local builds happen dozens of times before reaching a committable stage, moving them forward to a dev-integration environment. It’s here where having a local environment is key. Oddly, most continuous integration pipelines are designed to run externally from a local machine. So, the ability to move to a local CI pipeline helps build confidence that the externally run pipeline will be successful.

    Continue on Your Continuous Integration Journey

    Continuous integration might seem like a solved problem for many organizations, but as with any technology, there is always room for improvement and modernization. Like any engineering efficiency paradigm, CI is a journey and the destination ever-evolving.

  • GitLab Acquires UnReview to Further AI Ambitions

    GitLab Acquires UnReview to Further AI Ambitions

    GitLab announced this week it has acquired UnReview, a provider of a tool that employs machine learning algorithms to identify which expert code reviewers to assign to a project based on both the quality of their previous efforts and current workloads.

    David DeSanto, senior director for product management at GitLab, said the acquisition of UnReview is the latest step in an AI strategy that, in addition to optimizing DevOps processes, will eventually unify machine learning operations (MLOps) and DevOps workflows.

    Accessed via the Dev section of the GitLab platform, UnReview will also be employed to manage the overall code review process.

    GitLab

    DeSanto said GitLab is committed to employing AI technologies to automate workflows and compressing cycle times across all stages of the DevSecOps life cycle. The goal is to not eliminate the need for DevOps teams, but rather eliminate low-level tasks that conspire to hamper productivity while at the same time improving application security, noted DeSanto.

    Providers of DevOps platforms are now locked into an AI arms race on two separate fronts. Each of them clearly sees the opportunity to leverage machine learning algorithms and other forms of AI to automate a wide range of processes. At the same time, it’s apparent providers of MLOps platforms are borrowing heavily from DevOps best practices to manage the development of AI models. However, from the perspective of a DevOps team, an AI model is just another type of software artifact. Rather than deploying two distinct platforms, the goal should be to bring the data scientists that build AI models into the larger DevOps community, said DeSanto.

    The current challenge, of course, is the pace at which DevOps and data science teams work. It may take six months or more for a data science team to construct and validate an AI model that needs to be embedded within an application. Aligning the timetable for an AI model with the application development life cycle is difficult to accomplish if neither team has any meaningful visibility into each other’s workflows. As the rate at which AI models can be developed steadily improves, that alignment issue will only become all the more pressing.

    Going forward, it’s hard to envision any application that won’t have some sort of AI model embedded within it. The issue is that, just like any other software artifact, an AI model needs to be updated. As new data sources become available, an AI model is likely to drift beyond the parameters intended. A rapid change in business conditions may also require the replacement of an entire AI model. The same processes that DevOps teams apply to update any software artifact can also be applied to an AI model.

    It’s unclear how long it will take before some type of convergence of DevOps and MLOps inevitably occurs, as organizations look for more efficient ways to manage what will become thousands of AI models. The one certain thing is the longer it takes to make the effort, the more difficult it will become to overcome the organizational inertia that has been allowed to set in.

  • Security Heroes Wanted: Join Our Virtual DevSecOps Conference Shifting Left 2.0 this June

    Security Heroes Wanted: Join Our Virtual DevSecOps Conference Shifting Left 2.0 this June

    Every year data shows us that technology is advancing faster than ever. In January of this year, DataReportal estimated that 4.66 billion people around the world use the internet: a 316 million increase since 2020. Now, with global internet penetration standing at 59.5%, it’s clear our world has changed, and application security is no exception. The ⅗ of the global population represented in DataReportal’s emphasizes just how many people rely on digital services to live and work. With this rapid change in technology practices and a steady upward trend in digital usage, it’s imperative that application security keeps up. Because if it doesn’t, the implications for poor code security could be detrimental.

     

    With everything accelerating at such an unprecedented rate, the question isn’t “will developers have a larger role in security,” rather “when will developers have a larger role in security?”

     

    We know this evolution is important and that it’s better to get started early than be late to the game. Which is why we’re hosting Shifting Left 2.0: a free two-day virtual conference aiming to bring together Modern Dev Teams, Application Security Gurus, and the developers who are ready to become security heroes. Be sure to stick around our Fireside Chat where we’ll discuss how to measure the success of your AppSec program and how AppSec-developer collaboration is key to AppSec success in an agile world.

     

    We have a great lineup of speakers and fireside chats that you won’t want to miss!

     

    Who will be speaking at the event?

    David Howell: Vice President, Zero North

    Erich Smith: Principal Security Engineer, JupiterOne

    Andra Lezza: Senior Application Security Engineer, Bulb [Fireside Chat]

    Paolo del Mundo: Head of Application Security, The MotleyFool [Fireside Chat]

    Adam Fletcher: CISO, Blackstone Group

    Dr. James Ransome: Chief Scientist, CyberPhos

    Shaleen Devgun: CIO, Schneider National

    Izak Mutlu: Ex-CISO, Salesforce

    David Estlick: CISO, Chipotle [Fireside Chat]

    Enrique Salem: Partner, Brain Capital [Fireside Chat]

    Stephen Scharf: CISO, DTCC [Fireside Chat]

    Stuart McClure: Ex-CEO, Cylance [Fireside Chat]

    Terence Runge: CISO, Reltio [Fireside Chat]

    Nikhil Gupta: Co-Founder & CEO, Armorcode

     

    What can attendees expect from this event?

    1. Connectivity to security experts: Learn from the people behind ShiftLeft and the industry’s top visionaries as they discuss the future of application security. You’ll be able to ask questions, chat one-on-one, and join panel sessions like our Fireside Chat. This is the perfect networking opportunity for any level of developer involved in modern security solutions. Take the opportunity to strengthen your connections, build confidence, and gain more knowledge of application security and its importance.
    2. Learn AppSec Best Practices: Hear directly from developers and security leaders as they discuss best practices for integrating security into CI/CD pipelines. Not only will developers be exposed to more security questions in the future, they’ll be asked to do things much faster than ever before. If you’re a developer tasked with incorporating modern security solutions into your workflows or an application security guru looking to learn, our event can help boost your technical skills and prepare you for intensive security situations you’ll face in the future.
    3. Product Roadmap and Industry Trends: Get an exclusive first look at upcoming releases and our take on the latest trends in application security. With application security changing constantly, this event poses an opportunity to gain a different perspective and see application security in a new light.

    Schedule

    June 22:

    9 am-9:30 am (PDT)

    Opening Keynote

    Manish Gupta – ShiftLeft

    9:35 am-10:05 am (PDT)

    The Need For Speed: Early and Accurate AppSec for the Modern SDLC

    Rob Lundy – ShiftLeft

    10:10 am – 10:40 am (PDT)

    AppSec Ecosystem

    10:45 am – 11:45 am (PDT)

    A Fireside Chat – Future of Application Security

    Manish Gupta – ShiftLeft

    11:45 am – 12:00 pm (PDT)

    Coffee Break

    12:00 pm – 12:30 pm (PDT)

    AppSec in Context

    1:05 – 2:05 pm (PDT)

    A Fireside Chat – How to Measure the Success of Your AppSec Program

    Arun Balakrishnan – ShiftLeft

    June 23:

    9 am – 9:30 am (PDT)

    Opening Keynote

    Chetan Conikee – ShiftLeft

    Fabian Yamaguchi – ShiftLeft

    9:35 am – 10:05 am (PDT)

    Incremental Data Flow Analysis with CPGS

    Fabian Yamaguchi – ShiftLeft

    10:10 am – 10:40 am (PDT)

    Intro to Code Analysis

    Vickie Li – ShiftLeft

    Suchakra Sharma – ShiftLeft

    10:45 am – 11:45 am (PDT)

    A Fireside Chat – State of the Art in AppSec

    Manish Gupta – ShiftLeft

    11:45 am – 12 pm (PDT)

    12:00 pm – 12:30 pm (PDT)

    HackSec: A Hacker’s PoV for Finding Source Code Weaknesses

    Chetan Conikee – ShiftLeft

    Suchakra Sharma – ShiftLeft

    12:34 pm – 1:35 pm (PDT)

    TBA

    When and where will the event be held?

    This free event will take place virtually from Tuesday June 22 – Wednesday June 23, 2021 from 9am-2pm PT.

    How can I register?

    1. Click here to get to the registration portal.
    2. Begin registration by providing your email and your registrant type (e.g. attendee).
    3. Provide some essential information.
    4. Get your confirmation and mark your calendar.
  • No-Nonsense Guide to Distributed Databases

    No-Nonsense Guide to Distributed Databases

    I got my first DBA job 15 years ago, and quite a few things have changed since then. The amount of data exploded, we saw the rise of NoSQL, and business logic moved away from being stored in relational databases to applications.

    To this day, the three pillars of reliability, scalability, and maintainability are the banes of a DBA’s existence. To spice things up, your monthly cloud bill for managed databases just made your CTO lose the will to live.

    So, now you have two extra things to worry about in addition to these three pillars: cost efficiency and vendor-agnosticism.

    In this article, I’ll (try to) run an open source, new-generation database, benchmark it and touch on some of the challenges of being cloud-neutral.

    TL;DR

    • Solving the SQL vs. NoSQL dilemma in the Kubernetes world
    • How to leverage a distributed SQL database in a multi-cloud world
    • Taming performance – single cloud versus multi-cloud
    • Running TPC-C as a transactional benchmark
    • Taming the costs – the question of egress costs

    New Packaging For a New Age

    Just five years ago, people were like, “Containerizing stateless microservices? Sure! No problem.”

    But when you actually containerize a database, your persistence layer is asking for trouble.

    Over time, containers grew on us. Now, it’s the default way of packaging and shipping software. Heck, even AWS Lambda caved and started running container images. Databases just couldn’t resist.

    Once a database is containerized – say, a PostgreSQL database – Kubernetes takes over dealing with some of the more painful aspects of reliability and maintainability (with the help of middleware-specific operators).

    Containers decouple data from the runtime, so upgrades and configuration are easier through infrastructure-as-code (YAML). Hardware failure and maintenance windows are covered by Kubernetes’ built-in capability to reschedule pending pods on surviving nodes. Full scheduled backups or point-in-time recovery are in the hands of the operator’s automation.

    But what about scalability?

    Kubernetes’ vertical pod autoscaler can adjust container resources, deleting and recreating pods with new resource settings. As a traditional relational database, PostgreSQL can have only one primary replica that writes data. This means that you’ll be facing a  short downtime while the new pod comes online. The majority of workloads are about five times oversized, so while sizing is painful, it’s better than no sizing at all (please, have mercy on your CTO’s budget).

    NoSQL has none of these limitations. Databases like Cassandra were built for scaling horizontally without downtime.

    Enter Distributed SQL

    What if we could blend Google Spanner’s ability to operate at distances with strong ACID consistency, Cassandra’s scaling and PostgreSQL compatibility?

    This is where YugabyteDB helps.

    YugabyteDB is an open source, relational, distributed SQL database management system. It was designed to handle large amounts of data across multiple availability zones and geographic regions, all the while delivering single-digit latency, high availability and no single point of failure.

    I hate when the new kid on the block brings their own syntax language because, you know, their case is so very special – just like everybody else’s.

    Yugabyte doesn’t do that. They have a wicked-smart storage layer (inspired by Google Spanner) that reuses the PostgreSQL query engine. This means no mental strain on the development team – you get to use the time-tested, marketable and incredibly powerful PostgreSQL language-level features that many are already comfortable with.

    If Google Spanner is so inspiring, why is it not taking over the world of distributed SQL? Well, it’s available only as SaaS, and heavily depends on the specifics of Google Cloud hardware like atomic clocks (trueTime) and Google’s backbone network. If your private data center or favorite cloud provider is not GCP – well, no Spanner for you, my friend. Personally, I’d be hesitant to marry into the ultimate vendor lock-in. Yugabyte doesn’t have any dependencies and would happily run on any cloud, private data center, VM or bare metal – and if your coffee machine runs Docker containers, you can run Yugabyte there, as well.

    If Yugabyte is robust, scalable and easily maintainable, you have the top three pillars covered. But what about the other two pillars your CTO is nagging you about (cost efficiency and a vendor-agnostic approach)?

    How to Make Your Database Vendor-Agnostic

    Being vendor-agnostic means being able to switch between major cloud providers at any point without depending on prohibitively expensive services like DynamoDB. This approach also allows you to leverage inefficiencies in cloud pricing so you can look for new opportunities to reduce cost and dynamically shift resources between cloud providers online.

    This is something CAST AI can do.

    The CAST AI platform acts as a cloud abstraction and makes the whole multi-cloud, vendor-agnostic requirement quite trivial.

    Developers just interact with standard Kubernetes (no CRDs), and the complexity of several clouds is abstracted. A Kubernetes cluster in CAST AI can span across several cloud providers at the same time, bringing some unique cost optimization opportunities.

    What if spot/preemptible instance interruption wasn’t totally random anymore, but something you could actually predict? You could be proactive and—by operating in several compute bidding markets at the same time—reduce the risk of running out of capacity.

    Why not slash your monthly cloud bill radically by running some of the database containers on spot/preemptible nodes?

    Highly Available Stateful Application on Multi-Cloud

    Yugabyte on a multi-cloud CAST AI Kubernetes cluster is a robust design without a single point of failure.

    Active/Passive solutions are so ’90s—failovers cause brief downtime, and DBAs tend to leave the failover to be manually initiated due to occasional short-lived network blips. Active/Passive solutions constantly require testing and validation. Will your disaster recovery work on darker days? Because these tests cause downtime, nobody does them regularly.

    The best highly available solutions are active-active, don’t require user failover, and don’t rot if not tested regularly.

    CAST AI has a tutorial in place that takes you through every step of building the above solution in about 10 minutes, from scratch.

    Go ahead, open your cloud provider’s console and release your inner chaos monkey by killing Yugabyte, business app pods or whole Kubernetes nodes.

    CAST AI, Yugabyte, and Kubernetes were built with a core tenet that nothing is guaranteed; nothing should be shared. But keep in mind, consensus algorithms work when there’s still a majority left to vote N/2 + 1.

    You may be asking, what’s the performance impact of increasing resiliency when going multi-cloud with a distributed database?

    Let’s find out.

    Let’s benchmark a distributed Yugabyte database on top of CAST AI Kubernetes spanning AWS and GCP. These cloud providers are arbitrary choices here; Azure or DigitalOcean can be used in the mix, as well. We picked GCP and AWS because their VMs boot up a bit faster.

    Mono-Cloud Vs. Dual-Cloud Network Benchmark Results

    Let’s compare a Yugabyte containerized database on Kubernetes in a single-cloud scenario versus a distributed database working in two different clouds.

    Setup

    We took the OSS Yugabyte HELM chart with the image version “2.5.1.0” with the replication factor of 3.

    Role

    YB-Master

    YB-Tserver

    Description

    Control plane, consensus

    Serves data

    CPU

    3 CPUs

    7 CPUs

    RAM

    3 GiB

    14 GiB

    Storage

    50 GiB

    300 GiB

    Remote Network Block storage:

    • EBS gp2 (300 IOPs)
    • Standard persistent disk (R225/W450 IOps)

    Nine pods, each on a separate VM to ensure plenty of resources:

    Mono Cloud

    Regional GKE k8s cluster with 9x GCE N2d-standard-8 distributed in three availability zones. Casual VPC network in Google’s US-East4 region.

    Dual Cloud

    AWS EC2 3x c5a.2xlarge

    GCP GCE 6x n2d-standard-8

    A network between cloud providers set up with a Wireguard-based full mesh VPN that encrypts traffic end-to-end (also inside the same VPC).

    To minimize noise from compute and local storage efficiency, we didn’t optimize for cost but wanted to isolate and better understand how distributed databases would work in situations where database nodes are distributed single-digit milliseconds away (in this example, less than 9 ms).

    Nine milliseconds of network round trip latency means a lot of flexibility in choosing between data center providers distributed within a few hundred miles.

    The majority of cloud provider regions lack imagination and are clustered in the geographic vicinity of a densely populated metropolis. California, northern Virginia, Montreal, São Paulo, London, Frankfurt, Amsterdam, Mumbai, Tokyo, Singapore, Sydney, etc.

    So, what are your options in, say, Frankfurt? AWS, Azure, GCP, DigitalOcean, Oracle, Alibaba, IBM Cloud, Hetzner, Linode—not to mention the white-label providers.

    We carried out tests on U.S. East (Ashburn) and Europe Central (Frankfurt) with similar results.

    How We Measured It

    If we want to test relational database performance – the gold standard ruler to date is a synthetic TPC-C benchmark.

    Why did we choose that? Because it’s the most mature OLTP benchmarking test suite that has stood the test of time. As stated here:

    “While the benchmark portrays the activity of a wholesale supplier, TPC-C is not limited to the activity of any particular business segment, but, rather represents any industry that must manage, sell, or distribute a product or service.”

    We loaded an identical Yugabyte configuration in both scenarios with 300 warehouses worth of data and then ran benchmarks several times.

    Each test took half an hour, and the output was the single most important metric: transactions per minute. The test also provided different outputs per type of transaction, average and 99th percentile duration in milliseconds.

    Results

    This table shows a comparison of TPC-C results with the average duration for a single cloud on Google and AWS + Google in the same region, US-East.

    300 warehouses

    Mono Cloud

    Dual Cloud

    Num New Order transactions per 1800 s

    113,071

    113,247

    TPM-C

    3,769

    3,774

    Efficiency

    97.6%

    97.8%

    NewOrder Latency avg msec

    580.2

    498.8

    Payment Latency avg msec

    30.8

    46.7

    OrderStatus Latency avg msec

    33.8

    32.4

    Delivery Latency avg msec

    123.1

    174.9

    StockLevel Latency avg msec

    239.4

    465

    And comparing the 99th percentile:

    300 warehouses

    Mono Cloud

    Dual Cloud

    NewOrder Latency  p99 msec

    6985.6

    5498.7

    Payment Latency p99 msec

    110.5

    157.5

    OrderStatus Latency p99 msec

    146.3

    185.1

    Delivery Latency p99 msec

    331.5

    696.8

    StockLevel Latency p99 msec

    712.3

    1083.3

    As you can see, the difference between the mono cloud and dual cloud scenarios is quite small.

    Some operations, like OrderStatus, are plain read operations. The nearest server can quickly respond with data to the client—usually, a microservice running on the same K8s cluster.

    Yugabyte’s lowest isolation level is a snapshot. This means that those reads are protected from the undesirable effect of the “dirty read.”

    What about writes?

    Writes are a bit more expensive. Raft consensus, hybrid logical clocks and lockless multi-version concurrency control (MVCC) algorithm magic—all of this means a lot more chatter and replication between nodes to get write committed.

    We see that, in payment and delivery operations duration (30ms vs. 46ms and 123ms vs. 174ms, respectively) the geographic distances start to be noticeable.

    The actual network latency between nodes in different availability zones in the mono cloud scenario without network overlay and encryption is, on average, about 0.6ms. Network latency between two clouds with overlay (VXLAN) and encryption (Wireguard) is about 5ms.

    The laws of physics aren’t going away anytime soon. But as we can see, the results are much better than expected.

    YMMV, but industry accepted norm is that the majority of IO operations will be reads, at 70%; only remaining 30% writes, reducing the impact of speed of light even further.

    Having said that, the gold standard for measuring OLTP database performance for the last two decades says that performance results are identical (TPM-C 3’769 vs. 3’774).

    Data Gravity and Egress Costs

    Data gravity refers to a scenario where compute gravitates closer to data.

    For example, if you have a hybrid cloud or multi-cloud strategy but your data stays in a single location like an on-premises data center. Most of the compute with stateless services will tend to stay in the same data center, closer to data.

    The whole point of multi-cloud and a high-performing distributed database was to get rid of data gravity. If we have the same data on two or more clouds, then the data gravity effect disappears.

    If all your data is replicated to several locations, what about network traffic costs?

    All cloud providers allow unlimited incoming (ingress) data. It doesn’t matter where data is coming from—if it’s your on-premises data center, a different cloud provider, the dark web or most cloud-native services. All the incoming data is free.

    “You can bring as much data as you want to us. But if you want to take your data back – sorry, you need to pay.” This is universal between all cloud providers. All the outgoing (egress) traffic from your availability zone is paid! Some cloud providers, like Oracle Cloud, are very generous with egress costs, and companies like Zoom saved a ton of money when they moved some of Zoom’s infrastructure to Oracle Cloud.

    DigitalOcean gives a generous egress monthly allowance per Droplet (VM), depending on size and how long you run it. But, at a minimum, it starts at Terabyte per smallest Droplet. The monthly egress allowance is aggregated in your account, and you pay only for the combined extra.

    All clouds have some minimal free tier—but in general, egress costs start at around 10 cents per GB of data sent outside VPC, and, on average, 2 cents for data between availability zones in the same VPC (I bet you didn’t know that you pay 1cnt/GB in AWS and Azure for incoming traffic coming from same VPC/Vnet from another AZ).

    If you send more traffic, your cost per GB falls. The first drop is at 10TB and generally flattens at around 5 cents at ~150TB.

    How does it make you feel when cloud providers charge an eye-watering 97% margin on that egress traffic? It’s like we’re back in 1995 with dial-up modems, right?

    There is a more cost-effective alternative. But first, let’s answer the ‘Will it Blend?’ question. Let’s add Direct Connect, Express Route, Cloud Interconnect and Layer 2 or Layer 3 providers like Equinix or Megaport. Yes, you get a Dedicated Fiber Link smoothie out of the blender.

    Dedicated fiber link slashes costs to a mere 2 cents per GB. And if you have more egress traffic than 7TB, it’s more cost-effective than relying on the weird discount models from cloud providers.

    You might be thinking, “2 cents for every GB?! That’s way too much! I’m using RDS—yes, I have vendor lock-in and data gravity—but at least I have none of the problems with egress cost, resilience, scalability and overall affordability of the service, right?”

    That’s just the result of an opaque billing design.

    https://twitter.com/QuinnyPig/status/1372598432095891458

    All the traffic between Availability Zones in all clouds is paid at 2 cents per GB of egress+ingress. The only place where you pay for ingress is between Availability Zones in the same region (AWS/Azure). Some managed services offer free replication, but they charge double on compute costs, etc.

    Through the ServiceTopology feature, Kubernetes can keep your application pod’s traffic inside the same cloud service provider Availability Zone and cloud, to avoid round robin, random calls between clouds. This means that you get the best latency and pay no traffic premium.

    Most of the database activity is reads (70/30, YMMV) and are effectively free, egress-wise (coming from the local AZ due to the Kubernetes topology awareness). So, the only thing you replicate and subject to egress costs is your database change delta rate per month.

    Now you can see that the issue of egress costs is an incredibly overstated problem.

    The overwhelming push to the public cloud over the last decade brought on new challenges like vendor lock-in, data gravity and eye-watering monthly infrastructure bills.

    During that time, innovation in non-traditional RDBMS, containerization and workload scheduling removed some of the old barriers.

    Running a hands-free, strongly consistent, highly available and scalable database in heterogeneous data centers on a budget was a monumental task a decade ago. Today, it has become an affordable best practice for running our business applications.

  • How Low-Code/No-Code Can Transform Your Organization

    How Low-Code/No-Code Can Transform Your Organization

    For many companies, IT transformation is no small feat. Between the technology, process and organizational changes needed, it can take time to see a return on your IT transformation efforts and investments. So it’s no surprise that low-code/no-code is starting to be seen as a compelling solution for some.

    With low-code/no-code, you can empower teams of ‘citizen developers’ and enable experienced developers to accelerate deployment and reduce IT backlogs. To gain insights on the ways that low-code/no-code can transform your organization, I asked several DevOps Institute Ambassadors for their thoughts. Here’s what they said:

    Brendan O’Reilly, DevOps Specialist, Daysha DevOps

    Low-code/no-code introduces urgency into an organization. By removing the bottleneck that is scarce development resources, you can reduce the lead time to value.

    Mark Peters, Technical Lead, Novetta

    Low-code situations are likely best for highly tailored situations, with clearly defined purposes and minimal changes. Low-code can work when your business depends on scaling rather than creating new code. If the business is good enough, and one is adding microservices or more instances of the same expanded for a larger market, low-code can be perfect. Implementing low-code then allows the next opportunity to move from some code to no-code, providing a graphical interface to change architecture, implement policy or change recurring controls through mouse clicks rather than code. This also provides an excellent chance for improved ops control; if one is scaling the number of users, controls can be implemented to ensure the graphical delivery does not hard-code a password into the system, instead of relying on approval checks within an alternative interface.

    Vishnu Vasudevan, Head of Product Engineering and Development, Opsera

    When an organization practices DevOps, they continuously expand by team, product, platform and application because of different solutions coming into the market. Incorporating a low-code/no-code approach gives enterprises the ability to speed time-to-market and expand engineering capabilities beyond IT.

    If you have a low-code platform that can help manage and provide visibility into technology and security compliance, that’s a gold mine for any developers or any organization. For example, anytime a new application comes in, teams can use a template from the previous application and put it over the new application. The same security quality of the audit governance is quickly established as a baseline, and all the developers have to do is focus on coding.

    Shriniwas Sathe, DevOps Chief Architect and CoE Leader at Capgemini

    Low-code/no-code tools can help change the way that regular employees interact with technology. With no-code tools, every employee, regardless of their background, can create custom applications, websites, forms, etc. With low-code tools, this can be taken a step further by building upon the offerings of a no-code tool by coding in the unique features needed by the organization. This is much less time-consuming compared to traditional development processes, even though it requires a general know-how of coding.

    With every employee able to contribute to new applications and tools, there’s a better chance of obtaining unique insights and unforeseen capabilities. You can also simplify processes to an extent where regular employees can benefit from the freedom from tedious and repetitive tasks. There are low-code/no-code tools for most industries, which gives you a choice of either a ready-made solution or one that can be customized to your particular requirements.

    Peter Maddison, Founder, Xodiac, Inc.

    Low-code development platforms are great at automating important procedures using drag-and-drop editors that allow citizen developers to create virtual models of an app’s business logic and user interface.

    A major advantage of having an enterprise no-code platform is the presence of built-in governance capabilities. No matter what an IT team’s size, a central console offers visibility for all applications and environments so that they can keep track of any issues or vulnerabilities.

    Business developers can use the solution to create applications that fit their unique business needs. And more than one developer, or a team of developers, can work on the same module at the same time.

    Of course, we need to ensure we are providing appropriate guard rails so our citizen developers are not able to accidentally expose data or create additional risks through the solutions they create.

    If you’d like to learn more about the latest in low-code/no-code and similar topics, check out the upcoming SKILup Day schedule. Or, learn more about the benefits of becoming a DevOps Institute Member.

  • A Funny Thing Happened On the Way to API Management

    A Funny Thing Happened On the Way to API Management

    As API use has exploded across IT departments large and small, the need to manage APIs as independent entities—both APIs themselves and calls to them—rapidly became apparent. We have been through this cycle several times before–ORBs, DCOM, object repositories … the list goes on.

    There are several competing goals when introducing some management structure into formerly as-needed remote calls occurs. We want to publish and advertise connections in the hopes we can avoid (or at least minimize) reinventing the wheel, while we also want to make access easier for app developers that are trying to use our APIs. Meanwhile, we want a centralized location where ops can monitor API usage, security can review APIs for compliance and “approved” APIs can be advertised or even hosted. Finally, we want to give internal developers access to approved external APIs that have been deemed appropriate and safe for the organization to use.

    As with previous iterations of this process, these goals, taken together, prove to be huge. There is a lot there to try and cover in an ever-changing API landscape. It is worse in this iteration, simply because of the proliferation of external APIs. Prior to REST, each iteration had more APIs, both internal and external, than the one before, and REST is keeping with that pattern, though now that we can look back, the external bit is a hyperbolic curve, not a line.

    So, it is interesting and cool to see the market fragmenting a bit. The entire package is a huge order that a few companies have taken on; I’ll leave it to you to decide if they’ve handled it well enough for your org. Others have taken one of two approaches—centralizing API access to external services that have been vetted and interfaced with by the vendor or enabling internal API developers and users.

    Now, we have a couple of manageable chunks to look into. I would even go so far as to say most vendors come from one or the other of these worldviews, and you should compare their “tilt” to your organization’s needs before purchasing an API management product. I would much prefer if we separated these markets into ‘API management’–those doing (or trying to do) it all, ‘API integration’–those simplifying and enabling access to approved APIs like Salesforce or ADP and ‘API enablement–those making writing, publishing, securing and advertising internal APIs easier. But I don’t get to make these calls, so we’ll have to watch it unfold.

    If your need is to streamline and protect your organization’s access to external platforms, and you use many popular services, start with API integration. If you need to get a handle on APIs that you are creating and using internally, start with API enablement. If you need both, and a centralized store of approved APIs regardless of source, look to API management. APIs have become central to our development efforts, and there will only be more of them in the future, so it is worth deciding where your org could use help and set out to research your options.

    Of course, you’re rocking it. DevOPs isn’t letting DEVops poke too many holes in the firewall; DEVops is cranking out solutions and devOPs is keeping them alive. This is just another tool to keep things on an even keel as more and more of the organization’s development is API-based.

  • Half a Decade

    Half a Decade

  • Cribl Automates Observability Efforts

    Cribl Automates Observability Efforts

    Cribl today announced it has updated the Cribl LogStream observability tool in addition to generally making available a software-as-a-service (SaaS) offering dubbed LogStream Cloud.

    Nick Heudecker, senior director for market strategy and competitive intelligence at Cribl, said Cribl LogStream provides the means to aggregate log data collected from multiple platforms and applications in a format any observability or monitoring tool can access.

    The challenge with observability platforms today is they leave it up to IT organization to copy and paste data into the platform. LogStream automates that process via a log router that collects and optimizes data streams from existing installed agent software and then shapes and routes that data on to analytics platform.

    Version 3.0 adds LogStream Packs, a framework for accelerating deployments of the log router. Alternatively, DevOps teams can employ LogStream Cloud to build and share LogStream configuration models.

    Heudecker said the goal is to reduce the cost of achieving observability by reducing the time and effort required to set up and manage data pipelines. No customization effort on the part of a DevOps team is required to collect and send data from hundreds of sources to any number of destinations, noted Heudecker.

    While observability is a core DevOps tenet, achieving it has been a major challenge. In addition to deploying and managing agent software to instrument IT environments, there’s a significant amount of time and data engineering effort needed to set up the pipelines employed to transfer data to a platform where it can be analyzed. Cribl is making a case for automating those data engineering tasks using a tier of software that abstracts data into a format that can be consumed by multiple observability and monitoring platforms.

    It’s not clear yet to what degree IT organizations perceive observability to be an evolution of monitoring, or simply the next logical evolution of monitoring. One way or another, IT teams need a lot more context than they have historically been able to attain using legacy monitoring tools. Each platform employed within an enterprise typically comes with its own monitoring tools that are used by the IT teams tasked with managing it. Whenever there is an issue, however, IT teams will spend hours correlating data from multiple tools to ascertain the root cause of a problem.

    Observability platforms promise to reduce that time and effort by applying analytics to data collected from multiple platforms. The challenge now is finding a way to efficiently collect all that data.

    It may be a while before IT organizations start to abandon all the monitoring tools they have in place in favor of observability platforms. However, as IT environments continue to become more complex (thanks, in part, to the rise of cloud-native computing platform based on microservices) the need for those platforms becomes more acute. The issue is enabling DevOps teams to achieve that goal without having to wait for an overworked data engineer to find the time to build a pipeline.