aq9
At least with Enterprise support you can yell at your TAM, which sometimes is less effective than you would think, considering the price.
RE the police force and private security, that has been a fact of life in South Africa for decades, not a new development. Anyone with the means employs private security, in the same way that anyone with means utilizes private health care, not public health care. Here South Africa is not that much different from other high-crime and high-inequality countries like Brazil and Mexico.
* Yes, many companies need the help.
* However, they typically (not necessarily unfairly) have a dim view of consulting/consultants.
* They can't (or won't) prioritize stopping or slowing down feature development to make the infrastructure changes that will lead to significant improvement. Often the potential solutions are actually either known or obvious already.
* In systems of appreciable complexity, it can take a significant amount of time for a consultant to examine all the moving parts to come up with a good/reasonable set of recommendations.
* So, as a result, consultants are often only brought in when things have deteriorated to an extent where it really hard to help. One other case is upon change of control (company is sold or acquired); this might be a better point to implement change.
* Lastly, knowing what needs to be done is one thing; actually implementing the necessary changes "on the fly" is actually the hard(er) thing. Often the company's team just don't have the skills to do that. Accordingly the best results are often when you can bring in a team to both consult and help the team through the implementation/changes.
Context: I looked into uptime monitors quite deeply about 10 years ago when I thought about doing a SaaS.
Implementing a good uptime monitoring system is actually more complex than you would think from a technical perspective (dealing with network splits which could be the result of your network or the target endpoint's network, so you need to triangulate continuously between multiple network sensors).
Actually, something like pagerduty is even simpler from a technical perspective; but as a business, is probably a different story.
ICs and lower level managers are all about inputs and outputs, blocking and tackling, getting shit done.
At the higher management levels it is all about setting direction, setting the "tone", "getting the culture right".
There is just so little concerns that intersect between these groups, that communication becomes a challenge.
For the type of organizations that run workloads on IBM mainframes, there are three drivers: * Legacy: The application was written for the mainframe, cannot run on anything else, too expensive in terms of dev and test time to re-platform * Business value: This is the big one; these workloads make their companies 100s of millions to billions of dollars per year. The price premium for running this on a mainframe is a rounding error. * Reliability: With the cloud, I hold the opinion that the average x86 application is less available/reliable than a well-run pre-cloud application (which already included HA, etc.). Mainframe apps and hardware blow all this out of the water.
FWIW: I programmed mainframes briefly early in my career, I am quite familiar with the ecosystem.
High QPS is in the eye of the beholder, but let's say something like a few hundred thousand QPS and up.
If you have scale in just one of these 3 dimensions, the solutions are relatively easy (except maybe for high write QPS, depends on the nature of the writes). If you are at scale on all three dimensions, solutions get harder (sharding, non-innodb storage engines).
Of course, there is also the wildcard: the nature of your queries/transactions. Large transactions along with scale will make your life a living hell.
It's a shame fuckedcompany.com is not around anymore. We miss you, Pud.