Voice of the DBA

Tag: Cloud Computing

  • The Useful Cloud Tags

    One of the things I’ve seen in working with cloud based resources is that you get a lot of them in your account quickly. A database might end up with a server, an IP address, a network, security groups, and more. A few clicks of the mouse in the Azure Portal can create a new Resource Group that doesn’t just have the one thing you need, but 3, 4, or more other items.

    In addition to the quantity, there are also the problems of namespaces in cloud resources. Some of the items you provision are publicly named in a domain, such as database.windows.net. In these cases, the resources need to be unique among all cloud customers. Just like domain names, this means that you might have collisions with your favorite name. While I might like jones.com, there are a few other people that would likewise prefer this. The rest of us might have to choose jones2.com, stevejonesincolorado.com, or some other variation. In large organizations, you might end up with LA34532345454.database.windows.net for an Azure SQL Database.

    That means that the names of the systems don’t make sense to anyone, and many of the people that need to use or manage them will not even know which resource belongs to which system. This has been true for servers in many organizations for a long time, even with their own domains. Often there is some document, perhaps stored on the root of the machine or in an online share, that provides more information for people accessing the system.

    The cloud makes keeping track of systems harder, and there is a greater need to classify, categorize, and tag resources. Most of the cloud providers have built extensive tagging systems that help users add metadata to various resources and search/filter by these tags.

    Today I’m wondering which tags are useful in the cloud? How do you decide which tags, or type of tags, to apply? You might choose to apply an application name, a business department or owner, or some other type of information that helps you keep track of which resources are needed and how to deal with them. Is there some guideline on the type of key-value pairs you use for tags?

    I also would you want to easily have tags for on-premises SQL Server instances? We do have extended properties, but those are cumbersome. Would you want some sort of easy system query that retrieved all tags. Perhaps something like @@InstanceTags or @@DatabaseTags that retrieved all the data you’d stored in extended properties.

    We are only seeing more and more resources that need to be managed, patched, and deployed. Tagging is one of the ways that helps our organizations keep track of resources, especially if we provision them and we move on to our dream job somewhere else. Let me know how you handle things today.

    Steve Jones

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

  • The Cloud as a Foundation

    The cloud for computing is a fascinating structure. I know there are plenty of jokes about the cloud just being someone else’s computer, and there are good reasons not to use the cloud. However, there are also lots of good reasons to use the cloud. Whether you choose to embrace it or avoid it, cloud computing is going to be a part of our careers for a long time. The use is growing, and more and more companies are shifting workloads to cloud services.

    How that will evolve, especially for data-intensive systems, will be fascinating. One of the interesting changes that seems to be taking places is the growth of database and data stores that fulfill specialized roles for customers. Snowflake might be one of the most well-known examples, but there are plenty more. The number of offerings is growing, and perhaps this is another evolution of how the cloud will integrate into more businesses.

    To date, most of the large cloud providers (Azure, AWS, GCP) are offering a full stack of different systems that you use to deploy code and run applications. These cobbled-together services and platforms often lock customers into a particular cloud, though that isn’t what many organizations would like. Especially in some regulated industries that mandate multiple clouds be used for redundancy. This article talks about the cloud as a foundation on which other customers can build services or platforms, especially data platforms.

    This is something I would like to see. Snowflake is something that a company can run on AWS, Azure, or GCP.  CockroachDB is another that allows customers to work with the platform on the provider of their choice. I like the idea of a wider set of platforms built upon cloud providers, but in a way that allows customers to move if need be, and also pressures cloud providers to keep pricing in line with each other.

    In my mind, the more we find innovative companies building cloud-native data stores and other products, the more pressure on existing companies to improve their offerings. Competition is good, and it brings us new tools, while also forcing existing companies to update their offerings. It’s not perfect, as sometimes we get new features without quality improvements in the base product, but without competition, we might not get that anyway.

    I am fascinated and pleased by the cloud. The more I learn and work with it, the more I appreciate this as a truly new way of approaching the building and operating of software.

    Steve Jones

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

  • Going Cloud Native

    I am constantly surprised at the migration of workloads to the cloud. It seems that many of the customers and clients that I speak with are moving some of their assets to the cloud. Some are moving the majority of their systems, and they are pushing to do this sooner than later, including database assets.

    I ran across an article that noted that while many companies love the on-demand provisioning of cloud resources, they don’t always get improvement in their software performance. In fact, quite a few might experience worse performance, though often not horribly worse. Instead, what they often get is a bit more unpredictable performance, and sometimes a bigger bill, which makes perfect sense. After all, the cloud is really just someone else’s computer, and the one you’re using might have other people doing the same thing.

    To truly embrace the cloud and get the power of the cloud, you do need to consider being cloud-native, which is often a change in how your software is architected. It is also a change in your entire software lifecycle, meaning not just buying DevOps tools or renaming a team, but also embracing the entire way that DevOps works. Not just fast releases, but experimentation, learning, adapting,  testing, and changing how you build and release software. This is also changing how you manage the teams that build software.

    If you think this is just for the Netflixes and Spotifys of the world, that’s not true. Stripe and Capital One are financial companies completely in the cloud. There are plenty of other examples as well, and the successful ones, in all industries, are embracing a new way of building and operating software. Docusign has had a lot of success, and quite a bit with a lift-and-shift to IaaS resources as they continue to build and rebuild their software to embrace the cloud and adopt more PaaS services. They didn’t move systems and expect everything to just get better. They started a journey that they continue to travel every week. The move is a journey, not a quick move, another item that the article points out and many managers forget.

    That being said, not everyone is moving their systems to the cloud. Even organizations that adopt some cloud services, implementing Salesforce as a CRM, might continue to run plenty of systems on-premises. Lots of companies use the cloud for IaaS, but with the architectures and software that used to run in their own data centers. They just moved their  VMs.

    The cloud can be successful in many ways, but you need to understand how you adopt the technology, what capabilities can help, and how limitations can hinder your software. There is no magic bullet, but there are a lot of opportunities if your organization takes advantage of them.

    Steve Jones

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

  • T-SQL Tuesday #139–A Hybrid World

    tsqltuesdayIt’s time for T-SQL Tuesday in June 2021, with a new host this time. Ben Wiessman (b | t), who graciously responded to my request to host, and to whom I want to congratulate on an addition to his family.

    In any case, for #139, Ben asks us about hybrid data. He’s a cloud advocate and someone that has been working with Big Data Clusters and Azure Arc. In fact, he’s written books on those topics(Azure Arc-Enabled Data Services Revealed and SQL Server Big Data Clusters), Bid , so I expected a topic related to those.

    Moving to Hybrid

    I haven’t dealt with hybrid in production at all. My work with SQLServerCentral, and much with Redgate and customers, is all either on-premises or in the cloud. All the SSC stuff runs as IaaS, and most of Redgate does. While we have a lot of local workstations and environments for dev, much of the infrastructure is in the cloud, without much hybrid stuff.

    I do see customers that developer locally and deploy in the cloud, which is something I’ve done, but not too often. Most want to do everything in one place. I don’t really consider IaaS as a “hybrid” despite it being in the cloud, because these are just VMs that could be anywhere, and there isn’t any real change if they live in Azure, AWS, or a remote data center my company owns.

    Experimenting in the Cloud

    The exception for me is Spawn. This is Redgate’s research project on hosted cloud databases that you might use for local development. I started working with this when it was early in the lifecycle, and now it’s something that I use regularly.

    Essentially you create a database, and it’s hosted in a container somewhere. You get a connection string back, but the database lives in a cloud service, and this is a hybrid environment.

    It’s an interesting idea, and while I haven’t made any large databases, I do find that the ability to programmatically start a database to be quite fascinating and simple. A few times when I’ve looked to update a demo project, the ease with which I can set up an environment on a new machine is fascinating.

    The team that manages our main demo made a number of changes in 2020. I had scheduled a talk on the platform and realized a week before that the old demo I had was broken. When I contacted them, they gave me these instructions.

    • Update the CLI tool
    • Update my repo from the “demo” branch of the repo
    • Open the folder in VS Code
    • Hit F5

    That’s it and I had a running environment right away. I did a talk on this at ConFoo 2021, and it went well. The ease of getting things running even impressed me, as I hadn’t dealt with the front end side of things as often. Amazing.

    To me, this is where the hybrid cloud gets interesting, when I easily access resources either locally or remotely.