devopsy.kinsta.cloud

Tag: Chef

Using DevOps to Achieve Business Agility – A Webinar with Rally Software and Chef
We are kicking off our devopsy.kinsta.cloud webinars with a real blockbuster! Join Colin Campbell of Chef and Jonathan Chauncey and Jeff Smith of Rally Software as they discuss:

Using DevOps to Achieve Business Agility

In today’s digital economy, leading companies are turning to software to deliver new services in response to customer demand and competition. Technology can enable and expedite innovation, but it requires business leaders, software developers and IT operations teams to closely collaborate around shared goals, at new speeds, and with the flexibility to change on a dime to customer needs and market shifts. In this webinar, Rally Software, a leading global provider of enterprise-class software and services solutions, will discuss how it has institutionalized DevOps and how it uses Chef to support its speed-focused approach to delivering business agility. You’ll learn firsthand how Rally automates its virtualized infrastructure, accelerates application development and tightens customer feedback loops.

Date and Time: Thursday, September 4 at 11am PT/2pm ET

Register at: http://devops.megameeting.com/registration/?id=1949-232488

The webinar will be hosted by devopsy.kinsta.cloud and moderated by devopsy.kinsta.cloud editor-in-chief, Alan Shimel. Speakers include:
- Jonathan Chauncey, developer at Rally Software. He’s been involved in Web application development for almost 10 years, four of which have been at Rally. His technical interests include: automation, testing, clojure, Ruby and search.
- Jeff Smith, development manager at Rally Software. He’s been involved in Web application development for almost 20 years, 11 of which have been at Rally. His technical interests include: test automation, continuous deployment and infrastructure automation.
- Colin Campbell, director of patterns and practices at Chef. He has worked on advanced model-based testing and analysis techniques for a number of years in industry. He is currently involved in developing and documenting Chef best practices and design patterns.
Registration is required to attend the webinar. You can register here.
August 21, 2014
How to Find Your Continuous Delivery Rhythm
This article is a part of a series of pieces on digital innovation, accelerating change and the rise of the coded business from innovators in the Chef community. In this article we present an interview with Jez Humble, Principal Consultant, ThoughtWorks, on digital innovation.

Focusing on speed and scale allows you to respond more rapidly to weak signals in the market, and to arbitrage those opportunities quickly. This is different from the way it used to be. In the past, we’d only respond to the strong signals in the marketplace. But now, with the lower cost of investment in product development, and the resulting optionality in that process, we can service subtle market signals effectively.

Here’s an example of this. A company noticed that when people searched for bird-cages online, very few entries came up. So, to fill the void, the company began making bird-cages. And now this business has created a new revenue stream selling bird-cages. We’re also learning that the way we service customer demand – in all its varieties – is part of the product development process. This comes with the emergence of user-experience design. And it shows that marketing, as well as technology, is an essential part of product development today. Zappos is a great case study that illustrates my point. Many companies try to minimize the time spent on customer support calls. Zappos spent a maximum amount of time on customer calls every day. And, by deeply engaging with the customer, they learn about the customer.

Code is really the key to exploring and exploiting new opportunities in an inexpensive and scalable way. And here, we have to give credit to Toyota, which has been using Lean to show us how to re-tool on the fly in response to customer demand. As a result, software is now following automobile manufacturing.

A major part of all this is continuous delivery of code, which, from my perspective, is fundamentally about reducing the transaction cost of putting out incremental changes. And I want to emphasize the importance of incremental changes and small batches; continuous delivery of code really can’t be effective if it’s one-piece flow.

Think about it this way. You don’t buy eggs at the supermarket once a year. And you don’t buy an egg as a replacement every single time you use one. No, you buy eggs on an ongoing basis in small batches. This is the kind of rhythm that powers our ability to move rapidly when there’s a weak signal in the marketplace. It’s the kind of rhythm that powers our ability to change code based on customer demand. And it’s the kind of rhythm that powers our ability to compete effectively – and with a decided advantage.

Netflix, Etsy, Amazon, Google and Facebook are five of the best at this. And I also like the way the British government’s digital service has been re-tooled and re-built with Lean, customer experience, and continuous delivery principles in mind. The government site is, without question, all about customer demand and customer service, and it has saved citizens a lot of money as well. The take-away here is that software companies shouldn’t be thinking narrowly about software; instead, they should be thinking about how their software can better serve customers. To do that, the entire business has to be run differently and more effectively. And, again, technology people – as well as product marketing people, financial people and governance people – all have to join in and help make it happen.

There are three practices of continuous delivery that can help you create the most efficient path from hypothesis to continuous feedback:
- Comprehensive configuration management
- Continuous integration
- Comprehensive automation of build, test, deploy, and infrastructure management
A new kind of “MVP”

One of the key ideas that the Lean startup movement has popularized is the minimum viable product (MVP), which is defined as the least possible amount of work you can do to test your business hypothesis.

Of course, people in manufacturing have been producing minimum viable products for decades – they’re called prototypes. I like the MVP because you’re not betting the company, or spending big wads of cash.

Another key Lean concept is validated learning; here, you gather actionable metrics based on real usage of your product, without asking people. To do this, however, you’ll need to be able to answer questions like:
- Did the changes we made to the product improve signup, retention, revenue? Or is it time to pivot?
- Which version of our new feature came out better when we did A/B testing?
- All our system metrics look okay, but a user reports that our site isn’t working. Are we down?
- Which features of our product are generating the most revenue?
These questions should be answerable by looking at a dashboard, and the information should be completely auditable. But this kind of learning is only possible if metrics are built into the “hypotheses” that are being tested. Once you have an idea for a minimum viable product, you need to start delivering software. The first step is analysis. My view is that you need to do just enough analysis up-front, and this approach needs to continue throughout the lifecycle of the project, with the emphasis on creating very small, incremental stories.

Doing less and learning more

Let’s say you’re working on a hotel booking site, and you want to add a feature to allow people to choose whether they want breakfast. Don’t create this feature for all hotels, or for all partner sites. Instead, start with a “hypothesis” that allows you to add that feature for a single hotel, with no configuration options, and get feedback for that possibility before you proceed further.

Do less, so that you can focus your efforts on learning from your users.

If you want to increase your release frequency, it’s essential to decouple your deployments from the act of taking a feature live. Feature toggles (also known as bits or switches) help you control who can see which features. This setup also allows you to release new versions of revised software that include partially complete features, containing perhaps a story or two of work, but nothing you’d want the general public using.

In addition to enabling incremental delivery of functionality, feature toggles let you turn off a problematic feature when a release goes wrong, as an alternative to rolling back your deployment.

The bottom line is that continuous delivery like this liberates us by reducing the cost and risk of releasing software, and by powering much-needed innovation at the same time.

Jez Humble is a principal consultant with ThoughtWorks and co-author of “Continuous Delivery” and “Lean Enterprise.” He began his IT career in 2000. Over the past 14 years, he has been a developer, system administrator, trainer, consultant, manager and speaker. He has worked with a variety of platforms and technologies, consulting for non-profits, telecoms, financial services and on-line retail companies. Since 2004, he has worked for ThoughtWorks and ThoughtWorks Studios in Beijing, Bangalore, London and San Francisco. He holds a BA in Physics and Philosophy from Oxford University and an MMus in Ethnomusicology from the School of Oriental and African Studies, University of London.
July 21, 2014
Web-scale IT drives Chef momentum
Chef today announced a series of metrics and features showing their support of and success as a result of what they call the shift to Web-Scale IT. As the picture below shows the Web-scale IT era has given rise to an exponentially larger, more scalable IT infrastructure.

What is Web-sclae IT? According to Chef:

Web-scale IT brings the practices of large, web innovators into every business
- Web-oriented architecture
- Cloud capable including hybrid
- Commodity hardware
- Open source software
- DevOps practices
But I don’t want to give the impression that Web-scale IT is a Chef invention. Actually it is Gartner that is providing a lot of the analysis on the key drivers here and forecasting its heightened importance in IT. From a recent press release from Gartner:

By 2017, Web-scale IT will be an architectural approach found operating in 50 percent of global enterprises, up from less than 10 percent in 2013, according to Gartner, Inc. Web-scale IT is a pattern of global-class computing that delivers the capabilities of large cloud service providers within an enterprise IT setting by rethinking positions across several dimensions.

Barry Crist, CEO of Chef said, “Today, every business is a software business. Customers everywhere expect delightful and immediate services. Meeting these expectations is only possible through the speed, scale, and consistency provided by employing web-scale IT. Chef’s IT automation platform packages the success patterns of web innovators and delivers them to the enterprise,”

Here are some of the elements or patterns of Web-Scale IT:

Having been through so many IT adoption cycles (I remember the big move to client/server), I am always weary of any new “paradigm changing” scenarios. If they were all true I would have retired an Internet millionaire back in the first dotcom bubble. However, what Chef is calling out here is certainly supported by the facts. IT today because of the Cloud, Big Data, virtualization, mobility and more has fundamentally changed. Automation, agile and lean principles are enabling the leveraging of these technologies more every day.

Companies like Chef are capitalizing on these trends by providing solutions that both leverage and enable Web-scale IT. It is hard to argue with the numbers from Chef:
- 182% Incremental Revenue Growth YoY
- 100% New Enterprise Customer Growth YoY
- Over 700 paying customers
- 70% of total Sales to F1000
- 600,000 Chef downloads per month
- 55,000 Registered Chef Community members
- Millions of Managed Instances
As part of the announcement around their momentum Chef also announced some new product features. From their press release:

–        New Analytics Platform, Acquisition of Tower 3: Chef’s new analytics platform provides full visibility into all activity on the Chef server and lays the foundation for audit and compliance capabilities. Chef recently acquired big data and analytics startup Tower3, adding significant engineering resources and expertise to its ongoing analytics development efforts. Now available to Chef subscribers is the new Chef action log, which publishes notifications on who is changing what on the Chef server and allows administrators to track cookbook usage, roles, environments, and changes to infrastructure, all through an easy-to-use dashboard.

–        Test-Driven Infrastructure: Test-driven infrastructure ensures maximum IT safety and consistency with programmatic and automated testing of the entire stack. Chef is the first company to offer its customers commercial support for test-driven infrastructure. Chef has also created a single installation package – Chef DK – for the open source tools covering the entire test and development workflow, from the workstation all the way to production. Rally Software is among a range of enterprise customers using Chef for a test-driven approach to infrastructure and applications (see separate release).

–        End-to-End Container Workflow Automation: Chef is the first automation platform to deliver end-to-end management of container workflows. Chef Container is a build of the Chef Client that integrates with all Linux containers (LXC), including Docker, to enable seamless management of container resources. In conjunction with Chef Container, Chef is also releasing a Knife Plugin-in for Docker integration with Chef Container, enabling users to launch, configure and manage Docker containers. Together, Chef’s new suite of container tools and content fully automate the creation, management, monitoring and testing of containers, making them versionable, testable, and repeatable within a production workflow.

If you are interested in learning more about Web-scale IT, Chef have also released a white paper: “Automation and Web-Scale IT”

All very impressive from Chef. But I don’t want to convey the idea that Chef is the only success in Web-scale IT or DevOps. Other companies like Puppet Labs, Saltstack, StackDriver, Ansibile, etc. are all experiencing rapid growth by riding the Web-scale IT express. Behind them are a host (no pun intended) of new startups that are offering solutions in this area. Maybe this time we really are seeing a paradigm shift.

In the meantime congratulations to Chef on some phenomenal growth numbers. For those of you who have made it to the bottom here, how is Web-scale IT changing your life?
July 15, 2014
Using Docker & Ansible by John Minnihan @Gluecon 2014

Continuing our series of videos from the DevOps track at Gluecon this past year, our next video is “Why Docker + Ansible Make Chef and Puppet 100% Unnecessary by John Minnihan, ModernRepo” Again many thanks to CloudSoft for recording and making these videos available to us to post. Also the picture above is from the Ansible website originally.

This presentation sounds pretty controversial if you just look at the title. Actually John is not advocating throwing away your Puppet or Chef scripts. If you already have Chef or Puppet set up and you like the way it is working, there is no reason to change. However, John believes that Docker with Ansible can negate the need to use either of these tools going forward. John is primarily talking about a greenfield situation here I believe. Anyway, the video like the previous ones in this series are about 30 minutes. Enjoy!

June 4, 2014
Simplify and expedite server management

Deploying, managing, and maintaining servers can be tedious. Deploying, managing, and maintaining thousands, or tens of thousands of server instances is overwhelming—bordering on impossible—without the right tools. Thankfully, the right tools exist.

The Pain of Doing Things the Hard Way

I know I am dating myself, but when I was an IT admin for a dot.com startup, I had to deploy servers the old-fashioned way. UPS would show up with a box from Dell. I’d unpack it, and mount it on the rack in the datacenter. Then, I’d begin the process of configuring the operating system, and installing the application software. Each server was essentially a full-day project, and we seemed to constantly be adding new servers, so my full-time role was basically “racking and stacking” for a while.

Adam Jacob was experiencing similar obstacles when he developed Chef. Working as an IT infrastructure consultant, Jacob was frustrated by the configuration tools that were available, and the lack of a simple, repeatable process. Rather than starting from scratch and reinventing the wheel for each client, he developed Chef to enable IT admins to create modular, reusable “recipes” that automate the process.

Server management doesn’t end with deployment and initial configuration, though. You also have to maintain the servers, and resolve issues that might occur. When an issue arises, it could mean hours of troubleshooting to identify the root cause, and another few hours to work out and implement a resolution.

I used to get into philosophical debates with management and other IT personnel because it was my opinion that we should just skip the troubleshooting and rebuild the server from scratch. My theory was that it might be nice to know what caused the problem, but from an operational perspective I knew I could rebuild the server and restore normal operations in a couple hours. Troubleshooting, on the other hand, was an unknown—both in terms of whether or not it would even be successful, as well as how long it would take.

The Beauty of Doing Things the Easy Way

Tools that automate configuration and deployment of server instances automatically solve both of these problems. They expedite deployment and configuration, and simplify management and maintenance—freeing IT admins and IT personnel to focus on more important, less mundane tasks.

Tools like Chef help IT manage complexity. It is great from a DevOps, automation perspective to have a tool that enables you to quickly deploy and configure servers, but the real value comes from the ability to maintain a stable, dependable network with minimal effort.

Chef nodes “phone home” periodically to ensure the configuration matches the recipe it has been assigned from the Chef server. Any deviations are automatically overwritten—so any changes that may have been made locally on the node are erased, and the server remains configured as it should be.

In order to implement lasting configuration updates, the changes have to be made to the recipe at the Chef server level. The bonus is that once the recipe is updated, all Chef nodes working from that recipe will be automatically updated.

When an issue occurs on a server instance, it should ostensibly be corrected automatically when the node communicates with the Chef server and overwrites the configuration. However, even if that doesn’t happen for some reason, the use of DevOps tools like Chef still makes the task of troubleshooting and/or resolving server issues much more efficient.

With the push of a button, you can just deploy a new server—properly configured and ready to go. You could choose to kill the server experiencing issues and just replace it with the new one, or you could launch a new server to take over the roles and responsibilities of the affected server while you take the time to troubleshoot if you really need to understand what the root cause of the problem was.

Embrace simplicity

Apparently, I was an IT admin at the wrong time, and I got out of that career path right when things started to get interesting. Necessity being the mother of invention and all that, Adam Jacob created a platform with Chef that reduces the complexity and tedium of deploying and managing servers.

Chef isn’t alone. Tools like this form the foundation of DevOps because a culture that combines development and operations, and iterates new releases on a rapid scale needs to have this sort of automated IT infrastructure to keep up.

May 21, 2014
Automating code helps businesses adapt to customer demand quickly

This is the first article in a series of pieces on digital innovation, accelerating change and the rise of the coded business from innovators in the Chef (click here) community.

How does the need for speed and scale affect businesses today?

Let’s start with scale. As a technology company grows, its infrastructure grows – more machines (or machine images), more networking, more data storage needs, more code, more developers, and more users. The only way to scale with growth is with automation. And, as more and more of the world’s interactions happen online (be it commercial transactions, email, social networking, video streaming, etc.), that scale of infrastructure is breaking records all the time. With these new levels of scale come ever-increasing automation requirements.

On the speed side, first-to-market has always been an important part of business – but what that means has evolved. It’s no longer simply about producing that new cool item before the other guys. Now it also means you must be able to iterate quickly, adjust quickly for changing user tastes, and adapt quickly to the ever-increasing pace of new technologies. To be able to do this effectively, instead of just developing fast, you need to be able to deploy quickly, react quickly, troubleshoot quickly, and update quickly. For many companies, this is no longer icing on the cake, but instead, the structure underpinning their business – in the same way that having an e-commerce site was 10 years ago.

Speed is becoming ever more critical for business in the digital age. With the rise of social media, a lot of customer feedback is public or semi-public, allowing people to unite behind specific complaints or desires and provide more clear and unified messages to companies. This helps companies get more feedback of higher quality and – hopefully – to react to it more quickly. This is also dramatically accelerating the cycle of getting features/products/releases to users, and, perhaps more significantly, prompting users to provide more useful feedback faster. As I mentioned, the scale and speed of business operations in every industry are growing daily, and, because of that, automation has gone from being beneficial to critical. In the technology world, this automation comes in the form of code.

Pushing your code faster and faster means you have to be able to update and deploy infrastructure faster, which in turn means infrastructure/systems teams must also be able to deploy, react, troubleshoot and fix faster.

But code, in and of itself, isn’t necessarily sufficient to meet the challenge of escalating speed and scale. How quickly you deliver that code is what’s important. Continuous Delivery is one technique used to address this need.

Continuous Delivery (CD)

People talk a lot about CD and it’s important to remember that this phrase refers to a methodology that has pros and cons.

For most technology companies, especially those whose product is primarily Web-based, CD is often the best choice to enable speed of delivery. The main benefit is that the closer to “continuous” your release-cycle gets, the easier it is to have an iterative process. Faster feedback from users means you can more rapidly deliver updates based on that feedback. As you approach CD, you approach near-real-time feedback, which allows you to hone your product or feature far faster than if it were sitting in long dev/qa cycles. Another benefit is best described with a comparison. In troubleshooting, a key rule is make one change at a time, so you know which change fixed the problem – or made it worse. CD is an extension of this idea, although it comes earlier in the lifecycle. If you are pushing/delivering a codebase more often, there are less changes per push, and so breakages are easier to track down – and it’s easier to push fixes.

A common misconception is that an organization either achieves CD or it does not. CD is a spectrum with frequent releases on one end and less frequent on the other. A CD solution for a bank may mean something very different than a CD solution for a gaming Web site. The idea of the CD methodology is continuing to push toward faster deployments, in order to reap the benefits that come from doing so.

In the end, no matter what part of the CD spectrum a company aims to achieve, they must be willing to adapt and change.

From an internal IT perspective, this means realizing that this isn’t the old world, where businesses lock users into small boxes to make things simpler. We’re in a world where everyone has the power of the Internet in his or her pocket and there’s enough information out there for anyone to break out of his or her box. Businesses need to provide engineers, designers, assistants, VPs, etc. the flexibility and freedom to work and think in ways they do best, so they can take the business to the next level.

From an external (production) IT perspective, companies must be able to quickly adapt to new growth and new technology. It took the Internet a (relatively) long time to start adapting to the small displays on mobile devices, and it adapted only slightly faster to tablets. But new form-factors are just the beginning. Broadband is becoming ubiquitous in first-world countries, and companies are just starting to rely on that fact. Yet there are still many users the Web isn’t taking into account very well. Mobile is becoming the default interface for a variety of locales and ages, and many countries have limited bandwidth and/or high latency. Further, it seems likely that we will see drastically different user input mechanisms, as well as display mechanisms, in the near future.

Technologists need to be agile and readily adapt to technology and infrastructure changes, as well as speed and approach changes, such as CD, which will be required for the next generation of user and technology demands.

About the author

Phil Dibowitz has been working in systems engineering for 12 years and is currently a production engineer at Facebook. Initially, he worked on the traffic infrastructure team, automating load balancer configuration management, as well as designing and building the production IPv6 infrastructure. He now leads the team responsible for rebuilding the configuration management system from the ground up. Prior to Facebook, he worked at Google, where he managed the large Gmail environment, and at Ticketmaster, where he co-authored and open sourced a configuration management tool called Spine. He also contributes to, and maintains, various open source projects and has spoken at conferences and LUG’s on a variety of topics from Path MTU Discovery to X509.

May 8, 2014
Security automation with DevOps: show me the code!
Last week Andrew Storms put up a good post hinting at the promise of security automation in [SecDevOps: Security Automation By Example – The Firewall Change]. He included an example of automating a series of actions when a firewall rule is changed. It’s a good article, although I’m increasingly convinced there’s no such thing as SecDevOps. In my book, it’s all DevOps, but that’s fodder for another post (when I’m not battling a stomach bug). However, what Andrew describes is more of what I consider an automated assist. It isn’t necessarily full automation, since it triggers on a manual firewall rule change. Ideally we rarely manually change a firewall (or Security Group) rule, and rely more on self-configuring based on policies. Yeah, I know, the usual analyst BS, so here’s a bit of process, and a bit of code. Let’s approach this differently. Take Andrew’s process, but let’s have the security group or host firewall self configure based on the asset. My example is going to be Amazon Web Services specific, since I have some code snippets to show off how it works. (Sorry, I don’t have the time or intestinal fortitude to write out all the code today; seriously, where did this bug come from?!?) There are two techniques I generally see forming the core of dynamic Security Group policy enforcement:
1. Tags
2. Configuration Management integration
Some cloud services, like AWS, support tags at the object (in this case, instance) level. These tags can tie internally to policies while also being consumable for external tools. Here is a policy I use that restricts access to an object if the “SecurityStatus” tag is “IR” (for “Incident Response”):
```
{  
  "Version": "2012-10-17",  
  "Statement": [  
    {
      "Action": "*",
      "Condition": {  
        "StringEquals": {
          "ec2:ResourceTag/SecurityStatus": "IR"
          }
          },
          "Resource": [
          "*"
                      ],
          "Effect": "Deny"
      }
      ]  
    }         
```
I could apply that tag manually or automatically, and in either case the instance can no longer be managed by any account this policy is applied to. Now this doesn’t help us change firewall/Security Group rules, since you can’t manage those directly in EC2 based on tags (but I had the policy handy to demo, so there you go). For that to work, you need to write your own code to scan for tags and then take actions. I don’t have exactly the right code examples on hand. but here are some snippets to get you close. Most of these are cribbed from my SecuritySquirrel proof of concept on GitHub. They are all in Ruby, using the AWS 2.0 developer preview SDK. First, to pull a list of all instances with a certain tag, you can use the following:
```
def testing
 # testing some tag code
 instancelist = @@ec22.describe_tags(
 filters: [
 {
   name: "key",
   values: ["SecurityStatus"]
 }
 ]
 )
 puts instancelist.to_h
end  
```
That shows everything with the SecurityStatus tag (instances and values, shown as a hash), but you could also filter on value. From there, you could pull the instance IDs with a map (you might want to further filter only on instances, but if you made it this far you can figure that out):
```
 instances = instancelist.map(&:resource_id)  
```
Then you can pump those into a method to change the Security Group. Here’s the one from SecuritySquirrel that places an instance into a “Quarantine” group:
```
def quarantine
  #this method moves the provided instance into the Quarantine security group defined in the config file.
  puts ""
  puts "Quarantining #{@instance_id}..."
  quarantine = @@ec22.modify_instance_attribute(instance_id: "#{@instance_id}", groups: ["#{@QuarantineGroup}"])
  puts "#{@instance_id} moved to the Quarantine security group from your configuration settings."
end  
```
Want to trigger some scanning? Here’s a code snippet to trigger a Qualys scan on an instance from a virtual appliance in your AWS account (keep in mind, I’m skipping a bunch of important pieces, like configuring the service and authenticating):
```
  instance_IP = instance_details.reservations.first.instances.first.private_ip_address
 timestamp = Time.new
 scan =(HTTParty.post("https://qualysapi.qg2.apps.qualys.com/api/2.0/fo/scan/",
      :basic_auth => @qualysauth,
      :query => { 
        :action => "launch",
        :scan_title => "SecuritySquirrel Scan at #{timestamp}", 
        :ip => "#{instance_IP}",
        :option_title => "Initial Options",
        :iscanner_name =>  "us-west-2" 
      },
      :headers => { "X-Requested-With" => "ruby httparty"}))
      puts "Launching Qualys scan named: SecuritySquirrel Scan at #{timestamp}"  
```
Or want to change the CloudPassage Halo host firewall rules? Well, that code uses a pre-release of their Ruby SDK, so I’ll save it for another day (I’m not employed by them, but they let me play with the pre-release gem). These examples are all based on tags, but remember that if you use a tool like Chef or Puppet you can do the exact same thing based on what software is configured and running within the instance. For example, you could create a policy to quarantine all SSL when the Heartbleed vulnerability hit by closing off port 443 on any server running the vulnerable OpenSSL package, then remove the rule when it is updated to the patched version. I’m a bit rusty since I don’t code every day, but I could probably pop that code off in an hour or two, it isn’t that hard. Also my tool is designed for demos, and doesn’t run in the background, but clearly you could have it running all the time, adjusting things based on tags or even attributes of software deployed in the instance. Security automation is insanely powerful. It can completely automate complex security tasks, or, as in Andrew’s example, supplement manual activities and policy changes. Hopefully my snippets give you some ideas, and pop me over any good examples if you are willing to share.
May 7, 2014
Delivering Delight At ChefConf 2014

Chef CEO Barry Crist stirs the pot to open ChefConf 2014

The theme from ChefConf 2014 is stirring delight and if you listened to Barry Crist during todays opening keynote, then you would know its more appropriately “F****ing Delight”. Amidst high energy, loud music and a smattering of exciting expletives, Barry Crist called for attendees to stir delight in their enterprises using DevOps methodologies and, of course, Chef.

Crist defined delight when the customer’s experience exceeds expectations. Using Uber as an example when traveling in New York, he joked that the influx of Uber cars was so high that it took only 30 seconds for him to wait for a ride. And what more he didn’t have to deal with payment when exiting the car at the airport. In short, the service not only provided the expected functionality of something as simple as a car ride, but provided a delightful experience. The new economy, we are part of he said, is the “delight economy”. And the call to action for ChefConf attendees is to bring others along with them into this new and leading economy.

Using Volvo as a case study, Crist also touched on the concept that many companies, not just web development organizations, can utilize DevOps practices. When his wife’s Volvo navigation system needed a map update, he received a set of DVDs. The DVDs needed to be manually loaded into the on-board computer while leaving the car running for 5 hours. Crist countered that Volvo is more like a software company than a car manufacturer, but they just didn’t know it yet. For example, this would have been an excellent case for continuous delivery in that the Volvo probably didn’t need to ship him a handful of DVDs, but just the small changes and probably could have been delivered in a much more economical means.

Crist concluded that using DevOps methods and delivering delight isn’t limited to any industry and certainly isn’t just for web dev shops. And so ChefConf 2014 begins.

April 17, 2014
Microsoft bridges the gap between Azure and DevOps

DevOps can be easy for a startup. Many of the concepts and principles of DevOps come quite naturally to a fresh company just getting started. It’s a different story, however, for large, established enterprises trying to wrap their arms around this DevOps thing. For IT admins working in Microsoft’s Azure cloud platform, though, things just got a lot easier thanks to the integration of Chef and Puppet Labs.

Many organizations are heavily invested in the Microsoft ecosystem. IT teams and administrators are familiar with Windows domains, Active Directory, Hyper-V, and Azure. They know how to write scripts and leverage PowerShell to get things done, but they’re much less familiar with the core principles of DevOps, or common DevOps automation tools like Chef and Puppet Labs.

One of the driving forces of DevOps is the ability—or perhaps necessity—to automate those tasks that can be automated so IT resources are freed up to focus on more important tasks. Deploying and configuring virtual servers and applications is necessary, but it can also be tedious, and it is a task that can be easily automated using DevOps tools.

The arrangement also works the other way. Smaller companies that are already familiar with, and invested in DevOps may need to scale to a platform like Azure. They should be able to build on what they’ve started, and continue to use the tools they’re familiar with as the company migrates to Microsoft’s Azure.

One of the main attractions of Microsoft Azure is the degree of flexibility, choice and control it gives customers. Microsoft Azure’s partnership with Puppet and Chef allows customers to choose from an array of existing technologies and communities to easily deploy, configure, automate and manage their VMs.

According to a Microsoft spokesperson Puppet Labs and Chef complement and extend Microsoft technologies such as Resource Groups and PowerShell Desired State Configuration (DSC) to offer more options for customers to migrate existing or deploy new applications to the cloud. The partnership offers Microsoft the ability to support Linux and UNIX environments, and also alleviates the concerns that organizations already using Puppet or Chef will have about abandoning their investment. Now, they can continue to use their Puppet modules or Chef recipes in Azure.

Luke Kanies, CEO of Puppet Labs believes the integration of Puppet Labs and Azure will help Microsoft IT admins by making it easier to deploy applications across any platform or cloud environment. Kanies explained in a press release, “Our goal is to help you automate the configuration and ongoing management of your machines and the software running on them, so you spend less of your time firefighting and running simple scripts across a thousand machines, and more time getting great software in front of your users.”

I spoke with Kanies about the difference in dynamics between a small company and a large enterprise. He told me that in a small company it’s much easier to communicate and coordinate resources, and the cost of failure of any particular project is much lower. For a large, established enterprise, however, there is assumedly a large base of existing customers, and there is more fear and worry about possibly disrupting normal operations.

I also had a chat with Ken Cheney, VP of business development for Chef. His philosophy mirrors a lot of what Kanies described. Cheney told me that emerging companies have the luxury of starting from ground zero with a clean slate. There aren’t yet any established processes to navigate. The challenge is trying to transform an organization with established processes, and a team of existing developers over to a DevOps mentality. Integrating DevOps into Azure helps organizations to meet that challenge.

DevOps adds an element of speed and simplicity that makes it easier for larger enterprises to be more agile. Using tools like Puppet Labs and Chef enables IT admins to add speed as a core requirement for infrastructure projects without disrupting or conflicting with other requirements—like security and stability.

Ultimately, the new alliance illustrates Microsoft’s commitment to empower Azure customers with the best-in-class configuration and automation tools by embracing the technologies, communities and ecosystems that developers know and love. Combining Azure with powerful and popular platforms like Chef and Puppet Labs bridges the gap between traditional IT and DevOps—enabling old school IT admins to embrace DevOps, and DevOps startups to mature and evolve into larger enterprises.

April 15, 2014
Microsoft’s DevOps Gambit and devopsy.kinsta.cloud’s Business Directory

Last week was a big one for Microsoft in DevOps. At the Build conference they unveiled several new features and functionality in both Azure and Visual Studio Online to make give them more DevOps chops and DevOps friendly.

At just about the same time they announced partnerships and integrations with both Chef and Puppet Labs to bring even more DevOps to Azure. That is an awful lot of DevOps functionality in a short period of time.

Frankly it is to be expected though. In doing my research for devopsy.kinsta.cloud prior to launch, I had a chance to speak to some folks at Microsoft about DevOps. Frankly they were frustrated. They thought they had a great story around DevOps and had not been able to attract the DevOps community to what they had available. Microsoft, much like IBM at one time owned the developer market. In fact the sheer number of developers who still develop in Visual Studio and code for .Net and other Microsoft platforms, is pretty amazing.

Now you don’t just have .net folks on Azure anymore. The platform now supports Node.js. Java. PHP and more. It blends both IaaS and PaaS, allowing users to slide between them almost seamlessly.

In the meantime DBMaestro announced it was bringing DevOps for database to MS SQL server. This is the same teamwork functionality that DBMaestro already delivered to Oracle users.

In addition to these announcements Microsoft also released some metrics that show just how scalable and quick the uptake has been on Azure and Visual Studio Online. Ultimately the answer will be do enough developers think Microsoft gives them what they need to build great applications on a great platform. This will determine whether Microsoft becomes a competitor to Amazon and Open Stack in the public Cloud.

But they are making their play. Whether you love them or hate them, it is never smart to bet against Microsoft. The numbers they announced last week show they can gain critical mass pretty quickly.

There are some good background stories on this at Redmond Mag, eWeek and TechWeek Europe. We will have a full feature story here on devopsy.kinsta.cloud shortly.

On another note, here at devopsy.kinsta.cloud we have put up our DevOps business directory in beta. Over the next few weeks we will pretty it up, but right now we are testing the functionality. We have populated the directory with some companies, but need more. Listing a company is free and if you list your company this week, we will upgrade you to the deluxe listing free ($99 value).

You can add long and short descriptions, logos, files to download, contact info and more. The directory over time will we hope become the source for finding DevOps related companies.

Look for more devopsy.kinsta.cloud features and events over the coming days and weeks.

April 8, 2014