Voice of the DBA

Author: way0utwest

  • 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.

  • Daily Coping 10 Oct 2022

    Today’s coping tip is to write down three things you can look forward to in the next month.

    Easy.

    1. Visiting my daughter. I’m heading up this weekend to watch her play and hang out
    2. SQL Saturdays – Boston and Toronto, exciting to get back to a few events
    3. Open Gyms – Volleyball won’t start for another month, but I have a few gyms I’m hosting for kids that aren’t playing now. Looking forward to seeing them out on the court.

    I started to add a daily coping tip to the SQL Server Central newsletter and to the Community Circle, which is helping me deal with the issues in the world. I’m adding my responses for each day here. All my coping tips are under this tag.

  • No Autopilot in the Tesla

    Recently I was driving home and I couldn’t engage Autopilot. I kept seeing the availability icon come and go, and found this interesting, but also a sign of why Level 4 or 5 is likely hard to solve in a general way.

    This is part of a series that covers my experience with a Tesla Model Y.

    Denver Sun

    When I first moved to Denver, I was driving down I-25 early one morning. There was a stretch that turned East and was blinded. It felt like the sun was directly in front of me on the horizon. This is something that I’ve gotten used to a few times a year, as the sun seems to be at a lower angle than I see anywhere else in the world.

    My Tesla Model Y, Long Range (MYLR) apparently had the same problem this week. I was out early to town and ended up coming home around 8am. Driving East, the sun was low and seemed to be coming directly into the car. Fortunately it was slightly to the right, so I could see straight ahead. This is a section of road that I often engage autopilot as it’s got some ups and downs, is fairly quiet with a median, and I like letting the car control the drive.

    However, when I engaged Autopilot (AP) I got the alert that it wasn’t available. I glanced down and saw the icon, which indicates AP is available, so I assumed maybe I’d done it at a place where there weren’t lines. The icon disappears in intersections or other places where the car doesn’t see lines immediately.

    I tried again and the same thing happened. As I glanced down a few times, I’d see the icon come and then go. I looked out and realized that I could barely see the lines in the center of the road because of the glare.

    This continued for a few minutes until the road turned left further and a large hill shaded the road. I engaged AP and it handled the rest of the drive out to the road that turns toward my house. Once engaged, it seemed to do well, even on a few hills where the glare was strong, though not as strong as it was leaving town.

    Radar and Lidar

    There are a number of situations and places where I think that lack of radar or lidar would help. This isn’t one of them. Unless radar is painting the painted lines in the middle of the road, it wouldn’t solve this problem.

    Conclusion

    In a city, or even suburb, where the roads are well mapped, this might not be a problem. In a neighborhood, or place where cars might park on the street, then perhaps radar could help, but vision is vision, and it’s not something that a computer can necessarily do better. Humans make mistakes with glare and blinding light, and cars that depend on vision can do the same thing.

    Actually, I think the recognition of visual artifacts ( shadows, glare, etc.) is slower and more difficult for computers than humans. Humans will also make mistakes, but like many, I think I have less tolerance for computers making the same mistakes. Not sure that’s rational, but I do feel that way.

    This is a reason that I think L4 or L5 isn’t easy, or likely, outside of highly mapped and geo-fenced areas.

  • 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.