Sean Hull discusses on Quora – What is Behavior Driven Development?
Agile software development seeks a more lightweight methodology of making changes and releases to software. In the traditional, incremental approach, large pieces of software are written at once, and releases happen less frequently. Once features are complete, the testing phase happens, and then deployment to production. These releases can happen over many weeks in time, so turnaround for new features tends to be slow. Advocates would argue that this forces discipline in the process, and prevents haphazard releases and buggy software.
Agile methodologies, seek to accelerate releases of much smaller pieces of code. These releases can happen daily or even many times a day, as developers themselves are given the levers to push code. Agile tends to be more reactive to business needs, with less planning and requirements gathering up front.
While Agile remains the buzzword of the day, it may not work for every software development project. Web development & applications where small failures can easily be tolerated and where small teams are at work on the effort, make most sense.
Object Relational Mappers or ORMs are a layer of software that sits between web developers and the database backend. For instance if you’re using Ruby as your web development language, you’ll interact with MySQL through an ORM layer called ActiveRecord. If you’re using Java, you may be fond of the ORM called Hibernate.
ORMs have been controversial because they expose two very different perspectives to software development. On the one hand we have developers who are tasked with building applications, fulfilling business requirements, and satisfying functional requirements in a finite amount of time. On the other hand we have operations teams which are tasked with managing resources, supporting applications, and maintaining uptime and availability.
Often these goals are opposing. As many in the devops movement have pointed out, these teams don’t always work together keeping common goals in mind. How does this play into the discussion of ORMs?
Relational databases are a technology developed in the 70’s that use an arcane language called SQL to move data in and out of them. Advocates of ORMs would argue rightly so, that SQL is cumbersome and difficult to write, and that having a layer of software which helps you in this task is a great benefit. To be sure it definitely helps the development effort, as software designers, architects and coders can focus more of their efforts on functional requirements and less on arcane minutiae of SQL.
Problems come when you bump up against scalability challenges. The operations team is often tasked with supporting performance requirements. Although this can often mean providing sufficient servers, disk, memory & cpu resources to support an application, it also means tuning the application. Adding hardware can bring you 2x or 5x improvement. Tuning an application can bring 10x or 100x improvement. Inevitably this involves query tuning.
That’s where ORMs become problematic, as they don’t promote tweaking of queries. They are a layer or buffer to keep query writing out of sight.
In our experience as performance and scalability experts for the past fifteen years, query tuning is the single biggest thing you can do to improve your web application. Furthermore some of the most challenging and troublesome applications we’ve been asked to tune have been built on top of ORMs like Hibernate.
Devops is one of those fancy contractions that tech folks just love. One part development or developer, and another part operations. It imagines a blissful marriage where the team that develops software and builds features that fit the business, works closely and in concert with an operations and datacenter team that thinks more like developers themselves.
In the long tradition of technology companies, two separate cultures comprise these two roles. Developers, focused on development languages, libraries, and functionality that match the business requirements keep their gaze firmly in that direction. The servers, network and resources those components of software are consuming are left for the ops teams to think about.
So too, ops teams are squarely focused on uptime, resource consumption, performance, availability, and always-on. They will be the ones worken up at 4am if something goes down, and are thus sensitive to version changes, unplanned or unmanaged deployments, and resource heavy or resource wasteful code and technologies.
Lastly there are the QA teams tasked with quality assurance, testing, and making sure the ongoing dearth of features don’t break anything previously working or introduce new show stoppers.
Devops is a new and I think growing area where the three teams work more closely together. But devops also speaks to the emerging area of cloud deployments, where servers can be provisioned with command line api calls, and completely scripted. In this new world, infrastructure components all become components in software, and thus infrastructure itself, long the domain of manual processes, and labor intensive tasks becomes repeatable, and amenable to the techniques of good software development. Suddenly version control, configuration management, and agile development methodologies can be applied to operations, bringing a whole new level of professionalism to deployments.
Processes are said to be coupled when they are tightly wound together, and dependent on one another.
A loose analogy might be replacing a traffic light by a traffic circle. You keep the traffic moving, reducing the overall wait time for any car entering the intersection.
Decoupling web applications might involve replacing a makeshift queue your application currently implements in a table, with a message queuing service such as RabbitMQ or Amazon’s SQS.
Ultimately decoupling promotes scalability, as you can scale the pieces of your infrastructure that your capacity planning identifies to be bottlenecks. What’s more you can make those pieces redundant, increasing high availability at the same time.