DevOps has become the practice du jour among innovative IT departments. But what does it look like day to day? And how did it evolve over time? Below, I'll explore some tools and platforms that help enhance your DevOps practice.
I came across the term "DevOps" about a couple of years ago when the client I work for started using Chef for deployment
of applications. It was a significant step towards automating the deployment process. Chef allows you to write automation
code in human-readable Ruby scripts. It standardizes the deployment process by policies. It can scale infrastructure
quickly by just adding a new "node" to the Chef cluster and running Chef client on it. A "node" is a machine - physical,
virtual, cloud - that is under management by Chef server.
A question that came to my mind was what is DevOps, and how does automation by Chef falls under that description? Loosely defined by Wikipedia as "a culture, movement or practice that emphasizes the collaboration and communication of both software developers and other information technology (IT) professionals while automating the process of software delivery", DevOps seeks to create a process by which software can be quickly and effectively developed, tested, and released.
Chef definitely allowed testing and releasing software by making the deployment process fast, reliable and repeatable.
Although during the transition phase the scripts are written by Chef experts, over time developers can contribute by
reviewing the scripts and even writing them. The scripts become a kind of contract between the developer infrastructure
requirements and the infrastructure implementation.
A lot has changed in the DevOps field over the years. Provisioning of infrastructure has always been a slow process, and
hence a bottleneck for quick delivery of software. Virtual machines helped a lot in this regard by providing flexibility
of running different operating system on the same physical resources. The companies do not have to go out and buy new
physical machines every time a need arises, but can configure their existing resources instead. This cuts down the
release and delivery time.
With the emergence and mainstream acceptance of cloud, organizations can deliver software even faster. IaaS
(Infrastructure as a Service) clouds offer virtual machines as a service. PaaS (Platform as a Service) offers a development environment to developers. SaaS (Software as a Service) offers applications as a service. Organizations have an option
to use third-party cloud services on a pay-as-you-go cost or they can deploy cloud services in house (on-premise).
It has become easy to setup a build/deploy pipeline using cloud services. Building software is as simple as provisioning
a machine on cloud and running an CI (Continuous Integration) server like Jenkins on it. Deploying software is as simple
as pushing the published artifacts from build step to the cloud. Spring Boot comes with embedded tomcat server so it cuts
down the deployment time. The client I work for has started to use a separate build/deploy pipeline for individual
projects. This cuts down the investment on proprietary CI servers and decouples the problems associated with using the
centralized CI server. The pipeline can be set up within a few hours once the process is tried a couple of times. That is
remarkable improvement over the existing practices. It requires collaboration of infrastructure team and developers -
infrastructure manages and provides the resources that developers can use. It is correctly a good DevOps practice.