DevOps Nordic APIs blog postThe nature of the IT industry is one of constantly emerging and refining processes and trends. One of these trends that has taken the IT world by storm is the emergence of DevOps. As more and more groups adopt DevOps organizational strata, understanding this new structure is key to keeping fresh and innovative.

A change to the very fundamental approach and organization of IT groups and API developers, DevOps is a firestorm that can empower and extend capability.

What is DevOps?

What exactly is DevOps? To understand what DevOps is, we first must take a step backwards. The development world is largely split into two groups – Development and Operations. Think of Development and Operations as the Felix and Oscar odd couples of the IT world — constantly fighting, at odds with one another, but ultimately dependent on one another.

Traditionally, Development is concerned with one thing — development. The continual innovation and experimentation resulting in iteration on previous versions is what drives the development of most applications and services. While continual development creates a wealth of services and functionality, it is at odds with the concept of “stability”.

That’s a problem, because that’s what Operations is all about. Operations is concerned with stability above all else — the maintenance of systems and the stability of the forward facing application is the prime goal.

While many API providers can unify these groups, the fact is that the disconnect between purposes causes friction. This friction results in some huge issues for API developers, and drives much of the issues an API developer will face in the API lifecycle.

Blog-Post-Wide-CTA-API-Stack

Why DevOps is Powerful

Enter DevOps. DevOps, a portmanteau of “Development” and “Operations”, is a production philosophy that unifies the concept of experimentation and iteration with a measure of control to ensure stability. DevOps is incredibly powerful when implemented correctly.

The biggest source of increased power is the fact that implementing DevOps structuring makes an organization more agile. By tying in iterative development with stability testing, organizations can surpass the time limitation often incurred between shipping versions between development teams and testing teams.

This joining is often referred to as “IT alignment”, and its power can’t be overstated. By properly aligning production and development, versions can be tested against the actual production environment, reducing the incidence of bugs and feature-set failures.

Fundamentally, this reduction of segregated development procedures means greater results with less time and resources.

Implementing DevOps

The biggest change an API developer must make to support the switch from traditional segregated development to DevOps is a change to the fundamental development approach.

Development is commonly considered a process of “waterfall” interactions — one team does their work, shifts it down to another team, that teams does their work, and so on, culminating with the testing of the finished product and ultimate acceptance or denial.

While this is great on paper for ensuring compatibility and functionality, in actuality, all it does is put the development process through a corporate version of the “telephone game”. Each transition from one team to another dulls the product, waters it down, and ultimately removes it one more layer from the original vision and purpose.

By changing the concept of development from “waterfall” to “point-to-point”, developers can harness the power of collaborative work in a more functional way.

When a feature is proposed, DevOps should treat it as a journey from inception to creation, and test it throughout development. When a feature is completed and tested, it should be implemented. Streamlining the process makes development more effective, quicker, and more efficient.

DevOps Tools

With increased power and responsibility, DevOps groups require more powerful and extensive tools to carry out their job. Thankfully, with the emergence of DevOps as a concept, DevOps tools have become more common.

One tool for DevOps in production is the ELK Stack. Combining Elasticsearch, Logstash, and Kibana, the ELK Stack creates meaningful information from data culled from consumers. By examining usage demographics and behaviors, deploy issues can be identified, possible issues can be extrapolated pre-deploy, and behavioral trends and security issues can be determined.

Some tools, like Atlas, integrate DevOps as a process rather than a state of being. Atlas integrates deployment with automated workflows, constrained by set policies. By controlling the nature of deployment and tying it to the development cycle, Atlas allows for a seamless transition from segregated development and operations to the fabled DevOps.

A similar tool, Chef, utilizes “recipes” in place of policy-driven workflow automation to rapidly and automatically deploy services. Chef also has the added benefit of functioning in the open source realm, and boasts a collection of thousands of user-made “recipe” scripts, allowing for proven and rapid development regardless of the enterprise scale and scope.

Not all tools have to focus on automation, either. We’ve previously discussed the power behind Docker, and this power is no more evident than with DevOps teams. Docker allows developer to segregate services into separate containers, and allows for the quick “spinning up” of new environments for testing, development, and isolation. By allowing for mutli-modal production environments and isolating testing from deployment, deploys can be more thoroughly vetted throughout the streamlined process.

One of the biggest oversights in DevOps isn’t necessarily the development cycle, however — it’s the development environment. Even with powerful solutions like Docker, environments in production and in development can differ wildly. This often results in developers making changes to the base code that worked in development to work in production. For developers moving into DevOps, the environment must be unified.

Thankfully, there are just as many tools for exactly this purpose. One of these is ScriptRock GuardRail, a powerful monitoring and configuration system that checks the states of QA, production, and development environments. By ensuring that these environments are the same, DevOps can unify their functionality, and make their development that much more efficient.

For managing these production resources, there’s yet another powerful tool — Stackify. Stackify aggregates errors, tests database queries and requests for speed and accuracy, and collates all of this into easy to read metrics. This is a great tool for ensuring that your production environment is as good as it can be, but is also great for stamping out issues in QA environments as they arise. Having an integrated solution such as this goes a long way towards making the adoption of DevOps possible and painless.

Conclusion

There’s a lot to be said for DevOps. While there will undoubtedly be issues switching from more traditional development cycles to the DevOps world, the fact is that DevOps is incredibly powerful, and is quickly becoming standard for enterprise businesses.

A speaker at DevOps Days put it best by saying:

In most organizations, Dev and Ops have misaligned goals. Dev is measured by the number of new features. Ops is measured by 100% uptime. Question: What’s the best way to get 100% uptime? Answer: Don’t introduce any new features or make any changes.

It is this chief issue that so many developers have experienced that makes DevOps such a raging firestorm. Adoption now could help in the long run, making your API and enterprise more agile, creative, and innovative. Not adopting it? Well, it could either have no effect whatsoever, or leave you in the dust.

The choice is pretty clear.

About Kristopher Sandoval

Kristopher Sandoval is a web developer, author, and artist based out of Northern California with over six years of experience in Information Technology and Network Administration. He writes for Nordic APIs and blogs on his site, A New Sincerity.