Thursday, March 28, 2013

Demystifying DevOps


There has been a lot of noise recently about this 'DevOps' movement. In this blogpost, I present my take on the topic and hopefully, help the reader towards understanding it.

Wikipedia puts this as:
 "DevOps (a portmanteau of development and operations) is a software development method that stresses communication, collaboration and integration between software developers and information technology (IT) professionals."

Image: Wikimedia Commons
However, owing to pressures often within large corporations having plentiful resources at their disposal, it is easy to create a hype around a process that in general, is common sense and at the very best is automation.
Speaking of agile delivery, it is easy to deliver a product in small teams that the big ones. As my experiences go, in my present company the product gets a new release every evening(India time), prior to which the changes made in the release are tested by the commiters of the changes itself before the decision about build is taken. After the release is done, basic testing as well as testing of the new features is carried out. While this is pain staking methodology, this works well as the team size is relatively less, leading to fewer overall changes. As an astute reader would have pointed out by now, what is missing is automation as well as demonstration of scalability - about what to do when the product goes live. Some uneasy questions like these are answered by the DevOps which:

  • Focuses on convergence of Development and Operations.
  • Minimizes the gulf/barrier between development and production.
  • Brings about QA into development.
  • Is agile, and strives the processes after development to be agile/flexible
  • Required as rapid scaling & uptime of applications is necessary.
  • Focus on automation, towards reducing repetitive work

So, where does a software developer like me comes in?
Here's what I typically deal while playing with web applications: Java, ruby and some combination of these thrown in together with the odd php or python based applications. In this recession prone economy, there is a requirement for cutting costs; which can be effectively met by ensuring that developers also stick in charge for the deployment process. As this lean process gains its acceptance, it is obvious that development is going to be easier for operations people and similarly for developers, deployment/production environment is going to reduce its level of complexity.

Where does it affects us ?

For the java developers, the heavy duty work gets 'magically' done by the enterprise servers that we deploy on. As java is built with performance in mind, it is easy to ramp up the scale of operations (tomcat is insufficient, deploy on glassfish, Too many queries, use memcached, database connections are piling, use connection pooling).
However, the (physical) servers over which these applications are deployed in production also need to be profiled and studied.

To run load/stress tests, one needs to have a production environment. These are easily available as Amazon Machine Instances or rackspace or any other myriad cloudproviders, however this costs money and given the increasing hardware capabilities, one can perform similar tasks without using the cloud(and paying for such kinds of testing).

Virtualbox needs no introduction and is a free virtulization tool from Oracle (it was a sun offering earlier). However, for our example, even virtualbox fails out of box as it can only provision a single vm. To enhance its capability, one can use Vagrant, which is a tool for building and distributing virtual development environments. In other words, it is what rvm is for ruby; a manager that lets the user have clean state (of the server) as well as abstracted setup(different server configurations from same set of VMs). Vagrant is primarily a driver for virtualbox vms.

One can work with it on a per-project basis(similar to a version control) and configure it through a plaintext file, Vagrantfile which vagrant uses as a DSL. The nicest thing about it is that it does everything that you need virtualbox UI for, which is really beneficial while running numerous headless servers.
For example:
Vagrant::Config.run do |config|
   config.vm.define :app do|app_serv_config|
     app_serv_config.vm.customize ["modifyvm", :id, "--name", "app", "--memory", "512"]
   end
   config.vm.define :app2 do|app_serv_config|
     app_serv_config.vm.customize ["modifyvm", :id, "--name", "app2", "--memory", "512"]
   end
   config.vm.define :db do|db_config|
     app_serv_config.vm.customize ["modifyvm", :id, "--name", "db", "--memory", "1024"]
   end 
end

This is just getting started with different servers as in real life, you'd need to provision the vms - setup them with useful stuff and services, deploy and run your programs on them. Two of the widely popular tools that deserve a mention are: puppet and chef.
While the documentation and discussions around them typically involve rails, there is no reason why java, and for that matter any other technology stack can not be used.
Puppet helps us chiefly with setting up the stuff; it is not big on automation, but saves us the work of setting up different softwares in a vm manually.
For instance, the following puppet config file sets up apache and ensures that it runs as a service during vm startup:

Exec {
  path => "usr/local/sbin:/usr/local/bin:/bin:/opt:/usr/sbin"
}
package {
  "apache2":
      ensure => present
}
service {
    "apache2"
         ensure => true,
         enable => true
}

Once we've set up our environment, only half of the battle is over as we also need to monitor and report the status of the environment to evaluate the areas of concern in the setup.
Nagios is a wonderful monitoring tool that displays the health of server - which is needed in a headless environment. To use it, we need to build a puppet module and  enable its service and use the nagios server interface on the vm itself to gleam the details of the vm, displayed as services  as well as re-shedule it when needed. To monitor the nagios instance itself, one can use a service like pingdom.

There are various other tools related with setting up of the servers, but would stretch the discussion far from the concept of devopts in practice. Thus, there is a need to resist the urge of going on to cloud, but keep the production environment close to the development environment itself. This would not result in the elimination of cloud as production environments are now predominantly becoming cloud based, but will go a long way in ensuring lesser pains when the product goes 'live'.

Thursday, March 14, 2013

Exporting java projects from netbeans to eclipse

Yesterday, I had to create a simple java desktop application for performing some file based automation quickly. For this I used Netbeans that has Mattise RAD tool inbuilt(it is available for eclipse also, since it is rarely required, I haven't installed it there) to create a desktop java application that I intended to export as a standalone jar file.
However the finished jar file could not run anywhere else as it did not package the referenced libraries in itself.

Exporting a runnable java application from Netbeans does not works out of box, as you need to export the entire dist folder that contains the distributable .jar file as well as the lib folder containing the dependant jars. In order to do so, I devised the following method that saved me a lot of time.

  1. First, create an application in Netbeans and build it.
  2. Open eclipse and create an empty java project.
  3. Copy the source folder contents to create the equivalent project in eclipse.
  4. Copy the jars and set the build path to fix the compile errors occured by missing reference.
  5. Check whether the exported project works in eclipse.
  6. Finally export the eclipse application as a runnable jar.

There are other methods ; i.e: Changing the jar file manifest, copying the referenced jar contents into the final jar, but these are more error-prone than this one.

Saturday, March 9, 2013

Book review: Effective Monitoring and Alerting

I've just finished reviewing the book, 'Effective Monitoring and Alerting' by Slawek Ligus, published by O'Reilly Media.
This  deals with System Operations and administration. Given the importance  that maintenance of production software commands these days and the  emerging convergence of developers and operations; thanks to the devopts movement which has gained a fare amount of traction, the importance of  this text cannot be underestimated.
The author presents the concepts in a technology agnostic manner and focuses on latest trends in operations.
The  book gives you a short, high level overview of the topic in 150 pages  and covers the common tasks involved in monitoring and alerting of  operations.

It starts with the introduction of monitoring and alerting and the issues surrounding these concepts. Over the next few chapter, monitoring and alerting is discussed with greater detail and explanation about interpreting the monitoring as well as understanding the nuances of alarms are given. 
After these topics, the implementation, challenges and implications of scaling these on a large basis is discussed by some sane advices obtained from real world projects. These are then closed off by displaying the principles that capture the essence of the topic.

Get in the habit of measuring
Draw Conclusions Reliably
Monitor Extensively
Alarm Selectively
Work smart, not hard
Learn from the experiences of others
Have a tactic
Run a bank of cases
Enjoy the process

While these might come as common words of advice; these were presented in a practical yet succinct manner.
As the book focuses on a  niche that involves guesswork and intuition from non system  administrators towards understanding these concepts, it provides a lot  of insight that senior administrators can impart. While the book focuses  on theory in all the chapters, setting up Open TSDB is given as an  appendix, I've gone through this and it is different from what is  generally available in the blogs and online tutorials as it covers the  setup from the perspective of actual deployment rather than focusing on a  specific technology(like hbase or nagios) used in the exercise.
Overall,  this was a power packed guide that covered various concepts but took  off from advanced level in various concepts, leaving me lost in few  areas where I do not have any prior experience .
Disclaimer: I received a copy of the book under the Blogger Review Program - O'Reilly Media.