WHAT TO CONSIDER WHEN CHOOSING THE “RIGHT” OBSERVABILITY STACK
Avoiding the Roadblocks: How to Choose the Right Tools for Your Observability Stack
The options and configurations for building a functional observability stack that is tied to your systems are vast, like the Multiverse. You could choose to run an on-premises stack, opt for a cloud provider or SaaS solution, or even adopt a hybrid approach, where some of the stack is hosted within your own cloud or data center and the other half is hosted by a third-party provider.
Understanding the requirements that the company has
Every organization has unique needs and requirements when it comes to observability.
It is crucial to understand what goals you want to achieve with your observability stack before choosing any tools. These requirements can come from various sources, both internal and external. For example, if you operate in a heavily regulated industry such as banking, the monitoring requirements may already be set by governing entities.
Additionally, it is essential to consider the internal requirements and understand the financial impact of system disruptions.
Scalability and flexibility is essential
As your organization and infrastructure expand, it is essential to choose observability tools that can scale and adapt with it. Opt for tools that are flexible and can handle large volumes of data to keep your observability from becoming a bottleneck to rest of the business . Keep in mind that larger data volumes may result in increased costs for data hosting, ingestion, and extraction.
Additionally, it is important to consider potential mishaps, such as the accidental logging of sensitive data, and have failsafe mechanisms in place to remove unwanted data from your platforms. On-premises solutions may provide more ease and control in removing unwanted data, as opposed to having to file a support ticket with a cloud provider.
To SaaS or not to SaaS?
Open-source tools often offer more flexibility and customisation options than proprietary solutions. They also have a large community of users and developers who can provide support and contribute to the development of the tool.
On the other hand, enterprise tools typically offer improved customer support functionality, and many SaaS providers for observability offer engineering support to help clients get up and running quickly. In some cases, it may make sense for a company to use a combination of open-source tools and enterprise-level support from the software creators.
It is also crucial to keep in mind the regulations governing your business when selecting observability tools. For example, if your logs contain client information and your clients are based in the EU, it would be in violation of GDPR regulations to store the logs on US soil or outside of the EU. Therefore, it is essential to be mindful of the location of the data stored, the certifications held by the SaaS provider, and overall where to keep the data.
Total cost of ownership
The cost of the tools is an important consideration, but it should not be the only factor. Make sure you are getting the best value for your money by considering the features and capabilities of the tool, as well as the vendor’s support and documentation. I’ve personally seen over-provisioned and underutilised accounts that cost a tonne but engineers either do not know how to use it or the tool itself has very limited user experience driving away the users from using it.
However when choosing to go on-premises solution one has to factor in the cost for engineers that will uphold the systems, improve and train others to use the systems and the technical side of hosting the servers, data, pods or containers on their own.
All of the above is handled for in the SaaS offering deeming it to have a lower cost curve in the beginning, once you’re starting up with your company and all of your headcount allocation is going towards product engineering and not so much towards sustaining the on-premises offering.
What is the Bondora way?
At Bondora, we chose to go with a self-hosted solution for our observability stack. We currently use Prometheus for metrics collection and storage, Loki for aggregating and collecting logs from various systems, and Grafana to provide a single pane of glass view of our data. This solution allows us to scale faster without worrying about the costs of SaaS providers increasing as we grow.
At the time of writing this article, our infrastructure and services are in very different forms, ranging from Windows VMs that run some parts of our service, to Docker Swarm that supports some of our microservices, and a full-blown Kubernetes cluster with tens or hundreds of microservices running on it.
Given this complexity, we had to come up with a custom solution to be able to observe our infrastructure and services. SaaS providers that aim to be a one-stop-shop for Kubernetes or Docker did not meet all of our needs.
In conclusion, choosing the right observability stack is not a one-size-fits-all solution and requires careful consideration of your unique requirements, scalability, flexibility, cost, and regulations. By understanding your specific needs and evaluating the different options available, you can ensure that you select the tools that will help you achieve your goals, avoid roadblocks and ultimately improve your business.
Interested in joining us?
https://www.bondora.group/careers/
