Category: Editorial

  • Coming Out of the Cloud

    Google has launched a version of their AlloyDB that can be installed on-premises. AlloyDB is a PostgreSQL compatible cloud database, a full-managed PaaS service. However, they are giving away a free developer edition and a paid for commercial license that can be installed where a customer wants to run it. The new product is called AlloyDB Omni.

    I like Google’s approach here. Obviously Google would prefer lots of their customers would move to the cloud version hosted in GCP (Google Cloud Platform), but they know that’s not realistic. Even for customers that want to move to GCP, the customers might need to keep some workloads on-premises for a period time, so Google is giving them an option to modernize their workload with a new datastore that is PostgreSQL compatible, but running on-premises. Presumably this will be compatible with the cloud version and if customers want to, they can just shift to AlloyDB.

    This is similar to what Microsoft is doing as Azure SQL versions, both  database and Managed Instance, are mostly compatible with SQL Server on-premises. There are easy migration paths, but since the cloud and local versions aren’t quite the same, it might not be simple to migrate. There are lots of tools to help, but the biggest problem (in my mind), is having a development environment that mimics what I get in the cloud. I need to be able to work not only offline, but with the unlimited CPU I get on my laptop. I don’t want to pay for developers to stand up cloud instances to experiment with code.

    There is the SQL development container (running Edge), but that’s a container and I find far too many people don’t like working with the container versions. They struggle with getting their data set in the container, or keeping it up to date. Plus there’s the fact that the local environment seems linked to database projects, which not everyone uses. Especially those of us using Redgate tooling.

    I have been surprised in the last five years by how many companies have moved to the cloud. I’m especially surprised how many have performed lift-and-shift migrations to IaaS services after a mandate by management. I’m also not surprised that many customers find they’re spending too much, and that both Azure and AWS realize they need to help customers spend less before they lose them.

    The cloud can be a good place for workloads, but you need to plan for it, and often you need to modernize apps, make them less chatty, and write better code against your data services. To do that, I think you need a local dev environment and I like the way that Google is providing that with AlloyDB Omni. I wish we also had a switch to get a local SQL Server dev edition to act like Azure SQL DB.

    Steve Jones

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

  • The Loss of Knowledge

    This article has a great opening quote. It says: “We are drowning in information but starved for knowledge”. It’s from John Naisbitt, who wrote the book, Megatrends in 1988. I think this quote can be very apropo in organizations as we have data, we have plenty of reports deriving information, but sometimes we don’t have a lot of knowledge, especially when there has been turnover in our staff.

    We can train new people on many things, but not everything. The knowledge of the culture, of what others know, of the little strange bugs or behaviors that can’t get fixed, the tribal knowledge accumulated by living in an environment. These are the learnings that can’t easily be replaced, and until they are, often new employees are less productive.

    Of course, sometimes new employees will view the world in a different light and find solutions others haven’t considered. That happens, but it’s more likely that they will make mistakes, break something, or just be less effective than their predecessors.

    There are no shortage of articles, like the one above or this one, that discuss the concerns IT leadership has about employee turnover. Perhaps the leadership does see that as a problem, but often first level managers don’t. Often leadership doesn’t realize how poorly trained or effective first line managers are in working with their technical staffs. I sometimes think that the world in Dilbert is far too prevalent precisely because of very poor management skills. It certainly seems that efforts made to retain employees are relatively rare in many companies.

    In my career, we’ve had some boom and bust times in the market for developers. There have been times where anyone with a certification or a hint of experience could get hired (or get a raise). There were other times when people were careful to hold onto their jobs because finding a new one could be hard.

    I think employers should not only invest in their staffs, but work to train and upskill them, demand more from them over time, but treat them fairly with more than just a paycheck. The dividends from a hardware allowance, a training budget, and more can easily pay for themselves with better productivity and the lack of fees to recruiters. You should certainly hold staff accountable and responsible for getting work done, but make sure you also treat them fairly and support them.

    That’s if you also spend time managing your managers and ensuring they balance the demands they make of employees with the support needed to ensure their staff performs well. If you ignore the managers, you might as well ignore the staff, set aside more recruiter fees in your budget, and hope for the best.

    Steve Jones

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

  • Big Data Downsides

    Companies often want more data to help them make decisions on how they run their business. There has been this quest to gather and analyze as much data as possible to increase the efficiency of their operations to help reduce costs or increase profits. This has led to the importance of data as an asset, and the need for more data professionals in many organizations.

    That’s good for many of us that work with data.

    However, using data to try and improve your efficiency has a downside. It can lead you to a very narrow focus in your approach. That can be good in narrow, well-defined areas, such as minimizing the distance driven or packing containers. For less focused tasks, such as telling a story or writing code, this can mean you get stuck in a rut and limit your opportunities to improve.

    There’s an interesting article about big data and Hollywood, specifically looking at the types of products produced. Big data analysis leads companies to aim for the most effective types of movies that make money. Good for a company, not so good for society. Arguably, not even good for a company over time as people will tire of the same story, or type of story over time. Eventually, making simple decisions based on past data will start to fail.

    I can see the same thing in other industries as well. Using Big Data to drive decisions can help, but many of the areas where we use these techniques will evolve and change over time. The way we solve problems with code change over time as we develop new tools, techniques, platforms, languages, etc. There isn’t a perfect way to design a database or write a CRUD app precisely because new capabilities or new possibilities emerge. You could say the same things about marketing, manufacturing, medicine, and many other endeavors.

    This isn’t to imply big data and complex analysis isn’t helpful or useful. It’s just not everything. We need to balance human input, with some creativity, some instinct, some diverse thought, and some guessing. Most importantly, we ought to experiment and learn, not only from what machines might extrapolate, but from how humans change their thinking over time.

    Find a balance, accepting some imperfection in your process and in the world at large. Hopefully that will lead you to some success.

    Steve Jones

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

  • A Prompt Engineer

    No, Redgate Software isn’t hiring for SQL Prompt. I’m sure quite a few of you depend on SQL Prompt and would like more engineers working on it. Maybe a few of you would find that an interesting piece of software to work on.

    Rather, a Prompt engineer is someone that works with AI, trying to get a system to produce better results. I can’t decide if this sounds like an interesting job that stretches your brain or the equivalent of a mediocre developer that just keeps copying something from Stack Overflow, hitting compile, getting an error, and repeating that cycle.

    I can picture a scientist using their voice to continually correct some AI system by saying “no, that’s not quite right. I want to see more blue” or some other type of guidance. Is this job the equivalent of raising a digital toddler?

    I actually found one of these jobs on Indeed.com. For a company in San Francisco, a hybrid position paying between US$175k-335k to help create steerable AI systems. I’m not entirely sure what this is, but at that pay rate, it is tempting to learn.

    I think AI systems are fascinating, especially for someone that has done some development and can see how difficult it would be to specify an algorithm that can handle some tasks. Like composing some prose result. Or suggesting code based on what you’ve typed. These are some handy features that have been added to some IDEs and services.

    GitHub CoPilot is interesting, and if you haven’t tried it, I think it helps Java/C#/app programmers. Go watch some videos or sign up for a trial. I am not sure about these helping us in database work. There is probably a little more work needed before an AI delivers help for your particular database issue. However, I’ll be testing and working with some tools to see what I think.

    If you are interested in AI and have a lot of patience to train models, and a lot of patience to work on data cleansing and loading, then maybe you can find a new career in AI. It might be a fad, but I don’t think it will ever go away, and I do think there will be a lot of opportunities in this space in the next decade.

    Note: If you find this interesting, I had a discussion recently with a few others in a webinar.

    Steve Jones

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