Advice I Like: Apologies

How to apologize: quickly, specifically, sincerely. Don’t ruin an apology with an excuse – from Excellent Advice for Living

This is great advice. I remember myself often saying “I’m sorry, but …”, which takes away from the I’m sorry. In fact, I wasn’t really sorry.

I’ve learned to just apologize. No excuses, no qualifications, just apologize for what you (or often, I), did. Leave it at that.

I’ve been posting New Words on Fridays from a book I was reading, however, a friend thought they were a little depressing. They should be as they are obscure sorrows. I like them because they make me think.

To counter-balance those, I’m adding in thoughts on advice, mostly from Kevin Kelley’s book. You can read all these posts under the advice tag.

Posted in Blog | Tagged , | Comments Off on Advice I Like: Apologies

Removing the REST Endpoint in the Data API Builder

The more I work with the Data API Builder (DAB), the more I lean towards GraphQL instead of REST. Rest isn’t bad, but it’s tough.

This is part of a series of posts on DAB that I’ve written. I also have articles at SQL Server Central about DAB.

Checking the Endpoint

In my first article and DAB, I set up things with defaults and exposed a table. As you can see, my REST endpoint is live and running.

2024-12_0250

I can also see this in Postman.

2024-12_0251

Wht if I want to remove this and only look at GraphQL? Let’s see what I need to do.

Removing the REST Runtime

In the config file, there is this section for the REST configuration at runtime.

2024-12_0252

I can remove this, but I’d hope I didn’t mess up the JSON. This is hard to read. Certainly this is something I can delete, but is there another way?

There is. In the DAB CLI  reference, one of the parameters is –rest.disabled. Let’s try that.

2024-12_0254

That doesn’t work. Hmmm, OK, let’s add the database type

2024-12_0255

Apparently init only creates new files.

There is an update verb, but that doesn’t work either.

2024-12_0253

I guess I’m editing the file. I remove the highlighted section above and the API starts.

2024-12_0256

Let’s check the REST endpoint. It appears to still work:

2024-12_0257

In the runtime, I see this log:

2024-12_0258

Weird. I see an error, but data is returned.

Looking down, I see this in my config for an entity. The REST is enabled.

2024-12_0263

I’ll change that to false and restart the DAB service. Now I see this. REST is still there, but this path is broken.

2024-12_0264

If I go to the root for /api, I get a 404. There’s still a response, as there is a service here running GraphQL, but the REST path for /api is gone.

2024-12_0264

Summary

I’m not sure this really works, as if I enable this for any entity, then the REST call works. If I add any entity without using the –rest: false parameter, the REST path is added by default, so my guess is this is likely to be randomly added back by developers if they don’t have a wrapper around the CLI that ensures no REST paths are enabled.

Posted in Blog | Tagged , | 2 Comments

The Managed Cloud Database Options

There are many, many choices for cloud database services these days. I would hope everyone is aware of the various IaaS options in public clouds with EC2, Azure VMs, GCP Compute Engine, and others. These are often the easiest way to move your workload, but you’ve really just moved a VM from one place to another (likely more expensive) place.

For managed databases, there are lots of choices, but you might not be aware of your options. I ran across an article that discusses the various flavors of managed databases in the big three public clouds for SQL Server. In the piece, there is a section that talks about when a managed database makes sense. I like that it discloses the development on a managed service is expensive.

The problem I have is that I know lots of companies that struggle when they don’t have a development environment that matches product. Invariably developers will use something in their local SQL Server/MySQL/Oracle/PostgreSQL database that doesn’t work in a managed service and causes no shortage of pain. Containers can help, but they’re not always available.

I won’t delve into details, but the article lightly looks at RDS (Amazon), Azure SQL DB and Managed Instance (Microsoft), and Cloud SQL (Google). There are pros and cons for all of them, but to me, the Google option is interesting. It gives you an instance (with SSIS/SSRS) and a proxy, but it does have limit you to instance restores. Same for RDS, which is a limitation I’d be worried about. Often I have an issue with a database, really often with just a table. Restoring a whole instance instead of a db might be a delay I wouldn’t want to deal with. I hope this changes over time, as not recovering a database from an instance is a big hole to me.

The comparison of hardware resources and performance seems to show Azure has the highest capacities, but as the article notes, if you approach the maximums, the cost is very high. I tend to agree there, and I think this is one of the things that gets lost when companies consider the cloud for workloads. They look at the maximums with an eye towards growth if they need it. Rarely, however, do they compute the increased cost if they’ve under-provisioned resources. There’s also the concern that trying to match CPU/RAM/disk from on-premises to the cloud isn’t easy. This often isn’t the same type of comparison that most of are used to with local machines.

The main thing I find too many people forgetting is that moving to the cloud is a new architecture. You likely need to rework/refactor/rewrite your application to work better. Part of that work is reducing the amount and frequency of data queries. Without changing those things, you likely will end up spending a lot more money than you expect. Possibly without getting the workload response you expect.

The cloud can work well for your application and database, but it’s not easy and it’s not quick.

Steve Jones

Listen to the podcast at Libsyn, Spotify, or iTunes.

Note, podcasts are only available for a limited time online.

Posted in Editorial | Tagged | Comments Off on The Managed Cloud Database Options

T-SQL Tuesday #182: Personal Integrity

It’s time for the first T-SQL Tuesday blog of 2025, with an invite from the first non-founder to host a party, Rob Farley. I reached out to Rob and he graciously agreed to host. His invitation this month is on integrity, leaning towards data integrity.

I still manage the T-SQL Tuesday list, and I’m always looking for hosts. I have a few scheduled for 2025, but I can use more. If you’re interested in hosting, hit me up at one of these places:

While data integrity is important, I think personal integrity really matters as well.

Integrity at Work

I used to work for a large corporation, which I won’t name here. This was a 10,000+ person organization and I helped manage part of the data group for the company. I had a number of reports, 10 or 11, that handled different aspects of production operations across a variety of database platforms.

It was a busy job, and our environment was far from stable. As is the case, things get cobbled together, become popular, and then limp along for years. This happens in small companies and large ones, but in large ones, I think it continues because when there are problems, we can throw people at the problem. We could throw resources and fix chronic issues, but that wasn’t the case at this company.

At the time I worked at this company, we had a stacked ranking system for reviews.  Microsoft used to do this (and stopped), but think about ranking everyone in your team from 1-5, 1 being underperforming and 5 being outstanding. The “stacked” part comes from the need to have a certain number of 2s, 3s, and 4s. 1s and 5s were rare (5s more rare). Essentially a 1 meant you were on a performance plan and on the way to termination.

I had to rank my staff, who worked hard and kept our systems running, despite lots of incidents. We performed some large migrations and upgrades of systems where my staff worked multiple weekends, with no comp time, just meals covered.

My first integrity stand was that even though I wasn’t officially allowed to give comp time, I did, working through my staff with extra days off that were unrecorded anywhere. This might be more of a violation, and if my boss’s boss had caught wind of this, I would have been terminated. However,  I felt my staff deserved something, as a few of these long weekends weren’t adding business value; they were things executives wanted to do for optics.

Near the end of the year, we had to rank our workers for annual reviews. I had most of my staff at 4s, with a couple 3s. I put in one person as a 5 for some great work they did. Justifying a 5 is hard and I thought I had a good case.

In a meeting of our IT department, the VP of Operations told us that we had too many 4s and that each director (1 level above me) would get an allocation of rankings and that each manager had to work to fit their staff inside that allocation. Anyone ranked a 1 would be outside the allocation.

My second integrity stand was to argue with my boss on why my staff deserved their rankings. According to their job descriptions and performance, I’d ranked then well, even though his quota meant he wanted me to move a couple 4s to 3s and 1-2 people to a 2 ranking. I refused, arguing with other managers whose staff I had seen underperform through the year. I told a few others they needed to absorb the 2s and 3s and not the data team.

I lost that battle and had some uncomfortable reviews (and the accompanying bonus/salary numbers), but I acted like an adult and told people I had ranked them a level higher and upper management lowered their ranking, not because of performance, but because of a quota.

As we went through the next year, management decided they needed to cut costs. They had managers compile a lot of numbers that were sent to outsourcing companies in an RFP to essentially remove IT from the company’s books. In a meeting, our CTO tried to spin this as good for workers as the winning company would hire our IT staff. The framing was that this outsourcing would save the company money.

My third integrity stand was when I questioned the way this worked in a large meeting of IT management and eventually got the CTO to admit that:

  • a) everyone would have to re-apply for their job
  • b) they might not get the same salary (higher or lower, you decide which is more likely)
  • c) not everyone would be hired

This might work out for some people, but likely those who got jobs at a new company were risking their salary and workload in a new situation. I questioned this as being good for the company overall as we would likely lose lots of knowledge.

I left shortly thereafter, voluntarily, but I’m sure I would have been let go at a layoff that occurred near the end of that year.

I hated that job in many ways and was glad to eventually leave. I decided I would never work for a stack ranking company again.

Posted in Blog | Tagged , , | Comments Off on T-SQL Tuesday #182: Personal Integrity