Some of you might already know that Checkmk team has started to develop a Software as a Service (SaaS) Checkmk solution. The idea behind it is to allow users to focus purely on monitoring – we would take care of the monitoring infrastructure and ensure security, performance, availability, and of course everything being up-to-date. The SaaS solution will be complementary to the self-deployed solutions (Checkmk Raw and Checkmk Enterprise). We do not want to replace our existing offering with it - rather we want to address the needs of the users, who want a SaaS solution.
And who better knows the needs of users other than you – our community. And we want to ask for your help in shaping the SaaS solution. We want to know who you are – people who use Checkmk and for whom SaaS solutions could be the reason to start using it. We want to know why you are looking for a SaaS solution. If you worked with SaaS solutions before we would like to know: what good practices we could follow and what mistakes we could avoid.
There are many things to be decided about this solution – and we want to make these decisions together with you. The product team is looking forward to talking to some of you who fill in the survey form based on your interests and your use case with Checkmk. For that, please, fill in this survey that would help us find the people who we could talk to later in an interview.
Small bonus: people chosen for the interview will get Checkmk souvenirs
UPD.: Thank you so much for your insights! The survey is now closed. If you left us your contacts, we will contact you in the upcoming weeks directly.
Thank you for contributing your experience to help us make Checkmk better!
You should set more focus on the recent products because they are not working correctly than putting all the time new stuff.
We as customer do the “quality service” for you and report you bugs which we have to pay for - ridiculous! Fundamental things are not working and if someone reports that it is just ignored by you.
I have received some reports of these replies being off-topic. I do not agree that we should ban concerns, but I do agree that it is neither the place nor the way that could bring up to any constructive dialog.
In any projects I had experience working with there is always this choice between working on fixes, designing new features (or like here – new formats) and doing some refactoring, for example to improve the performance, security etc. I believe Checkmk to be no different here – the work of our developers’ team (and other teams of course) consists of different things – including fixes and new features/ formats/ you name it. Unfortunately, the developers’ resources are not unlimited – and some things get prioritised over others. And we might try some ways to build better communication around it.
I do not believe though that this SaaS solution here is the case. I have a couple of reasons for that:
This SaaS solution will be based on the same Checkmk – meaning that most part of the development of the SaaS solution (and fixing its bugs, and improving it) will also be reflected in the main code of Checkmk. The idea behind SaaS is that we will operate Checkmk ourselves, meaning that we will be even more aware of all the issues quicker, and based on what I know, a lot of work of the SaaS teams already consists on looking into improving the existent Checkmk.
This research is being done by people whose sole purpose is to come up with new ideas and features – not to create more bugs but to stay on track with all the modern world requirements. The IT world is super fast-changing and even to stay at the same place you have to move with new ideas pretty quickly
I see that this is a presentation of a deeper issue than just one new feature. From my side, I will try in the beginning of the year to organise a way to communicate the concern with the stakeholders teams. In the last year we’ve come a long way in the way we communicate with the community – for example, changes in how code contributions are processed on GitHub, the new Feature Portal and others. As far as I know – we also made the QA team stronger. Fixing bugs is not a hot topic to talk about though.
The support model is something that we also want to have improved in the future. I believe we can find a way to better communicate this too.
Maybe my colleagues will have something else to say after the holidays as well.
Do you think if I create a special topic to voice concerns, we could discuss it in a more constructive way? I would gladly do that (unfortunately, it might need to wait a little as we are very close to Christmas holidays, but I would definitely do that – to be able to find a better way to work together).
From all I’m reading and hearing between the lines, maybe its good to do and hope the people will contribute and not hide between curtains with what they are not happy anymore - give it a shot
Hello everyone! I hope you are having great time at the beginning of the year!
Here I have created a topic where we could collect some of the concerns from this thread. It is a general topic – if concerns have a potential for more constructive discussion, I would split it into specific themes.
For now I just want it to be a platform where you could say what you have to say. Hopefully, we will be able to address at least some of the concerns and maybe find better ways of doing things and communicating them.
We had talked to Tribe29 years ago about a SaaS model because we wanted to offer something like that to our customers. In the end, we ended up with the Managed Service Edition. Not exactly what we had in mind but at least a step forward. Probably the time wasn’t ripe for our ideas back then.
Such a SaaS solution is a good option for customers who don’t have their own IT department or don’t have the will or time to build their own monitoring environment and don’t have the need for an “On-Premises” Solution.
What the other customers probably want to express is the fear that with all the new ideas and directions, the maintenance and further development of existing solutions will be neglected. I believe that Checkmk as a product will benefit in the long term from such a SaaS Solution, because now Trieb29 has to work with there Product themself. Tribe29 will then better understand what it means to run and maintain such a platform. And hopefully, they will first update their SaaS Solution before releasing the updates to the other customers
A SaaS offering? Might surely be interesting for some.
There might be a few things you’d want to ensure a few things so the service can deliver value month after month…
stand up a reasonably sized dev/ops team (as you wrote, this is a product; accordingly design & bringup is just 20% of the lifetime effort)
an independent team
let the team design a suitable stack (historically, that could become a fight against “not invented here” attitude)
give that team some decision power for roadmap choices/priorities that concern their service
or at least weigh their needs according to current - and projected - revenue
give them a separate channel for raising security issues and obtaining fixes (different liability stance)
scalability issues(*) would matter more since they hurt the business case
the team’s documentation and support must be able to handle many small sites with their different, fractured patterns
If you put this teams’ needs behind the customers’ needs you’ll be forgetting that they’ll be one of the biggest users. they have a unique constraint regarding availability: the value proposition in the short run might be often just billing needs or similar.
but what if you look at the long-term success? Then it matters that it’s run consistently better than what makes those users look for SaaS.
This might mean that “we’ll have separate people on this” is an incomplete perspective.
You’ll have separate people that will have goals to reach that are operational and, as such, can collide with and be more important than product roadmap.
You need to be able to handle this, effectively a second pipeline that needs to stay filled. (one manager called Ops a “projektfeindliches Umfeld”). It will not be often that your main devs need to drop their work to ensure the SaaS can run smoothly - but if the time arises, they need to be ready to support their colleages at that time.
That’s the nature of offering a “service”
I hope you’ll have a lot of luck with the new product, and to me it also sounds like it would have the potential to bring some more improvements (instead of novelties), so the frustration that has been expressed here might also be remediated.
