devopsy.kinsta.cloud

Category: Doin’ DevOps

Waterfall to Agile to DevOps: The State of Stagnant Evolution

DevOps is all the rage. The hot IT buzzword intended to heal the expanding divide between development and IT operations is being used to sell a range of services and solutions to struggling development shops and enterprises, even though DevOps can’t be sold – it’s a cultural shift that nurtures under a strong leadership.

Prior to DevOps, Agile methodology generated a similar hype that forced businesses to spend millions of dollars in revamping organizational hierarchy, deploying new solutions and hiring self-proclaimed expert consultants. The original values and principles of Agile development to deliver working solutions in small and iterative chunks were quickly forgotten. The methodology was only implemented during development phase and created backlogs for operation teams that failed to push product releases fast enough.

(more…)

November 11, 2014
The DevOps Scorecard
Mid-last year our team switched from doing Agile to doing DevOps. As we forayed into the journey trying to learn about DevOps and practice it at the same time, a lot of questions arose in the team. How was this different from agile and most importantly How were we going to be successful?

That’s when we wrote down what would be the success criteria for our team: “Ship code frequently without causing a customer outage“.

As the team matured we started evaluating a more granular way to track success. Could the team mantra be broken down into quantifiable success metrics that could be represented in a scorecard? Based on our experience the DevOps scorecard should contain these 9 metrics to track DevOps team success:
1. Deployment frequency: How often were we deploying code and getting new code in the hands of our customers? This metric should trend up or remain stable from week to week. Example: Twice a week, 50 times a day
2. Change volume: For each deployment how many user stories and new lines of code were we shipping? Example: 3 new features per day, Average 500 lines of new code per week. Another parameter to consider in addition to volume is complexity of change.
3. Lead Time (from Dev to Deploy): How long does it take on an average to get the code from development complete through a cycle of A/B testing to 100% deploy and upgrade on production? Lead time should reduce as the team gets a better hold of the lifecycle.
4. Percentage of failed deployments: What percentage of deployments failed causing an outage or a negative user reaction? This metric should decrease over time. Example: 9% deployments failed this month as opposed to 15% last month. This metric should be reviewed in combination with the change volume. If the change volume is low or remained the same but the percent of failed deployments increased, then there maybe a disfunction somewhere.
5. Mean time to recovery: When we did fail, how long did it take us to recover? This is a true indicator of how good we are getting with handling change and this should ideally reduce over time. You can expect some spikes in this number due to complex issues not encountered before. Example: On an average it took the team 15 minutes to resolve each last week, 14 minutes this week.
6. Customer Ticket Volume: Number of alerts generated by customers to indicate issues in the service. This is a basic indicator of customer satisfaction. Example: 54 tickets were generated this week as opposed to 38 while the user volume remained steady is not a good thing
7. % Change in User Volume: Number of new users signing up, interacting with my service and generating traffic. As new users sign up is my infrastructure able to handle the demand? Example: This week the number of customers spiked by 30% due to an external event causing volume of requests to go up
8. Availability: What is the overall uptime for my service and did I violate any SLAs? Example: 99.9% uptime consistently for the last 3 months even with change in user volume
9. Performance (Response Time): Is my service performing within my predetermined thresholds? This metric should remain stable irrespective of % change in user volume or any new deployment. Example: Sub 5 second response time from all geographies and devices
Would love to hear thoughts on what other critical metrics DevOps teams are using
November 10, 2014
Acorns Turns Sluggish FiServ on its Head with DevOps

Modern investment tools are popping up all over the place. Not only are they shifting the power from large institutions to the consumer, they are applying modern technology to a red-tape laden world.

(more…)

November 3, 2014
Scripts or Machine Images, What is the Best Way to bootstrap
Between the advent of handy tools, like Chef and Puppet, and virtual machine infrastructures, like VMWare and AWS, I feel like there has been a great debate about how to bootstrap machines. It seems like there are two extremes. On one side is heavy reliance on machine images (AMIs, in AWS speak) or scripting (recipes, in Chef speak) on the other with a bunch of grey in the middle. Naturally, there are pros and cons with each so let’s explore them.

Machine Images

The great thing about machine images are you get from zero to a fully functional machine in the time it takes to create the virtual machine. This can be an extremely valuable thing when you need to spin up or down quickly. However, they become dated with the rate at which your configuration changes.

Scripts

With the all scripts approach you are immune to the out of date issue encountered with machine images. The big drawback is that it can take a long time to spin up a new machine off of scripts, especially when you have to compile one or many components. In my opinion, this approach is most valuable when your system configuration changes quickly and there is some tolerance with regard to spin latency.

Either approach is suitable for things like auto-scaling and unlocks the elasticity of the cloud, so which is the best? To help you decide on which approach, or blend there of, best suits your situation. These may seem obvious, but I think you must weigh three major trade-offs or benefits afforded by scripting or imaging.
- Time to being service ready
How much time can you afford to spend from the time you start bootstrapping a new machine until handling live traffic? To meet our on-demand scale requirements, at Clip, we have a target of 10 minutes from when the virtual machine is requested to handling live traffic.
- Resilience to change
How dynamic is your environment? How often are new services deployed, dependencies added, or code deployed? At Clip, we add new services on a fairly regular basis and our systems change frequently from both the code and dependencies stand point.
- Cross platform support
How many platforms do you need to support? Platform, in this case, could be interpreted as operating systems, cloud providers and/or virtual or physical hardware. To date we have been able to minimize any cross platform issues.

Since we value flexibility and have the luxury of an acceptable spin up time of 10 minutes, we have chosen to lean heavily on Chef for our bootstrap process and only use basic machine images. However, as the product and business requirements evolve, the time to being service ready is gaining more emphasis, so our process will also change. At other companies, spin up time is so important, their CI system builds a new machine image for each version of the product that is deployed, so they can scale as quickly as possible. Regardless of the technology or process used, it is most important to satisfy business needs in terms of service ready time, resilience to change and cross platform support and continue to adapt as the requirements change.
October 28, 2014
The Human Factor in DevOps

DevOps is about pinpointing and eliminating bottlenecks in order to deploy code often—shortening the time-to-market and increasing quality and effectiveness. One of the most common bottlenecks in the release process is the interaction between the developers and the integration services/operations group.

Development (Dev) is entrusted with producing innovative software quickly while Operations (Ops) knows that service failures are often attributed to changes. This means Ops feels that if fewer changes are executed, fewer failures will occur and the system will be more stable and responsive. The natural conflict and opposing priorities between the two groups can create a productive equilibrium, but often results in communication difficulties, animosity and a financial loss for the company.

(more…)

October 28, 2014
The fashionable IT crowd

The IT Crowd

I was recently reading an article in Marie Claire UK (yes I do read non-nerdy publications, some higher AI should sentence my brain to enter a loop without an exit condition) which explained that women should start learning how to code in order to become successful professionally. That triggered my curiosity and I started to wonder when IT became classy enough to be mentioned in a fashion magazine. This might be the time for a little history.

Don’t blame Information Technology.

Once upon a time, well before the internet – yes kids, there was a time where people had to read books to access knowledge – IBM was ruling them all. It was such an important and powerful company that you could likely compare it to Google today. IBM salesmen were to wear suits, ties and an attaché case every day like other any other corporate person and techies had to wear a simple white shirt with an IBM logo on it. IT fashion at that time was pretty much neutral and IT was seen as any other field of work.

In the early eighties, Bill Gates who started to do business with IBM had a look that would, for some reason, stick with IT people for decades: oversized glasses, poorly shaped and tasteless beige tops with a pair of equally bad looking trousers.

Steve Jobs on the other hand when not representing his company officially was already seen wearing his now infamous denim and black turtleneck combo. The power of branding.

How come then that with so many different styles in circulation, one prevailed in people’s minds as the standard geek outfit? Well, in order to understand, we have to broaden our search a bit and we can then realize one thing: in the eighties, almost every person that had an interest in science had poor social skills and or almost no interest in fashion or styling. While this is a gross generalization a quick internet search for images of “nerd 80s style” should demonstrate what I mean.

Music has changed it all.

In 2001 Mp3 players had existed for years but were a niche market as their price was too high, their storage capacity too low (one album would fill up a player) and they required a computer and some technical knowledge. Downloading a song was also an obstacle as there was no massively spread peer to peer or legal solutions at that time.

Then came Apple with its iPod, almost like a piece of art that created curiosity and attraction and offered enough storage space for many albums at once. I think this was the first time the public saw an interest in a computer or mac related device. CDs while hugely popular were impractical – think of carrying more than one of them with you everywhere you go – huge and mostly unreliable for jogging or walking fast.

People who wanted an mp3 player and who did not own a computer had to get one and access to the internet. The internet which was mostly used by “people who knew” became more and more popular and people started to massively use emails and chats (msn, aim and all those brands which do not exist any longer) and slowly gained the knowledge to use internet in a more efficient way. This led internet providers to offer higher bandwidth and the development of a plethora of websites with ever more content.

With access to everything at all times, computers gained in popularity and the emergence of smartphones spread the use of internet even a bit further.

In the mid-2000s, technology, the people traditionally associated with it and their culture then became hip. That was the beginning of the “geek chic” trend, often confused nowadays with the hipster subculture. People started to wear old style clothes such as suspenders and those oversized horn-rimmed glasses. Not adapted to the business world, this trend quickly faded however with the public gaining awareness of things beyond glasses, thanks to popular TV shows such as The Big Bang Theory or Chuck, the geek culture spread widely.

Finally recommendable

All those factors contributed to IT becoming less and less a world of “freaks and geeks” and more and more a profession as acceptable and as open to everyone as any other, finally showing up as a recommendation for a professional path in a women’s magazine.

It was about time.

October 21, 2014
The DevOps Culture Cocktail

As I have written in previous posts, I believe that IT has accumulated decades of cultural debt that is now due. We are a young industry that grew up in silo neighborhoods, each with it’s proprietary practices, language and population of like-skilled specialists. Left unchecked, the resulting “framework culture” contributed to IT’s cultural debt and is partially the motivation behind DevOps.

The goal of DevOps is not to undervalue or replace the frameworks that are in place. On it’s own, DevOps is not a framework – in fact, successful DevOps relies on combined effect of best practices such as Agile, Lean and ITSM. By recognizing and adapting the best of each, IT can formulate a potent recipe for enhancing performance and increasing customer satisfaction.

So let’s belly up to the bar and mix ourselves a DevOps Culture Cocktail by taking the best guidance from the top shelf of each of the frameworks and practices.

Ingredient 1: ‘Git R Done’ Scrum

Scrum is the most prominent of the Agile frameworks and with good reason: it focuses on getting work “done” in manageable increments while reducing work in progress.

Pair it with a Kanban Board

While deceptively simple, Kanban is a powerful method for visualizing workflow, identifying constraints and keeping a team focused.

Ingredient 2: Automation

There is a lot of debate around the balance of automation use in DevOps, but there is no dispute that automation and metrics play a key role in successful DevOps.

Ingredient 3: IT Service Management

ITSM is the deployment’s “ever after”. Agile and repeatable service management processes lead the way to stable continuous delivery and increased flow.

Ingredient 4: Lean

Let’s make it a skinny by creating more value for customers with fewer resources and less waste.

Ingredient 5: People

The most important ingredient. DevOps relies on the way people think, behave, interact and trust their colleagues. According to Lloyd Taylor, “You can’t directly change culture. But you can change behavior, and behavior becomes culture.”

Finally, add a splash of common vocabulary and a shot of the alcohol of your choice and you now have a DevOps Culture Cocktail! Serve it daily, share it with your neighbors or sip it while reading a good book like The Phoenix Project. It does get more potent with age.

I recently had the opportunity to present the DevOps Culture Cocktail Party at Fruition Partner’s FruDevCon Conference. One of the attendees, a hobby mixologist, formulated her vision for a signature DevOps Culture Cocktail during my presentation. We asked the hotel bartender to mix it up, passed it around and a new cocktail was born. Here goes:

The DevOps Culture Cocktail
1 part pear vodka
1 part St. Germain
1 part Chardonnay
2 parts simple syrup or 7 up

Top with a spear of pineapple and a cherry.

Improvement recommendations are of course welcome. Could this become a staple at all future DevOps events?

October 9, 2014
Consumer Web Automation for DevOps?

These days event-based automation is everywhere from IFTTT recipes used by non-technical folks to cross post automatically to Twitter, Google+ and Facebook to email alerts for free iTunes downloads. And don’t forget the tech savvy that create even more complex sequences from Zapier and now Stamplay to track workloads and simple business processes or automate developer tools.

But this automation is not limited to consumer uses—it can also be the answer to DevOps challenges. Simple DevOps processes implemented with services such as IFTTT and Zapier improve the workflow and boost work performance.

(more…)

October 8, 2014
The Dark Side of Infrastructure as Code

We spend a lot of time extolling the virtues of infrastructure as code. All of it is true. Treating infrastructure as code can add great value in terms of its ability to promote consistent, predictable and repeatable results during the application deployment process. One of the ways in which infrastructure is treated as code is through the use of programmability.

Programmability is an integral component in software defined architectures and a part of the DevOps approach is automation through integration with traditionally development lifecycle focused tools and technologies. APIs, app templates and the ability to programmatically interact with the data path are enabling rapid provisioning of services in the network. That’s important to the business. Improving service velocity in the network is critical to achieving faster time to market and enabling the operational scale necessary to meet growing pressure on networks arising from the growth of applications driven by cloud, mobile and the Internet of Things.

Speeds and feeds of processes are now as important to gain a competitive advantage as speeds and feeds of packets.

Those who see DevOps and SDN as having a strategic impact on their organization view programmability as having even greater importance.

But that does not mean that treating infrastructure as code doesn’t have its dark side. Because adopting a programmatic approach to anything means you get both the benefits and the risks.

I happened to be cogitating on this topic when I stumbled across a post reminding us of the importance of code reviews. The content was so-so, but the premise was spot on: code reviews are a must for those embracing the notion of treating their infrastructure as code.

Why is that (or should it be) an imperative?

Consider some stats from InitialState, “a technology startup helping engineers capture and understand product data. Our cloud-based log visualization-as-a-service platform helps engineers make sense of the exploding number of logs being produced by “smart”, complex products and applications.”

According to their data, developers have to find and fix 100 bugs per 1000 lines of code. And it takes 30 times longer to fix one of those bugs than to write one line of code. Overall, developers end up spending 75% of their time (about 1500 hours per year) debugging code.

Now spend a moment thinking about what that means when you start treating infrastructure as code, writing scripts to automate provisioning and integrating with other systems to orchestrate deployment processes.

I won’t lie, code reviews can be tedious. But the first time someone points out an error, particularly one that could have resulted in a security breach or an undesirable service outage, the pain is more than made up for. In the long run, code reviews are beneficial to eliminating disruptive errors. A SmartBear survey in 2012 found that “70% of organizations indicated that code reviews are very important” and “Those that do code reviews clearly have a greater level of satisfaction in the overall quality of their software – they were twice as likely to indicate that they were very satisfied with their software quality.”

In other words, code reviews are an important part of the software development lifecycle (SDLC). Which means it should be a part of the software deployment lifecycle when it leverages programmability to treat infrastructure as code.

Therefore it is important in the early stages of DevOps (or SDN if you’re going that way) adoption that you put into place processes to check (and perhaps double check) the scripts, templates and integrations you’re using to automate application and service deployment along the entire operational chain – from the app to the network.

October 7, 2014
Trolling PuppetConf: Surveying Configuration Management
Troll (Internet)

In Internet slang, a troll (/ˈtroʊl/, /ˈtrɒl/) is a person who sows discord … by starting arguments or upsetting people,^[1] by posting inflammatory,^[2] extraneous, or off-topic messages in a… community …with the deliberate intent of provoking readers into an emotional response^[3] or of otherwise disrupting normal on-topic discussion.^[4]

-Wikipedia

When I stopped by the Chef booth at Velocity Santa Clara this year Nathen Harvey was out of XL t-shirts. I happened to have a Puppet shirt on at the time too, but it was just a lucky coincidence. Nathen’s always advocated using something (anything) to automate your infrastructure, as the ‘A’ in the CALMS model for devOps stands for automation, but the look on his face when I crossed his line of sight was as delightfully awkward as it could have been. Nathen told me he’d get me a Chef shirt if I got him my address back in Atlanta. I had been meaning to do it before I made it out to PuppetConf, but a tweet from Mandi Walls ultimately ended up prodding me into action.

To Nathen’s word, he got me a shirt in under a week, and in plenty of time for #PuppetConf.

I think “Stirring up delight” was the right shirt to send me too. I was half worried I’d get a shirt that was much more confrontational, putting me at risk of getting jumped and having my lunch money stolen. Lucky for me pretty much everybody that noticed the shirt thought it was funny. At least anyone who said anything to me about it. A proper troll is going to get at least one person a little bit angry though, right? Anyone that recognized I was in a Chef shirt happened to create an opportunity for me to ask a few questions, so I did.
1. Have you used Chef, Puppet, CFEngine, or any other configuration management tools?
2. Which do you prefer?
3. Why do you prefer that particular tool?
4. Why does the competition between these tools help or hurt our industry?
5. Where do you see these tools in five years?
I got pretty consistent answers just talking to people, and the Q&A often evolved into a natural conversation, which I prefer. (Another devOps principle I like to practice is shut the hell up and listen). I also put up fliers with a link to a survey while at the conference in an attempt to gather some empirical data. Truth be told, the survey was the real troll.

One of the best talks I saw at PuppetConf was by Lindsay Holmwood, call The DevOps Field Guide to Cognitive Biases. I wasn’t familiar with the term before the conference but I think I had the idea. I also know I still don’t fully understand it. Watch the video and check out the books Lindsay suggests at the end. It’s pretty deep stuff. I really like his advice on having engineers manage and managers engineer to help break these biases down, as it creates a lot of empathy between the two groups.

Given my own cognitive biases, I wouldn’t have filled out the survey if I had seen one of the flyers I posted. The flyer said nothing about a home school project for twin girls, which would have had a much better chance of getting my attention. Instead, it just asked folks to fill out the configuration management survey with the promise of cookies for their trouble. I’m pleased to say the tech community will respond to surveys for cookies even when crudely marketed. While I have enough responses to do sound statistical analysis, I know my data isn’t sufficiently stratified and probably doesn’t represent the larger population of the configuration management community. In other words my data lacks diversity.

My daughters’ home school project is to start a business, and the twins decided to launch Gemini Snacks. Their company is pretty much an online bake sale to allow them to give back to all the hospitals and organizations that have helped them and cheer up the kids that can’t go home yet.

The deal I made with my daughters was simple. I would print out flyers for PuppetConf to get survey responses to help me write this article. I would thank as many people as we could for filling out the survey by sending them some cookies, and I would hire their company to bake and ship those cookies. If people filled out the survey my kids would be in business.

There was a strong enough trend in the responses that I can discuss those now with confidence despite a lack of diversity in the data. Of course I got a lot of responses from Puppet users, but I also heard from people using CFEngine, Chef, Ansible, Salt, and bconfig2. A lot of people weren’t using anything and just recently picked up Puppet. I ran into a few folks that had used three or more tools at one point or another and could give comparisons which were really interesting. Here are the main conclusions I’ve been able to draw so far.

A Rising Tide Floats All Boats

Most organizations are still sshing into a lot of hosts to handle things, sometimes they do it with scripts. Configuration management (CM) tools are still becoming a fully adopted standard. I have heard users of every CM application in the market say it really doesn’t matter what tool you’re using, automate your infrastructure with something. As a result this is still very much a growing sector in the tech industry.

Don’t get into a Configuration Management Bake-Off

Bake-Off is the word that was used, and more than one person put it that way specifically. I don’t know what you’d call setting up test environments to try different CM tools before making a decision, but I’d call it a bike shed of yak shaving myself. Bake-Off is probably more familiar people anyway. My opinion is you should either be using Puppet or Chef, but if you’re not using any configuration management tool at all it’s advised that you start.If you can’t help but take more than one for a spin before committing then keep it short and sweet. You’ll be better off taking the time to commit to one and put the work into making the transition quickly than trying to figure out the easiest way to do it. This automation will take some effort. The key thing to understand is the right tool depends on your environment.

There’s a Lot of Respect and Appreciation for CFEngine

CFEngine is a trailblazing academic project that gained a lot of popularity in the early days of CM. The adoption of the software in the open source community really proved the viability of CM as we know it. While the application isn’t seeing continued growth now that there’s competition with newer tools in this space, several people went out of their way to emphasize the immense respect they have for the product and its founder, Mark Burgess, as CM wouldn’t be as evolved without them.

Puppet: Preferred by Ops Folks because it’s Easy to Configure

The main thing the ops crowd seems to prefer about Puppet is that it’s easy to configure. I had a book recommended to me at the conference called, “Switch: How to Change Things when Change is Hard”, by Chip and Dan Heath. The book describes a “Project Mood Chart” used by IDEO, a product design firm, to brace their clients for adversity.

When a new project starts we’re optimistic and hope for the best. We inevitably face adversity during the course of our work, and while this adversity is always frustrating it does lead us to insight. Empowered by our new perspective on the problem we can proceed to a viable solution with confidence.

I believe this is how Puppet evolved out of CFEngine. Luke Kanies, the founder and CEO of Puppet, was an early contributor to CFEngine. I can see Luke following this curve, gaining insight on the configuration difficulties the CFEngine community was experiencing, and going on to found Puppet, confident he had a product better adapted to industry since it was easy to configure.

Chef: Preferred by Devs because it Allows them to Treat their Systems Like Objects

I can see this same curve being followed as Chef came out of Puppet as well. With ease of use comes a lack of robustness. Puppet’s advantage over CFEngine is it’s easier to configure, but there seems to have been a point of frustration within the development community that lead to the creation of Chef. Developers like to treat things like objects, which should be obvious if you have any experience with object oriented programming. Abstracting the complexity of the software we write so it can be configured by end users that are not developers is challenging. Since Chef allows its users to treat their systems like objects, the difficulty surrounding the abstraction of any complexity into a declarative model is circumvented.

Which is the main reason ops folk don’t like Chef as much, because they’re not programmers. If you’re in an organization with a mature operations department that’s not so interested in learning to code, Puppet ‘s declarative model for describing systems is going to be a better fit. However, if you have developers doing most of the operations work out of necessity in a small shop or an operations group that’s doing more software development for internal tools, especially if they like Ruby, Chef may be a better fit for your organization.

Ansible: Symbiotic Orchestration

The best things anyone had to say about Ansible is that it’s great for orchestration. It seems to be competing more directly with mcollective, a framework Puppet Labs supports for orchestration tasks. Mcollective can be used with both Chef and Puppet, and the same appears to be true for Ansible. Ansible is also agentless, managing nodes over SSH. Depending who you talk to this can be a good or a bad thing. By not running an agent the nodes aren’t dealing with the overhead that would come with it, but you’ve also lost the ability to monitor your systems as tightly as you could if they were running an agent. I’m under the impression CM is trying to move us away from SSH loops. While I don’t think it’s fair to write Ansible off as an overblown SSH loop, I am of the opinion that the advantages provided by agents running on each node in your environment are well worth the overhead. It will be interesting to see if Ansible’s relationship with other configuration management systems continues to evolve into a symbiotic orchestration provider or if another product, like mcollective, continues on to fill that void.

Salt Isn’t Really Configuration Management Software, but it’s Fast

Salt is a remote execution platform build on zeroMQ that was designed with speed in mind. Everything salt’s being used for, including CM, has been an afterthought to the fast remote execution platform at the heart of the project. The constant connection the nodes (called minions) maintain with their master definitely contribute to the speed of the system. This would lead me to believe Ansible is the slowest of the four technologies discussed here, since it doesn’t run an agent at all, and Chef and Puppet would fall somewhere in the middle since they run an agent on their nodes but it isn’t on constant communication. (This is an educated guess on my part. Please let me know if you can speak to the speed concern from personal experience.)

I have run into a few businesses that deal with high speed financial systems that use salt for a lot of things, including CM, but only because it’s fast. If you have systems that demand split second responses to failure and change, salt may help solve a lot of problems your organization is currently facing. I’m not convinced it’s that easy to use.

Salt seems popular with groups that want to avoid Ruby like it’s the plague or folks that are so horribly comfortable in a CLI that using a GUI just seems unnatural. I think these are terrible reasons to select a tool, since it’s directly avoiding the ‘adapt or die’ mentality that the devOps community embraces. Still, depending on your environment and the adversity you’re dealing with, these may be entirely reasonable grounds to use salt instead of another technology. I’d be less concerned if you told me you picked salt because it’s fast though.

The Survey is Still Open

I hope you like what you read here but I’m sure somebody doesn’t agree with me at all. The good news is you can still fill out the survey and let me know. When my data looks sufficiently diverse I’ll publish another update, and there’s a decent chance you’ll get some cookies for you time too. I’d also like to thank everyone that took the time to discuss this with me. Gene Kim, John Willis, Chris Webber, Charles Johnson, Dawn Foster, Kara Sowles, everyone at Puppet Labs, and of course Nathen Harvey and Mandi Walls, all helped to make PuppetConf a huge success and a memorable experience for me. I’ve learned way more than I expected from the experience and I’m excited to see how the competition in this space plays out in years to come. Competition is a good thing. As different challenges arise and as projects go through mood swings I believe we’ll see two things happen: The communities for these tools will adapt them to adjust to the environment they’re operating in, and at some point enough adaptation will lead us to a new set of tools all together. I for one am really excited to see what happens.
October 6, 2014