devopsy.kinsta.cloud

Author: Mark Nunnikhoven

  • Orchestration: How To Get Everyone in Tune

    Orchestration: How To Get Everyone in Tune

    Automation is key to success in the cloud. When your entire infrastructure is accessible via an API, it doesn’t make sense to configure and install your applications by hand. This is where orchestration tools come into play.

    Simply put: You will not have long-term success in the cloud unless an orchestration tool is a core part of your strategy.

    Orchestration Tool Uses

    Each orchestration tool works in roughly the same manner, taking a set of instructions (Chef uses recipes, Puppet uses manifests and Ansible uses plays) and applying them to one or more systems. The syntax of the instructions and how they are applied changes with each tool, but the principles are consistent.

    This leads to the most common use case: configuring a new server.

    Instead of manually installing all of the required libraries, applications, config files and other tools, you simply run the matching set of instructions. Need a new web server? One command and you’re set. Need a database server? Another command has it up and running quickly.

    That’s the basic idea, but with each of these tools you easily can build out a more complex configuration by nesting sets of instructions. Taking the two examples above, you could have a baseline server configuration with all of the common tools and configurations, then customize each server with a smaller set of configurations specific to web servers and database servers.

    Does a new utility need to be on all of your systems? Do you have a new version of your app? Do you need to push out a new configuration file for your data stores? Send one set of instructions through your orchestration tool and you’re done.

    It doesn’t take long to see the value of these tools and to mandate their use for all of your cloud deployments.

    Not So Fast

    Like most challenges in the DevOps space, orchestration isn’t that simple. You can’t just wave your magic wand and get all of your teams using a centralized orchestration tool. This is not a new challenge, we’ve been trying to get this right since the early ’90s (remember Novell ZenWorks or the first version of Microsoft Systems Manager?) and are just now starting to see wide(r)spread success.

    Culture is the No. 1 blocker when it comes to this category of tool.

    You’ll hear some common objections from teams:

    • The choice of technology (is Chef versus Puppet versus Ansible versus the Emacs versus Vi?)
    • It wasn’t built here.
    • The manual process works just fine.

    These objections rarely hold up to scrutiny, but that doesn’t matter. Any objection raised needs to be addressed in some manner until you’ve got enough people on the target team to sway the rest over to the direction you’re trying to head.

    When you’re facing a cultural challenge, you have to address the people side of the equation in your strategy!

    3 Steps to Take

    No solution is going to work in all cases, as every organization is unique. You know the culture of your organization best, so go with your gut. With that in mind, here are the three approaches that tend to work best for most organizations.

    1. Empathy

    No one likes to be told what to do from up on high. While mandating that a team switch over to this shiny new orchestration tool might get the work done initially, it also will build resentment. That’s the opposite of what you want. You want buy-in.

    Odds are, each team in your organization already has a to-do list a mile long. Regardless of the benefits, your orchestration project probably isn’t very high on the list. Accepting that your priority isn’t their priority is a key step toward understanding and empathy.

    2. Pitch In

    One way to help move up the priority list is to offer to help out and pitch in.

    Learning a new tool and new way of conducting ops doesn’t just happen overnight. Have a strong, step-by-step plan to help bring other teams up to speed. A core part of that plan has to be one of your team working with the new team for as long as it takes to get them comfortable with the new tool.

    Take a patient, hands-on approach. Let other teams learn by doing … and by making mistakes. Your role is to guide them along the path of adopting the new tool. Time and time again, this type of approach has proven to be far more successful than other options.

    3. Duct Tape

    As your efforts progress, you may reach the point where the other teams are comfortable with the tooling, understand the workflow and are ready to adopt the new tool.

    The problem is now either:

    1. Developing new sets of instructions or
    2. Converting old scripts or hacks to the new tool.

    To tackle the first challenge, make sure you’ve set up an easy way for teams to share sets of instructions. A centralized set of git repos work great for this. This will reduce the overall workload and encourage collaboration. It’s better to borrow than to rewrite.

    You’ll also want to make sure there is a regular communication highlighting successes with the new tooling. This will help remind teams of the value of the new way of working.

    To tackle conversion (problem No. 2), plug your nose and use this messy hack. All three major orchestration tools allow you to execute another script or program. If you already have working sets of instructions, keep using them. Just wrap them in the new tool to gain the workflow benefits.

    Eventually you will replace them with native instruction sets, but if it’s working “as is,” that’s one less set that you need to build.

    Smoother Operations

    A lot of operational issues happen because of a manual error. Asking someone to make the same configuration change on six systems is bound to lead to a mistake. By moving to the cloud, you’ve already accepted the ability to program your infrastructure. Manually configuring the assets in that infrastructure doesn’t make any sense.

    Orchestration tools allow you to reduce the number of mistake made, ensure consistent results and amplify the productivity of your teams.

    What’s not to love?

    What have your experiences moving a number of teams to a common tool been like? What tips and tricks did you learn along the way? Share in the comments below or on Twitter, where I’m @marknca.

  • Hybrid Cloud: How to Avoid Twice the Problems

    Hybrid Cloud: How to Avoid Twice the Problems

    Regardless of how enthusiastically you embrace the cloud, unless you’re a brand new business, you have already have an infrastructure running your applications. Odds are, you’re either renting space in one or more data centers. Or maybe long ago you reached the tipping point and built a data center or two of your own.

    Regardless, moving to the cloud is going to be a process. You’re going to be working on a scale of months, if not years. During that time, how do you manage and secure assets that are in more than one environment—especially when those environments are radically different?

    The Data Center

    Your data center environment is probably well-established. You’ve got a mature technology stack, a high level of rigor around manual processes and a traditional “castle walls” perimeter-based approach to security.

    Specialized teams are in place for the networking infrastructure, operating system management, security, data center logistics and other areas. Each team does a great job running the day-to-day of their areas and planning for the five-to-seven-year life cycle of their technologies.

    The challenge here is that this structure has lead to a slow, stable cadence around innovation and encourages each team to work in their own silo. Common ground and management is established through a formal change management process. This results in stability, but at a very high cost when it comes to rapidly iterating on ideas.

    The Cloud

    In stark contrast, the cloud is constantly changing. New technologies are deployed quickly, systems such as continuous integration/continuous deployment (CI/CD) enforce what used to be a manual process and capacity planning is basically a thing of the past.

    Just as the cloud is delivered in a different manner, teams working in the cloud also are delivering in a very different manner.

    When assets are available on demand and at a higher level of abstraction, a lot of the work associated with deploying a new application is handled by automation, allowing you to focus on solving problems for your customers.

    Reconciliation

    It’s clear that the data center and cloud are two very different environments. How do you reconcile having assets in each without simply duplicating all of your tooling and processes?

    Tools

    Start with the tools that your teams are using today. Odds are, the set of tools you’re leveraging in the cloud more closely aligns with what you want to achieve around application delivery.

    Cloud-first tools also are more likely to be able to handle the rapid pace of change and the large-scale environments normal to the cloud. These traits make it easier for cloud-first tools to adapt to the data center.

    Make sure you’re pushing your cloud-first tools in to the data center and not the other way around.

    Responsibilities

    Leveraging more cloud services from a variety of providers means that the day-to-day operational and security responsibilities are spread out among teams and organizations. This can pose some serious challenges if not addressed properly.

    You need to ensure responsibilities are defined clearly for all involved and there is a spirit of cooperation so that you can avoid finger-pointing when things hit the fan.

    Remember that service level agreements (SLAs) represent the worst-case scenario. Solutions and services always should beat the stated SLA. If a team or organization you’re working with is consistently blowing their SLA or barely meeting it, it’s time to re-evaluate their involvement.

    Process

    Your processes define how the responsible teams are going to use the tools you’ve deployed. Data center processes are the weak spot in joint hybrid environment processes.

    The traditional workflows typically are too slow and require too much manual work to support the style of work the cloud promotes. Take the processes you use in the cloud (think CI/CD), map out where you absolutely have to make exceptions for the data center, and use those as your baseline processes.

    The goal here it to double down on your DevOps culture shift and force it into the data center. You want to maximize your current data center investment while not slowing down the culture transformation you’ve started with DevOps.

    Security

    The last piece of the puzzle (at least a high level) is security. It’s crucial you view security as a unified layer across all of your environments.

    Security is challenging enough without creating additional work for your teams.

    Security controls need to integrate with your preferred cloud service providers and be applicable inside the data center. The traditional perimeter is gone, and tools that still try to defend your data under that principle are needlessly increasing your risk.

    Modern controls need to be applied as close to the workload and data as possible. They need to present a unified front across environments and still handle the speed and scale of the cloud.

    That may seem like a tall order, but there’s a lot of work being done in the vendor and open-source communities to modernize the approach to hybrid security rapidly.

    The Way Forward

    Even in a best-case scenario, you’re going to be dealing with hybrid environments for months–if not years–to come. Doubling your workload or ignoring the challenges will only make matters worse. It’s best to tackle the problem head on.

    Here are the three keys to remember:

    1. Aim for one set of processes,
    2. Push cloud tools into the data center, and
    3. View security as a unified layer.

    This is a difficult task. You are not going to get it right the first time. The key is to ensure your teams are working together, communicating regularly and iterating often.

    What are your experiences managing hybrid environments? Let me know on Twitter, where I’m @marknca, or leave a comment below.

    BTW, if you’re looking for a deeper dive on the topic of hybrid environments, watch my webinar hosted by devopsy.kinsta.cloud, “Handling The Realities of Hybrid Cloud.” Watch below or over on the Trend Micro site.