Voice of the DBA

Tag: Cloud Computing

  • Serverless

    About a year ago I kept hearing about serverless as the way to go for all new code. It seemed every conference, every cloud vendor, even many developers were discussing serverless as a technique for running small snippets of code. This technology seemed to burn very bright, but then dropped out of the media somewhat. It’s still being adopted, but seems less popular than a year ago, with containers and Kubernetes becoming more popular this year.
    Serverless computing is kind of a backend-as-a-service (BaaS) or a function-as-a-service (FaaS) architecture where you write and deploy functions on a cloud service that are called by your application as small chunks of functionality. The pricing is by the execution, with a very low cost for resources. Azure Functions cost US$0.20/million calls and US$0.000016 / GB-s. Strange metrics, but the result is a very low cost for most clients to use a functional part of a system. The key is that there are not infrastructure worries. The serverless platform provides the CPU and RAM needed to execute a function, with storage also available on the cloud provider’s platform.
    I ran across an interesting article that talks about serverless platforms on premises don’t quite make sense. The idea with serverless is that you most closely pay for what you use, not being charged for times when your code isn’t being executed. On premises, you would need some hardware running all the time that you are paying for, which is ready for when code is called to execute.
    I’d disagree slightly, especially with architectures like Azure Stack that blur the line between private and public cloud resources. With Azure Stack, you should (at some point) be able to write applications using serverless functions that execute in your data center. If you need more resources, you scale your data center up with Azure cloud resources, and pay for your usage. When the workload shrinks, you stop using cloud resources and just use your data center.
    Most of us won’t necessarily want to run an Azure Stack, so why would be use serverless on premises? To me there is one element of a cloud service I can’t control: what other people do on the platform. Cloud services are large and distributed and in use by lots of customers at a time. If I execute things in my data center, on some serverless platform, I have better control over how things work and likely more predictable performance. If my workload is well known, I also probably have lower costs.
    In many cases, we know the workloads of our databases, and we want predictable performance (however good or bad it is). Databases are potentially a good fit in the cloud, but often in a mature application, we would be better served by keeping the database on premises, especially if we’ve already invested in the hardware and other resources.
    Serverless is a very interesting idea, as is much of the cloud. It might suit your application, or it may not, but you have to think about the requirements for your situation. Knowledge of new options and technology is important for us to intelligently debate and discuss what works best for our organizations.
    Steve Jones

  • Protecting Data Between Services

    I saw an announcement this week that Microsoft is shutting down their HealthVault service, where someone might have chosen to store their medical records in a way that it could be shared with health professionals, but an individual could maintain control of the records. They could share them out to friends, download them, etc. It was a good idea, and I was interested in it for the future. Since I have been fortunate to mostly avoid doctors and hospitals, I never signed up, but I still could as of this week.

    Google used to have a similar product, but shut it down a few years ago. I suspect that this commercial space just isn’t as lucrative and valuable as either company thought, as I don’t really see any competitors out there that might allow a user to transfer their records. While I don’t know that there needs to be a service for this, I did think of the hassles and potential issues that might exist if there were. Imagine your mother or grandmother keeping their health records here for the last decade and now needing to download them and manage them before they could be used again. What if someone downloaded these to a PC and had a hard drive failure?

    Backups are needed, we know that, and I’d hope most consumers know that, but in a rush or in the worry that these need to be copied, but securely, would you want to keep this data on a tablet or PC? Or would you want an encrypted drive. If that’s the case, would you want to ensure you have 2 (or more) of them? Easy to plan this out, hard to think about if you get a notice about the service shutting down. Imagine that your spam filter knocks this down or you’re inundated and miss it and get a final notice on Sept 1 or Oct 1? A real hassle.

    The higher level view of this in my eyes is that we need better data formats for capturing and keeping lots of our data in systems. Those of us that are impacted by the GDPR (or similar laws) might be thinking about this already, as we have a need to provide data in response to requests. Providing a report, and packaging this up, is no small task. I assume I’d use a .zip file, but maybe a .nuget with a manifest is actually a better idea for customers.

    As the use of services grows, I expect that we will want to get more portability for data over time. Certainly vendors that provide services have an incentive for tooling. WordPress has import/export for other blog services, Microsoft will help you move data from Oracle (as will Oracle in the other direction), and there are specialized vendors in niche applications doing the same, but really I’d like to see us have more open, and extensible, data formats that relate to the types of data in our lives. I know we’ll have more disparate types of data, in various formats, so why not an easy way for each of us to store text, images, and more as a service that contains some metadata, some indexing. A personal data lake of sorts.

    We could have other services, like image services, visualization services for numbers, and more be authorized (or de-authorized) for our data. Imagine a way for us to allow a company to hold our data, but we disperse that to other vendors as needed for services. I could easily imagine various “storage” vendors competing and allowing us to “port” our data to a new service as easily as we port phone numbers for mobile phones. Perhaps a whole new era of data storage and management is coming.

    Or maybe we’ll just stick with the current separated, proprietary, limited view of data that we manage on hard drives and USB sticks. It’s more likely, but much less preferable in my mind.

    Steve Jones

  • Cloud Native

    The cloud is an amorphous thing that isn’t well defined, but we do know that there are various types of services (IaaS, PaaS, Saas) that many of the cloud vendors offer. While IaaS is the easiest platform on which to move our software applications, it is fundamentally limited and lacks the scalability of the other services.
    PaaS systems offer the largest opportunity for systems that scale up and down, allowing the ability to meet workloads while ensuring cost savings by reducing resources when times are slower. To use PaaS, we often need to rewrite code to be cloud native as most on-premises applications do not run smoothly in the cloud. This often entails different code structure, connection handling, and other technical details in the software development.
    There is continued pressure to move both application code and databases to the cloud, often because of financial advantages. There can be a cost savings by reducing resource loads, as well as changing from capital to operational costs. Today I’m curious how many of you are moving to the cloud, whether wholesale or in a limited fashion.
    If you are moving any systems to the cloud, are you rewriting software to be cloud native? Or are you trying to lift and shift systems into an IaaS infrastructure? Do your teams think there is an advantage in rewriting code to take advantage of the cloud or is it too much work and effort? If you are moving to the cloud, are you doing any work to change and improve your database code. After all, a more efficient database will matter in the pay-for-use model.
    Steve Jones
    Listen to the podcast at Libsyn

  • Cloud Backup

    I think that backup and restore are the most critical things for any database professional to master. Whether you’re a professional DBA, a developer setting up a system, or a seasoned DBA, I would argue having your data safe is the primary task. Security comes next, then performance, availability, and a number of other tasks that could go in any order, but if we don’t have a way to restore our data when hardware fails, we’re in trouble. And given enough time, or enough difference pieces and parts, something will fail. If you can’t restore a system when a problem occurs, that’s what Grant would call an RGE.

    Over the years companies have moved to many different technologies to handle backups. Tape was common early in my career, but all disk systems, with de-duplication capabilities have become popular. I really don’t think about anything other than getting a second (or third) copy of data these days, so I can’t speak to any particular way of managing backups. However, for SQL Server, I do want the option to set full, differential, and log backups based on my RPO and RTO requirements.

    There seems to be a new trend for companies that I ran across: they’re moving to the cloud. Here’s a short slideshow of some stats that show cloud use is increasing. This is a survey, so it’s not all companies, but the trends are clear. More data is being backed up, and it’s likely easier (and cheaper) to use cold storage in the cloud. That makes sense since it’s data that you expect you’ll very rarely need to use in a restore.

    There are a couple of other interesting items I saw in the survey. The number of companies that are backing up more than 100TB grew quite a bit, even as the number of companies backing up < 25TB fell. That’s a sign that we’re capturing more data. Whether we need to, or whether legislation like the GDPR will get companies to trim some of that data, remains to be seen.

    Another interesting item is that more companies are testing their DR plans. Fewer never test them, but the frequency is increasing with more companies testing quarterly or monthly. That’s smart as we become more dependent on computer systems. I know some organizations can’t roll back to paper, as we’ve seen in a number of airline IT issues. If you never test your DR plan, I hope that you don’t have an issue when you can ill afford to find another job, becuase you might suffer those consequences. Really, I hope that you actually know this isn’t professional and you start working on ways to test a restore of service.

    More companies are moving to the cloud, and the resistance for security, cost, privacy, etc. reasons is going down. I think many of the concerns that both executives and IT professionals have had in the past are proving to be non-issues. This is especially true as more vendors institute government rated or more secure data centers as a part of their product offering.

    If you don’t like the cloud, that’s fine. If you don’t know anything about it except rumor, guesses, or hearsay, I’d suggest you learn more. The cloud is likely coming into your career, so learn a bit about it. At least enough to give reasons why you don’t want to move your data there. If you do, you might be surprised that the cloud is not that bad a place to be, at least for some workloads.

    Steve Jones

    The Voice of the DBA Podcast

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