Voice of the DBA

Tag: Cloud Computing

  • Re-Evaluating the Cloud

    Last year 37 Signals (makers of Basecamp and Hey)  announced they were leaving the cloud. I wrote about the decision, and wondered if they’d look back at this as a great decision or one they’d regret and backtrack to the cloud again. They planned to build their own tooling, buy a bunch of servers, and run their own data center (or rather, rent space in someone’s data center).

    Recently there was an update, in an FAQ, about how the transition has gone. In short, very well. One of the founders, David Heinemeier Hansson answered several questions about the move and the financial status. They didn’t hire more people, so their payroll is the same. They used a service to unpack and rack their servers, so they could just connect to them remotely and not deal with hardware. They built their own redundancy across two data centers where they rent space, and they think they will save well over $7 million in the next 5 years. They had a $3.2million cloud budget per year, so that appears to be halved (3×5=15 – 7 = 8ish) with their move.

    There are some answers to various questions, which are likely of interest to many data professionals who might feel pressure to move to the cloud. First, they discuss resource optimization in the cloud. I think that’s really hard, to do well and if they gave the details of what they’d done, that might help others decide if 37 Signals did a good job, or if there are things others could do. I think many people might struggle to optimize their usage, especially if you are only responsible for one thing, like the database. In many orgs, once something gets deployed, or developers build a PoC using some cool, new service, it’s hard to get rid of it or even change how it’s used. I think 37 Signals has some agility here that many orgs struggle to implement.

    Rewriting things are cloud-native is the way to go, in my mind, and I do have customers and clients who see applications working better in the cloud. However, I might argue that rewriting applications is hard and expensive, and many companies aren’t great at writing software that’s efficient, so rewrites are hard. I also think in most organizations, developers struggle to understand what cloud-native means. I think DHH is a little off here, as their developers probably could make better software written for the cloud, but they didn’t want to spend the time and/or money.

    The points about security and reliability are fair, but I think those are a function of having good people implementing systems. You can get good security and reliability in the cloud or poor implementations of either. The thing about security is that the overall protections that detect some of the DDOS or attacks are better with Azure/AWS, but simple SQL injection or open firewalls are still a problem. Authentication and security are just hard for most people and often people do this poorly in the cloud. To be fair, most people don’t do this well on-premises, so at least in the cloud, there are some services/scanners/checks that let you know when you’ve messed up. Whether you change or implement their suggestions is another whole debate.

    Is reliability better? AGs are hard in SQL Server, as are distributed clusters. The cloud services do this better for most people, but maybe not for you. That brings me to his super engineer point. He doesn’t think he has super engineers on staff, but I disagree. I think they can pick good people, especially because of their profile, and they don’t need a lot of people, so their average engineer is likely better than the average engineer at most organizations. They built some great software, and they’ve built an amazing framework and tooling to deploy their software. Don’t tell me that’s even close to the capabilities of the staff at many organizations. We have really good engineers at Redgate, and I think we’re above average as well. I don’t know how we compare to them, but we haven’t had people publicly write and release code that thousands of other developers use. At least not at quite the same high profile level.

    The cloud has its place. It can work well and it can be very expensive. This journey is worth sharing with your management if they want to move to the cloud, especially if they want to lift and shift. That might create some flexibility and CapEx/OpEx changes that are worth it, but you ought to debate and question whether that’s reality or marketing hype from a vendor. After all, it’s not clear if a cloud move is really something that returns an ROI or one that reduces your profitability.

    Steve Jones

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

  • Ten Database Commandments

    I love the Notorious B.I.G. His music isn’t for everyone, but I enjoy it. This piece takes one of his songs (NSFW – Ten Crack Commandments) and applies the list to databases. Each item from the song is listed, along with the way it might be changed for database work. The list is from Ottertune, which is a service designed to help you optimize your use of AWS RDS and Aurora databases, with AI. If you believe their hype, their service will get better performance and lower costs for you.

    In any case, with regard to databases, I suspect that the author is having some fun with the rules, and a few of them made me smile. They are cloud-related, but a few will apply to any environment.

    The first one is about budgets, noting you should not disclose your budget, which is in general a good rule whenever you are buying something. Don’t disclose information, and someone working for a vendor of tools, I think that most budget conversations aren’t something technical people should worry about. Decide what value you get from some tool/service/process/etc. and if there are time savings. Then let someone else decide if the ROI is worth the cost.

    Rule 2 is a stretch, but I do think that looking at new tools can be helpful. The caveat here is that many people, don’t often learn enough about existing tools to understand if they will solve issues. There are a lot of things you can do with many tools, so don’t just look for some magical new tool. Learn to use your tools well, and if you want to try a new one, keep in mind you will need to invest some time both learning about it and practicing some skills before you really know if it’s helpful. The other thing to remember is every new tool increases the bar for new staff. Try to limit the number of tools you use to those you need.

    Security is important and rule 3 is remembering not to give out more permissions than needed, especially to developers. I love this quote: “You don’t want randos at your organization logging in and running queries that they found on Stack Overflow.”

    A number of the other rules have to do with performance, which is certainly Ottertune’s business, but these are good basic practices that I see organizations not following. Too often management wants to save money and technical people make decisions that compromise performance. Lots of people overload systems, and then they can’t handle the workload well. I get that many CFOs and others want to see high CPU usage, which means they’re using the resources they pay for, but databases can be very bursty with resource usage. At the same time, you don’t want to over-provision resources because you are scared. Learn to find a balance that doesn’t waste money, but handles your workload well.

    Perhaps one of the best things about the cloud is that if we do make bad decisions, we can often provision more resources. It can take time to move to a new tier of service, so don’t expect instance response up or down, but if you need to double the CPUs for month-end processing, you can likely plan for the time to scale up your database instance and then scale down again when all the work is complete.

    It’s a fun article, and if you’re looking for some fun Notorious B.I.G.-related database content, grab a cup of coffee when you need a break and a smile.

    Steve Jones

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

  • Flexing for the Cloud

    Many of us in technology regularly experiment with new tools and technology. We often do this to adopt new skills when we need to solve a problem or we have inherited some code that needs enhancement. The cloud is in many ways no different than things we’ve done before, but the way we do them, or maybe the way the cloud handles some things, means that we need to change how we view a task or perform our jobs.

    Migrating to the cloud is something that many of us have had to tackle at some point. I’ve seen a good amount of lift-and-shift, including many companies who just mandated moves to the cloud without much planning. As mentioned in this article, that was cloud migration 1.0. Really, I think this was something that’s been going on for years, and continues to occur today. Lots of management are seduced by the promises of the cloud to make their organization’s IT systems better, so they move everything without thinking.

    Then many run into cloud migration 2.0, or maybe that’s coming. I see plenty of customers with things in the cloud they complain about much in the same way they did on-premises. Nothing has changed with regards to how their systems work, and they are likely spending more money on the same services they had on-premises. With the same people. They didn’t plan well, didn’t provision well, and they haven’t changed anything but their costs.

    Cloud migration 3.0 is what many tech professionals would like to see. Evaluate apps, decide which benefit from the cloud, and leave the rest alone. Leave them on-premises in a familiar environment. That’s hybrid, but that’s fine.

    What many tech professionals worry about are their jobs, so they don’t often consider where the cloud can provide benefits from some apps. The flexibility and scalability are undeniable. You just need to ensure that you understand where the cloud fits, where cloud-native can benefit your org, and then make sensible recommendations.

    No matter how your organization approaches the cloud, likely you’ll have engineers from the provider or third-party consultants involved. Do what I do with people I’ve hired: ask a lot of questions. You’ll learn something, flex your knowledge, and even if you never work in the cloud yourself, you’ll be better prepared to make recommendations and evaluate future choices.

    Steve Jones

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

  • The Cost of the Cloud

    Basecamp (formerly 37 Signals) is quitting the cloud. One of the founders gives some reasons, and he had some detail in a tweet on what they’ve spent in the cloud the last few years. Over USD$3mm on various services, though their costs in search seem very high. I don’t, and haven’t, run as busy a business as they do, so I don’t know if they’ve truly done a good job architecting things and setting up services. They say they have, though I’d expect everyone to say and think that.

    However, I’ll assume they are correct and they can’t optimize things any more than they are currently. Their decision makes some sense, and I agree with it. I’ve been surprised at the growth of the cloud, both in size and how quickly people are moving to the cloud. I’ve also been saying for years that if you have a steady or known workload, the cloud is likely very expensive.

    Maybe that’s worth it for your organization. Not dealing with physical resources, maybe having slightly less staff, maybe less CapEx vs. OpEx. Those are decisions for management and finance people. For most of us, the cloud both simplifies some tasks and makes others more complex. Provisioning, testing out Proof-of-concepts, and scaling are easy. Identity protocols, gaining (and keeping) knowledge of how various options work (networking, storage, etc.) , and keeping track of resources become more complex. Not to mention the world constantly shifting under your feet as cloud providers change how their platforms work.

    There are costs in both hard dollars (or your currency of choice) and in the time your staff spends dealing with a new way of doing business. The calculation of whether this is a cost that makes sense is very dependent on your situation. I have customers that love the cloud and others that hate it. The value they get varies dramatically and some would never go back to data centers while others are ready to work long hours to leave the cloud. Overall the sentiment is the cloud is great, but like many decisions made by management there are particulars that baffle the technical staff.

    The one thing I have learned about the cloud is that it takes a different sort of mentality from staff than on-premises resources. We have to learn to spin things up and down, scaling as needed. We need to better understand budgets and not look at costs as though they were personal expenses. We also need to be flexible with resources, understanding that machines that are idle are not sunk costs; they are ongoing costs.

    The cloud is amazing, and I think it is very useful in lots of situations, but a blanket move to the cloud can be expensive. Make sure that everyone involved in moving to the cloud understands that.

    Steve Jones

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