The Many Layers of DevOps

Posted on February 22, 2013 by Steve Boone

For many people, DevOps and infrastructure as code are synonymous. However, I am usually quick to point out the other moving parts that need to be managed. There is more to DevOps than infrastructure as code. Once the infrastructure is in place we need to do something with it. Application deployments, database updates, static content deployments, application configuration, middleware configuration, all of these things come into play after the infrastructure is in place.

There are many excellent applications for managing your infrastructure; tools such as Chef and Puppet obviously come to mind (they are easily the most popular). These types of tools are perfect for making changes across multiple servers, and making sure your infrastructure is in sync. They are also great for taking newly spun up virtual machines and making them identical the other servers in your environment.

Infrastructure is only part of the entire stack, and honestly it is not the most volatile part. New machines requiring infrastructure may be added daily but once the infrastructure is in place it tends to change less often than other components of the stack. For example, the middleware configuration, the applications, and the application configuration all change much more frequently than the infrastructure. Managing these changes is a crucial aspect of DevOps.

In the image above, the lowest layers can be handled by a number of tools. These layers are typically handled by the major IaaS providers (Amazon EC2, Rackspace, and others), which involve provisioning of the servers, as well as the OS and the OS configuration. Another great solution is to use Terraform or uProvision to handle the provisioning. These tools enable companies to build an internal PaaS offering to allow teams to automatically spin up servers and make them available for deployment.

The middleware layers have a handful of solutions for automation. Some companies include this configuration in the base image of their virtual machines. Another popular option is using any of the “infrastructure as code” tools mentioned above. These types of configurations can even be managed as part of your application deployment in an application deployment automation (ADA) tool such as uDeploy.

The application, and the application configuration can change multiple times a day in any continuous delivery environment. Often it may only be the configuration itself (and not the binaries) that need to be deployed. uDeploy is designed to not only automate the deployment of the application but also provide visibility into which versions of changes have been applied and where.

“Application Release Automation” is a terrible term

Posted on January 2, 2013 by Eric Minick

The analysts agree, uDeploy and its competitors are “Application Release Automation” tools. We used the same term on our website. Unfortunately, “Application Release Automation” is a bad description for this class of tools.

Let’s look at the three words in this term and see what fits:

Application: Not bad. This scopes things down to software applications rather than hardware or endangered animals. The Application also indicates that we’re working at larger scope than a single tier or component, which is also ok.

Release: To release an application, generally means to deploy it into the production environment. Certainly, production is in scope for these tools, but pre-prod environments are as well. Using the same process in prod and testing environments is a best practice. “Release” might be pointing to heavily towards production. In many companies a “Release” is scoped far larger than a single application or application group. A release can contain numerous unrelated applications. That’s not what ARA is about.
Similarly, we have shared terminology with release management. Is this tool automating a release managers job? Not really, while it can enforce some quality gates and provide better visibility it doesn’t have a detailed Release Management feature set. At UrbanCode, we even provide a specialized release management tool to focus on those topics.

Automation: Not bad. Most people look to a tool like this when they want to greatly improve the speed and quality of their deployments by automating as much as possible.

So the problem is with “Release”. It suggests that we should ignore earlier environments and implies more of a release management role than the tools really fill.

What would be better?

We propose Application Deployment Automation (ADA). Tools like uDeploy are automating the deployment of applications.

Sometimes its a deploying to production – a release. Sometimes its one of the many deployments to the test labs that get us ready for the eventual release. What a tool like uDeploy does extremely well is let you define a standard process that is used in both environments.

Like this sort of thing? Here are other blog posts where I nitpick about jargon:

Automating Database Deployments: Worthwhile and Supported by Tools

Posted on October 11, 2011 by Eric Minick

I get to present UrbanDeploy a few times a week and the part of the demo that always draws questions is when I deploy database upgrades. Why is this spooky magic while application deployments are expected?

Basically, database deployments are hard. Unlike most applications, you can’t simply replace the old version with the new. The changes are incremental, they impact data, and they need the blessing of mystics (DBAs). While hard, database deployments are automated by many teams. They treat database changes like code, and use widely available tools to help them with the migrations.

Continue reading →

True Benefit of Deployment Automation

Posted on September 2, 2011 by Ryan Haffey

With more and more companies looking into automation solutions it’s only natural that the debate of risk vs. reward enters the discussion. Recently I’ve heard the question, “What are the true benefits of automating deployments?” Most people would argue that automation will:

· Help avoid human errors that can occur when deploying manually.

· Lower the amount of time a deployment takes.

· Give folks back their weekend

These are all undoubtedly true when implementing deployment automation, but at the end of the day they are simply components of a greater advantage. The true benefit of automating deployments is enhanced business efficiency, effectiveness, and capability. In other words, when automated, deployment enables growth and change rather than existing as a bottleneck to advancement. Continue reading →

Want a big impact? Start small

Posted on August 26, 2011 by Ryan Haffey

In an enterprise environment patience and small victories are key, when introducing automation into software deployment. This week, I had a conversation with a release manager that reinforced what I know about large organizations. Big change is hard to drive quickly because organizational inertia is so great. Look for little victories in areas the company is ready to take a risk on, and use that to become a trusted provider of a good service to the rest of the company.

The release manager explained in detail two of their most difficult deployments one of which took around 55 hours to complete, the other had multiple issues due to required changes made in the QA environment not being captured and were subsequently over looked when the application was deployed to production, and both deployments had 40 employees on hand to complete. Continue reading →

Webinar: Release Management Best Practices — Balancing Agility and Control

Posted on September 8, 2009 by Eric Minick

Tomorrow (Wednesday Sept 9th) at 2 pm EDT / 11 am PDT Maciej Zawadzki and Damon Poole are going to be talking about Release Management Best Practices: Balancing Agility and Compliance.

The origin of this talk is the conflict we see in development organizations between the people who are trying hard to go faster, and the people who are trying hard to stay in control. There seems to be a fundamental tension between speed and safety… but in practice this is a false dichotomy. Automating manual tasks is a huge win both for time saved and for process enforced, for both Agility and auditing.

If you’d like to hear more you should Register Now and the join us Wednesday.

Practical DevOps Tools

Category Archives: Automation