Evolution of Software Development and Operations – Part 5

In the preceding posts 1 (Operations), 2 (DevOps Gen 1 & Infrastructure as a Service), 3 (DevOps Gen 2 & Infrastructure as Code), 4 (Application Platforms), of the series ‘Evolution of Software Development and Operations’ a brief history of software operations has been drafted.

The following articles of this series change perspective and re-narrates how – analog to operations – software development has changed in the past 10 years.

See how web applications have evolved from simple scripts to multi-layered, service oriented, distributed applications. Also learn how test driven development (TDD & BDD) lead to the emerge of continuous integration (CI) and continuous deployment (CD). Explaining cloud-native and 12-factor compliant applications and microservice based architectures will then complete the re-narrative of software evolution.

From loose Scripts to Web Frameworks

The early days of web development have been dominated by scripting languages such as Perl. It was a huge step from a static html file to a web server that triggers the invocation of a script dynamically generating html.

Performing an action in a web application often meant to re-run the entire application with new input parameters. Primitive scripts, wildly mixed code and HTML. At this time design and usability of web applications were not what they are today. Browsers had rudimentary skills. Javascript has not been a major factor and design was very HTML centric. Bandwidth was limited and way below 1 MBit/s. A request-response-cycle often took seconds.

The evolution from a dynamic script to a web application is about structuring code. In a growing project code and HTML had to be separated. Templating engines have been introduced and applications have been split into modules. Data has been stored in the filesystem and a relational database system such as MySQL.

Even a few years later, well organized web applications made use of dozens of different libraries. Often these libraries have not been well integrated. A data structure had to be repeated many times in various code locations. In HTML or its form generator, in the code reading the response, form validation classes, a class representing an object, an object relational mapper storing objects to a database, just to name a few. Every application was entirely different. Configuration files, if at all, where at random locations, no assumption about their structure could be made.

With such a chaos, automating software operations was nearly impossible.

Small applications have been put on shared hosting servers. A user login granted FTP access to upload scripts to a particular location. The web server was configured to invoke scripts. A shared database was assigned. Deploying in application meant to upload the code via an FTP client.

Large applications where put on dedicated servers which were expensive at that time.

Ruby on Rails – A Game Changer

Around the year 2006, the term Ruby on Rails spread more and more. After downloading this Framework — one of a kind at that time — eyes went open. WOW! This is a dream! A web framework, so well integrated. Magic! It’s suddenly fun to write web apps.

Most of the Rails learning curve was about exploring all those things that you don’t have to do anymore. Write code, see the result immediately. No web server restart necessary. A built-in object relational mapper (ORM), a pleasure to use. No need to repeat yourself over and over again. Strictly DRY – don’t repeat yourself – a data structure had to be written once and many other components reflected upon the resulting object and injected appropriate code. Validation was done easily and it provided verbose log files. There were so many great aspects of this framework.

Much of this magic is thanks to Ruby. A language enjoyable to write. It is the foundation of Rails’ magic and allows the framework user’s code to be simple and readable.

But Ruby on Rails was not only heaven for developers. Rails has been a major influencer in the emerging of modern application platforms. The strict convention over configuration paradigm does not only provide benefits to developers such as looking at Rails project and immediately recognizing the folder structure. Also any operator knows where to look for configuration files such as the database configuration. He immediately knows how to perform changes to the database by executing database migrations.
It was no coincidence that one the first application platforms has emerged from the Ruby on Rails community.

Even if Ruby on Rails has passed the hype cycle, it is still a leading web framework and key influencer. Rails inspired many other frameworks to overcome usability issues. Once, something like Rails existed nobody could ignore the benefits it provided anymore. Therefore, nowadays no developer creates web application‚ without a web framework anymore.

In the next post of this series the transformation from monolithic fullstack web apps to multi-client applications will be discussed.

Leave a Reply

Your email address will not be published. Required fields are marked *