Voice of the DBA

Category: Editorial

  • Microservices for Databases

    I ran into a talented developer last year that was talking about microservices. It’s an interesting concept, one the Netflix has adopted with success. I was excited about the possibilities of using microservices until this guy said that everything could be a microservice and the day of the RDBMS was over.

    That was silly, and I’ll admit I struggled to remain polite in the discussion. Eventually I had to walk away because the idea of no RDBMS for any application is a ludicrous as the concept of using an RDBMS for every single system dealing with data. It’s frustrating to talk with someone that views our industry as too black and white. There are many ways to solve any problem and many problems can be handled by a variety of techniques.

    However I am intrigued by microservices. It’s an area that I want to continue to research, as I suspect that the idea of small, loosely coupled applications, working in a service-oriented architecture, is a great way to scale systems.

    From scratch.

    I’m not sure that many of the monolithic, large applications we have in banking, in retail, in supply chain, in a variety of industries are worth rewriting to use SOA concepts. The return just isn’t there, as many of these systems can be served with bigger, faster hardware as they upgrade.

    Microservices are interesting, and I suspect we’ll see more of them in the future. I also think that SOA, using messaging services like Service Broker, are a very robust way to build applications. I hope that more developers out there learn about SOA and find ways to start building system that can work well together, but aren’t so highly dependent that changes are difficult or stressful on everyone.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.3MB) podcast or subscribe to the feed at iTunes and LibSyn.

  • Source Code Security

    I’m not surprised, and I had expected to read about something like this much sooner. Apparently someone at the ride sharing company, Uber, posted a security key online in a GitHub distribution. I assume this was some sort of code repository for Uber that may or may not have been supposed to be shared publicly, but having used GitHub, I could see someone making a mistake and accidentally putting private code in the public space.

    Uber is worried as the key is a security authorization key used to access their databases. Someone apparently downloaded Uber database files and now Uber is attempting to track them down. The whole situation is a mess, but there are a number of problems here that we could learn from.

    I give a talk on encryption options in SQL Server and one of the main problems I see with symmetric keys in SQL Server is that they can be reproduced with the same parameters passed to CREATE SYMMETRIC KEY. This means that your source code is now a security hole, at least if the production values are stored in a VCS.

    However that’s a no-no. Developers shouldn’t have access to account information or keys that are used in production. There should be separate credentials used in development, precisely for this reason. If someone gets your code, or hacks a dev machine, they shouldn’t be able to jump to production.

    There’s also the issue of using a service like GitHub, or any online VCS. The distinction between private code and public code shouldn’t count on a human checking or un-checking the right box. I’d like to see some better separation, perhaps requiring separate accounts and connections for public and private distributions.

    As we see here, convenience can easily result in poor security. That’s not a trade-off we should be making with our security and applications. Especially not for software developers.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.5MB) podcast or subscribe to the feed at iTunes and LibSyn.

  • Software Engineering in Practice

    I ran across a review of a developer’s first year at a company. The company is endjin and the poster describes their first year as a “software engineer apprentice,” which is an interesting way to look at one’s early career. While it’s not for everyone, I suspect that many developers in this business could actually use a bit of apprentice time to solidify their foundation of knowledge.

    The post talks more about the way in which the work is done than the actual tools involved. A few are mentioned, but this is really a look back at the philosophical way in which the company solves problems. More importantly, it’s the view of an apprentice learning a trade.

    I wonder if this apprenticeship mentality might make a good approach for DBAs. It seems so many people working with databases lack fundamental SQL skills and even thoughtful approaches to solving problems. There are people that grow to be experts by diligently working through complex problems on their own, but it seems most people don’t get solid grounding in relational principles, or even learn good engineering practices, like measuring systems before and after changes are made.

    Many companies rush to get work done. They want code written quickly, which I completely understand. However if your staff isn’t well grounded in building solid code, then I’m not sure that poorly written applications are getting work done quickly. I suspect they’re just getting something done, which then has to be fixed, enhanced, and refactored before it allows work to move faster (if at all).

    All of that takes place in the time that it might take someone with more skill to do it well the first time.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.0MB) podcast or subscribe to the feed at iTunes and LibSyn.

  • Efficiency

    This editorial was originally published on Oct 22, 2010. It is being re-run as Steve is away on vacation.

    There was a debate recently about older IT workers and the fact that there is some age discrimination going on in this industry. While that’s probably true, it happens in other fields as well. Especially blue collar fields where the amount of work done often relates to some physical activity. Older workers might make less, or be paid less, because they do the job differently.

    Without getting into the debate about age discrimination, I wanted to get a feel for how you feel about your career progressing. I’m sure those of you in your 20s can’t conceive of being 60 and programming any differently than you do now, but times will change for you.

    One of my feelings is that there is a lot of value in experience. The latest .NET changes aren’t harder to use or understand than the previous ones, and the changes to T-SQL bring about new things to learn, but they aren’t really any more complex than previous features, commands, and constructs. For this Friday, I wanted to ask this:

    Are you becoming more efficient as you progress in you career?

    Maybe you can answer how you are getting more efficient. Are you developing skills that allow you to produce higher quality code in less time?

    I hope that most of you are, and the explosion of blogs, books, and events like SQLSaturday mean that you have more chances than ever to learn how to become more efficient in whatever type of technology you work with in your career.