Voice of the DBA

Tag: Cloud Computing

  • The Hybrid Cloud

    When various vendors started to push the idea of using the cloud for computing infrastructure, the focus was on moving all your systems to a hosted solution. It didn’t matter if you were interested in IaaS, SaaS, or PaaS solutions, there press from salespeople and even some technology professionals was for a complete migration. Put all your infrastructure in AWS, Azure, or some other place and your systems will run great.

    Over time we’ve started to realize that moving to the cloud isn’t as simple as just renting a new box or service and there may be plenty of work to get settled. Even then, there are some limitations or restrictions, either technical or otherwise that might make the cloud a poor choice. Security and compliance are often reasons to not move, but certainly there are also challenges with technology mismatches between on-premises and cloud platforms as well.

    One of the very interesting things that I saw demonstrated a few years ago was the idea of the Azure Stack. The idea behind this technology is that a hybrid cloud can be built, with a single management view. Both the Azure cloud and local resources are combined together and managed as a single entity, with the choice of whether to run workloads on the vendor’s infrastructure or your own on-premises machines. There are other versions of this, for example, with OpenStack working in conjunction with AWS.

    There are many advantages to this, including the ability to limit certain workloads from bursting or moving from one environment to the other. One reason for this might be compliance. An organization might be required to keep some resources off of public networks, for example, the need to ensure that certain data is domiciled in a particular country. The reverse could also be true, with the desire to use a secure public portion of the Azure stack as their system might be certified in ways that your local infrastructure may not be.

    I think the idea of cloud resources, managed, moved, and scaled as needed is a great one. It doesn’t matter if this is all in your data center, all in the cloud, or both. Working this way allows a much more flexible use of any resource, wherever its located. Cutting edge organizations already do a small portion of this with ESX or Hyper-V hypervisors, software configured storage networks, or other software configured resources that can be reallocated on demand. Azure Stack, OpenStack, and other frameworks are a great way to start to leverage the cloud, but in a controlled manner that continues to use any capital investments you’ve made.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 4.1MB) podcast or subscribe to the feed at iTunes and Libsyn.

  • Cloud Snake Oil

    I’m sure that those of you reading this have a variety of opinions about the “cloud”. Actually, I’d guess that many of us have different definitions of what the cloud actually means. That’s fine, since it’s really an amorphous, marketing term that encompasses quite a bit of different technologies, services, and products from many different companies. Some of you might use the cloud, and if you do, then perhaps this will ring true to you.

    I was reading Dr. Greg Low’s blog, and he asked the question in a post about what a managed service was. In this case, Dr. Low was looking to host his blog on some service, and apparently the definition of a managed service varied from provider to provider. His first provider didn’t tell him that backups were being run, with each file being counted against the space that he’d contracted for. When he asked for them to be deleted, he was told it would take a day or two as there wasn’t anyone to provide the service.

    He continues looking at how other providers define service, which does vary, but the interesting thing to me is that many of these companies aren’t really providing management of systems. They’re selling you a product, which has some capabilities, but they aren’t really managing anything. At least, that is my impression. I know if someone asked me to manage a system, I’d expect to deliver some level of service that would be useful for the client.

    In the cloud, it’s really a wild west version of computing, where companies want to sell you some service, often touting various management aspects, but they may not necessarily provide the level of service you expect. Cloud vendors, even worse than other computing vendors I’ve dealt with, want to work at scale, and they want to standardize how things work as much as possible. They don’t want to engage in person to person communications if possible. I learned this lesson with Google and their products, few of which had any way for a user to contact a help desk.

    Apart from that, what I’ve seen too often in the cloud is that a company wants to offer some service or capability, but they don’t often have the tooling available for end users. This is especially true for new services, where it seems the purchase process works flawlessly, but the configuration or cancellation process doesn’t work, or might not even exist.

    The one piece of advice I’d pass on from my cloud experiences is that anyone using services needs to reconcile their bills regularly. We can add resources easily, but removing them is hard, and often a customer service person promising removal doesn’t follow through. I’ve had people in the support centers not even be sure of what resource I was referring to when requesting removal or credit. It’s a frustratrating experience that has led me to adopt another habit. I grow resources very slowly, ensuring that I know what the billing is and that I really need the service. That seems like the opposite of what the “cloud” is supposed to offer.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 3.7MB) podcast or subscribe to the feed at iTunes and Libsyn.

  • A New New Microsoft

    Microsoft is changing again. Microsoft is reorganizing and the head of Windows, Terry Myerson, is leaving. The reorganization isn’t that surprising, as like most large companies, Microsoft usually does something each year. What is interesting is that they are moving away from their major divisions focusing on products. We’ve had divisions for Windows, Servers, Devices, etc. Now we move to Experiences and Devices as one major group. The other will be Cloud + AI Platform, which seems more product oriented, but still is rather amorphous. Gaming is still separate and there’s still a large Research engineering group.

    Why are they doing this? There’s some thoughts at ZDNet and Geekwire. It seems that the cloud is becoming the most profitable part of Microsoft, and I’d expect that we will continue to see more push for cloud and subscription type software. Along with the advances in AI, Microsoft seems to be hoping that more of us will start to do work using their infrastructure. That makes sense for some, but not for others.

    For those of us using the data platform, I do think that we ought to be thinking cloud first unless we already have substantial infrastructure and automation capabilities to quickly stand up new instances. As development and other departments look to get work done, especially around data analysis, we need to meet their needs or many people will start to use the easy to provision and use cloud services, especially those for machine learning and AI. Companies are entranced by new technology, even if we aren’t, and the media hype around ML and AI will put pressure on us to do better. We don’t need to learn R or Python, but we should be able to run those scripts against data if our business demands the capability.

    The GDPR and other security initiatives might seem to slow cloud deployment, but in many cases the cloud isn’t more or less secure than our own systems. Certainly we may have issues with privacy with the new US CLOUD Act, but for most of our businesses, that won’t really matter. The conflicts there are more around illegal activities, and if you are in that space, US based companies might not be your choice for hosting data.

    For many of us, we do need to understand how to build and enforce more secure applications, and I’d argue that Azure makes this as easy any any other system. Our recent move at SQLServerCentral to AWS was essentially the same as if we’d have moved to a VM at Azure, Google, or even back to the Redgate office. The systems look the same, it’s the cost, the firewall and networking, and things beyond the data platform that are just different. And that’s the key, they’re not necessarily better or worse, but different.

    As Microsoft changes, I think their code quality improves, though certainly their rapid pace means that people getting updates too quickly are on the bleeding edge. Their DevOps deployment, however, means that the bleeding edge usually doesn’t last tool long if the issues are severe.

    Steve Jones

     

  • Cloud Safe

    I saw a question recently from an individual that was trying to decide if it made sense to move their databases to the cloud. In this case, management wanted to move, but the technical staff had concerns about Disaster Recovery in the cloud. These are very valid concerns for any system, as technical staff is often responsible for data, regardless of who decides on the architecture of a system.

    The concerns got me thinking a bit. Is the cloud safer for DR? It’s certainly an “it depends” question, especially as the “cloud” isn’t necessarily the same thing for each of us. Some of us would use IaaS, with VMs in the cloud. Others might choose PaaS, with RDS or Azure SQL Database as a platform. Still others might want something like Managed SQL Instances, which is like IaaS+, or maybe PaaS#. I’m not completely sure how to classify this.

    In any case, your choice of cloud architecture can mean better or worse DR. The closer you are to IaaS, the more that you still have the same responsibilities that you might have inside your own data center. The difference is that hardware replacements or options are often quicker to procure, though perhaps with limited choice.

    If you choose PaaS, then you have different DR capabilities and responsibilities. Your vendor might handle some aspects of DR and remove the need for you to worry about hardware, or regular backups, but you might need to worry about other items. Your vendor might give you PIT recovery, but you might not want a database replacement in a busy system, especially if you’ve processed a few thousand transactions since someone ran that UPDATE without a WHERE batch. In that case, perhaps you want to ensure you can restore your database elsewhere, or you have other options.

    Many of us know that managing systems is complex work. Not every environment can be handled in the same way, and we often implement exceptions in both technology and staff knowledge. Ensuring your application and environment can recovery from a DR situation often requires detailed knowledge of both requirements and capabilities of the environment. While I’m not afraid of migrating to the cloud, I’d want to be sure I was prepared to answer questions from management if there are issues. After all, they’re going to look to me, not some vendor, for answers.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 3.4MB) podcast or subscribe to the feed at iTunes and Libsyn.