Category: Editorial

  • SQL in the City 2016

    It’s time for SQL in the City 2016 to start today. Actually, by the time some of you read this, we may already be underway. This year the event is being broadcast from the Redgate Software offices in Cambridge, UK. Along with Grant Fritchey and a number of other Redgaters, we’re holding our annual conference live for the world to watch. In fact, to ensure everyone can watch, we’re going to broadcast both today and tomorrow (Dec 15) at different times to reach the entire world. If you can’t tune in today, come back tomorrow as the content is the same, just about 4 hours later. That means an early day in the office for me today, and then a late one tomorrow, but it’s worth it to give you a fun show.

    I’ve enjoyed being a part of SQL in the City for many years, in quite a few cities around the US as well as London. Each year we spend time trying to showcase new products and features from Redgate that can better help you develop software. That’s the mission at Redgate. We want to make you more productive as you build applications on top of SQL Server. Part of doing that is showing you examples and providing education in addition to selling software.

    As an evangelist, I’ve been proud that Redgate continues to give back to the community and invests heavily in SQLServerCentral, Simple Talk, and many other conferences and events around the world. We truly do want to be a part of the #sqlfamily and try to ensure that every one of us gets better at our job over time. To me this is one of the great things about the SQL Server community in that we all support, inspire, assist, and share with each other. I’m happy to help contribute what I can to educate SQL Server professionals every day.

    This should be a fun couple of days, and I hope you enjoy the sessions we’ve been developing this fall. We’ve got some great new products that have been under development in 2016 and should be releasing soon. I think you’ll like what we’ve been working on.

    Steve Jones

    The Voice of the DBA Podcast

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

  • DBAs Need to Learn to Develop

    This editorial was originally published on Jan 7, 2014. It is being re-run as Steve is at SQL in the City today.

    My first exposure to computers was as a child, learning to program in BASIC, Assembler, and Pascal. From there I moved into other areas, such as networking and system administration. I learned about a variety of technologies before focusing on databases, but I found that my knowledge from other areas of computing helped me be a more successful DBA at quite a few jobs.

    Last year we put on a number of SQL in the City Seminars where Grant Fritchey and I talked about development practices. We give a variety of advice and practices that you can use, but one of the best things that we say in our half day event comes from Grant. He says that DBAs need to “Follow the local development paradigm as much as possible.”

    I completely agree with this. I think that many of the practices of building software, as flawed as they might be, are good ideas that many developers use on a regular basis. They know how to work in a flexible manner, tracking their code and keeping it under control, and fixing problems in a rapid manner. As immature as the software development process can be, there are things that we, as DBAs, can learn.

    As SQL Server continues to grow as a platform, there are more and more enhancements, many of which involve programmatic capabilities expanding. I highly recommend that DBAs think about learning more about programming, and specifically a .NET language, if you’ve never used one. If you have, consider brushing up those skills.

    Steve Jones

     

  • The Five Year Plan

    This editorial was originally published on June 13, 2013. It is being re-run today as Steve is traveling.

    IT departments won’t exist in five years. A bold prediction from the CITE conference last week. It’s not so much a prediction of an increase in cloud services, but more the idea that the centralized IT department is struggling with the consumerization of technology, the increasing demands of the business for faster turnaround on projects and prototypes, and the flexibility being demanded by an increasingly technology savvy workforce.

    Like most predictions, I take this one with a grain of salt. I don’t think five years is enough time to change the face of the enterprise IT groups. Five years ago the first iPhone had been out for a year and was being demanded by users to replace their Blackberries. These days many corporations support iPhones, along with other smartphones, and Blackberries have disappeared from many organizations. However IT has adapted, released some of their control, and even integrated some of their policies into new technologies. When I enabled corporate mail on my smartphone recently, I had to allow some remote management features to get mail, which was fine with me.

    I do agree that we will start to see some of our IT functions, especially small projects and POC (proof of concepts) increasingly being driven in departments. There are too many projects, too many different technologies, and too little time to work on them for central IT departments to tackle all these projects. Departmental management won’t wait for IT that is stretched too thin, especially if they have existing staff that have some technology skills. That latter factor is something becoming more and more common all the time.

    However I can’t see central IT disappearing. There are often quite a few systems that are complex, that are too large, too important to let someone manage part time. There are projects that cross departments, or even the entire company, and coordinating tasks and resources between departments is complex. Add to all of this the problems and hassles of hiring good technology people, and I can see projects rising in departments, but being turned over at times to IT to manage.

    I do think that central IT groups need to be more flexible, and reduce some of their rules, or adapt them to new technologies and platforms. I expect people working in central staff to be “lent” to departments for projects, perhaps even multiple departments at the same time to help get projects completed, while also gaining some training on the various systems in order to provide support when other staff isn’t available. Such as weekends.

    Steve Jones

     

  • Faster Versions and More Support

    When I started working with SQL Server, the versions came a strange paces. Three years between v4.2 and v6.0, but less than 1 before v6.5. Then two years to v7, one more to SQL Server 2000, but five until SQL Server 2005. After SQL Server 2008, we’ve moved to a 2-3 year cycle, but I can see that accelerating a bit more as SQL Server vNext looks like it might come in 2017, a year after SQL Server 2016. Since much of the code is released to Azure first and exercised there, I could see us getting on premise releases coming every 1-2 years in the future.
    Overall, I like this pace. We can see changes coming to the product on a regular basis and enhancements that I can choose to implement or not. We no longer have to wait years to get an enhancement or evolution of a feature. We always have the choice to upgrade. Many of us won’t, but that’s OK. Perhaps we’ll use new features in new applications, and learn how they might make the case to, or not to, upgrade existing instances.
    There’s a flip side to the rapid releases and enhancements to the platform. Many of our organizations expect a database server to last for years. We invest plenty of resources in building these database servers, and I think many managers and organizations expect they will be in service for at least five, and maybe ten, years or more before they are decommissioned or perhaps upgraded. I know there are still plenty of SQL Server 2005 and 2008 instances (probably not 2000) that are being used on a daily basis with no plans to replace them.
    This means that as the developers and DBAs that work with SQL Server, we will likely be supporting a wide range of versions in the future than ever before. Even if you started a company two years ago with a SQL Server 2014 instance, I’d guess you might have a few more now, perhaps some SQL Server 2016 instances. In two years you might have 2014, 2016, and 2017 (assuming vNext becomes SQL Server 2017). In five years, perhaps you’ll have five versions to support. I know there are people in that situation today with 2014/2012/2008R2/2008/2005 instances in production.
    There was an announcement this week from Microsoft. They are now offering SQL Server Premium Assurance, which will give you 6 years of support after the 10 you ca now get with Extended support. Certainly there are restrictions and costs, but I expect that there will be some large organization that think it’s worth paying this to continue to use older versions as long as possible. After all, this is a platform, which implies some level of stability.
    That doesn’t solve the knowledge issue and need to keep staff around that understand the platform, but with all the education and knowledge available from places like SQLServerCentral, perhaps supporting multiple versions isn’t a bit deal.
    Steve Jones