Alternatives to CloudBolt logo

Alternatives to CloudBolt

Scalr, Morpheus, Terraform, RightScale, and Ansible are the most popular alternatives and competitors to CloudBolt.
6
16
+ 1
0

What is CloudBolt and what are its top alternatives?

Deploys in minutes. Simple to use. Easy to extend. Centralize workload automation and orchestration, achieve unparalleled hybrid cloud visibility and cost-savings, and deliver self-service IT for your developers.
CloudBolt is a tool in the Multi Cloud Management category of a tech stack.

Top Alternatives to CloudBolt

  • Scalr
    Scalr

    Scalr is a remote state & operations backend for Terraform with access controls, policy as code, and many quality of life features. ...

  • Morpheus
    Morpheus

    Morpheus is a cloud application management and orchestration platform that works on any cloud or infrastructure, from AWS to bare metal. Enjoy complete cloud freedom with Morpheus. ...

  • Terraform
    Terraform

    With Terraform, you describe your complete infrastructure as code, even as it spans multiple service providers. Your servers may come from AWS, your DNS may come from CloudFlare, and your database may come from Heroku. Terraform will build all these resources across all these providers in parallel. ...

  • RightScale
    RightScale

    Automation is the core of RightScale, freeing you to run efficient, scalable, and highly-available applications. Our multi-cloud integration enables you to choose your own clouds, providing freedom to work with any vendor in a rapidly changing market. And rest assured knowing that you have visibility and control over all of your resources in one place. To take advantage of best practices, we encourage you to tap into cloud expertise provided by our service, support, and partner networks when building and managing your infrastructure. ...

  • Ansible
    Ansible

    Ansible is an IT automation tool. It can configure systems, deploy software, and orchestrate more advanced IT tasks such as continuous deployments or zero downtime rolling updates. Ansible’s goals are foremost those of simplicity and maximum ease of use. ...

  • New Relic
    New Relic

    The world’s best software and DevOps teams rely on New Relic to move faster, make better decisions and create best-in-class digital experiences. If you run software, you need to run New Relic. More than 50% of the Fortune 100 do too. ...

  • Kibana
    Kibana

    Kibana is an open source (Apache Licensed), browser based analytics and search dashboard for Elasticsearch. Kibana is a snap to setup and start using. Kibana strives to be easy to get started with, while also being flexible and powerful, just like Elasticsearch. ...

  • Grafana
    Grafana

    Grafana is a general purpose dashboard and graph composer. It's focused on providing rich ways to visualize time series metrics, mainly though graphs but supports other ways to visualize data through a pluggable panel architecture. It currently has rich support for for Graphite, InfluxDB and OpenTSDB. But supports other data sources via plugins. ...

CloudBolt alternatives & related posts

Scalr logo

Scalr

20
26
Scalr is a remote state & operations backend for Terraform with access controls and policy as code
20
26
PROS OF SCALR
  • 5
    Image Builder
  • 3
    Open Source
  • 3
    Auto Scaling
  • 2
    Orchestration
  • 2
    Multi-Cloud Support
  • 2
    Cost Analytics
  • 2
    Chef Integration
  • 2
    Hybrid Cloud Management
  • 2
    User Friendly
  • 1
    Terraform CLI Integration
  • 1
    Open Policy Agent
  • 1
    Cost
CONS OF SCALR
    Be the first to leave a con

    related Scalr posts

    Morpheus logo

    Morpheus

    32
    18
    Orchestrate, Automate, and Manage Across Any Cloud
    32
    18
    PROS OF MORPHEUS
    • 2
      Easy to deploy and use
    • 1
      Hybrid Cloud Management
    • 1
      Life cycle management
    • 1
      App provisioning
    • 1
      UI, API and CLI
    • 1
      Governance
    • 1
      SDN - ACI, NSX, Neutron
    • 1
      Config Management-Chef,Puppet,Salt,Ansible,AnsibleTower
    • 1
      Reporting
    • 1
      Analytics
    • 1
      Scheduling
    • 1
      Tagging, Env variables, cypher
    • 1
      Automation - Tasks and Workflows
    • 1
      Image builder
    • 1
      Infrastrcuture as Code
    • 1
      Platform as a Service
    • 1
      Infrastructure as Code, Platform as a Service
    CONS OF MORPHEUS
      Be the first to leave a con

      related Morpheus posts

      Terraform logo

      Terraform

      18.5K
      344
      Describe your complete infrastructure as code and build resources across providers
      18.5K
      344
      PROS OF TERRAFORM
      • 121
        Infrastructure as code
      • 73
        Declarative syntax
      • 45
        Planning
      • 28
        Simple
      • 24
        Parallelism
      • 8
        Well-documented
      • 8
        Cloud agnostic
      • 6
        It's like coding your infrastructure in simple English
      • 6
        Immutable infrastructure
      • 5
        Platform agnostic
      • 4
        Extendable
      • 4
        Automation
      • 4
        Automates infrastructure deployments
      • 4
        Portability
      • 2
        Lightweight
      • 2
        Scales to hundreds of hosts
      CONS OF TERRAFORM
      • 1
        Doesn't have full support to GKE

      related Terraform posts

      Context: I wanted to create an end to end IoT data pipeline simulation in Google Cloud IoT Core and other GCP services. I never touched Terraform meaningfully until working on this project, and it's one of the best explorations in my development career. The documentation and syntax is incredibly human-readable and friendly. I'm used to building infrastructure through the google apis via Python , but I'm so glad past Sung did not make that decision. I was tempted to use Google Cloud Deployment Manager, but the templates were a bit convoluted by first impression. I'm glad past Sung did not make this decision either.

      Solution: Leveraging Google Cloud Build Google Cloud Run Google Cloud Bigtable Google BigQuery Google Cloud Storage Google Compute Engine along with some other fun tools, I can deploy over 40 GCP resources using Terraform!

      Check Out My Architecture: CLICK ME

      Check out the GitHub repo attached

      See more
      Emanuel Evans
      Senior Architect at Rainforest QA · | 20 upvotes · 1.6M views

      We recently moved our main applications from Heroku to Kubernetes . The 3 main driving factors behind the switch were scalability (database size limits), security (the inability to set up PostgreSQL instances in private networks), and costs (GCP is cheaper for raw computing resources).

      We prefer using managed services, so we are using Google Kubernetes Engine with Google Cloud SQL for PostgreSQL for our PostgreSQL databases and Google Cloud Memorystore for Redis . For our CI/CD pipeline, we are using CircleCI and Google Cloud Build to deploy applications managed with Helm . The new infrastructure is managed with Terraform .

      Read the blog post to go more in depth.

      See more
      RightScale logo

      RightScale

      19
      0
      Manage all of your cloud infrastructure with a single, integrated solution.
      19
      0
      PROS OF RIGHTSCALE
        Be the first to leave a pro
        CONS OF RIGHTSCALE
          Be the first to leave a con

          related RightScale posts

          Ansible logo

          Ansible

          19.2K
          1.3K
          Radically simple configuration-management, application deployment, task-execution, and multi-node orchestration engine
          19.2K
          1.3K
          PROS OF ANSIBLE
          • 284
            Agentless
          • 210
            Great configuration
          • 199
            Simple
          • 176
            Powerful
          • 155
            Easy to learn
          • 69
            Flexible
          • 55
            Doesn't get in the way of getting s--- done
          • 35
            Makes sense
          • 30
            Super efficient and flexible
          • 27
            Powerful
          • 11
            Dynamic Inventory
          • 9
            Backed by Red Hat
          • 7
            Works with AWS
          • 6
            Cloud Oriented
          • 6
            Easy to maintain
          • 4
            Vagrant provisioner
          • 4
            Simple and powerful
          • 4
            Multi language
          • 4
            Simple
          • 4
            Because SSH
          • 4
            Procedural or declarative, or both
          • 4
            Easy
          • 3
            Consistency
          • 2
            Well-documented
          • 2
            Masterless
          • 2
            Debugging is simple
          • 2
            Merge hash to get final configuration similar to hiera
          • 2
            Fast as hell
          • 1
            Manage any OS
          • 1
            Work on windows, but difficult to manage
          • 1
            Certified Content
          CONS OF ANSIBLE
          • 8
            Dangerous
          • 5
            Hard to install
          • 3
            Doesn't Run on Windows
          • 3
            Bloated
          • 3
            Backward compatibility
          • 2
            No immutable infrastructure

          related Ansible posts

          Tymoteusz Paul
          Devops guy at X20X Development LTD · | 23 upvotes · 10.2M views

          Often enough I have to explain my way of going about setting up a CI/CD pipeline with multiple deployment platforms. Since I am a bit tired of yapping the same every single time, I've decided to write it up and share with the world this way, and send people to read it instead ;). I will explain it on "live-example" of how the Rome got built, basing that current methodology exists only of readme.md and wishes of good luck (as it usually is ;)).

          It always starts with an app, whatever it may be and reading the readmes available while Vagrant and VirtualBox is installing and updating. Following that is the first hurdle to go over - convert all the instruction/scripts into Ansible playbook(s), and only stopping when doing a clear vagrant up or vagrant reload we will have a fully working environment. As our Vagrant environment is now functional, it's time to break it! This is the moment to look for how things can be done better (too rigid/too lose versioning? Sloppy environment setup?) and replace them with the right way to do stuff, one that won't bite us in the backside. This is the point, and the best opportunity, to upcycle the existing way of doing dev environment to produce a proper, production-grade product.

          I should probably digress here for a moment and explain why. I firmly believe that the way you deploy production is the same way you should deploy develop, shy of few debugging-friendly setting. This way you avoid the discrepancy between how production work vs how development works, which almost always causes major pains in the back of the neck, and with use of proper tools should mean no more work for the developers. That's why we start with Vagrant as developer boxes should be as easy as vagrant up, but the meat of our product lies in Ansible which will do meat of the work and can be applied to almost anything: AWS, bare metal, docker, LXC, in open net, behind vpn - you name it.

          We must also give proper consideration to monitoring and logging hoovering at this point. My generic answer here is to grab Elasticsearch, Kibana, and Logstash. While for different use cases there may be better solutions, this one is well battle-tested, performs reasonably and is very easy to scale both vertically (within some limits) and horizontally. Logstash rules are easy to write and are well supported in maintenance through Ansible, which as I've mentioned earlier, are at the very core of things, and creating triggers/reports and alerts based on Elastic and Kibana is generally a breeze, including some quite complex aggregations.

          If we are happy with the state of the Ansible it's time to move on and put all those roles and playbooks to work. Namely, we need something to manage our CI/CD pipelines. For me, the choice is obvious: TeamCity. It's modern, robust and unlike most of the light-weight alternatives, it's transparent. What I mean by that is that it doesn't tell you how to do things, doesn't limit your ways to deploy, or test, or package for that matter. Instead, it provides a developer-friendly and rich playground for your pipelines. You can do most the same with Jenkins, but it has a quite dated look and feel to it, while also missing some key functionality that must be brought in via plugins (like quality REST API which comes built-in with TeamCity). It also comes with all the common-handy plugins like Slack or Apache Maven integration.

          The exact flow between CI and CD varies too greatly from one application to another to describe, so I will outline a few rules that guide me in it: 1. Make build steps as small as possible. This way when something breaks, we know exactly where, without needing to dig and root around. 2. All security credentials besides development environment must be sources from individual Vault instances. Keys to those containers should exist only on the CI/CD box and accessible by a few people (the less the better). This is pretty self-explanatory, as anything besides dev may contain sensitive data and, at times, be public-facing. Because of that appropriate security must be present. TeamCity shines in this department with excellent secrets-management. 3. Every part of the build chain shall consume and produce artifacts. If it creates nothing, it likely shouldn't be its own build. This way if any issue shows up with any environment or version, all developer has to do it is grab appropriate artifacts to reproduce the issue locally. 4. Deployment builds should be directly tied to specific Git branches/tags. This enables much easier tracking of what caused an issue, including automated identifying and tagging the author (nothing like automated regression testing!).

          Speaking of deployments, I generally try to keep it simple but also with a close eye on the wallet. Because of that, I am more than happy with AWS or another cloud provider, but also constantly peeking at the loads and do we get the value of what we are paying for. Often enough the pattern of use is not constantly erratic, but rather has a firm baseline which could be migrated away from the cloud and into bare metal boxes. That is another part where this approach strongly triumphs over the common Docker and CircleCI setup, where you are very much tied in to use cloud providers and getting out is expensive. Here to embrace bare-metal hosting all you need is a help of some container-based self-hosting software, my personal preference is with Proxmox and LXC. Following that all you must write are ansible scripts to manage hardware of Proxmox, similar way as you do for Amazon EC2 (ansible supports both greatly) and you are good to go. One does not exclude another, quite the opposite, as they can live in great synergy and cut your costs dramatically (the heavier your base load, the bigger the savings) while providing production-grade resiliency.

          See more
          Sebastian Gębski

          Heroku was a decent choice to start a business, but at some point our platform was too big, too complex & too heterogenic, so Heroku started to be a constraint, not a benefit. First, we've started containerizing our apps with Docker to eliminate "works in my machine" syndrome & uniformize the environment setup. The first orchestration was composed with Docker Compose , but at some point it made sense to move it to Kubernetes. Fortunately, we've made a very good technical decision when starting our work with containers - all the container configuration & provisions HAD (since the beginning) to be done in code (Infrastructure as Code) - we've used Terraform & Ansible for that (correspondingly). This general trend of containerisation was accompanied by another, parallel & equally big project: migrating environments from Heroku to AWS: using Amazon EC2 , Amazon EKS, Amazon S3 & Amazon RDS.

          See more
          New Relic logo

          New Relic

          20.9K
          1.9K
          New Relic is the industry’s largest and most comprehensive cloud-based observability platform.
          20.9K
          1.9K
          PROS OF NEW RELIC
          • 415
            Easy setup
          • 344
            Really powerful
          • 245
            Awesome visualization
          • 194
            Ease of use
          • 151
            Great ui
          • 106
            Free tier
          • 80
            Great tool for insights
          • 66
            Heroku Integration
          • 55
            Market leader
          • 49
            Peace of mind
          • 21
            Push notifications
          • 20
            Email notifications
          • 17
            Heroku Add-on
          • 16
            Error Detection and Alerting
          • 13
            Multiple language support
          • 11
            SQL Analysis
          • 11
            Server Resources Monitoring
          • 9
            Transaction Tracing
          • 8
            Apdex Scores
          • 8
            Azure Add-on
          • 7
            Analysis of CPU, Disk, Memory, and Network
          • 7
            Detailed reports
          • 6
            Performance of External Services
          • 6
            Error Analysis
          • 6
            Application Availability Monitoring and Alerting
          • 6
            Application Response Times
          • 5
            Most Time Consuming Transactions
          • 5
            JVM Performance Analyzer (Java)
          • 4
            Browser Transaction Tracing
          • 4
            Top Database Operations
          • 4
            Easy to use
          • 3
            Application Map
          • 3
            Weekly Performance Email
          • 3
            Pagoda Box integration
          • 3
            Custom Dashboards
          • 2
            Easy to setup
          • 2
            Background Jobs Transaction Analysis
          • 2
            App Speed Index
          • 1
            Super Expensive
          • 1
            Team Collaboration Tools
          • 1
            Metric Data Retention
          • 1
            Metric Data Resolution
          • 1
            Worst Transactions by User Dissatisfaction
          • 1
            Real User Monitoring Overview
          • 1
            Real User Monitoring Analysis and Breakdown
          • 1
            Time Comparisons
          • 1
            Access to Performance Data API
          • 1
            Incident Detection and Alerting
          • 1
            Best of the best, what more can you ask for
          • 1
            Best monitoring on the market
          • 1
            Rails integration
          • 1
            Free
          • 0
            Proce
          • 0
            Price
          • 0
            Exceptions
          • 0
            Cost
          CONS OF NEW RELIC
          • 20
            Pricing model doesn't suit microservices
          • 10
            UI isn't great
          • 7
            Expensive
          • 7
            Visualizations aren't very helpful
          • 5
            Hard to understand why things in your app are breaking

          related New Relic posts

          Farzeem Diamond Jiwani
          Software Engineer at IVP · | 8 upvotes · 1.5M views

          Hey there! We are looking at Datadog, Dynatrace, AppDynamics, and New Relic as options for our web application monitoring.

          Current Environment: .NET Core Web app hosted on Microsoft IIS

          Future Environment: Web app will be hosted on Microsoft Azure

          Tech Stacks: IIS, RabbitMQ, Redis, Microsoft SQL Server

          Requirement: Infra Monitoring, APM, Real - User Monitoring (User activity monitoring i.e., time spent on a page, most active page, etc.), Service Tracing, Root Cause Analysis, and Centralized Log Management.

          Please advise on the above. Thanks!

          See more
          Shared insights
          on
          New RelicNew RelicKibanaKibana

          I need to choose a monitoring tool for my project, but currently, my application doesn't have much load or many users. My application is not generating GBs of data. We don't want to send the user information to New Relic because it's a 3rd party tool. And we can deploy Kibana locally on our server. What should I use, Kibana or New Relic?

          See more
          Kibana logo

          Kibana

          20.5K
          262
          Visualize your Elasticsearch data and navigate the Elastic Stack
          20.5K
          262
          PROS OF KIBANA
          • 88
            Easy to setup
          • 65
            Free
          • 45
            Can search text
          • 21
            Has pie chart
          • 13
            X-axis is not restricted to timestamp
          • 9
            Easy queries and is a good way to view logs
          • 6
            Supports Plugins
          • 4
            Dev Tools
          • 3
            More "user-friendly"
          • 3
            Can build dashboards
          • 2
            Out-of-Box Dashboards/Analytics for Metrics/Heartbeat
          • 2
            Easy to drill-down
          • 1
            Up and running
          CONS OF KIBANA
          • 7
            Unintuituve
          • 4
            Works on top of elastic only
          • 4
            Elasticsearch is huge
          • 3
            Hardweight UI

          related Kibana posts

          Tymoteusz Paul
          Devops guy at X20X Development LTD · | 23 upvotes · 10.2M views

          Often enough I have to explain my way of going about setting up a CI/CD pipeline with multiple deployment platforms. Since I am a bit tired of yapping the same every single time, I've decided to write it up and share with the world this way, and send people to read it instead ;). I will explain it on "live-example" of how the Rome got built, basing that current methodology exists only of readme.md and wishes of good luck (as it usually is ;)).

          It always starts with an app, whatever it may be and reading the readmes available while Vagrant and VirtualBox is installing and updating. Following that is the first hurdle to go over - convert all the instruction/scripts into Ansible playbook(s), and only stopping when doing a clear vagrant up or vagrant reload we will have a fully working environment. As our Vagrant environment is now functional, it's time to break it! This is the moment to look for how things can be done better (too rigid/too lose versioning? Sloppy environment setup?) and replace them with the right way to do stuff, one that won't bite us in the backside. This is the point, and the best opportunity, to upcycle the existing way of doing dev environment to produce a proper, production-grade product.

          I should probably digress here for a moment and explain why. I firmly believe that the way you deploy production is the same way you should deploy develop, shy of few debugging-friendly setting. This way you avoid the discrepancy between how production work vs how development works, which almost always causes major pains in the back of the neck, and with use of proper tools should mean no more work for the developers. That's why we start with Vagrant as developer boxes should be as easy as vagrant up, but the meat of our product lies in Ansible which will do meat of the work and can be applied to almost anything: AWS, bare metal, docker, LXC, in open net, behind vpn - you name it.

          We must also give proper consideration to monitoring and logging hoovering at this point. My generic answer here is to grab Elasticsearch, Kibana, and Logstash. While for different use cases there may be better solutions, this one is well battle-tested, performs reasonably and is very easy to scale both vertically (within some limits) and horizontally. Logstash rules are easy to write and are well supported in maintenance through Ansible, which as I've mentioned earlier, are at the very core of things, and creating triggers/reports and alerts based on Elastic and Kibana is generally a breeze, including some quite complex aggregations.

          If we are happy with the state of the Ansible it's time to move on and put all those roles and playbooks to work. Namely, we need something to manage our CI/CD pipelines. For me, the choice is obvious: TeamCity. It's modern, robust and unlike most of the light-weight alternatives, it's transparent. What I mean by that is that it doesn't tell you how to do things, doesn't limit your ways to deploy, or test, or package for that matter. Instead, it provides a developer-friendly and rich playground for your pipelines. You can do most the same with Jenkins, but it has a quite dated look and feel to it, while also missing some key functionality that must be brought in via plugins (like quality REST API which comes built-in with TeamCity). It also comes with all the common-handy plugins like Slack or Apache Maven integration.

          The exact flow between CI and CD varies too greatly from one application to another to describe, so I will outline a few rules that guide me in it: 1. Make build steps as small as possible. This way when something breaks, we know exactly where, without needing to dig and root around. 2. All security credentials besides development environment must be sources from individual Vault instances. Keys to those containers should exist only on the CI/CD box and accessible by a few people (the less the better). This is pretty self-explanatory, as anything besides dev may contain sensitive data and, at times, be public-facing. Because of that appropriate security must be present. TeamCity shines in this department with excellent secrets-management. 3. Every part of the build chain shall consume and produce artifacts. If it creates nothing, it likely shouldn't be its own build. This way if any issue shows up with any environment or version, all developer has to do it is grab appropriate artifacts to reproduce the issue locally. 4. Deployment builds should be directly tied to specific Git branches/tags. This enables much easier tracking of what caused an issue, including automated identifying and tagging the author (nothing like automated regression testing!).

          Speaking of deployments, I generally try to keep it simple but also with a close eye on the wallet. Because of that, I am more than happy with AWS or another cloud provider, but also constantly peeking at the loads and do we get the value of what we are paying for. Often enough the pattern of use is not constantly erratic, but rather has a firm baseline which could be migrated away from the cloud and into bare metal boxes. That is another part where this approach strongly triumphs over the common Docker and CircleCI setup, where you are very much tied in to use cloud providers and getting out is expensive. Here to embrace bare-metal hosting all you need is a help of some container-based self-hosting software, my personal preference is with Proxmox and LXC. Following that all you must write are ansible scripts to manage hardware of Proxmox, similar way as you do for Amazon EC2 (ansible supports both greatly) and you are good to go. One does not exclude another, quite the opposite, as they can live in great synergy and cut your costs dramatically (the heavier your base load, the bigger the savings) while providing production-grade resiliency.

          See more
          Tassanai Singprom

          This is my stack in Application & Data

          JavaScript PHP HTML5 jQuery Redis Amazon EC2 Ubuntu Sass Vue.js Firebase Laravel Lumen Amazon RDS GraphQL MariaDB

          My Utilities Tools

          Google Analytics Postman Elasticsearch

          My Devops Tools

          Git GitHub GitLab npm Visual Studio Code Kibana Sentry BrowserStack

          My Business Tools

          Slack

          See more
          Grafana logo

          Grafana

          18.1K
          415
          Open source Graphite & InfluxDB Dashboard and Graph Editor
          18.1K
          415
          PROS OF GRAFANA
          • 89
            Beautiful
          • 68
            Graphs are interactive
          • 57
            Free
          • 56
            Easy
          • 34
            Nicer than the Graphite web interface
          • 26
            Many integrations
          • 18
            Can build dashboards
          • 10
            Easy to specify time window
          • 10
            Can collaborate on dashboards
          • 9
            Dashboards contain number tiles
          • 5
            Open Source
          • 5
            Integration with InfluxDB
          • 5
            Click and drag to zoom in
          • 4
            Authentification and users management
          • 4
            Threshold limits in graphs
          • 3
            Alerts
          • 3
            It is open to cloud watch and many database
          • 3
            Simple and native support to Prometheus
          • 2
            Great community support
          • 2
            You can use this for development to check memcache
          • 2
            You can visualize real time data to put alerts
          • 0
            Grapsh as code
          • 0
            Plugin visualizationa
          CONS OF GRAFANA
          • 1
            No interactive query builder

          related Grafana posts

          Matt Menzenski
          Senior Software Engineering Manager at PayIt · | 16 upvotes · 1.1M views

          Grafana and Prometheus together, running on Kubernetes , is a powerful combination. These tools are cloud-native and offer a large community and easy integrations. At PayIt we're using exporting Java application metrics using a Dropwizard metrics exporter, and our Node.js services now use the prom-client npm library to serve metrics.

          See more
          Conor Myhrvold
          Tech Brand Mgr, Office of CTO at Uber · | 15 upvotes · 5.2M views

          Why we spent several years building an open source, large-scale metrics alerting system, M3, built for Prometheus:

          By late 2014, all services, infrastructure, and servers at Uber emitted metrics to a Graphite stack that stored them using the Whisper file format in a sharded Carbon cluster. We used Grafana for dashboarding and Nagios for alerting, issuing Graphite threshold checks via source-controlled scripts. While this worked for a while, expanding the Carbon cluster required a manual resharding process and, due to lack of replication, any single node’s disk failure caused permanent loss of its associated metrics. In short, this solution was not able to meet our needs as the company continued to grow.

          To ensure the scalability of Uber’s metrics backend, we decided to build out a system that provided fault tolerant metrics ingestion, storage, and querying as a managed platform...

          https://eng.uber.com/m3/

          (GitHub : https://github.com/m3db/m3)

          See more