the last couple of years, there has been a radical series of changes around how developers work with databases. One of the results has been to change the responsibilities of DBAs and developers with regards to the database. Let’s examine how these changes affect the development process.
Where we came fromDuring the client/server years, the role of DBA was a hybrid of systems administrator (specializing in supporting databases) and developer (creating various views, stored procedures, functions, etc. for consumption by applications). The DBA had to know how to optimize hardware and OS configurations for the best performance. DBAs also needed to have a bag of tricks such as table partitioning, careful index creation and tweaking, and so on to get the best performance out of a system. In addition, the DBA would handle security concerns; one of the most common chores in a DBA’s day was to create stored procedures that provided extremely limited access to a database and expose that stored procedure to the application as needed, and keep the underlying table locked down.
Developers, on the other hand, were generally at the mercy of the DBA. The DBA had full access to the database, and only granted permission to applications and users where needed. The last thing the DBA wanted was to allow the developer the ability to model a database, since developers are notorious for making some less-than-stellar decisions about database design. In addition, DBAs tried to limit developers’ ability to run custom SQL against the data, since many times developers’ SQL code would have poor performance because they were not as well versed in databases as the DBA.
However, in many organizations, these distinctions and role divisions never existed. Some IT departments let the developers have full access to the database systems, and in other cases, the developers basically were the DBAs, and the server folks handled the rest. But in larger companies, this division of labor has been very common and expected for quite some time.
What’s changedThere has been a huge explosion in development frameworks and systems that make it much easier for developers to run decent code against the databases. Various systems came out that finally let developers run properly parameterized code against a database (Visual Studio 2005 comes to mind) instead of gluing SQL statements together as strings, exposing the system to SQL injection attacks. At the same time, a variety of systems came out (like reporting/data warehousing/BI/etc.) that would create their own SQL code; these systems were often as good as or better than the average developer could put together. Hand tweaking by a skilled human could often improve the generated code, but for most purposes, it is good enough.
We have had major advances in object-relational mapping (ORM) systems like Hibernate and the .NET Entity Framework that have added an additional abstraction layer on top of the database and further obscured it. The ORMs are much easier to work with if the developer has full access to the database and does not need to worry about working through limited access stored procedures. LINQ to SQL in .NET and Rails’s AREL are additional examples of systems that make it much easier for a developer to work directly with the database than to work through a stored procedure.
The biggest change of all is the advent of various Agile development techniques. Project specs (and therefore, database models) can now change with every call with a client, and applications are worked on in two weeks sprints as opposed to the six month timelines of the past. Waiting for a DBA to update the data model and change the stored procedures, views, etc., and then have the developers get to work is too many moving parts in a stripped down Agile team. In these kinds of environments, developers are often creating and packaging the databases themselves, and leaving it to an automated deployment process to push the changes to the database.
What’s aheadDoes this mean that the traditional DBA role is dead? I don’t think so. DBAs are still needed, but they are definitely losing their status as “keepers of the keys to the kingdom” in a number of organizations and probably many more down the road.
Databases still have a very unusual set of performance characteristics, and it takes a trained and experienced professional to plan and tweak systems for the best performance. Beyond that, the existing installation base of legacy applications is huge. Plus, for environments where many applications access a shared database, a DBA is needed to coordinate things (and often to write stored procedures with the proper transactional safeguards) to ensure that no applications trample each other. It’s one thing for an application to be loose with data constraints in its own data; it’s another thing when other applications need to access that data as well, for example. Constraints are a great example of the kinds of things developers tend to overlook but DBAs don’t.
The world of development is changing rapidly, and a lot of job roles are being affected. DBAs, developers, and PMs are at the top of that list.
No comments:
Post a Comment