I made the front page of dbatools, as a part of the community that is supporting this project. Along with quite a few others, I’m happy to be there and doing my part to make SQL Server administration and scripting easier.
Maybe I’ll even write a cmdlet some day. Since I keep working on my PoSh skills and playing with the various cmdlets.
The Internet of Things is coming, or maybe it’s a wave that’s growing underneath us right now. It certainly hasn’t crested if that’s the case, and I expect that we’ll see more and more devices, sensors, and applications coming in the next decade. We’ll get larger and smaller devices, commercial and industrial tools, some amazing innovations and some silly ones that will make most people roll their eyes.
I ran across an article with some pros and cons from the general perspective. Certainly security is a huge concern, and one that isn’t well addressed by many organizations. In fact, many of the demos of the Azure IoT hub don’t do a great job of showcasing security. I think the Azure IoT Hub is a great idea, with some well thought out security measures, but developers need to build in habits early, and certainly include them in their applications. Let’s leave aside security for a moment and stipulate that it is, and likely always will, be a concern and issue.
What about the data perspective of IoT? The age of new sensors and devices mean a glut of data, perhaps an overload. We may get a scale of data that we don’t expect and need to plan for more TB or PB sized databases. Those are serious challenges for any organization, and likely we’ll need archival plans to remove old data, or at least ensure we don’t have to scan it for queries. We might even need some sort of governors that prevent the errant “select * from table” queries that try to query 100 billion rows.
We also may see crazy rates of data acquisition as well. One of the strengths of some NoSQL platforms is that they handle quick streaming sets quicker than relational engines. In fact, in some domains we might not even want to bother storing all the data we can and may need to process this as we get the data, only storing certain samples or ranges. I worked with a stock market application once and the streaming of prices was enough to overwhelm our SQL Server until we learned to limit the data we actually needed to store in the system.
There’s also the chance we’ll get new, or different types of data that we aren’t sure of the value. Data that might not seem like there is an obvious use for it, but we’re just gathering the bits because a sensor or device captures them. This is where I see more intelligent analysis, more of the “data science” being used. Most of us won’t know how to create these queries, but we certainly will know how to implement and run them, which is a much simpler process. This also means we might need to learn more about to partition, archive, or otherwise move some data of OLTP type, transactional systems to help manage our loads.
I think IoT is somewhat scary, but also very exciting. New types of data, new applications, new uses for data, which will make our jobs very interesting in the coming decade.
Steve Jones
Another post for me that is simple and hopefully serves as an example for people trying to get blogging as #SQLNewBloggers.
A quick one today, and this one I remembered without looking anything up.
I recently needed the service name to kill it for a test. I was using the sc.exe command line and couldn’t get it to give me the SQL Agent service name. I could have hit Windows, typed services, scrolled down, found the Agent, right clicked it, selected properties, and gotten the name.
Or I could do this:
Get-Service | Where {$_.Name –Like ‘SQL*’}
That worked and I could quickly see all the names.
The only thing that threw me was I forgot the hyphen before “like”. One of these days I’ll actually remember that.
As I work with more server systems that help developers run Continuous Integration and automated releases, one of the things I see used often are variables. These are values you can set for a particular process and reference inside of that process. Great for setting server names, paths, etc. In releases, these are great for specifying specific values that change for each environment, such as the instance name or IP address.
As with many developer based systems, security is not always set tightly on these systems and any developer can access the build server to kick off builds, reconfigure a process, etc. That makes sense in a CI process, but not so much in a release system. This is one reason I do recommend a separate release server from the CI server. You can use Jenkins or TeamCity to perform releases, but is it a good idea? Have you thought through the security?
In the release servers, one thing that most systems allow the admin to do is use a variable for a password and mark it secret, so the value cannot be recovered. In this way, if some developer is working on the release process, they can’t get the password to the production server. They can only click the buttons that deploy to that server.
However.
They can deploy to that server, and they don’t need the password. If I were to execute a script in the release system that executes the “CREATE USER” and a “ALTER ROLE ” commands to give me access to data, does it matter if I know the deployment password is “G4da%$2h#5f” or $(ProdPwd)? It doesn’t. The actual value isn’t relevant; I just need to be able to use it.
I think release systems are great pieces of software for reducing the risk of your deployments, but I do think the security models need to be carefully designed and easy to configure, especially when it comes to allowing arbitrary code to be submitted and executed by one person. Be sure that developers can’t necessarily deploy code directly to production servers, whether the password is hidden or not. If there is a way to use the value, someone will find it.
Steve Jones
