Tag: Cloud Computing

  • Why Billing Will Be Part of Our Job

    I am old enough to remember when many large corporations implemented chargebacks. Essentially, each internal department was charged for their usage of IT systems, similar to how we are charged in the cloud. It was a mess, and individual departments had to answer for excessive charges. I don’t know that any department ever lost service, but their shared of the IT budget was certainly discussed in management meetings.

    These days more and more of us are going to move systems to the cloud, and some of those systems moved will be databases. We may not move all our systems, but we will move some, and the ongoing cost of those systems is something that we will periodically be asked to justify. In the past, we rarely dealt with billing, usually just when specifying and procuring new hardware or requesting a VM.

    Moving forward, I can see us spending time every quarter, or likely every year, analyzing the resources we are paying for and then determining if we are overspending.

    Or, if you’re proactive, perhaps you’ll start looking at costs and performance, as Brent did, and try to write better code to reduce your outlay every month by more efficiently using resources. Have you built in-efficient designs? Are you pulling back too much data with SELECT * from a table or view? Are you building code that recreates the N+1 problem?

    We’ve known for years that writing good code to interact with databases can prevent scale problems and overloaded hardware, even with large workloads. Many case studies over the years show SQL Server backing extremely large databases and busy workloads. Multi-TB databases with thousands of concurrent clients are common these days, and often we find that workloads at clients would easily be run on existing hardware with some better code.

    For some of us, the refocus on the cost of systems may give us some help in pushing developers to write better code from the beginning, learn to use efficient patterns and avoid anti-patterns, and perhaps even get more time to tune systems. However, those are skills that many of us need to improve, learning how to find code that can be improved, and what techniques to use to do so. We have lots of articles that help, as to Brent Ozar, Erik Darling, sqlSkills and others. There are lots of ways to improve your skills, and they can help improve your bottom line. If you work on them.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Cloud Migration Challenges

    Like many of the trends in technology, I’ve been skeptical of the movement to the cloud. Quite a few people that I have discussed this with across the last five years have had concerns, and real challenges with latency, performance, and cost. The cloud hasn’t always been cheaper, with more than a few people having larger bills than expected.

    Across the last couple years, the trend seems to be changing, which is certainly reflected in the growing revenue Azure, AWS, and other providers are reporting in their annual reports. More and more companies are finding the cloud valuable, and the cost to be acceptable. While the cost still might appear to be larger than on premises, the lack of commitment and the change from capital expenditures to operating costs seems to be worth the move.

    Moving to the cloud, however, takes some work. Certainly your applications might need to change, but as compliance becomes a bigger concern for organizations, there is some good advice in this piece about secure cloud migrations. I think understanding your current security and how this can be improved or adapted to a cloud vendor’s architecture is important. Far too many people think about security after infrastructure is in place, which often results in poor security.

    This is one place I think the cloud can be more secure. Since the vendors don’t want issues between their customers, and certainly try to avoid issues on their own networks, the cloud platforms inherently ask for more security as you provision and deploy systems. Certainly there are companies that just open up all networking to get systems to work, and I hope this is the minority. Anyone moving applications to the cloud should configure secure networking, and limit access between resources wherever possible. Just like we don’t want applications using “sa” to log in, we don’t want every machine able to access every other machine. We certainly don’t want every user or application able to connect to every other one.

    I do think the cloud plays a part in the future of most organizations. Not all, but most, with any type of workload and application you may have. The performance continues to improve with new offerings, as well as the flexibility. The costs rise and fall, but the ability to scale up and down can make this option very attractive. DR is superior to what most of us can build on-premises, certainly in any short period of time, and there are sufficient security options that work very well for almost all of us. The challenge for most of us, and our organizations, is learning to implement them correctly.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • The Clear Cloudy Future of Databases

    One of the things I’ve advocated across the last few years is the need to learn more about the cloud and be aware of the database options. I have written many pieces, including asking the question of whether or not you should be thinking cloud first. More and more companies are thinking that way, as you can see in the revenue growth from Azure, AWS, and GCP. This is a trend that is continuing to grow and I doubt it will stop anytime soon. I see many management and technical people more interested in the cloud than worried about it, and the numbers of adopters continue to grow.

    Gartner is a source that many organizations use to try and plan for trends in the world. With much of our choices sometimes impacted by technology media, plenty of managers look at their reports. One of Gartner’s latest reports is worth reading the short blog summary: The future of database management systems is the cloud. In this blog, Donald Feinburg summarize their report that the cloud is first, it’s the future, and that only legacy requirements should keep you on-premises. I tend to think that as well, though I think your investment in an existing platform is reason enough to stick with it for now. I also think that very predictable workloads, without any large spikes, are likely worth keeping in house.

    One neat thing is the market share trends of various platforms from 2011-2019. Microsoft comes in at #3 to start, but comfortably in #2 for the last few years. If you look closely, you’ll see AWS has grown to take the third spot from IBM, and Google is growing rapidly for a platform with the fewest years of availability. Looking at some of the others, I see downward trends from a number of on-premise vendors.

    The cloud offers amazing flexibility in both cost and performance. If you’ve looked at any of the cloud database platform vendors, they offer great scaling options for those times when things run fast  or slow. We have a customer at Redgate that actually scaled up their Azure SQL Database for a few hours to meet a workload jump. Going from tens or hundreds of dollars per hour to thousands isn’t for the weak of heart, but if it’s just a few hours and you scale down, that’s the flexibility that isn’t available on premise. At the same time, scaling down when you were overly optimistic about a workload can save a lot of money.

    Whether you like the cloud or not, it’s permeating many organizations, and it’s a skill set you should spend time learning. After all, even if this employer isn’t interested, there’s a good chance that the next one will be.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Cloud Pace

    Recently, a user responded on SQLServerCentral to something I’d written on Azure, asking how do I keep up with all the changes. I wrote back: “Between the complexity and pace of change, I’m always learning something.”

    To be clear, I don’t really keep up. Even just trying to read all the Azure Announcements can be overwhelming, especially if you want to set up a quick demo on any of them. Even trying to get through the (free) e-book, The Developer’s Guide to Azure, was a chore. There were so many things I hadn’t heard of or barely knew about that I had to stop myself from logging in and trying something to get to the end.

    The Cloud isn’t really anything new. Not very new. All the IaaS stuff has been around for a long time, where you could rent a machine from some data center owner. The PaaS stuff is a little new in its implementation, but the idea is what many developers have dealt with in organizations where they didn’t have any administrative privileges. The database was just a database, no server involved.

    The biggest change I see with the “cloud” is the pace of change. Companies lose some of the overhead of dealing with different departments and getting resources provisioned. Because cloud vendors are working at scale, they’ve built tools that allow customers to spin up new VMs, databases, even clustered systems in minutes. Much of the tedious complexity has been removed, which allows users to just move forward with building systems.

    The move towards DevOps, with a focus on automation, means that vendors also build new platforms, capabilities, and options that we can use at a furious pace. The choices we have can be overwhelming at times, with no one person really able to keep up with the myriad of possibilities.

    To me, this means two things for your company. First, you always need to have some experiments running. No proof of concepts that will be turned into applications, but true developer or operational experiments where people try out an elastic pool or machine learning or a K8s replica set of Hello, World containers. Your staff needs to be learning and sharing with each other in small ways.

    The second thing is that you need to limit the technologies in use. While there are many amazing and useful new services, you can’t bounce between them and support an unlimited number of choices. Limit the number of technologies (languages, frameworks, platforms, services, whatever) to the few that get the job done, with a process to add new ones if a rational case can be made.

    The bottom line is that it is important to keep learning, evolving and using better technology over time, but we have to be sure that most of our time is spent working on the software we’re building, using the knowledge we already have. We’re paid to get work done and while learning is a part of that, it’s a small part. Mostly we need to be doing the other parts of our jobs.

    Steve Jones