devopsy.kinsta.cloud

Tag: devops

  • Sprinting in a DevOps Marathon: Tips for Success

    Sprinting in a DevOps Marathon: Tips for Success

    Remember the good old days of 2007, when Heroku was the shiny toy everyone wanted? Thanks to Moore’s law and the evolution of tech, 2007 seems like a lifetime ago. In fact, 2015 seems like a lifetime ago, now that machine learning has advanced for artificial intelligence to “wake up”—but I digress.

    DevOps and building applications in a microservice architecture appears to be here to stay. Monolithic applications have been around since the advent of the “stack,” but thanks to DevOps, we can build faster and smarter with better quality and lower cost. Consequently, it’s dumbfounding why only .5 percent of engineers operate DevOps (according to Gene Kim). DevOps would unlock trillions of dollars if the other 99.5 percent made this adoption, thereby ushering in a new era of economic prosperity.

    If you’re part of the other 99.5 percent, let’s go through the considerations for DevOps adoption—it’s the wave of the future, so you better start now!

    The Road to DevOps Success

    Assess the competency and maturity of development practices and processes of your organization across the following parameters:

    • Culture (i.e. collaboration and standardization)
    • Design and architecture
    • Data analysis and management
    • Build, continuous integration and continuous deployment
    • Assessment and testing
    • Application deployment across environments (Dev, Test, Production)
    • Continuous delivery and application upgrades/updates

    Assessing the aforementioned practices and processes result in a baseline to compare against industry standards (see Puppet’s “2017 State of DevOps Report“) and identify areas of improvement. This may seem intuitive or obvious, but true agility through DevOps requires frequent evaluations as new tools, practices and methodologies become available (i.e., you’re not still using dial up now are you?).

    Enhance and Improve the Culture with Shared Values and Objectives

    Design, Dev, Operations, QA, Product and other applicable teams historically have operated independently of one another in “silos,” which is the antithesis of DevOps. The goal need not be pushing code, configuring applications or testing; the goal should be to deliver value to the customer. Unfortunately, the culture of most organizations inhibit teams from maximizing value because they’re removed from the customer and seldom listen to the sales team (which I emphatically state as a seasoned sales professional!).

    That said, this is the easiest thing to fix by implementing the following steps:

    • Introduce a feedback loop including customers, sales, marketing and customer support to introduce new ideas to product so value is maximized.
    • Clearly articulate goals to motivate product teams and get them excited about their work.
    • Institute a culture of continuous improvement by listening to developers, operations, design, product, etc.

    Base Decisions on Facts, not Conjecture

    Seldom do organizations correlate sales and customer satisfaction metrics with product investment and product operations. All too often, organizations let sales or product dictate the best direction for the company when they need to be evaluated in conjunction due to their impact on profitability (i.e., building products to drive sales or letting sales dictate what products to build). DevOps expedites the delivery of products, thereby aligning the objectives of product with the goals of the sales team. This enhanced agility makes it’s easier to incorporate feedback from sales to enhance products while enhancing sales by delivering value faster, lowering the sales cycle and fostering happier customers!

    Choose the Right Tools, not the Popular Ones

    Months ago, the Bluemeric team started an engagement with a Fortune 500 team that was beginning its journey into containers. Long story short, this client evaluated the container platforms based on name recognition, not on the relative strengths and weaknesses or how the PaaS will achieve the client’s goals with the least amount of effort. The client reviewed dozens of platforms and entertained 10 for a proof of concept, but only one (and a relatively unknown PaaS) was able to install on its infrastructure (AWS, Azure and Google), spin up a cluster, build the application and deploy the applications. The competitors had tens if not hundreds of millions of dollars in revenue and thousands of customers, but the one that got the job done wasn’t the first, second or even third choice. It was the lightweight PaaS that Bluemeric recommended, which promised simplicity, minimal effort and ease of use that doesn’t drown customers with unnecessary features—and which actually worked. Obviously, this isn’t limited to PaaS; it’s an example on why decisions to adopt tools, methodologies or vendors must have a thoughtful evaluation, free from outside opinions and bias.

    That being said, implementing and adopting DevOps is neither easy nor fast, but it will be a requirement for all businesses in the very near future. As noted earlier, Gene Kim discovered that .5 percent of all software engineers currently operate in a DevOps environment, which is astonishing when comparing profitability against those who aren’t practicing DevOps. Once the trend becomes mainstream in the world of finance, the other 99.5 percent of software engineers better catch up or face the consequences.

    — Gabriel Deupree

  • Adding Accountability with ‘You Build It, You Run It’

    Adding Accountability with ‘You Build It, You Run It’

    Let’s see if this scenario resonates with anyone: Your department, organization, company, etc. is beginning to embrace DevOps practices, which is, of course, an amazing step in the right direction! One of those key practices is the “You Build It, You Run It” (YBI/YRI) mantra that helps facilitate a higher level of quality and accountability. This common practice also solves the mentality of throwing your solution/code over the fence for some other team to fix.

    I’m a huge proponent of YBI/YRI. However, in the case of existing brownfield solutions, there are several things you need to consider when transforming into the YBI/YRI model, including:

    • What if you have an existing solution where the collective “Y(ou)” in ‘You Build It’ does not include any or many of the original team that built it? This would be anyone who was part of the end-to-end creation of the solution and was empowered to make decisions impacting the design, development and delivery of a solution. In this case, it becomes, “Someone else built this mess, now you run it,” [SEBTM/NURI] which not only makes for a horrible acronym but is also a very realistic scenario that requires special consideration we’ll discuss below.
    • What if you are still heavily siloed and have a squad spread across multiple organizations, each with different goals and objectives? If you are still running outside of a true squad model, it can be difficult to ensure everyone’s priorities and goals are aligned to produce quality solutions with the right functions customers want.
    • What if you have varying definitions of “You” within your organization? Often in the YBI/YRI model, the interpretation makes some roles or key decision makers exempt from the glory of pager duty or answering to an angry customer. This can be especially true when you’re still trying to get to a point of having fully cross-functional, empowered squads.

    I think it’s fair to say that most DevOps transformations don’t necessarily happen on greenfield solutions, which means, especially at the enterprise level, the reality can end up being a beast of a monolithic solution(s) built by others who may or may not still be around.

    How do you fix it? My suggestion is that every person who was empowered to make a decision that contributed to the “B” (Build), becomes a “Y”(You). Of course, this doesn’t work if “Y” is no longer with the group or company, in which case I think it becomes a different issue of ensuring the new “Y” is 100 percent empowered with the ability to make decisions that enables that team to successfully run it.

    One more complication that adds to the mix of a YBI/YRI strategy is putting that strategy in place without a solid foundation of agile practices. Ideally when you are adopting DevOps practices, you already have a solid agile foundation with empowered cross-functional squads; however, in practice we often see the agile foundation still being built and/or refined at the same time as incorporating DevOps practices. As a result, there still exists a lot of hand-offs while two transformations are trying to run in parallel. If you have hand-offs combined with team’s with separate business objectives, those blurry lines of accountability will become an issue sooner than later.

    During transformations, if you find yourself in that in-between state of not having fully empowered accountable teams and are working with solutions your team may not have actually built, below are a few suggestions to get through those initial challenges:

    1. Ensure you allow for enough time to address technical debt during your sprint planning. Continuing to add features and functions on a poorly designed and/or broken solution will only cause further issues and likely increase the level of frustration on the team.
    2. Ensure that EVERY person who contributes to key decisions on a solution is included in the pager rotation in some way. Until you are in a state of fully empowered cross-functional squads, it’s important to drive the importance of accountability. As an example, if you have an architect in one organization who is working with a development team in another organization, that architect needs to be included on the pager as well to be aware of any problems resulting from a key architecture decision.
    3. Get in the habit of operational retrospectives. Begin (or continue) the habit of operational retrospectives that bring together the end-to-end squad into a cross-functional review of the operational incidents, root cause assessment and stories/tasks that need to get added to the backlog and prioritized.

    Although the transition into YBI/YRI for brownfield solutions can be muddy, empathizing with the mountains of technical debt and fully empowering solution teams can go a long way in truly helping your team’s succeed through the beginning phases of your DevOps transformation.

    About the Author / Shelbee Smith-Eigenbrode

    Shelbee

    Shelbee Smith-Eigenbrode is a senior software engineer/IT architect at IBM and has been in IT for 19 years.  She has worked across varying roles spanning the software development life cycle. Her experience across functional roles as well as performing that work deeply inside traditional silos has contributed to her passion for embracing the DevOps culture and transforming the way teams are delivering technologies by adopting DevOps practices. She is a member of the IBM Academy of Technology committed to driving innovation and technical advancement.

  • CircleCI Injects Workflow Flexibility into CI/CD Platform

    CircleCI Injects Workflow Flexibility into CI/CD Platform

    Nobody likes to be told how to get a specific task or job done. In fact, it’s arguably that very sentiment that holds backs adoption of DevOps processes inside many IT organizations. Aiming to provide IT organizations with a more flexible approach to DevOps, CircleCI has updated its continuous integration and continuous deployment (CI/CD) software to give IT organizations more granular control over workflows within a DevOps environment.

    CircleCI CEO Jim Rose says the issue with most CI/CD frameworks is that they are too monolithic. Rather than allowing IT organizations to apply different types of workflows against various types of scenarios, Rose says most CI/CD platforms are too prescriptive in how they define workflows.

    To provide some additional flexibility, version 2.0 of the company’s namesake CI/CD platform provides IT organizations with the ability to employ different types of workflows whenever appropriate, including:

    Sequential job execution: Provided in the first release of CirceCI, this class of workflow is optimal for approaching jobs in a lockstep build-deploy-test model.

    Parallel job execution: Allows IT organizations to run multiple jobs simultaneously in a way the resolves dependencies before deployment.

    Fan-in/fan-out in a repo: Ideal for a more complex build orchestrations involving different test suites against commits to get faster feedback.

    Branch-level filtering for job execution: Allows deployment of code off specific branches.

    Job execution from failed and job execution from start: Allows IT operations teams to choose where and how build reruns are implemented to save repeating unnecessary jobs. IT allows IT operations teams to start jobs from the last failed job, instead of rerunning every job or stage.

    Rose says the rise of microservices has begun to stress CI/CD platforms that were not designed to scale to support environments where Docker containers in any given microservice often are replaced. Any change to an element of microservice is likely to have a significant impact upstream and downstream. Rather than having to continually rerun every job, Rose says CircleCI now enables IT organizations that have embraced microservices to respond more adroitly to changes in the overall environment.

    In an ideal world, DevOps processes lead to faster rollout of new applications and updates. In reality, however, there are more dependencies than ever. Rose contends that CI/CD platforms need to evolve to the point where they can allow IT operations teams to cope with accelerated rates of change instead of becoming a bottleneck. The irony of that, of course, is that CI/CD platforms were adopted to eliminate bottlenecks. But as microservices architectures continue to evolve, in many cases the CI/CD platform has become a new bottleneck.

    It’s too early to say what impact microservices will have on DevOps. There’s no doubt that adoption of microservices will finally force the DevOps issue inside many organizations. But at the same many organizations that have already gone down the CI/CD path may soon find that some of their initial assumptions about what the word “continuous” meant were considerably misguided.

    — Mike Vizard

  • How AI Impacts DevOps Pipelines

    How AI Impacts DevOps Pipelines

    The rise of machine- and deep-learning algorithms is about to create some interesting data-gravity challenges for IT operations teams. Over most of the last decade IT operations teams have been caught up in a public- versus private-cloud computing debate that has mostly been species. The truth is that most organizations wind up employing both. But as IT organizations are just now getting used to that multi-cloud reality, the rise of machine- and deep-learning algorithms to create a new generation of advanced artificial intelligence (AI) applications are about to add some significant nuances to managing the DevOps pipeline.

    New applications tend to be built and deployed where they can access the most relevant data. Most of the data employed by the average enterprise resides on-premises today. But it’s clear that the data being created in various types of cloud services is growing at a faster rate, thereby altering data gravity forces across the enterprise.

    To get the most value out of that, developers are now building a new generation of advanced applications that employ machine- and deep-learning algorithms. In most cases those algorithms are being deployed wherever data happens to reside. For example, Salesforce just announced at its Salesforce TRAILHEADX 2017 conference that it is making available additional APIs to the Salesforce Einstein Platform Services for building custom applications that can now be infused with sentiment analysis, the ability to detect objects and understand customer intent.

    Michael Machado, director of product management for Salesforce Einstein, says that the success of any AI initiative will come down to both the amount and quality of the data being accessed. As a CRM application consisting of a mix of structured and unstructured data concerning customers, Salesforce represents an attractive platform for building AI applications. In fact, to facilitate the building of applications, Salesforce also is making it simpler for developers to collaborate across multiple alliances in addition to providing access to DevOps tools from Atlassian and Github.

    But CRM applications are only one element of the typical application portfolio. The more data that any set of algorithms can be applied against, the faster the application learns and the more accurate it becomes. As developers build the next generation of applications, they are going to want to be able to access as much data as possible. For many IT organizations, that will mean the applications will be hybrid almost by definition—attempting to centralize all their data will prove to be impractical as well as prohibitively expensive. Constructing application pipelines spanning multiple data sources, however, requires a very mature set of DevOps processes.

    Arguably, the rise of these next-generation applications might finally force the DevOps issue inside most organizations. Most have been able to manage application development on various cloud platforms in isolation. Going forward, that may no longer be practical, as developers seek to incorporate more data sources within their application environment. The challenge IT operations teams will need to wrestle with is providing timely access to that data in way that doesn’t ultimately compromise their performance.

    — Mike Vizard

  • 8 Reasons Why DevOps Needs Competent Writing Skills

    8 Reasons Why DevOps Needs Competent Writing Skills

    It’s a fact: DevOps practitioners need to have competent writing skills to help them in their career. It may seem a little antithetic—after all, software engineers and programmers are well-known to be the kind of people whose brains are wired toward math, not English. Written communication may not be an area of strength for people who spend their days looking at code; however, it could set someone on the path to success.

    Here are eight reasons that highlight exactly why DevOps practitioners should work on their writing skills to advance in your career.

    There Are Similarities Between Writing and Code

    This may not be immediately apparent, as most English students would pale at the thought of writing code and most computer science students would cringe at the thought of producing an essay. However, writing and coding are very similar in the sense that they both require a clear mind, have a set beginning, middle and end, and normally address a problem. Plus, as writing is essential in finding and landing a job, you can boost your skills by practicing writing for CVs, resumes or cover letters.

    Learn from Each Other

    Software engineering is becoming an increasingly collaborative area of study; however, for people to get involved with your project, they need to know what it is and understand it. Being able to write well helps people understand and follow simple instructions and communicate clearly on what they want to achieve or add to a project. If you’re unsure how to write a proposal, you can find great advice in the writing forums or from online editors and writers.

    Become a Proponent of Literate Programming

    Codes are fundamentally written for a computer; however, literate programming supporters state that it should be written for humans, too. The code can have a longer shelf life and be a lot clearer and high-functioning if the people who write it have the interests of a human at the other end in mind, and if the code has a purpose that can serve human needs.

    The Role of Writing is Increasing

    Programmers do have to work with others at times, and even programmers who work on individual projects have to communicate progress and setbacks to their employers, universities or the people who provide funding. If you want to be able to keep all of these people happy so you can carry on with your work, then you need to be able to write quality emails and progress reports. You can find plenty of email and written communications help by using online proofreading free tools on the web.

    Improve Your Professionalism and Reputation

    If you can sell and market yourself well, then you’ll be better-received within your own specific field and within the organization that you work for. Poor writing, littered with spelling and grammar mistakes that leads to miscommunications, just makes you look bad and can make people doubt your ability.

    Make Sure You’re In Line for Promotion

    Programming is a competitive field, even if many of the people who work in it work independently. This means you need to stand out from other programmers when you want the best projects to work on, and getting advice from a professionals is the best way to present your ideas and goals can go a long way.

    Show Your Authority

    A lot of people you work for will not understand code, so you’ll need to employ other means to convince them that you know what you’re talking about. This could include using sources and references to describe why you’ve taken certain courses of action.

    Develop Better Relationships

    It’s always good, and sometimes useful, to maintain good relationships with colleagues, so you can make sure you aren’t being too curt by checking your emails with word count tools, to make sure you’re engaging and approachable.

    Writing and DevOps may not seem to go together; however as the list above shows, they are actually compatible and both necessary for anyone to really succeed in the workplace.

    About the Author / Gloria Kopp

    Gloria Kopp is a digital marketer and an elearning consultant from Manville, Wyoming. She is a regular contributor to such websites as Engadget, Ukwritings and Huffington Post. Connect with her on LinkedIn.

     

  • Continuous Testing: Solving the Biggest DevOps Bottleneck

    Continuous Testing: Solving the Biggest DevOps Bottleneck

    It’s time to start implementing the practices of Continuous Testing

    Earlier this year, Computing Magazine conducted a fascinating study around the adoption and benefits of DevOps in its DevOps Review 2017 publication. The findings that stood out most fascinating to me where around quality assurance and testing.

    In this survey, the question was asked, “Where are the main holdups in the software production process?” Of all the self-proclaimed DevOps practitioners, a whopping 63 percent said the biggest delays occurring in the QA/Test phase. In fact, this cited bottleneck was more than 2 times greater than the next proclaimed bottleneck, which they felt was in planning (29 percent).  In this same survey, another question asked, “What tends to lose out more in DevOps environments?” While 43 percent said, “Nothing,” nearly 30 percent of these DevOps practitioners said that quality was being sacrificed. When asked which area they wanted to focus on improving in the next year, over 40 percent opted for quality.

    Why is it that quality has taken such a hit?  The study cited two issues: 1) Testing and QA is often siloed from the other parts of the organization, and 2) Testing tools haven’t matured much in the past five years.

    Testing must become a cross-functional operation across the software development lifecycle (SDLC) spectrum, one that involves all teams. Agile developers and testing teams don’t have weeks to test, but hours. Testing hasn’t kept up because it hasn’t applied the methods and concepts of agile development have not been applied to testing and QA processes. By removing the constraints that force testing to the end of a development cycle, developers and QA teams can achieve accurate, automated testing from day one. They can create an integrated pipeline, capable of taking an idea from design to deployment, at speed, without compromising quality.

    Open-source, cloud-based solutions can be the catalyst that brings the speed of agile to testing.  Here are a few examples.

    Better In-Sprint API Testing: Since APIs have become the major component of applications, organizations are shifting their approach from starting testing when the user interface is complete to shifting the focus of testing at the API level.  But the hard thing is finding enough time in a development sprint to test them sufficiently.

    Today’s applications are a collection of microservices and API calls. UI testing alone just won’t cut it. UI testing is very brittle, and whenever it changes, testing breaks. Testing needs to shift left into the development cycle—into sprints. But if you shift testing left to be a focus of the sprints, what kind of API testing can you really do? How comprehensive can they really be?  Creating those API tests has to be quick, and simple.

    Dev and Test teams must utilize automated tools that not only generate API tests, but create an exhaustive set of test cases from the API, then execute those tests. These tools also need to support the most popular open-source testing frameworks allowing developers to run functional API tests as performance tests without any proprietary conversion issues. And, vice versa, developers must be able to take open-source performance tests and be able to run them as functional API tests.

    Orchestrating Testing: A Continuous Delivery Pipeline Manager: “Faster” is becoming table stakes with automation.  The facts show that companies who have widespread agile adoption and are deploying more frequently with significantly reduced lead times. But, this too often leads to release failures, quality issues and disorder with multiple—if not hundreds—of applications rolling through the SDLC. Plus, things slow down significantly with time-consuming handoffs and rework in the release process. DevOps teams, who release features and fixes frequently while significantly reducing errors and manual processes, need toolchain-agnostic pipeline planning, orchestration and optimization solutions that enable them to eliminate spreadsheets, automate test processes and feedback, and continually improve the delivery of revenue-generating features to end-customers. New CD SaaS tools help make this orchestration process easy.

    Performance and Functional Testing Using Open Source Frameworks: More and more organizations are trying to move from legacy testing tools. It’s not so much that these don’t adequately test, but they were never designed to meet the needs of agile development approaches. Rather, they were designed for releases that occurred two to three times per year. But that won’t cut it anymore.

    And as developers begin to incorporate testing activities in the coding process, they need simple-to-use, open-source tools. Luckily, there are such tools like JMeter, Selenium, Gatling, Locust and others. There are even tools that help you convert from legacy platforms to open source technology with ease, and guides to transform existing functional tests created with other tools over to load tests.

    These are just a few examples of how continuous testing eliminates the testing hurdle. With continuous testing, organizations can:

    • Automatically convert user stories from requirements management tools like CA Agile Central or Atlassian JIRA into the minimum number of test cases required for complete code coverage, and being able to adapt automatically to changing business requirements.
    • Reduce test cycle prep time by requesting test data from within requirements.
    • Request, reserve, and create test data at any time, even from requirements phase.
    • Virtualize APIs for better testing, while managing API access to developers.
    • Institute easy API testing that can generate comprehensive test cases (positive, negative, edge case, and SQL injection) and execute those tests automatically.
    • Democratize testing with SaaS-based testing tools so that developers can test early and test often.
    • Speed testing by feeding test data directly and securely to virtual services.
    • Use open-source testing tools such as JMeter, Selenium, Jenkins, Jenkins, Appium, Taurus, Gatling, Locust and more.
    • Orchestrate the application delivery pipeline to promote releases from one environment to the next as soon as all the tests pass and enable faster feedback loops.

    This is testing unleashed, going hand in hand with agile development to accelerate quality into production.

    By adopting next-generation testing practices, DevOps teams have the ability to test early, often, automatically and continuously. To learn more about continuous testing and why it is critical to DevOps and Continuous Delivery initiatives, visit this Continuous Testing informational page.

    — Aruna Ravichandran

  • Fleetsmith Pulls Apple into DevOps Orbit

    Fleetsmith Pulls Apple into DevOps Orbit

    For too long now Apple Macintosh systems have been the proverbial red-headed stepchild of DevOps. There are a lot of ways to incorporate Windows systems automatically into a larger DevOps pipeline, but Macintosh systems generally require a lot of manual intervention.

    As part of a larger effort to automate application deployments across Apple systems, Fleetsmith has announced that the platform it created for automating the management of Apple systems now supports both the Puppet and Chef automation frameworks. DevOps teams looking to extend the reach of those frameworks to Apple systems can now invoke Fleetsmith to automate the deployment of Chef and Puppet like any other Macintosh application.

    Of course, once Puppet or Chef are installed, IT organizations can control what gets deployed on those systems going forward. But in general, organizations that deploy Macintoshes prefer to employ tools that provide a native Macintosh experience when it comes to managing those systems, says Fleetsmith CEO Zack Blum. There are plenty of options when it comes to cross-platform management tools, but Blum notes each of the tools compromises the Apple Macintosh experience such that individuals who prefer Apple systems must manage those systems using a construct that was not primarily designed for use in, for example, a Windows environment.

    Over the years, a number of developers have shown a marked preference for Apple Macintosh systems. As a result, it’s difficult to develop a coherent approach to DevOps that does not include some way to automate the management of those platforms, including the ability to deploy DevOps tools such as Puppet and Chef. Blum says that, in time, Fleetsmith plans to increase the number of Macintosh applications that can be distributed via its platform.

    Naturally, Apple is too focused on the end-user experience to trifle with IT management issues. It prefers to leave those issues in the hands of partners such as Fleetsmith, JAMF Software, IBM and SAP. The other alternative is to rely on open-source software that has been created to address this same issue. But Blum says open-source alternatives are more complex than commercial software, while rival commercial approaches to provide the same level of fleet management of Apple system at scale.

    Fleetsmith was developed when its founders worked at Dropbox and Fandom. Both organizations had evaluated several Mac management options before deciding to develop their own code. The company launched last fall with $3.1 million in funding.

    Pricing for the service, which officially is still in beta, is $10 per month per device. The service is free for any organization with fewer than 10 Apple devices. In addition, Fleetsmith integrates with Google G-Suite to make it simple to authenticate users of the service.

    Obviously, there’s more to be done in terms of pulling Apple devices into the greater DevOps ecosystem. But as a first step, making it simpler to deploy Chef and Puppet on these systems signals greater awareness of the overall issue.

    — Mike Vizard

  • Cisco Looks to Bridge Gap Between Networking and DevOps

    Cisco Looks to Bridge Gap Between Networking and DevOps

    Networking in the enterprise has always stood apart. It might take two minutes or less to spin up a virtual machine, but it can take two weeks to set up the network connections. To help bridge some of the gaps between networking and the rest of the DevOps team, Cisco Systems this week unveiled a series of intelligent switches that promise to do just that.

    Via a Cisco intent-driven networking initiative, it soon will be possible to describe a business outcome that will be automatically enabled at the networking level, says Kiran Ghodgaonkar, senior marketing manager for Cisco. To achieve that goal, Cisco is moving to unify networking on an end-to-end basis, which Ghodgaonkar says primarily will require building a common controller that can be implemented at both the edge of the network and in the data center.

    The first concrete step in achieving that goal is a set of Catalyst 9000 switches running an IOS XE operating system, which Cisco has imbued with machine learning algorithms. Over time, those algorithms will be deployed across both legacy networking infrastructures when appropriate, as well as any new networking and security equipment Cisco brings to market in the future. Once in place, IOS XE will make it easier to implement policies in software that spans everything from prioritizing traffic to implementing security polices.

    This latest Cisco initiative follows the rollout a Tetration analytics platform based on an instance of Apache Spark and Cisco’s acquisition of AppDynamics, provider of an application performance management service delivered via the cloud. Ghodgaonkar says Cisco is aiming to combine analytics and machine learning algorithms to simplify network management in a way that furthers DevOps integration. Right now, however, the biggest impedance to achieving that goal, says Ghodgaonkar, is the fact that 80 percent to 90 percent of networking tasks still require manual intervention. Because of that issue alone, many organizations have experienced limited success in terms of integrating server, storage and networking management, despite the rise of software-defined networking (SDN) in the data center. In fact, to get past that issue, many organizations make investments in pre-integrated systems such as the Cisco Unified Computing System (UCS) platform. But the number of organizations willing to make that kind in forklift investment in IT infrastructure is not all that high when compared to the size of the overall IT market.

    The biggest DevOps issue IT organizations now face, says Ghodgaonkar, is that as various elements of the IT organization invest in automation, silos of automation are created. Cisco says it has developed open application programming interfaces (API) will provide interoperability between its technologies and the rest of the IT environment to help break down those silos.

    It’s still a little unclear these days just how much networking and IT operations can get automated. The good news is that, given the state of network management inside most organizations, things can only improve. The real issue (as any existing DevOps team already knows) may not be so much the technology as it is the culture differences spanning the compute, storage and networking teams.

    — Mike Vizard

  • 7 Steps to DevOps Hiring Success

    7 Steps to DevOps Hiring Success

    As many of us in the DevOps scene know, most companies are hiring, or, at least, trying to do so. The required skills and job descriptions can change entirely from company to company. As a broad overview, most teams are looking for a candidate from either an operations and infrastructure background or someone from a software engineering and development background, then combined with key skills relating to continuous integration, configuration management, continuous delivery/deployment and cloud infrastructure. Currently in high-demand is knowledge of container orchestration.

    In the ideal world, the two backgrounds will meet somewhere in the middle to form Dev and Ops, but in most cases, there is a lean toward one side or the other while maintaining sufficient skills to understand the needs and demands of their counterparts to work collaboratively and achieve the end goal of continuous delivery/deployment. Every company is different and there isn’t necessarily a right or wrong here. It all depends on your infrastructure, tech stack, other team members’ skills and the individual goals you hope to achieve by hiring this individual.

    Focus Your Hiring

    Now, given the various routes to becoming a DevOps practitioner, how do hiring managers focus their search and selection process to ensure that they’re hitting the mark?

    Decide on the Background

    Assess the strengths of your existing team. Do you already have some amazing software engineers but you’re lacking the infrastructure knowledge? Aim to close these gaps in skills. You may have been given the budget to hire for DevOps, but you don’t have to spend weeks/months searching for the best software engineer who happens to use Docker and Kubernetes because they are the current hot trends in this space. Find the person who will provide the most value in your environment and go from there.

    Contractor or Permanent Employee? 

    Many hiring managers will automatically start searching for a full-time permanent employee when their needs may suggest that they have other options. Sometimes a contractor is your best bet or maybe contract-hire. If you’re aiming to design, implement and build a new DevOps environment, why not find a senior person who has done this a number of times already? Try hiring a senior contractor and bring on a junior full-time hire in parallel; this way, you’ll be able to retain the external contractor knowledge by having them work alongside the junior hire. Contractors can be expensive, but the knowledge they bring can be invaluable, especially if the work can be completed over a shorter time frame. Again, this is just another point of view and you might be best off with a full-time hire to grow the team.

    CTRL F is not the Solution

    Focus on their understanding of DevOps and CI/CD-related processes over specific tools. I believe the best approach is to focus on finding someone who understands the methodologies over the tools. Does your candidate understand the concept of continuous integration or the concept of continuous delivery? That’s more important than asking whether your candidate uses Jenkins versus Bamboo versus TeamCity and so on. Try not to get caught up in the exact tool chain. The focus should be on the candidates’ ability to solve problems. Are they obsessed with increasing efficiency, saving time, automating manual processes and constantly searching for flaws in the system? They might be the person you were looking for, but you missed them because you didn’t see the word “Puppet” on the resume.

    Work Closely with your Internal Talent Acquisition Team and/or an External Recruiter

    Be clear and precise with what you’re looking for and have an ongoing, open communication with recruiters. They can and will help you if used effectively. The job of these recruiters is to save you time by sourcing candidates while you’re focusing on your day-to-day role. Work closely with them and deliver in the same way that you would expect them to deliver for you. If you say you will review a candidate by X time, do it. If they say they’ll have a candidate in your inbox by Y time, make sure they do it, too. Start by setting up an initial call to talk through your requirement, lay out a timeline in which you expect candidates by a specific time and explain your process in terms of when you will interview, how many interview rounds and how soon after you will be able to make a final decision on whether to offer or reject the candidates. If you can get this relationship working well, you’ll save lots of time. And make sure your internal teams are focused on supporting your process, not blocking it.

    $$$

    Decide how much you want to pay. It’s not all about the money, but you can waste a lot of your and other people’s time if you don’t lock down the ballpark salary or hourly rate that you can afford. If your budget doesn’t stretch as far as your competitors’, you need to consider what else can help sell the opportunity. Flexible working hours and remote working options are some great ways to do this. Most companies have snacks, beer and cool offices nowadays, so focus on the real value such as the innovative work your team is doing and how awesome your game-changing product might be.

    Drop the Ego

    You may have an amazing company and/or product, but you also have some hot competition. Everyone is hiring in this space and candidates have a lot of the buying power. It is no longer as simple as saying, “We are hiring” and the awesome candidates come flowing in. You need to sell your opportunities. Maintaining a reputation as a great place to work is also important. A poor hiring process, such as interviewing without giving feedback, can contribute to bad rumors being spread across the industry. It only takes a few minutes to leave a sour review on Glassdoor.

    A Smooth Process is a Successful One

    “Let’s get every single person within the company to do a one-hour interview with the new DevOps person we are hiring!” No, let’s not do that. Two or three stages should be sufficient. You have managers and directors for a reason. Trust your instinct and use your experience to make decisions on who will fit into your organization. Some of the most successful companies can do one phone screen followed by an in-person meeting. During the in-person interview, spend a morning or afternoon allowing the candidate to meet the relevant leaders and senior members of their direct team, then take them for lunch, dinner or drinks where you can see how they are on a social level. If you can’t have a simple conversation with them, then you probably won’t enjoy working with them. If the thumbs are up, make the hire and don’t wait around. A good candidate will usually have numerous offers on the table at the same time.

    If all goes well, you should be inviting your shiny new employee or contractor into the office in the next few weeks and hopefully many more throughout the year.

    About the Author / Conor Delanbanque

    conordelanbanque

    Conor Delanbanque has been recruiting and leading recruitment teams in the DevOps space for the past few years. As well as being exclusively responsible for growing some of the most innovative DevOps & SRE teams in the US and Europe as an external consultant and recruiting partner, Conor also founded the Future of DevOps Thought Leaders Debate, sponsors DockerNYC Meetup on a regular basis and co-hosts ServerlessNYC. You can tweet him at @ConorDevOps, find him on LinkedIn or at events, expos and writing articles on DevOps.com.

     

  • Top 5 Issues Curtailing DevOps Adoption

    Top 5 Issues Curtailing DevOps Adoption

    DevOps may seem simple and logical on the surface, yet most of the companies we talk to are struggling in one aspect or another. This is no surprise: Successful DevOps initiatives require putting together a full toolset and simultaneously creating a smart team of developers, testers and project managers who are well-versed in cloud and agile technologies.

    Those tasks alone can take many months of trial and error until you are ready to start DevOps in earnest. After a period of experimentation, it’s time to refine and optimize. Focus shifts to more mature issues such as creating a fully integrated tools stack, supporting a rich test data environment that doesn’t undermine privacy and security, and determining the best DevOps infrastructure strategy for your company.

    Regardless of your DevOps maturity, we’ve outlined some top issues to consider and mitigate, as your DevOps practice evolves.

    Integrating Tools

    As the practice of DevOps matures, we have seen an explosion of tools, both open-source and commercial. These tools serve every discrete need in the process: requirements management, test management, defect tracking, agile planning, source code management, build, deployment, monitoring and more. We calculate there are at least 1,500 such tools available today.

    So, while developers, testers, project managers and business analysts have many sophisticated capabilities to streamline DevOps, those tools must work together. It’s imperative that tools and groups don’t work in silos, but are part of an integrated pipeline. This allows the code to flow seamlessly according to business objectives, from requirements definition to test and dev, production and deployment. Organizations may choose to create these integrations themselves—although that gets costly fast, both at the onset and with ongoing maintenance. Some vendors offer out-of-box integrations with popular tools, although you must consider if these will fit your workflows and needs. A few vendors now offer the best of both worlds—connectors that are simple to set up and with the ability to easily customize the integration when needed.

    Configuration as Code

    A common problem in DevOps is the need to align the environment configuration present when/where the code is written with the environment configuration used in production. By adopting configuration as code (consisting of tools and processes), you can store all configuration data as a file alongside the code. This is valuable because if there are bugs or UI issues, your staff can quickly locate the version of the configuration that matches the code/feature in question and load it into that environment quickly. If we are confident that the environment configuration is accurate, we can narrow down the app failure being most likely due to the code itself.

    Having both code and the configuration setup information in one place is also useful for testing purposes, as infrastructure configurations sometimes differ between development and testing worlds.

    Fast is Not Free

    Software teams have always wrestled with the need to balance speed with quality and cost. You can’t get the best of everything, so teams should figure out where they can compromise and where they can’t. In DevOps, however, the emphasis is almost always on speed. Once you reach maturity, you usually go fast and achieve high-quality results, yet this requires investing in tools, process and people.

    Working smartly can go a long way toward moving faster without sacrificing quality. If your team can figure out how to be efficient and precise, with clear objectives, then you won’t have to do much rework, which adds cost and time. Many people will flaunt the benefits of full automation to work faster. In many cases, however, automation ends up being a more expensive solution to the problem. Automation adds additional maintenance and overhead that needs to be outweighed with saved effort; you will have more tools and integrations to maintain, and more pieces that will break.

    Justify how much automation you need and acquire only the tools necessary to meet your goals. Ideally, organizations should determine the need for speed based on business requirements. Many industries are not driven by speed to market and benefit more by working in a steady, iterative fashion. Make sure you have a sound business reason for working faster and releasing faster, and that you can effectively manage the automation and staff needed to work at that pace.

    Acquiring Test Data

    For high-stakes applications, such as a new e-commerce site or mobile customer app, there is a great deal of risk in launching an app that hasn’t been tested on representative data. Accumulating enough high-quality test data to find bugs and optimize all the key features and scenarios before going live can be a monumental task given today’s big data initiatives, fragmented DB technologies and data privacy/security concerns. Specifically, when companies are dealing with sensitive data, such as customer information and credit card numbers, this is a tricky endeavor.

    One common option is to use real customer data and “scrub” it to remove identifying characteristics. If the cleansing process is not thorough, however, you’re creating tremendous security risks for customers. Another basic option is to create fake data that’s representative of production data. However, that data might not be accurate in all key scenarios, nor comprehensive enough to meet your QA objectives.

    Our analysis is that test data is a complex problem that no one tool can solve, and should be handled with importance as a cross-functional initiative. It’s not unusual to see security, compliance, testing, development and business personnel involved in test data management activities, especially for companies handling sensitive data.

    Internal vs. External Hosting

    DevOps environments seem to run optimally in the cloud. Cloud infrastructure gives organizations the optimal scale, flexibility and speed to run more builds and test faster through highly automated services. Top providers including AWS and Azure offer a full range of DevOps-oriented services to manage infrastructure for you, such as load balancing, log and instance monitoring and automatic backup/failover. With many DevOps vendors hosting their products and services in the cloud as well, it’s logical to host the entire environment there.

    However, this isn’t possible for many organizations with strict security and compliance requirements. Running a DevOps infrastructure internally requires a great deal of configuration, maintenance and software, not to mention staff to maintain it all. Automated testing often can be time-intensive when limited machines are available in the internal network for testing. Running those tests may require waiting for the weekend to free up resources, given the many hours required to complete those jobs. This, in turn, causes significant delays in testing and code quality feedback.

    One solution to this problem is using containers to scale the internal DevOps infrastructure. This allows more tests to run at once and reduces the overall build process time. Companies strictly doing web development can use open-source tools to do this. Conversely, large enterprises with apps on multiple platforms will need to build out a great deal of their own infrastructure.

    It’s a Process

    All of this might seem overwhelming to organizations just getting started with DevOps. But remember that DevOps is a journey taken over time; it is more than just new tools and skills. DevOps is a dramatic and evolving way to develop software and services that meet the frequently changing demands of customers. DevOps is the only way organizations can truly become data-driven operations, supporting new revenue streams and product innovation. When viewing it through this lens, we know that change will be gradual. Celebrate the small wins with low-risk projects first, and work to drive efficiency wherever possible.

    About the Author / Kevin Dunne

    Kevin Dunne pic

    Kevin Dunne is vice president of strategy and business development at QASymphony. Prior to joining QASymphony, Dunne was a business technology analyst at Deloitte. He can be found online at Twitter and LinkedIn.