May 31, 2023 at 12:00 am
Comments posted to this topic are about the item Scaling Up Monitoring
May 31, 2023 at 3:50 pm
Interesting post, Steve. For the most part, I agree with you, but I will challenge you on some of it. For example, I'm interpreting what you were saying when you wrote, "I would say that far too many software engineers think that their solution will scale without actually testing it" paragraph. Around that section of your article, I interpret what you've said to be software engineers need to be willing to write something, then if it doesn't work, re-write it as something else. If I've gotten that wrong, please let me know.
Assuming, for the moment, that I've interpreted what you've said correctly, then I'd like to point out that everywhere I've worked in my career, both in the public and private sectors, as we plan to write some new software solution it really turns into considering what approach we should take, knowing that we cannot re-write it as we don't have the time. Of course, there's always a chance to make small changes along the way, based upon what we've learned or user feedback. But it is always a small change. I've taken agile and DevOps to support the idea of small changes, making minor adjustments. I've never worked anywhere that first decides we'll write a web app, then halfway through decide it would be better to make it a Windows or mobile app. It has always been the idea that once a direction is decided upon, then that's it. Stay on the course and finish the project decided upon. Your article suggests, to me, that at any point during the journey it's OK to radically change direction. I've never worked for any organization that was agile or truly practiced DevOps, so maybe my point of view is stilted. But I know that none of the managers I worked for, over the years I've worked, would consider a radical change in direction. They would first get rid of me, or whoever suggested such a daring thought, then risk delaying a project much further than it always has gone.
Kindest Regards, Rod Connect with me on LinkedIn.
May 31, 2023 at 4:22 pm
The build vs buy is a challenge. The question is what is the need? Will an off the shelf package provide all of what you need?
Probably not. It seems as if there is always an "I wish it did XYZ" with any of the popular packages. Creating your own makes sense, as long as you make sure you do not get carried away. Been there, done that.
The things I have written to augment the off the shelf monitoring software fit into two categories. One, to provide something specific data that is related to our business needs, or to produce analytical type data. A simple one I wrote a long while ago was "At the current growth rate, your X: drive will run out of space on <date>. Not very elegant, but it was geared toward scaring the higher powers into spending some money. The majority of the home grown things were pretty simple, and filled a need. An email if a server is re-booted. A proc that reads the error log every so often and looks for specific strings, and sends an email if it finds them. A proc that gets called when an SSIS package fails, and sends the errors out. And so forth.
I also have a somewhat different view of monitoring. I don't really need it to tell me something happened. I tend to use monitoring to confirm what I already know or suspect is occurring. And to make really pretty reports for the bosses!
Michael L John
If you assassinate a DBA, would you pull a trigger?
To properly post on a forum:
http://www.sqlservercentral.com/articles/61537/
May 31, 2023 at 5:19 pm
Interesting post, Steve. For the most part, I agree with you, but I will challenge you on some of it. For example, I'm interpreting what you were saying when you wrote, "I would say that far too many software engineers think that their solution will scale without actually testing it" paragraph. Around that section of your article, I interpret what you've said to be software engineers need to be willing to write something, then if it doesn't work, re-write it as something else. If I've gotten that wrong, please let me know.
Not really, though perhaps I mixed some messages. The idea of scaling up is separate from architecture. If I write code, whether for monitoring like this, or a web app that does CRUD work, I ought to think about how this works with more than 100 rows of data. While I might have some process that updates lots of rows (or searches through them), expecting that to behave the same on 100 rows of data as 1millon is silly.
However, too many devs will do that. They think because Google used the same tech and it scaled up, it will scale for them. Or they think that their indexing schema on 100 rows is what is needed for 1 million. Or that a REST API with an API server and microservices magically scales. I've seen too many customers find the API server is a bottleneck because they had some success with a part of their app, but once they move every service here the system is overloaded.
Separate from that, the architecture chosen can be problematic or better/worse for certain situations. I wouldn't change from a web app to a desktop app, but I might say a 2-tier is better than 3 tier, or vice versa. I might suggest that using Elasticsearch for part of the app is better than embedding "like '%somestring%'" in our queries.
May 31, 2023 at 5:23 pm
The build vs buy is a challenge. The question is what is the need? Will an off the shelf package provide all of what you need?
Probably not. ...
I also have a somewhat different view of monitoring. I don't really need it to tell me something happened. I tend to use monitoring to confirm what I already know or suspect is occurring. And to make really pretty reports for the bosses!
I don't think any software does everything I need. Even the stuff I've written. I never have time to add everything I need, and I certainly don't have time to maintain it.
I agree on the need to match what your requirements are. For monitoring software, there are a lot of things that packages bring, especially with managing data, working across versions, consolidating stuff, etc. Maintaining that for individuals isn't a good use of their time. Especially in a team when there are support requests and change requests. Better to use your skills and time to augment what's there.
I usually want monitoring software to confirm something I suspect, but also to tell me if this is normal. I've had too many users get upset and when we check the system, we find it's often behaving like this. It's just that the day the ticket is filed the user has less patience.
June 1, 2023 at 2:39 pm
Ah, now I see how I misunderstood you, Steve. You're correct, I was confusing scaling up with architecture. My bad. Thank you for making it clearer to me.
Your example of some developers testing 100 rows of data, then thinking that will scale to 1 million rows, is valid. It makes me wonder about the code I've written over the years. For the most part every system I've written would at most involve 100 rows of data. I admit that I've not written apps that would involve a large number of rows in one transaction. I've dodged that bullet without even knowing it could be flying by. WOW, I really wonder how some of my code would have held up under that kind of load. I must believe that at least some of it wouldn't have done well.
Kindest Regards, Rod Connect with me on LinkedIn.
June 1, 2023 at 2:48 pm
Your example of some developers testing 100 rows of data, then thinking that will scale to 1 million rows, is valid.
One of the contractors submitted code. They created triggers that would only work properly if a single user/row was being inserted or updated. We tried to explain it to them, they could not understand why. And worse, they argued with us that the code was fine! We had to prove it by executing the code and showing them that the data did not get updated properly.
Michael L John
If you assassinate a DBA, would you pull a trigger?
To properly post on a forum:
http://www.sqlservercentral.com/articles/61537/
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply