IT Service Management
Although the ideal of DevOps is literally the integration of Development and Operations, it’s still a significant challenge for IT organizations to master.
Writing for the itSMF Barclay Rae describes:
“I was besieged by many decent vendors pitching the value of their products, although none seemed to have any function beyond development – i.e. there was no interaction with operations or the actual ‘running’ of services.”
ITIL is a set of detailed practices for IT service management (ITSM) , a domain created to manage the core challenge of technology, that even the smallest of configuration changes can bring down entire systems, despite being created in an era of IT that was relatively simple in terms of the volume of changes being handled.
So you can imagine the challenge of moving to a world of Cloud, IoT and Microservices where the volume of code and interactions has expanded exponentially. Cloud may automate many previously manual tasks but it also introduces a vast new world of complexity that must be managed.
Change Management, DevOps and Containers
DevOps represents the better fusion of the usually quite distinct departments of software engineering and IT operations. The goal is faster and safer rates of software innovation.
This is a simple objective but a troublesome one in reality – as many experts explain the core issue is that they are directly opposed: One is tasked with creating as much software change as is possible, and the other tasked with minimizing change as much as possible. Even the smallest full stop in a URL in a line of code can break an entire system and deploying complex enterprise applications on a high frequency basis multiplies this risk factor my many magnitudes.
As DevOps guru Gene Kim describes in this article on the integration of DevOps with ITIL:
DevOps aims to address a core, chronic conflict that exists in almost every IT organization. It is so powerful that it practically pre-ordains horrible outcomes, if not abject failure. The problem? The VP of Development is typically measured by feature time to market, which motivates as many changes, as quickly as possible. On the other hand, the VP of IT Operations is typically measured by uptime and availability.
The discussion of the fit with ITIL is a perfect starting point for building an Enterprise DevOps strategy, as the practices are well established and well understood across many large organizations.
Gene makes the critical point: Rather than being competitive these are actually two halves of the same jigsaw. Gene describes DevOps as more ‘agile philosophy + practical tools like Puppet’ without a formal documentation base, versus ITIL which is entirely this. Complaints of ITIL are that it is too ‘heavy’, too bureaucratic, and so ultimately the DevOps movement simply represents an extension of ITIL practices – Being able to better achieve the processes it describes through automation tools described for this purpose.
Change Management for Containerized Applications
This DZone article Change Management for Containerized Applications begins to describe this type of automation, written by Jim Bugwadia of Nirmata, a highly scalable, always-on, cloud service that fully automates the delivery and management of cloud applications.
Jim also describes this core paradox, that ITIL seeks to minimize risk by controlling change when DevOps seeks to expand the rate of change.
He describes how although the use of containers and microservices expands the volume of changes by a magnitude the nature of the technologies is such that the solution to the challenge is inherent to them too, that “successful continuous delivery environments have modernized change management processes built-in” and that as microservices are independently versioned and therefore “microservices become the unit of change“.
So, with containers, we get immutable images, and with microservices, we get smaller units of change. Applying microservices and container together, system changes can now be small and fast.
Nirmata is designed to easily integrate with build tools like Jenkins, to holistically integrate this type of capability into Continuous Delivery pipelines, propogating change management policies across the complexity of large scale Cloud deployments.
This is an effect that can be applied to legacy applications too, via a principle they describe as “Application Containerization“, providing a simple walk through of when to consider this approach.
They describe how they decided upon the best recommendations for a profile of these modules by building their own SaaS, via an approach they describe as “Application Dockerization“:
We developed our own layer of service orchestration on top of Docker. Orchestration of microservices, combined with the choice of Docker as the delivery vehicle for microservices, proved to be a winning solution.
In particular they highlight the benefits of this approach to the SaaS Entrepreneur:
There is also a very interesting side effect to using containerization: cost saving. We use AWS to deploy our various SaaS environments: development, test, staging and production. Nirmata’s orchestration can use a placement policy to pack multiple containers on one single AWS instance. It represents hundreds of dollars of saving at the end of each month. Quite interesting for any cost sensitive business.
Reducing AWS costs
In addition to reducing the impacts of change management failures another key benefit is how this efficiency yields cost savings for use of Cloud providers like AWS.
In their case study of Smyl, a financial services SaaS provider, they describe how the startup wanted to optimize their AWS costs but found neither the built-in services nor open source options provided them the capabilities of ease of use to make it practical to do so.
They faced this core challenge of quickly scaling complexity while also being able to manage it easily, needing to provision lots of containers during a development sprint, handle communications between microservices and managing clustering and fail over.
The team built a full DevOps pipeline with automated container management and provisioning powered by Nirmata, so that whenever a developer checks in code, it automatically builds a new container image and deploys it into a shared staging environment, with changes promoted directly to production.
“Nirmata allows us to deploy services from a single console. Each service is deployed across a cluster of three containers to cater to both scale and availability needs,” Syml’s CTO Guy Pallister. “This way, we don’t need to maintain failover servers.” These newly provisioned services are immediately available since Nirmata automatically configures the addressing.
Nirmata works seamlessly with AWS spot instances to deliver significant cost savings. “As soon as a new spot instance appears in the cluster, Nirmata re-provisions the containers from an on-demand instance to the spot instance. Even if we provision 3x for each service we still save 50-60% in our monthly AWS costs.
- Consistent 50-60% reduction in AWS cloud costs.
- Fully automated DevOps workflows across development, test and production environments.
- Automated spot instance optimization and management.