Voice of the DBA Steve Jones

I have worked for a few startup companies, including SQL Server Central. Each has been a different experience, and I learned a lot at each stop. However, I'm not sure I'd want to go through that process again at my age. I was thinking about the challenges and the excitement of being at a startup while reading about the founding of Reddit. The post doesn't go a lot into the technical details or the working life, but it is an interesting read from a VC investor.
I also found this post on Choosing Startup Life, which talks about what the author thinks about before trying to start a company. He compares this with life in a Big Tech company, which relates to lots of companies, in technology or not. The main differences are lower salaries, less infrastructure, lots of work, and upside in a startup. Big companies have higher salaries and more perks, less stress and responsibility, and not a lot of context-switching. In general, that's been true in my experience, though in bigger companies that didn't think they were software companies, I sometimes could end up with a lot of context-switching.
Read the rest of Life in a Startup

When we build software, many of us use the same algorithms to solve problems. We might choose a similar method for a quicksort or a lambda validation or a regular expression. For database work, your code for a running total (or other common challenge) is likely very similar to many other people. At least on the same platform. You might solve this differently in SQL Server and Oracle, but for the same type of database, many of us write very similar code.
Actually, for many developers, they copy and paste an answer from SQL Server Central, Stack Overflow, or another site. I'm not sure if I think this is good or bad, as it's a good idea to reuse code if it solves the same problem. If you copy it and don't test it, that's bad. After all, the code might not solve your slightly different problem if you don't check it.
Read the rest of Common Algorithm Concerns

Several years ago, I heard about a new product coming in Azure that would provide an IaaS (infrastructure as a service) VM to run SQL Server, with Microsoft managing most of the admin tasks for the instance, like patching and backups. That didn't seem like a big load to me, and I wondered if anyone would actually pay for this product. After all, don't most companies find managing patches and backups?
That product became Azure SQL Managed Instance, and I've been surprised at the adoption. Quite a few clients have adopted this as a way to lift and shift (mostly) to the cloud in an easy fashion without the restrictions of Azure SQL Database. This looks like a "normal" on-premises SQL Server, and there are both high-performance (Business Critical tier) and average-performance (General Purpose tier) versions of the product that let you choose what level of price/performance you need to achieve.
Read the rest of Managed Instance Impressions

Most of the people I know who speak at a SQL Saturday or user group aren't paid for their efforts. At many of the community events, the speakers are volunteering their time. Many are also paying for their own way to those events not located in their area. A few, such as me, might get a company to cover their travel expenses, but often this doesn't include time. If I attend a SQL Saturday, I still have a bunch of work on M-F that needs to be done. No comp time for these events. That being said, I'm happy to donate some time and money to community events.
Some speakers build and teach full-day sessions, usually called pre-conference sessions, for which they are paid. There can be competition at large events like the PASS Data Community Summit and SQL Bits to get a session since the payment can be rewarding. I've seen some speakers make USD$1k or so, which can cover travel expenses, and others make over USD$10k, which is a nice payday.
Read the rest of The Costs and Rewards of Speaking

This article has a concept I've never heard about: invisible downtime. This is the idea that there are problems in your application that the customer sees. Your servers are running, but the application doesn't work correctly or is pausing with a delay that impacts customers. From an IT perspective, the SLA is being met and there aren't any problems. From a customer viewpoint, they're ready to start looking at a competitor's offering.
Lots of developers and operations people know there are issues in our systems. We know networks go down or connectivity to some service is delayed. We also know the database gets slow, or at least, slower than we'd like. We know there are poor-performing code and under-sized hardware, running with storage that doesn't produce as many IOPs as our workload demands. We would also like time to fix these issues, but often we aren't given any resources.
Read the rest of Invisible Downtime

Kubernetes is cool, and I think it's really useful in helping us scale and manage multiple systems easily in a fault-tolerant way. Actually, I don't think Kubernetes per se is important itself; more it seems that the idea of some orchestration engine to manage containers and systems is what really matters. As a side note, there are other orchestrators such as Mesos, OpenShift, and Nomad.
However, do we need to know Kubernetes to use it for databases? This is a data platform newsletter, and most of us work with databases in some way. I do see more databases moving to the cloud, and a few moving to containers. I was thinking about this when I saw a Simple Talk article on Kubernetes for Complete Beginners. It's a basic article that looks at what the platform consists of, how it works, and how to set up a mini Kubernetes platform on your system. It's well written and interesting, but ...
Read the rest of Kubernetes is Cool, But ...