Voice of the DBA

Author: way0utwest

  • 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 Aware DBA

    A long time ago, at least, a long time in the eyes of my kids, I worked for a large organization as a production DBA. We had a generic monitoring tool, but it wasn’t SQL Server specific. I ended up writing my own enhancements for the tool that used its data, as well as gathering other SQL Server specific items into a local database on each instance. From there, I had this data copied to a central location each night and a report generated. This helped us with ISO certification (originally) and later, Sarbanes-Oxley compliance.

    I was reminded of that when I read Pamela Mooney’s post on Things You Should Know About Your Server. She follows the simple method of ensuring each server monitors itself and rolls up that data. This works well, even if I’d never want to do this again. The time I spent building a monitoring system wasn’t really time well spent. These days I’d buy some monitoring software and then query that data, bother the vendor for enhancements and have either a notebook or a smaller set of processes that gathered specific data I might need. Likely I’d use XE and some stored query data, but if I monitor infrastructure, I don’t want to have to worry about building and maintaining monitoring software.

    The main point from Pamela’s post, however, is that she seeks awareness of how the systems work. That’s the key for a successful sysadmin of any system. You should not, and do not want to, check each system every day, but you do want to know how to find out what is “normal” quickly and be aware of changes. We want to quickly narrow down potential and possible problems because of our experience and history with some server/instance/application/etc.

    Most of us get calls on a few systems regularly. We may know those well, but often we’re fire fighting and normal can be an elusive definition. There are often many systems that we rarely get called to examine, but most good DBAs I know have some idea of how almost every system performs. Having a little data available quickly allows us to diagnose whether a problem is real or imaginary, chronic or transient, as well as how to proceed to resolve any issue.

    Awareness is an important skill when dealing with anything on a regular basis in your life. Certainly in parts of life outside of work, but even at work, paying attention and having some idea how how your environment should work will help you catch, diagnose, and solve issues. The best DBAs might do this before the client even calls.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Learning Kubernetes Security Concepts

    This post continues looking at my process of learning more about Kubernetes. I’ve been working through the 50 days of Kubernetes (K8s). Here I continue on with a few videos on secrets, configuration management and RBAC.

    Secrets

    I am glad that the idea of storing data securely has come to so many applications. Authentication, authorization, privileges, and more are complex and hard to get right. We continually see problems with passwords, certificates, and the link not being managed well.

    Kubernetes has the concept of secrets, which can be values or file contents (like a certificates). These can then be sent or mounted to containers for use.

    One problem, these are stored in the Kubernetes etcd (keyvalue store) in an unencrypted format. Kubernetes has new concepts to integrate into key management areas, like Azure Key Vault, to protect secrets, though Kubernetes privilege controls are still needed.

    A gross simplification, but I learned a little more about what secrets are.

    Configuration Management

    This is interesting to me, because I like abstracting things away. In Kubernetes, we abstract a configuration object as a separate entity, which can then be applied to a container/pod later. This also works through deployments, allowing configurations to be part of the rolling deployment, which can prevent issues.

    If you have good testing/evaluation of what is healthy. This is likely easier than comprehensive unit testing, but still.

    A good idea, just not sure if this is too much.

    RBAC

    I always think of this as row-based, but it’s really role-based, so maybe that should be the way I translate RBAC in my head.

    Like most systems that use RBAC, there is, of course, a role. The video wanders a bit in the explanation, but I’ll try to summarize what I learned. There are two facets to roles. First, these are verb/noun pairs that determine what permission is available for what resource. Like get/list for the verb, and pod, volume, service, etc. for the noun. These are setting up the permission side.

    However, there is another facet. These roles can be set as cluster roles, similar to server roles for SQL Server, or at the namespace level, more like a database role. In either case, you are scoping permissions. Obviously, be careful with cluster roles.

    The other side of this is the user. We can have users or groups used for these roles, similar to what is in SQL Server.

    A simple explanation, but at least I have some idea of the concept.

  • Getting Downtime

    It’s been a crazy year, as are many of my years. I tend to like that, because I prefer to be busy rather than idle. That’s good, but I am aware of the dangers of doing too much, especially across time.

    Most of my travel comes from May-October, and I’ve had a lot this year. In that time frame, I’ve had 4 international trips already, with 2 more to come. To help deal with that, I know I need some breaks between trips.

    Last week I was in the UK for work, but I knew that I would get a little break this week. You might have seen that I’ve republished a few editorials as I was in Custer, S.D. this week. It’s a camping week with the family, and a chance for me to unwind with no real connectivity or responsibilities. A good break for me after a bit of travel.

    I decided to take off August this year from travel. I’m sad to be missing a few events (Louisville, Baton Rouge among them), but I need the downtime. I also take my daughter to university in  a couple weeks, so I’ve got a long weekend helping her move in and then touring New York state a bit with my wife.

    Like lots of IT people, I struggle to get away from work at times, so I’m making an effort to get better. You should as well.