Phil Stanhope, Vice President of Technology Strategy at Oracle Dyn, knows a thing or two about the DNS. He has recently become interested in the role DNS can play in DevOps. We asked him a few questions about DevOps, how it is changing in a cloud world, and why DNS can be a valuable tool.
Q: In your opinion, what are the key principles of DevOps?
A: DevOps is much more than just the combination of development and ops. It is also a new way of thinking about ops as much more of a proactive, rather than a reactive way of managing servers. Freeing up time spent doing manual processes and dealing with issues allows operations people to spend that time creating systems that will dynamically respond to alert situations, or creating more proactive monitoring services to mitigate future risk of failure.
In many ways DevOps is a trade-off. The up-front work done to mitigate future issues is sacrificed in favor of allowing change and having systems in place to monitor and measure system behavior to quickly identify problems as they arise.
While this may sound more risky, it is worth reminding ourselves that for all the effort put in by traditional operations approaches to minimize the risk of issues arising, issues did arise fairly regularly, and the impact of resolving those issues was usually higher than in a DevOps world.
DevOps is not a job title or a set of tools or even a methodology. It is simply a culture or way of working that emphasizes certain core values. As such, there is no defined set of practices and tools that incorporate DevOps; it is more a set of principles.
The core principles have been defined in many different ways, though all definitions share the same common themes and can generally be categorized in the following three principles:
- Integration and communication
- Automation and repeatability
- Big picture thinking
Q: Can you talk a little more about integration and communication?
A: This is the core principle to DevOps: breaking down walls between teams and getting people to work together as colleagues, not competitors.
Firstly, this will remove the blame culture—the approach in any situation being to blame others until proven otherwise. Shared responsibility will enable a quicker resolution as the team works together to solve a problem.
Secondly, this will get potential issues spotted earlier on and a more proactive solution design will be undertaken.
Building a cross-functional team and working toward a shared objective focused on business objectives rather than silos focused on protecting their own interests can only result in a better outcome for the business.
Q: You mentioned automation and repeatability as a one of the three principles, why is repeatability of process so important to DevOps?
A: Just as in Agile development, the rule “if something is hard to do, do it early and do it often” applies.
This means that not only should your applications be easy to deploy, your infrastructure should be easy to recreate, ideally using a fully automated process. This involves a change in mindset: from infrastructure management as a process of manually installing and configuring hardware and documenting the process, to infrastructure management being the process of managing scripts that will dynamically create and configure your infrastructure, usually within a virtualized or cloud environment.
The result is that infrastructure creation code can be managed in the same manner as other development source code, and test platforms can be created automatically as part of a test or production deployment system.
Q: Lastly, what did you mean by Big Picture Thinking?
A: Developers want to solve all problems with code, DBAs want to solve all problems in the database layer, and operations wants to solve all problems with hardware. That is the nature of thinking when in a very siloed world.
By bringing the teams closer, this issue is mitigated in two ways:
- Earlier involvement of people with specialities so that all specialities have input into a solution.
- More knowledge sharing and appreciation of the elements of the system outside of their expertise, allowing people to understand the potential for solutions in these areas.
As systems become more complex and the options available for system expansion become more varied, this becomes ever more important. For example, when running in a cloud environment, performance issues can be addressed by either code investigation or by increasing the size of the production environment. Likewise, SaaS offering can negate the need for writing code, running infrastructure, or both.
Q: What role does DevOps play in the Cloud?
A: DevOps and cloud are two completely independent aspects of software delivery. You can deliver software using cloud platforms via traditional organizational structures and have a complete DevOps culture without using any cloud-based platforms; however, cloud platforms do make enacting the DevOps principles easier in many cases.
Cloud platforms generally blur the distinction between development and ops, as they are systems that are designed for automation and management via code-level APIs or scripting. Operational changes can be implemented by developers within application code, and operations people are writing code to manage how environments become available for use by applications.
The big picture, in this case, becomes not only the application but also the range of services offered by cloud providers that could be used by the applications, how these would be implemented, and the communication between systems.
Cloud environments have really enabled DevOps to become mainstream as the level of dynamic infrastructure creation and management needed for a true DevOps environment has become not only possible and affordable to organizations of all sizes, but actually the preferred way of working in those environments.
Automation, repeatability, creation and destruction of environments, and infrastructure as code are all elements that have been built into cloud platforms from the ground up.
Q: That makes sense. But why do you think developers should rethink DNS?
A: It may sound obvious to say that modern internet-based systems are dependent on the internet, but it is worth taking a moment to think about the actual impact this is having as systems become more complex, modular, and cloud based.
Before the internet was widely used, most systems were delivered as client/server systems over a leased line-based WAN. So everything was fully under your control; the full end-to-end connectivity and infrastructure were all dedicated to you.
However, this situation is very rare these days. Most connectivity now travels over the public internet. This is true of the connection between your users and your system, and increasingly between your system and third-party dependent services. The quality of this connectivity is largely beyond your control.
Moving into the cloud, however, gives you even less control over the connectivity in and out of your systems. When hosting systems within a data center, you can discuss and understand the nature of connectivity to the internet that are in place and use this as a deciding factor when choosing a data center. In the cloud this level of detail is rarely made public.
Despite its increased importance to people running web-based systems, the performance of the public internet is an area that is often overlooked. Using DNS as a tool for intelligent response allows you to repoint to a different backend system based on the real-time performance of internet conditions.
To read more about DevOps and DNS, download our ebook now!