If you are still working in a traditional working environment, one would observe an application developer awareness of software development life cycle activities include standard phases: requirement gathering, analysis, design, coding, and testing (unit, integration, user and system). Awareness of these phases traditionally does not put developers into a position where he thinks about how the software solution will be put to actual use by its intended user. From a developer perspective after coding and testing, it is about raising few requests to operations or admin team to get the necessary hardware to execute the software and it is perceived as ‘just’ providing hardware capacity to execute the solution on. Any delay in serving these requests add to developers’ frustration about operation team taking infinite time to service him and a similar story exists at operation team side as well. Operation team would always complaint about teams working in silos and not providing them enough information on time for them to provide necessary support and plan capacity accordingly. Stories from developers like operation team have broken the environment and I cannot perform the shakeout and hence delays.
Infrastructure requirements to support applications have gone huge. Software stack supporting applications has increased in complexity multiple times in recent years and require highly scalable (vertical & horizontal) support from operations team to continue working in a predictable environment. Application and infrastructure supporting it is fragile and breaks on even slight modifications and it takes long hours to know what actually went wrong adding to everyone’s frustration. Interaction between components have gone complex to find out what went wrong. From developers perspective they are there to get functional requirements implemented and mostly non-functional requirements would stay out of their focus areas, hence areas like scalability, performance, maintainability, monitoring etc. take a hit, which increases complexity and this keep compounding every day. What this results in; longer fixation hours, difficult deployments and fragile environment (it works on my machine).
People are using multiple types of devices and they are connected to these applications almost all the time. Irrespective of the fact whether or not any organization’s application is serving millions of users, the integration points have increased multiple times in recent years. Most integration points results from our changing ways of communication channels and there are many. Modern applications are expected to cater this and hence increases complexity of supporting software stack and applications are expected to service requests from these access points all the time. Line of business (LOB) needs predictability of availability of solution in totality (ready for use) which demands ops to become part of dev.
- ONLY Dev + Ops
- It is not a tool (CI tools, Cloud Operating Systems/platform used to manage infrastructure, monitoring tools etc.)
- Position or Title (What is DevOps engineer/administrator? Is it any technology?)
DevOps is a cultural/mindset change and expects collaboration and effective communication between developers and operation team to work together towards delivering the software solution and finally maintaining it. This involves closer participation of developers and operations right from planning phase by line of business in order to understand what exactly is needed so during phases of build and execute, development and operations teams are not working in silos, however know the expectations beforehand. It might not be wrong to say these expectation from dev and ops and together part of requirements analysis.
If you are working in traditional culture it would look something like this:
Requirements -> DEV -> Software (all traditional phases) -> OPS -> Working Solution in Production
Where development focuses on taking requirements and producing working software and operations focuses on deploying solution on production machines and keeps it running securely. DevOps is about collaboration and integration of development, QA and operations.
DevOps suggests:
- Collaboration, bringing Ops in Dev (Deciding team structure is a key challenge)
- Process convergence (dev & ops, changed way of working)
- Process implementation & enforcement by exploitation of tools
It is sometimes mentioned that DevOps is required to go agile; however it would be incorrect to paint a picture that DevOps is a requirement to go agile only. It in many ways does extends agility. There is a reason for adoption of agile and one of the principles is collaboration and same needs to be carried forward while providing a solution to a business problem in development as well in operations. It is like taking a holistic view, it all works together and it is the effectiveness of the interactions of various pieces which makes a solution complete and working (you need everything, either it works or not). DevOps become more significant with the advent of cloud as it is almost inevitable for organizations to ask, how to cloud enable themselves, though security still remains a key issue as it opens up many networks and data.
To start with one can choose to opt for following steps:
- Make environment as foundation of development, which means developer is building and testing on environment which is close to the environment used for deployment. This calls for making virtualized development platform and infrastructure existing as a code rather than existing in operations team mind. There are various provisioning solutions which are available and should be used by developers to make their development environment close to production. The development platform is virtually everything except the application software, which includes databases, message queues, networking, storage support, operating system and packages.
- Make feedback loop faster to catch the errors earlier. Fail early, fail often. Have a highly effective testing suites exploiting continuous integration. Developers can follow TDD/BDD and create an effective test suite at every level which gets executed at every code check in. This includes unit, integration, system and regression suites. It also creates virtualized infrastructure as part of building, this is to enforce that code and environment are tested together and does not give surprises in future. When we mention environment here, it includes development, QA and pre-production. CI pipeline planning would ensure promoting artifacts at each level starting from development after sufficient automated tests execution at each level. Test automation alone cannot be relied upon, however it provides a good feedback and should always be evolving.
- Create deployment procedures. These procedures for deployment are not in operations team mind, they exist as code so we know what environment production machine has. Doing this enforces that it does not depend on someone special; anyone is as good as one is in understanding the deployment code. Deployment procedures ensure recurring successful deployments in various environments. The deployment procedures not only create the environments and make bare metal come up for use or incremental deployment; they should also make access to those environments secure and capable of monitoring and measurement. Deployment procedures make deployment predictable and it is easier to fix the glitch. This also helps in achieving vertical scalability which otherwise is a time consuming exercise. Deployments can be pull or push, can be discussed depending on size.
Steps mentioned above should not be thought of as separate steps. Their integration has to be planned. One of the key challenges here is to structure the team for successful collaboration and transition, as with any transformation there might be steep learning curve and produce team reluctance.
For example, while making environment and development to be tested together and using virtualization as a solution, one need to integrate the development platform with infrastructure we create in Step 2. There are services which provide the platform mentioned in Step 1 and integrates them to infrastructure mentioned in Step 2, called aPaaS. Organizations have a choice to make here, whether to use aPaaS or create their own platform and integrate it with infrastructure, physical or virtual. Various cloud service brokerage solution provides way to transform to DevOps on various cloud platforms.
Transforming into the world of DevOps, one should be aware that it is a continuous improvement process. It could prove to be non-achievable aim if taken everything at a same time, however done in steps and understood holistically, it can eventually prove to be highly efficient and productivity increasing. Bringing ops into dev is about a message which is, we require everything, not just software solution from dev to make it work in predictable and scalable manner and above all it is a mindset change more than anything in terms of doing daily development business. Technology is a facilitator to businesses and businesses today demands agility to adapt to business environment changes and DevOps can help.
ABOUT THE AUTHOR
SANJEEV MALHOTRA
Director – DevOps and Cloud