Voice of the DBA

Category: Editorial

  • Things I’ve Learned About the Cloud

    I do a little cloud work, but mostly I end up working with customers that are trying to build and migrate their systems to the cloud. The transition to cloud-first took place quicker than I expected, though certainly the pandemic of the last 3 years has continued to accelerate the moves by many organizations. While not all systems will move, for better or worse, many organizations consider the cloud for everything and then decide to accept or reject the notion for individual cases. That’s the cloud-first world I see.

    At a recent event, I had numerous people telling me that their groups were mandated to move many systems to the cloud in a lift-and-shift fashion, and many of the technologists weren’t happy. That’s a conversation for another day, but listening to them and others has taught me a few things. Some of these are experiences I’ve learned myself, and some are things from others, nuggets gained from their hard experiences.

    First, lift-and-shift appears to be a way to get started in the cloud. Some people find this to be an end-goal when they can get systems running without ever worrying about hardware or facilities. While costs can be higher, flexibility and tax considerations can make this worth the effort. Others see this as a first step to moving towards Platform-as-a-Service (PaaS) products and rewriting software, and life-and-shift is a good way to approach this process, but that leads me to the second nugget.

    Everything takes longer to get settled in the cloud than you expect. Not that the cloud is slower to build and use resources. The opposite is certainly true as provisioning anything is fast, and upgrades (or downgrades) are incredibly flexible and quick. However, making the move, getting systems running to your satisfaction, decommissioning old systems, and more take longer. It seems most life-and-shift projects end up taking much longer than estimated, and not all of this is the massive data transfers needed to move data assets. Often it’s humans that can slow the process, whether through debate on decisions or just getting comfortable with cloud resources through testing. Things take longer.

    Maybe the last big thing that I’ve seen affect many companies is that we have to put better software development techniques and infrastructure configuration in place. The connection to resources is more complex and tenuous than it is on a LAN. We need to better architect software, really architect it as we were told to do so early in our careers with better error handling and retry logic. The cloud is very secure when you set it up right, but you no longer have the castle with high walls that you grew used to in a data center. Instead, you have a series of people and systems that are disparately connected and you need to ensure you protect each one along with the connections between them. That requires lots of configuration work and standards, and likely Infrastructure-as-code. Plus there are new tools to learn and the habit to build of using command line interfaces.

    I love the cloud. In many ways, I prefer it over building and managing things on premise. Not for everything, and not for things where I might lose productivity with slow connections. I certainly don’t want developer laptops or workstations in the cloud, but having other systems there can remove a lot of the hassles of managing assets that we purchase, track, upgrade, etc. I don’t know I’d ever want to buy another physical server in a company I owned, but I also know that at some scales, it might still make sense.

    The other thing I’ve learned about the cloud is there are a lot of unknown unknowns, as well as plenty of known unknowns. Tackling the cloud require a staff that wants to grow and learn with the platform, as well as one that knows when to use the resources they know best and don’t add complexity or novelty just because someone wants to try something new. The cloud is worth considering, especially as it seems physical offices and data centers are becoming rarer and rarer in many organizations.

    Steve Jones

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

  • Assembling Your Own Toolbox

    Last month Brent Ozar posted that September was community tools month. He had a number of posts that highlighted tools and a number of other people (Francesco, Erik, VladDBA ) did as well. I didn’t do any blogging because, well, it was a busy month for me. I was gone from home for 21 days, so a bit harried in life.

    As a part of this effort, I saw Ken Fisher write about being a Script Magpie, which is an interesting analogy. A magpie is a bird that collects various shiny objects. Ken collects scripts in the same way. Things that catch his eye are added to his repo of scripts that he keeps handy.

    I used to do something similar. I didn’t have a repo back then, though I should have. However, all VCSes in the past lacked some of the ubiquity of Git. Instead I had a folder that I kept synched on various flash drives that I carried from job to job. I’ve also usually had a share inside companies where a team of developers or DBAs could share SQL scripts.

    I’d hope that most technology professionals would share scripts, especially when they can be tokenized or added as SQL Prompt snippets. Reusing work is a big part of working with computers and why many people have embraced tools and utilities that they didn’t write themselves. I certainly think having a toolbox is important, especially tools that integrate well with an existing environment.

    I don’t think it’s worth rewriting many tools inside a company. I work for a software vendor, and I’ve seen the effort put into building tools. Both free and paid tools can save you a lot of time and effort inside your job, not the least of which is maintaining the tools over time as versions and editions change.

    What are the contents of your toolbox? Which things are those that you’d bring to a new position if you moved organizations or groups? Let us know today.

    Steve Jones

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

  • The Value of Seniority

    There was a short but interesting post on the value of seniority. It’s written from the perspective of someone that gets a new co-worker, but the co-worker is from the future. In fact, it’s the future you. The post is actually titled senior engineers are living in the future.

    We (hopefully) are more capable and impressive over time. I would hope most of us are learning more each day and our work reflects that. The code you write today should be better than what you wrote last month or last year. The choices you make, the bugs you solve, the experience you bring to work often does reflect your seniority. Not always, but often.

    Sometimes the extra experience you bring is valuable because of the knowledge you gain over time. Most of us have probably known people that seem to be the go-to resources for answers to questions or to solve problems because of the things they’ve learned over time about the environment. This can be frustrating to newer employees, and I’ve certainly seen my son experience that, but it’s one reason why staff who have worked there for more time are valuable.

    There’s a point in the post that notes you shouldn’t compare yourself to more senior people. They can seem like they’re from the future because they just know more. Junior people will get there, if they work at learning more.

    That’s a big point of focus that I try to emphasize to people that I work with, speak to, or read my editorials. Put effort into your career, learn more, both specific to technology and about the way your company works. Growing your skills, tech, soft, whatever, is a way that you can enhance your career and prove yourself to be more valuable.

    It’s a way to make people think you are from the future.

    Steve Jones

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

  • The Growth of IQP

    When Microsoft started to talk about Intelligent Query Processing (IQP) before SQL Server 2017, I wasn’t sure what to think. There was a diagram with 20 things on it, and only 5 were highlighted (you can see that in the article linked). That felt like something, but barely something. Over time, as we’ve gone through SQL Server 2019 and now 2022, the diagram now looks more filled in. In fact, now there are a lot of things filled in.

    When I think about new features of SQL Server, I don’t often spend a lot of time on the IQP stuff. First, I don’t have to live with people yelling at me every day about slow performance. If I did, I might be more anxious to test and evaluate the changes. Second, these are mostly just hidden things that come with the product and (fingers crossed) improve my workload.

    There’s an article on the 2022 changes, which improve upon some of the older IQP work as well as add some new items. It seems the feedback loops are getting better, though not perfect. I’m sure all the performance tuning experts will write posts about where these things fail, which is good. We want to know where we might have problems. Hopefully, we’ll also see lots of demo code that shows where these things work.

    One of the more interesting things is the Parameter Sensitive Plan Optimization. This should help with parameter sniffing issues, though it will be interesting to see what percentage of a variable workload is improved by this. I also wonder if loaded systems that struggle here might have other plan issues. I already know some people have an overloaded plan cache now. If they could have even more plans for each type of query, there might be other issues to contend with.

    For the most part, SQL Server works well for a wide variety of situations. Many people seem to be quite pleased with how well it performs. I don’t know if that means customers look forward to upgrades or are happy where they are, but I am glad that the product doesn’t just add developer features or complex technology for administrators to learn. Getting investments in better query performance is important, especially as it can be hard to get developers to write better code on their own.

    Steve Jones

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