The answer depends on your definition of SDN.
Category: Blogs
-
5 Secrets of Enterprise DevOps
There is still much debate surrounding the merits of Enterprise DevOps, some say that DevOps is great for the highly scalable startups but not feasible for the enterprise, while others say that DevOps is mandatory for a company’s survival. When enterprises evaluate the potential impact of DevOps adoption, they should consider some key points:1. Enterprise DevOps Adoption: One Bite at a Time
How do you make sure your developers get instant feedback? How can you go back and forth between versions? How do you integrate your entire CI/CD pipeline? While CI/CD for dummies is a good place to start, the biggest problem is how quickly you will get bogged down by the details. Whether you participating in the NASA challenge to find all asteroid threats to the human population and save the planet, or you are at an enterprise figuring out the DevOps strategy – first things first – define the problem and break it down into actionable chunks which may be done in parallel or sequentially.
When an enterprise is trying to tackle the DevOps challenge, the common scenario is that lots of people will have lots of interpretations on how and what it means to implement DevOps methodologies. It’s easy for projects to get stalled in the initial planning stages. The only way to take on this challenge is to break it down into smaller workstreams, for example, by defining the workflows in terms of infrastructure automation, build & test automation and configuration management – and deciding which technologies are the best fit to solve the specific challenges in each stream. So, basically, how do you eat an elephant? A spoonful at a time.
2. Dead in the water without on-demand cloud capacity
The limited enterprise data center infrastructure simply cannot keep pace with agile teams that need to be able to spin up multiple parallel environments with a click of a button or an API call without getting the message “ran out of capacity”. This issue becomes even more crucial when the project cycle peaks as a new application or updates need to be deployed in no time. To maintain agility in enterprise IT, enterprises must forever break free from capacity constraints, including compute and storage resources. Without a doubt the public cloud is a great fit – you must be able to use AWS and Google Cloud on-demand. To build a massive software lab entirely on premises, knowing fully well the bursty nature of the workloads, is downright foolish. If you want production on VMware and test environments in AWS, you need to ensure high fidelity environments to have real confidence in the test results. The environments must be exact replicas – identical VMs and identical networking in the data center and the cloud. The cloud gives you the capacity but how can you make the temporary test environment identical to production? Today it is indeed possible to clone your IT infrastructure in the cloud at the push of a button.
3. Death by Scripting for Complex Multi-tier Environments
Continuous integration and deployment are great methods increasing effectiveness and efficiencies. However in a multi-tier environment with complex networking elements, the overhead associated with the use of manual scripting to provision the relevant resources (multiple VMs, networking, storage), configure them and deploy all the components of an application each time you need a new test environment is very high. In addition, in today’s highly dynamic environment, scripts become outdated frequently, increasing the pain factor. Design for simplicity and scale: easily repeatable deployments, being able to snapshot and rollback to earlier versions are all requirements that must be carefully considered and met. For example, what if Jenkins could use a single API call to spin up multiple clones of your entire environment in the cloud, run all your tests in parallel, automatically release resources when completed and snapshot the environment in case of errors? Simplifying the automation and designing for complexity is a key requirement for enterprises.
4. Destroying team silos is easier said than done
One of the greatest enterprise DevOps challenges is to make the operations team fully integrated with the dev team and be able to plan and execute despite plenty of unexpected events. True integration of the development and operations teams cannot be stressed enough. For example, the ops team must be part of the SCRUM process. Creating a DevOps team is a start, but creating that DevOps team does not actually bring dev and ops together. Barriers between teams need to come down over time – the different teams need to cooperate and collaborate towards a larger shared vision.5.Managing infrastructure as code is do-able and totally worth the effort
Delivering on the promise of infrastructure as code does not have to be back breaking. Minimizing delivery cycles including creating just-in-time environments becomes a matter of an API call, hours become minutes. A wide variety of modern technologies are at your fingertips to help you achieve your mission. The most common scenario we see today may be the modern startup where its R&D organization was built with the DevOps notion from the get-go – but that doesn’t mean Enterprises will miss the bus. The enterprises that are adopting modern DevOps methodologies are doing so quickly, without a rip-n-replace of their entire infrastructure. For example, Ram Akuka, Director of DevOps at Deutsche Telekom shared their Enterprise DevOps journey describing how they used VMware, AWS, Chef, Jenkins and Ravello to set up a fully integrated CI/CD pipeline that accelerated their software delivery cycle like never before.
About the Author
Shruti Bhat, Director product marketing at Ravello Systems, the industry’s leading nested virtualization and software-defined networking SaaS. Prior to Ravello, Shruti was a virtualization junkie at VMware, where she managed the software-defined storage product line. She combines her MBA at UCLA Anderson with a bachelor’s in computer science engineering and has previously led R&D teams at IBM and HP as well as immersed herself in start-ups. -
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?
-
ElasticBox Jenkins Plugin – Easy Continuous Integration Setup
Introduction to Jenkins and ElasticBox
ElasticBox has recently released a Jenkins plugin which makes it possible to configure a continuous integration or continuous deployment scenario without writing any code or scripts! How have we done this you ask? Simple, it was magic. In all seriousness, magic is the end result if you integrate ElasticBox and Jenkins with the source control software of choice.
For those who rely on Jenkins for daily work, performing integration builds, orchestrating complex, large scale scenarios for testing or managing continuous delivery of applications with many configurations across multiple environments, is not uncommon. These types of scenarios require a lot of time setting up slaves and performing manual steps to configure the provisioning of cloud providers. Keeping consistency and across the environments becomes exponentially complex when you factor multiple clouds or hybrid cloud environments into the picture.
You can reduce the amount of manual configuration and scripting, while abstracting the provisioning of infrastructure, by using ElasticBox with the ElasticBox Jenkins Plugin. This means that you can use ElasticBox to solve complex continuous integration or deployment use cases in the quickest, most consistent and reliable way possible.
How Does It Work:
Here at ElasticBox we trigger tests, builds, and deployments on pull requests and merges, which is a very common use case. These actions start workflows that result in Jenkins triggering tests, builds and the deploying of instances. For more information on our internal continuous deployment scenario, take a look at this slideshare deck we presented earlier this year.
The first thing to understand is that we manage Jenkins as an instance that we deploy into our private datacenter through ElasticBox. We have a single Box that installs Jenkins Server on the provider of your choice. This makes it convenient to scale when multiple builds are slowing things down or to simply redeploy if something breaks all together.
The second piece of the puzzle are the required plugins, like the recently releasedElasticBox Jenkins Plugin, which, along with the Github Jenkins Plugin, makes it entirely possible to set up a continuous integration or deployment server without writing any code.
Setting Up Jenkins and ElasticBox:
First you have to set up ElasticBox as a cloud in the configuration page of Jenkins. You simply enter the ElasticBox url (http://elasticbox.com), a maximum number of instances, retention time, in minutes, and your ElasticBox username and password. Once all this information is entered correctly, you can go ahead and then test the connection.
ElasticBox Jenkins Example:
In this basic example, we’ll show you how we test changes to our website. When a branch is submitted as a pull request, we deploy a new staging instance of our Website Box. We validate the changes on an instance that is a replica of our production environment before merging the pull request into our master branch. When the code is merged, we then trigger a Jenkins job that reinstalls our production instances with the latest code changes (not shown in this demo). Now, our workflow for website changes is almost fully automated, minus the pull request and merge!
1) The first step is to create a new Jenkins item where we select “Build a free-style software project”
2) Once we’ve created a new item, we add the Github project URL and check the ‘this build is parameterized’ box. While this step isn’t required, it allows you to trigger a build manually and execute code from a specific branch.
3) In the source code management section, we specify the source code management tool, the ‘Repository URL’, provide credentials in the form of Username / Password, and for the Branch Specifier, use ‘${sha1}’ which represents the commit url of the branch submitted in the pull request. The Jenkins Git plugin is extremely complex and we highly recommend reading the Wiki on the plugin.
In the Build Triggers section, you’ll want to select “Github Pull Request Builder” Which is what will be triggering the Jenkins build and instance deployment in ElasticBox.
4) The final step is configuring the Build steps. With the ElasticBox plugin, you’ll have access to all your workspaces, boxes and deployment profiles. For more information on each of these features, please check out the links to our documentation. Specify the Workspace, the Box and the Deployment profile you would like to use. In our case, we specify our Production Workspace, our Website Box and our Staging Deployment Profile.
Conclusion:
Once all these configurations are set, you can test changes on new staging instances just by submitting pull requests. Even though this is a basic example, by continuous integration standards, you can see how the ElasticBox Jenkins plugin can seriously reduce the amount of configurations required to setup a continuous integration server.
With ElasticBox abstracting the infrastructure provisioning and allowing you to reuse existing application or infrastructure components, it’s much easier to scale the process in a repeatable and dependable way. We’ll be following up with blog posts that provide more technical examples on how to use Jenkins and ElasticBox for integrated builds, testing and continuous delivery models.
-
DevOps Days Tel Aviv Strikes Again
It’s no secret that the technology scene in Israel is at the forefront of innovation, and so it’s certainly no surprise that the DevOps community in Israel is simply booming. And well, it’s that time of year again, and me and my awesome co-organizers have rolled up our sleeves and started working on DevOps Days Tel Aviv.
This is my third DevOps event that I’m helping to organize in Israel, on top of our regular DevOps Israel meetup group that too has been growing and has had the pleasure of hosting some exceptional speakers (including the brilliant Kohsuke Kawaguchi at our next event).
So it is with great excitement that we have opened the call for papers for the next DevOps Days, and have already started receiving really awesome submissions.
The constant growth in interest and enthusiasm around these events has stunned even us. With the awesome speakers that came out at our previous events – John Willis, Stephen Nelson-Smith, Ben Kepes, and the caliber of speakers who have already submitted for this event – Yossef Mendelssohn, Julia Ferraoili, Michael Ducy, and many more in the works.
The event this year will be taking place September 28-29th, and we expect it to be even better than the last two.
Registration is officially OPEN. There are only a few early bird tickets available – so get ‘em quick.
You are more than welcome to submit your proposals for talks, ignite talks, and workshops here.
And as with all DevOps Days events – these are completely voluntary, and highly dependent on sponsorship – so if you’re interested, below you can find all the information you need, and you are more than welcome to reach out to the organizers of the event.
Sponsorship Packages
Included in Package Silver
1000 USDGold
3000 USDPlatinum
4500 USD
Two Available2 Tickets Logo on event website Logo on all email communication Mention via Social Media 5 minute pitch to full audience (including streaming audience) 2 additional tickets (4 in total) 4 additional tickets (6 in total) Shared table for swag Booth/table space Lunch or After Party Sponsorship (1 Each) We’d love to see you at the event. Reach out to us if you have any time @DevOpsDaysTLV
-
Mixed Martial DevOps vs.The Scrum Master
Royce Grace won the most tournaments in UFC history before he retired. With a record of 14 wins, 2 losses, and 2 draws, it’s understandable why he’s considered by some to be the most influential figure in the history of modern MMA. With 100% of his finishes from submissions, he’s undeniably Brazilian Jujitsu royalty. You’d be hard pressed to find anyone familiar with the fighting world that would argue against building a strong base in BJJ while learning to fight. Royce proved that BJJ was the single most effective form of fighting in the early nineties by submitting opponents much larger than him, like Dan Severn, in UFC 4. Severn had just shy of a 100 pound weight advantage on Gracie but ended up getting caught in a triangle choke. I can remember watching the video and trying to figure out how he made him tap like that. All the sudden fighting wasn’t just about kicking and punching anymore, the game had changed forever.
Fast Forward 12 years to UFC when the Master Royce Gracie is to make his return to the octagon. Matt Hughes crumpled him up like a paper napkin. Royce had continued to practice BJJ since his fight with Dan Severn as it was a successful strategy. The mistake he made was investing in a monoculture. Royce kept a razor point on his BJJ, but fighters like Matt Hughes were smart enough to put an edge on all the dull perspectives of their game. Hughes was a well decorated submission wrestler that knew he needed to work on his striking and maintaining his strength and endurance. Ronda Rousey made it clear after her last victory that she’d been working more on her striking too, which makes sense considering she’s already an Olympic medalist in judo.
At the end of the day it’s a fighter that wins a fight, not the discipline they practice. A well rounded fighter is going to be able to adapt to adversity better than someone that only has nth level experience in a particular area. The same is true for software methodology. A scrum master’s team will consistently be outperformed by a team taking a mixed approach. Not because something is inherently wrong with scrum, but that people get the work done, not the process. A team embracing a diverse approach is more likely to do what works. They will be open to more experimentation to figure out what is successful and to confirm when the current model isn’t working. Sometimes it’s the people not cooperating, but telling them there’s a problem because they’re not fully embracing the methodology is usually wrong. Often enough the methodology is being taken as gospel and is embraced too tightly.
I both like and understand kanban, but feel scrum has too much convention to adhere to specifically. I checked Google and it seems to agree with me:
Just to be fair, I checked to see how Google felt about kanban.
But Google didn’t seem to treat kanban as harshly.
If you can’t take my word for this maybe you’ll listen to someone else?
Just the other day Andrew Clay Shafer posted this on Twitter:
I did ask Andrew to offer an alternative approach if scrum wasn’t going to work, and he directed me to slide 46 of a presentation he did in Pittsburgh for a Ruby User Group (shown below). This slide advocates a mixed approach as well. I agree with everything Andrew encourages there, and can honestly admit I need to dig into XP technical practices a little deeper myself. This will not be an abandonment of current methodology and a complete shift in another direction, but an evaluation to see if I can fill some holes in my game.
-
Deploying a MongoDB Cluster with ElasticBox
Our founders, back in the day, were part of the .NET framework team at Microsoft. So it’s no surprise that their first version of ElasticBox was written on C#, .NET framework and SQL Server.
Fast forward to 2012. As the ElasticBox vision crystallized, we wanted a robust, scalable architecture to match our vision. So we reevaluated all the existing technologies.
Among other things, we decided to move from a relational database model to a document based approach. The main reason was because we wanted to store hierarchical data and be able to version it.
Today, to accommodate our data needs, ElasticBox relies on MongoDB clusters, which we run on three separate providers–two public, one private. Thanks to ElasticBox, we can now deploy our MongoDB cluster in a matter of minutes.
The Basics
What is MongoDB? MongoDB is an open-source document store database.
Why would you want to cluster MongoDB? To provide redundancy and high-availability for production deployments.
How We Use MongoDB
In our case, MongoDB is using a replica set model. A replica set is a group of MongoDB instances that host the same data set. One MongoDB, the primary, receives all write operations. All other instances, secondaries, apply operations from the primary so that they have the same data set.
The primary accepts all write operations from clients. Replica sets can have only one primary. Because only one member can accept write operations, replica sets provide strict consistency.
Deploying MongoDB through ElasticBox
ElasticBox provides a default MongoDB box that’s available to the public. It deploys a standalone instance of the MongoDB server. Our MongoDB production box very closely resembles the default box, minus a few configuration settings required for our production scenario.
While the default MongoDB box configuration is suited for development purposes, it needs to be configured further to use in production. To configure the MongoDB default box for production use, follow the steps below:
Step 1. Create a new box called MongoDB Replica. Add a box variable for the MongoDB Server (this is to use the default box settings).
Step 2. Add a text variable REPLICA_SET to hold the replica set name. This value must be shared between all the members of the cluster.
Step 3. Expand the MongoDB Server box. Edit its file variable COMMON_YAML and paste the following:
mongodb::replica_set: {{ REPLICA_SET }}
mongodb::key_file: /etc/mongod.key
This file will be used by hiera to pass arguments to puppet automatically without modifying the existing puppet default.pp file.
Step 4. Add a binding named primary of type MongoDB Replica (the box you just created).
Step 5. Add an install script. Get the script here.
Step 6. Add a start script. Get the script here.
When you deploy the box without a binding, it creates a cluster for you with an initial configuration. On the other hand, if you bind to an existing instance, it adds the instance to the existing cluster!
There, you have it, a MongoDB cluster in a few easy steps!
-
Provisioning versus Configuration
There’s a ton of hype and excitement surrounding containers, a la Docker, today, much in the same way virtualization took the data center by storm. In both cases, the excitement for operations focuses on the ease with which infrastructure might be deployed and managed via such technology.
Whether container or hypervisor, however, there remains a distinct difference between server and network virtualization that must be considered before getting too excited about the possibilities.
There are two distinct use cases for which virtualization and containerization of anything are considered beneficial: scale and deployment.
Scale
In terms of scale, both virtualization and containerization are excellent technologies. Both can fully encapsulate a service – whether application or network – and enable rapid deployment of multiple instances of the same service with very little (if any) post-provisioning requirements. This is the premise upon which cloud computing and NFV is based: clones of services and applications rapidly deployed to enable elastic scalability that matches demand.
For scalability purposes, virtualization or containerization of services is a match made (mostly) in data center heaven.
Deployment
Enabling rapid deployment of new services using virtualization or containers, however, is not necessarily going to net the same benefits. It is important note that the standardization and APIs associated with virtualization and containers that enable scalability so seamlessly is focused solely on the management of the container or virtual machine. The ability to provision a virtual machine or container is not at issue; APIs enable the rapid provisioning of a container or virtual machine with extreme alacrity.
What those APIs do not do is enable the rapid configuration of those services once provisioned.
Configuration != Provisioning
This is a critical differentiation that must be made lest we assume we can leverage virtualization and containers to enable a self-service style data center, a la IT as a Service. While virtualization and containers make provisioning a service instance a relatively painless experience, configuring those services must still be accomplished. When deploying a new service, existing configurations will not be wholly valid. There will always be some amount of customization that must occur, if only to make sure the service is interacting with the right application.
This means that once provisioning of the service is complete, there is still work to be done. One does not simply launch a load balancing service, for example, without instructing it how to distribute load (what algorithm to use) and to what set of servers (configure a pool).
It is important to recognize the difference between these two steps in the deployment process and take into consideration the impact of configuration after provisioning on that process. Depending on the method of configuration, this step can have a serious impact on the speed and efficiency of the deployment process as a whole.
It is also important to note for monitoring purposes, as virtual machine health and status is not the same as the health and status of the service, whether that be an application or a network service. Both must be monitoring and managed in a virtualized infrastructure to meet MTTD (mean time to detection) and MTTR (mean time to resolution) objectives.
In most cases, the impact from configuration is the greater of the two, with its time requirements most significantly impacting the application deployment lifecycle. It is optimization of configuration processes, not provisioning, that will ultimately provide the biggest benefits for DevOps in terms of reducing errors and improving time to market.
-
You can’t automate relationships
As an organization sold on the idea of DevOps what’s your first step in the journey?
Despite a constant deluge of well-reasoned guides for implementing DevOps the most prevalent step most companies have made is simply contributing to a proliferation of DevOps job titles.
Most likely it’s in no small part because asking the HR department to add “DevOps” to the latest sysadmin job posting title and “Chef” or “Puppet” to the requirements is easy. This is a woefully low bar to set for DevOps implementation. Compounding this further, afterwards when the CIO gets a survey asking about DevOps adoption, they gleefully indicate the company is well on their way and join many others as they artificially inflate industry statistics of a very worthwhile but nonetheless major undertaking for large companies.
Surveys can contribute to confused starts. Any survey that does not include questions on specific practices and draws its conclusions from simply asking if a company is doing a practice that has positive buzz in the industry is worthless. A welcome contrast is the Puppet Labs 2014 State of DevOps report which is quite a beneficial collection of supporting information covering various practices, recommendations and nuances of organizational structures.
Even actually making progress on an individual automation project, whether with newly titled DevOps members or from a grass roots effort in an existing engineering or operations team, does not fulfill a complete implementation strategy nor is it the best way to start. Automation is certainly vital to reliably and repeatably managing environments, but groups shouldn’t rush to tackle automation first only because it’s comfortable to start hacking away at a problem they think they can deal with on their own.
These isolated and well-intentioned practitioners may find that without buy in and solid trust and relationships across groups they may not be given access to automate and orchestrate certain key areas.
You can’t automate relationships!
There needs to be a holistic understanding of the value streams driving engineering work and how best to make improvements. Instead of diving headfirst into automation work on identifying common goals, shared pain, and potential wins across organizational groups. Starting either with collaboration between group members directly or through management level alignment can work provided the other quickly follows. Buy in is required from both engineering and management or progress will stutter.
Taking people through a story can bring support more readily than just listing bullet points. People need to feel emotionally engaged and connected to the pains of the culture and process prior to DevOps and how they can be realistically mitigated. For a large company audience, seeing a story from another large company with timeframes and phases that shepherd the transformation in bold, yet manageable steps can be helpful. The story of SAP Global IT is a candid and useful case study.
Once the stage is set then tackle automation together in a cross-functional group with shared measures of success leading your focus. Depending on the complexity of your process it may be beneficial to collaborate on a smaller application or time boxed simple proof of concept to vet new ideas and working relationships.
Despite the potential for rocky or inefficient starts, the transformative power of a meaningful DevOps implementation contributes to incredible innovation speed and satisfaction. What has worked to keep your organization keeping the long view in mind regarding DevOps?
Many companies are misappropriating the term DevOps to get attention, headcount, or perceived leverage in internal turf wars instead of building a cross-team continuous improvement engine. Is this a sign of the early peak of inflated expectations in the hype cycle?
Are we heading for a serious backlash? Is the tireless promotion of proper practices from prolific thought leaders enough to make failures clearly misguided implementations and not fundamental flaws in the movement?
I’m eager to hear your thoughts in the comments.
-
Coaching DevOps Baseball
Coaching DevOps Baseball
Every technology gets surrounded by hype during its maturation, and DevOps is certainly not immune to that phenomenon. If you’ve spent more than five minutes looking into it, you know that, because the current discussion sounds something like this:
“All right, there’s other stuff, but it’s just support, so I want you all to go out there and practice the important part! You only win the game if you score runs, and you only score a run if you run from third to home, so get out there and run from third to home! You’ll be the best team ever on the only part that matters, running it in!”
“What? That hitting the ball and making first, second, third base? That’s supporting stuff, doesn’t really matter, master running from third to home, that’s how you score runs, and runs win games! Oh sure, some hotshot can hit a home run, but then the team relies on the guy who can get home runs, so forget about it, just focus on running third to home!”
Yes, the vast bulk of punditry sound like this right now, and yes, it is as damaging to your DevOps efforts as this coach would be to a baseball team.
And yes, you need to care about all the other parts of the game – because it isn’t baseball if you only do one part, and it isn’t DevOps if you only do one part. No matter how much the coach thinks that part is the important part. After all, in the game, you’ll never get the chance to run third to home if you’re not able to handle the preceding parts of the game.
So when you read pundits at the moment, pay more attention to what they minimize than what they consider the end game. The benefits of putting scripts and configurations into version control, building automated testing, taking the time to write automation scripts you’ve been thinking about off and on for years (and putting those into VC also), all of these things are not only necessary prerequisites to the nirvana some foresee if only you do DevOps “right”, but they also hold benefits all their own. Harness your hotshots to automate what’s hard, and make that automation adaptable enough that it can change with the times. The “right” way to do it is methodically. Indeed, I would add the Etsy slogan “measure everything”. You can’t tell how DevOps is impacting the org if you’re not measuring things.
And doing it methodically is actually pretty easy. Pick a team or (my preference) a project, and tell them to do it. Set standards for keeping each change to configs in version control, demand that they automate as much as possible, but leave points in the process for human checking, require that automated tests are complete and run successfully before the code is considered complete (and set a standard for maintaining tests in the future, since that’s where most orgs have issues). Involve security deeply, because a failed drive, or a server dropped from a bad config can be recovered quickly, a security breech not so much. Then take what you learn, and apply what works well for your org again, perhaps to a larger team or project.
The whole point of DevOps is to improve IT’s responsiveness to changing business needs, increase operational capacity, and reduce human error. It’s not to achieve some goal set by people outside of your org, it’s to do it within the confines of your org.
So go hit some home runs, run the heck out of the first three bases, make IT more efficient and effective. Worry about things like “IT Transformation” when they come up and make sense, not when you’re just learning the rules of the game.
