What Software Developers Need to Know About DBAs and DevOps

Producing working software involves much more than just writing code.\n\nMost substantial software applications require some kind of data storage, and they have to be built, tested, and deployed somewhere.\n\nAnd you know what?\n\nWe need people who know how to handle that kind of stuff and to do it.\n\nThat is where the roles of DBAs (database administrators) and DevOps come in.\n\nYou might be wondering why you need to know about all that—can’t you just write the code?\n\nWell, yes, sometimes you can just write the code, but more and more teams are becoming cross-disciplinary, and software developers are being required to take on—or at least contribute and work with—a variety of different roles.\n\nSoftware development, especially in Agile environments, is more of a team effort, and we’ve added a whole bunch of best processes and “ways things should be done” as we’ve learned over the years how to deliver better and better software. (Or at least we think we have.)\n\nAnyway, as a software developer, you may be asked to wear several different hats, especially if you work for a startup or small company where there isn’t a dedicated DBA or operations team.\n\nIt’s not unlikely that someday you’ll be asked to install a database or set one up to work with an application.\n\nLikewise, you may be asked to help determine the process of taking the working application code, getting it built and tested, and deploying it to a production server.\n\nOr, you may also be asked to work with one of these strange creatures who call themselves DBAs or DevOps… dudes?\n\nAnyway, regardless of the reason, you should probably learn something about your technological brethren.\n\nOh—and we’ll get to Quality Assurance later; that deserves a whole chapter by itself.\n\n

DBAs

\n\n\n\nFirst, let’s start with DBAs.\n\nWhat exactly is a DBA, or database administrator?\n\nWell, the role can vary from organization to organization, but generally it involves hurting developers’ feelings by telling them their code sucks and is utilizing too many database connections and telling them “no” a lot when they ask if they can do various things involving the database.\n\nFor the most part, though, the DBA is responsible for setting up, maintaining, securing, optimizing, and monitoring the databases, and perhaps even setting up database schemas or writing stored procedures.\n\nSome DBAs tend to be very operational in nature and don’t do much in terms of actually creating database tables and writing any kind of database code.\n\nOther DBAs are more like database programmers in addition to the operational work they do on the databases.\n\n

Databases Need Care and Feeding

\n\nNot every development team is going to have a DBA.\n\nIn fact, many organizations are going to have developers—that’s you—doing many of the DBA duties, so it is useful to know your way around a database and some of the basics of installing and maintaining one.\n\nFor many software applications, the database is an important piece of the business, so whether the role of maintenance and administration falls directly into the hands of a DBA or is distributed amongst developers, it’s quite important that someone does the work.\n\nDatabases grow over time and can be pretty big resource hogs, so it’s critical to pick the right hardware to run a database on and to determine when it’s time to upgrade.\n\nDatabases also contain some pretty important data, so care has to be taken to back them up regularly, and someone needs to put together a disaster plan to restore a database or keep things running if one happens to fail.\n\nAnd let’s not forget performance. Over time, databases which are not well designed or tuned can get slow and inefficient, so special care has to be taken to profile the database and determine how the data should be arranged or indexed to make things faster.\n\nI could go on and on, but I think you get the point. Databases don’t just raise themselves.\n\n

Do I Need to Be a DBA?

\n\nNo, but I’d highly recommend you invest some time in learning how to:\n\n

Install and set up a database.

Create and restore backups.

Create tables and schemas.

Create stored procedures.

Index tables and how indexes work.

Perform basic operations like queries, inserts, updates, etc.

Join tables.

\n\nLike I said, you don’t have to be an expert in all this stuff, but knowing the basics will be extremely helpful in your job as a software developer, whether you have to do some of this stuff yourself or you have to work with a DBA.\n\n

DevOps: A New Role

\n\nIt’s not too often that completely new roles are invented in the IT field, so the role of DevOps is both unique and a little, shall we say, loosely defined.\n\nWhat exactly is DevOps?\n\nWell, it’s a conglomeration or a mashup, if you will, of development and operations.\n\nIn my mind, I think MacGyver.\n\nIf you ask different people, you’ll get many answers, but for the most part they’ll agree that DevOps is all about doing whatever needs to be done to get the code built, tested, deployed, and running in production.\n\nBut to really understand and appreciate DevOps, you have to understand…\n\n

Operations: How We Used to Do It

\n\nYou see, before there was DevOps, there used to be just developers and operations (sometimes called IT).\n\nDevelopers wrote the code, then they threw it over the wall to QA.\n\nQA would say it sucked and throw it back.\n\nThe code would go back and forth a few times before one party or both finally gave up, and then they’d collectively throw the code over another wall to the operations team.\n\nThe operations team would complain about how inefficient the code was, how it was going to break the server, and how developers don’t have any clue about security, then throw it back.\n\nThe developers would curse at the operations guys who are just trying to give them a hard time, make a few minor changes, and throw it back.\n\nFinally, the operations team would take the code, deploy it to the server, everything would break, and everyone would blame everyone else.\n\nOk, perhaps I’m being a little dramatic here, but the point is that we used to have very disconnected teams in the world of software development.\n\nIn the past—and for some organizations still today—it used to be that developers would write the code, and operations would take that code and deploy it without either team knowing much about what the other team did.\n\nThis did create a large amount of problems, but the problems were bearable until Agile software development came around.\n\nNow teams are shipping new code once, twice, sometimes three times a week instead of every six months or so.\n\nDevelopment teams are building the code multiple times a day and running automated tests and quality checks against the code.\n\nThings are no longer as simple as writing the code, building the code, and deploying the code.\n\nInstead, a whole set of operations and procedures emerged as a way to be as agile as possible and to be able to move code quickly from development to production.\n\n

What Is DevOps?

\n\n\n\nOk, so now that you know the backstory, what exactly is DevOps?\n\nIt’s the multidisciplinary process of getting code from development to production and taking care of the code when it’s there.\n\nInstead of having two or three separate roles that don’t know much about each other, and are arguably hostile and antagonistic at times, DevOps is about taking full ownership at every step along the way.\n\nIn some organizations, there are specific DevOps roles where you might have a programmer who understands how to build and deploy the code involved in creating a build and deployment system to automate the process as much as possible.\n\nIn other organizations, the developer, tester, and operations roles are still separate, but they all work together to fill the role of DevOps through mutual understanding, cooperation, and collective ownership.\n\nThe important thing about DevOps is that it is a fundamental shift in thinking about how software should be delivered to production.\n\n

What This Means to You

\n\nWell, technically, as a software developer, you are part of DevOps.\n\nWelcome. Congratulations. Here are your official DevOps wings.\n\nToday, software developers are expected to know about more than just writing code.\n\nYou can’t get away with throwing your code over the wall and letting it become someone else’s problem, especially if you are working in a small company or startup.\n\nYou need to understand the process and tools that are used to move code from development to production—and ideally how to set up and use some of those tools.\n\nObviously, you should know how to use an IDE and build your own code locally; no one is going to do that for you.\n\nHowever, you should also know how to use source control to check in and integrate your code into the other code in the system.\n\nYou should know the basics of continuous integration and how a build server works. (Don’t worry, we’ll cover most of this stuff in the upcoming chapters.)\n\nYou should know the fundamentals and types of testing and how automated testing of various sorts fits into the bigger picture of building and deploying the code.\n\nYou should know how an application gets packed up and ready for distribution or deployment.\n\nYou should understand the deployment process and how to automate moving code from a build server to a staging server or production server and how configuration is managed on various servers.\n\nFinally, you should know something about monitoring an existing application to check for performance problems and other issues.\n\nYes, I realize that is a large amount of stuff to know, but you don’t have to have in-depth knowledge about all these things—and you don’t have to learn them all at once.\n\nIt’s more important that you know of and what these tools and processes are for, so that if you needed to implement parts of this tool chain yourself or assist in implementing them, you could.\n\nThink of it this way.\n\nSuppose you are a pitcher on a baseball team.\n\nYou don’t need to know everything about every position on the team, but it’s going to be difficult to talk about any kind of meaningful strategy if you aren’t at least aware of the other positions and what they do.\n\nYou don’t want to join a software development team and be completely oblivious to what happens after you check in your code.\n\nAnd many software development teams don’t want to hire developers who are.\n\nLike I said, though, don’t worry. I’m going to give you a basic overview of some of these topics in the upcoming chapters.\n\n

\n\n