Is there enough Ops in your DevOps?

DevOps is a popular subject in the industry right now, and with the move to public cloud services DevOps has become easier than ever before. Development teams now have greater responsibilities, while delivering to shorter timescales. In a world where agility is becoming the norm, Ops needs to keep up with Dev.

Traditional IT service management (ITSM) models of deployment can slow release cycles and reduce agility, by enforcing change control meetings and maintenance windows on the environment. Automating Ops is often left to the end, with developer processes, such as build automation and code management, being the start of the DevOps transformation.

Environment deployment, load testing, patch management, security and configuration management are all things which must be addressed, and incorporated, to benefit from DevOps. Most importantly, feedback loops which drive constant improvement must be included in the environment.

Scale and Sizing

A good place to start with feedback loops is scale and sizing of the environment. Initially, we create environments of various sizes and run automated load testing on them against our code. This will determine the user capacity of each size server, or service, to determine where to start.

Next, we decide whether lots of small systems, or fewer large systems, is a better fit, and how auto-scaling would work if it’s used. Outputs from these load tests can include latency results and load times, memory and CPU usage under load, and other metrics which show how the system responds and what it needs to run efficiently.

Once the environment is selected, we can automate deployment to ensure it is deployed alongside code each time. When we deploy, the load tests are re-run and compared to the benchmarks set in early testing. This way we can determine if a code release has slowed the environment, whether due to bugs or enhanced functionality, which simply makes the system work harder.

If a build runs slowly, this feedback is used to decide whether to modify code, or the environment, to remediate. Changes can then be made and the deploy retested before being released.

Patching and Updates

Security of cloud based systems is incredibly important, and the core to this is patching and updates. Every product will, at some stage, have bugs in the code - also known as vulnerabilities. A firewall doesn’t secure against these since it is designed to let traffic through to the product, while restricting other access. Other security products may work, depending on their sophistication, but if the network traffic looks legitimate then it will probably be allowed through.

Regular patching helps to close these vulnerabilities and prevent easy access to the system - the best way to patch regularly is to replace the server in an automated process, where possible. As part of a deployment pipeline, new infrastructure delivered through code can be deployed and will be subjected to the same suite of tests as any new code release - giving confidence that the platform will work as expected, while also offering a rollback to the old server if things go wrong.


User access is often overlooked as a security vulnerability. Of course, removal of this requirement offers significant security advantages.

If logs are pushed out from the server, and configuration and maintenance is carried out by replacing the server or through configuration management tools, the only remaining issue is how to get new code into the server. Instead of traditional File Transfer Protocol (FTP), Secure Shell (SSH) or Session Control Protocol (SCP), we can simply pull code into the server as part of the build and deploy process, removing the need for user access - and greatly enhancing your security. Because this is a pull operation, there is no need to log in.

All the above is just an insight into the many benefits of extending ops into your deployment processes.

In future posts, we will dive into these and other advantages in more depth. In the meantime, if you want to know more please speak to your account manager to arrange a meeting.

Visit our events page to find out more about upcoming DevOps workshops with Ultima.

- By Dave Lusty (Solutions Architect)


Full Name