Tag: tools

  • Tool Development – In-House or Ready made

    Tool Development – In-House or Ready made

    Tool development and adoption

    The current pace of software development cannot manage its speed without the automation.

    Automation is the most important element in order to achieve agility in delivery of the product. Every part of the software development life cycle needs tools to perform their action automatically. These phases could be coding, code review, build & deployment, environment management, resource assignment, notification and many others.

    There could be 2 options, which a team can opt for:

    • Use a third party tool
      • One can select the tools, which are available in market, either open-sourced or free. You can even buy enterprise solution if needed.
    • Build an in-house tool
      • Tool can be built or developed in-house for the consumption as well.

    Lets take look different aspects of choosing options

    • Features

    Each organization and team may have different features for different use cases. Some time it makes more sense to build your own tool just for your need rather adaption of a third-party one for which most of the features are not going to be used.

    • Time for on-boarding

    Time is definitely a big factor here, if one thinks of developing in-house tool and use it then this will definitely take time. If, need of tool is not urgent or critical, in house development option could be considered.

    Third-party tool can be immediately on boarded and there won’t be much delay other then some logistics reason.

    • Effort and Resource

    If the tool is complex, its not easy to build, one will need resources and lots of time to build it and then next challenge is implementation.

    Above effort can be reduced by adaption the tools which is available in the market. There are chances that other users are aware of the tools and training time could be reduced.

    • Cost

    Lets discuss one more important part, which is the cost. Yes, money is also one of the biggest factors on deciding what to opt for. There may be good options to choose from free and open source tools. But if enterprise tools selected, then cost may incur.

    You will need a dedicated team and resources to build the tool with in organization.

    Its hard to decide if in-house tools will be costly or enterprise. Decision has be to taken by considering long term investment and return.

    • Support

    Enterprise tools usually come with a proper support. This is really important factor if tool is very critical. Open source tools may not have enough support, as it is community driven effort. In-house tools may need resource to provide support and training in the team/organization.  Even bug fix needs to be taken care under support category.

    • Adaption/Expertise

    In-House tools are highly customize as per use case and will need proper training for adaption with in organization. In case of thirdparty tool, as I mentioned earlier there are chances that other users are aware of the tools and training time could be reduced.

    So, Adaption of tool is not an easy task. Decision has to be taken with a very strategic thought process.

    If tool is complex then it is definitely not a part time task.

    One more important thing to consider is if the team is trying to build in-house tool, which is going to be major business for somebody else then it has to be developed with proper planning and priorities, otherwise there are high chances of failure.

    Please Note- I am not considering or referring to any tooling like script or some simple UI dashboard.

  • Code Review – Write your code right

    Code Review – Write your code right

    Writing code is definitely subjected to individual thinking, logics and perspective. How one writes code is completely depend on their technical and logical skills. Two different people can write the same code in an entirely different tactic (May be both logics of the code are right in their own way). Even two persons can write bad code as well as good code as per the same standard.

    In the real world it is most likely possible that one writes the code and same will be read multiple times by many other developers to fix the bugs, improve the features, understand the code. That is why each language has its own style of coding and guideline to make it more meaningful and understandable.

    Most of time the Developers struggle to understand the code written by someone else on the team. I have even heard people saying that it’s difficult to read someone else’s code rather writing same from scratch.

    I would like to highlight a few compiled techniques in once place to make writing code better.

    Classical Method

    Classical method is a tools based code review. Developers write their code and submit it for review in some 3rd party tool like review board, Rietveld, or Collaborator for somebody to review the code.

    The tool will be used to track code changes comments, patches and review. Someone can merge code to the active branch once it is reviewed. Reviewers can have a look at the code and provide comments and inputs to the relevant piece of code.

    The good side is that it can be used for almost all sorts of old source code tools and is very much compatible with most of the version control tools.

    The problem with this mechanism is that it needs another tool other then version control system to maintain code review related information.

    Integrated Method

    To overcome the classical method downside, review systems have been introduced with in version control tools; a very good example of this is GIT. Where there is no (or rarely) 2nd tool needed to perform code review activity. Code review can be done via pull request even before merging. Comments, issues, patches can be tracked within Version control system with same workflow.

     As mentioned earlier everything related to review remains with in the same system and that is the biggest benefit of this system.But this mechanist also needs the same time and effort for someone else to go through the code and sign off.

    Extreme Workflow

    Pair programming falls under this category. In this Technique, two programmers work as a pair together on one workstation. One writes code while the other, the observer, pointer or navigator, reviews each line of code as it is typed in. The two programmers switch roles frequently.

    This way coding and its review happen at the same time by 2 programmers simultaneously.

    Some say that 2 developers working on same code at same time doesn’t make any sense, as they will be end up spending double man hours. It may lead to problems with practical implementation of the technique.

    But the good part is that they don’t need to spend extra time to understand and perform code review. It removes to and fro communication between developers. You don’t even need another tool for additional help to submit patch.

    In conjunction with review techniques I would like to add one more point about who can review code.

    • Leaders review the code: – One of the very common processes is that 2-3 leads will review the code always from the entire team (number depends on team size). They are always whole responsible for performing the review, checking the code before it goes for further consumption.
    • Anybody can review the code: – Another technique is that anybody with in team can review the code. Only restriction is that the one is writing code cannot review his own code because this doesn’t make any sense to review your own written code. There is no leader who is responsible for code review. A junior programmer can also review code written by senior, as there is no reason to allot hard role and not allowing others to review code.

    Whatever practice we use it is very necessary to have a look at code by another pair of eyes and have code reviewed.

     

    References-

    https://en.wikipedia.org/wiki/Code_review

    https://en.wikipedia.org/wiki/Pair_programming

    http://www.scmtechblog.net

  • Librato Seeks to Unlock DevOps Application Monitoring

    Librato Seeks to Unlock DevOps Application Monitoring

    As wider adoption of DevOps methodologies continues to foster demand for new tooling to help streamline evolving workflows, at least one vendor is attempting to address the growing need for related monitoring capabilities.

    Librato, a San Francisco-based provider of Amazon AWS applications performance monitoring (APM) services, claims that it is finding favor among the rapidly expanding DevOps community driven by its ability to inject critical visibility into the engineering lifecycle.

    Acquired by Austin, Texas-based SolarWinds in January for a lofty $40 million and renamed Librato SolarWinds Cloud, the company is touting its recent adoption by well-known providers such as Slack for monitoring of DevOps-centric applications performance and health metrics.

    “At its core, DevOps is destroying conventional wisdom around ritualized processes and the need to perform them, mostly in the domain of scale,” said Dave Josephsen, Developer Evangelist at Librato. “By attempting to include monitoring as a key element of the development lifecycle, this has created a whole new range of challenges, and opportunities.”

    By providing a centralized Web interface and open API to help create visibility into critical applications engineering requirements, Librato maintains that it is creating the tooling necessary to empower integrated development and deployment processes, such as continuous change control.

    “There are a lot of disparate tools for monitoring individual engineering tasks, but there hasn’t been any practical way to bubble up that data for efficient monitoring,” Josephsen said. “Within the context of DevOps, change control is a ritual that we’ve abandoned as we’ve embraced test driven development and automated away the human element, so there’s a distinct need for monitoring of feedback and metrics.”

    For example, cloud-based productivity messaging specialists Slack are using the Librato “StatsD” lightweight daemon process to stream business and app-health metrics regarding PHP applications into the monitoring platform. Slack also leverages Librato to chart data regarding connect, query and fetch latencies for its server clusters, and to monitor internal metrics about overall system health.

    “Having those graphs side-by-side lets us clearly see and compare the effects of network latency on one of our new services, and that’s very cool,” Richard Crowley, director of operations at Slack, wrote in a recent testimonial posted to the Librato Solarwinds blog.

    Industry experts agree that broader adoption of DevOps strategies will continue to drive demand for relevant monitoring tools, with solutions such as Librato seeking to deliver “modern stack architecture for looking at the modern stack.”

    “I think that APM is always interesting because it’s always new,” said James Governor, industry analyst with RedMonk. “The pace with which we’re building new architectures to deliver services to end users is increasing all the time, and with every new wave of technology, we tend to get new and associated models of APM tooling.”

    Librato is taking advantage of the need for a system that brings together the elements necessary for cloud native monitoring, and in an agentless manner different from other competing tools such as New Relic, the analyst noted.

    However, whether or not the platform is able to break down traditional engineering siloes to enable more efficient DevOps management, as Librato officials claim, remains to be seen, he said.

    “Each wave of technology has promised to do this, to remove the inherent finger pointing, and each has always made the same claim to break down organizational firewalls,” Governor said. “DevOps hasn’t boiled the ocean in this manner yet, but there are some unique opportunities; unlike previous waves, where automation was intended to replace humans, this is now about augmenting people, and we are seeing that teams are choosing new tools from which developers can truly derive value.”

  • 9 Open Source DevOps Tools We Love

    9 Open Source DevOps Tools We Love

    While we have been building our SaaS company, we have been investing much time in researching and deciding which tools to include in our DevOps toolkit. We’ve based these decisions on our years of experience in the IT industry, dealing with infrastructure for the most part. From building a petabyte-scale, data analytics infrastructure, our architecture, tools, and processes have become key components of our technology and operations. We’ve taken great care in selecting, benchmarking and constantly improving our tool selection.

    As a company that is building a solution on top of an open-source stack (ELK), our team is heavily involved in the open source community, contributing to multiple projects such as Camel and Kafka while customizing tools to fit our needs. The vast majority of tools we use internally are open-source ones. By sharing the toolset that we’ve collected and honed over time, we hope to foster a discussion within the DevOps community on what further improvements can be made.

    With that, we welcome you to enjoy browsing through the following list that we’ve created. Some tools you may have known about for years, while others may be new. Of course, we invite any and all feedback, especially from those of you who are using alternatives!

    Must-Have DevOps Tools

    1. Nagios (& Icinga) 

    nagiosInfrastructure monitoring is a field that has so many solutions… from Zabbix to Nagios to dozens of other open-source tools. Despite the fact that there are now much newer kids on the block, Nagios is a veteran monitoring solution that is highly effective because of the large community of contributors who create plugins for the tool. Nagios does not include all the abilities that we had wanted around the automatic discovery of new instances and services, so we had to work around these issues with the community’s plugins. Fortunately, it wasn’t too hard, and Nagios works great.

    We also looked into Icinga, which was originally created as a fork of Nagios. Its creators aim to take Nagois to the next level with new features and a modern user experience. There is a debate within the open source community about the merits of Nagios and its stepchild, but for now we are continuing to use Nagios and are satisfied with its scale and performance. The switch to newer technology, such as Icinga, may be appropriate in the future as we progress.

    2. Monit

    monitSometimes the simplest tools are the most useful, as proven by the simple watchdog Monit. Its role is to ensure that any given process on a machine is up and running appropriately. For example, a failure occurs in Apache, Monit will help to restart the Apache process. It is very easy to setup and configure and is especially useful for multi-service architecture with hundreds of micro-services. If you are using Monit, make sure to monitor the restarts that it executes in order to surface problems and implement solutions (rather than just restarting and ignoring the failure). You can do this by monitoring Monit’s log files and ensuring that you are alerted to every restart.

    3. ELK – Elasticsearch, Logstash, Kibana – via Logz.io

    logz.ioThe ELK Stack is the most common log analytics solution in the modern IT world. It collects logs from all services, applications, networks, tools, servers, and more in an environment into a single, centralized location for processing and analysis. We use it for analytical purposes (e.g., to troubleshoot problems, monitor services, and reduce the time it takes to solve operational issues). Another use for this tool is for security and auditing (e.g., to monitor changes in security groups and changes in permissions). After receiving alerts on these issues, it is easy to act on unauthorized users and activities. We also use ELK for business intelligence, such as monitoring our users and their behavior. You can set up your own ELK or buy it as-a-service. We’ve written a guide for the community on using ELK to monitor your application performance.

    Disclaimer: Logz.io is our ELK-as-a-service that we use in our own environment. You can say that we eat our own dog food.

    4. Consul.io

    consulConsul is a great fit for service discovery and configuration in modern, elastic applications that are built from microservices. The open-source tool makes use of the latest technology in providing internal DNS names for services. It acts as a kind of broker to help you sign and register names, enabling you to access service names instead of specific machines. If, for example, you have a cluster of multiple machines, you can simply register them as a single entity under Consul and access the cluster easily. We praise this tool for its efficiency, although we still feel there is more that can be done with it. If you also use it, it would be great to hear about your own use case.

    5. Jenkins

    jenkinsEveryone knows Jenkins, right? It’s not the fastest or the fanciest, but it’s really easy to start to use and it has a great ecosystem of plugins and add-ons. It is also optimized for easy customization. We have configured Jenkins to build code, create Docker containers (see the next item), run tons of tests, and push to staging/production. It’s a great tool, but there are some issues regarding scaling and performance (which isn’t so unusual). We’ve explored other cool solutions such as Travis and CircleCI, which are both hosted solutions that don’t require any maintenance on our side. For now, however, since we’ve already invested in Jenkins, we’ll continue with it.

    6. Docker

    dockerEverything that can be said about how Docker is transforming IT environments has already been said. It’s great…life changing, even — (although we’re still experiencing some challenges with it). We use Docker in production for most services. It eases configuration management, control issues, and scaling by allowing containers to be moved from one place to another.

    We have developed our SaaS solution with a twelve-layer pipeline of data processing. Together with Jenkins and Docker, we have been able to run a full pipeline across all layers on a single Mac. It would be wrong to say that there aren’t any complications with Docker, as even small containers can take a significant amount of time to build. However, we want to ensure that our developers are as satisfied as possible and enable them to work rapidly. With all of the management involved in storage, security, networking — and everything surrounding containers — this can be a challenge.

    We see Docker progressing and look forward to welcoming the company’s new management and orchestration solutions. For those who might be having issues with Docker, we’ve also compiled a list of challenges and solutions when migrating to Docker.

    7. Ansible

    ansibleAgain, simplicity is key. Ansible is a configuration management tool that is similar to Puppet and Chef.  Personally, we found those two to have more overhead and complexity to our use case– so we decided to go with Ansible instead. We know that Puppet and Chef probably have a richer feature set, but simplicity was our desired KPI here. We see some tradeoffs between configuration management using Ansible and the option to simply kill and spin new application instances using a Docker container. With Docker, we almost never upgrade machines but opt to spin new machines instead, which reduces the need to upgrade our EC2 cloud instances. Ansible is used mostly for deployment configuration mostly. We use it to push changes and re-configure newly-deployed machines. In addition, its ecosystem is great, with an easy option to write custom applications.

    8. Collectd/Collectl

    Collectd/l are nifty little tools that gather and store statistics about the system on which they run and are much more flexible than other tools. They allow users to measure the values of multiple system metrics and unlike other log collection tools that are designed to measure specific system parameters, Collectd/l can monitor different parameters in parallel. We use these two tools to measure customer performance parameters and ship them to our ELK-as-a-Service platform. We’ve specifically wrapped a Collectl agent in a Docker container and push it with Ansible to all of our servers. It collects information every couple of seconds and then ships it to ELK to allow us to run reports and send alerts. If you’d like to see a specific example of how we do this process in our environment and how others can do the same, we’ve created a guide for everyone.

    9. Git (GitHub)

    githubGit was created 10 years ago following the Linux community’s need for SCM (Source Control Management) software that could support distributed systems. Git is probably the most common source management tool available today. After running Git internally for a short period of time, we realized that we were better suited with GitHub. In addition to its great forking and pull request features, GitHub also has plugins that can connect with Jenkins to facilitate integration and deployment. I assume that mentioning Git to modern IT teams is not breaking news, but I decided to add to it to the list due to its great value to us.

    Other picks?

    The modern DevOps world is full of outstanding and unique open source tools—it’s a jungle out there. We found the tools listed here to be the best in breed and think they should be included in every DevOps engineer’s shortlist.

    Or am I wrong? What open source DevOps tools are in your toolkit? I’d love to hear your own recommendations and experiences in the comments below.

  • IT Asset Management: How to Find Out if Your Database is Causing Performance Problems

    IT Asset Management: How to Find Out if Your Database is Causing Performance Problems

    As your IT infrastructure grows, it becomes increasingly important to be able to identify where bottlenecks, performance problems, or outages are occurring so that you can quickly act to fix any issues. Identifying the source of a problem can be a bit tricky once you have grown into having multiple apps, servers, and databases—but there are tools that can significantly ease your burden in locating where an issue has arisen.

    The Problem: Identifying the Source

    sw-request-timeline
    The end user experience is affected when services are not functioning properly. Source: http://logicalread.solarwinds.com/response-time-analysis/#.VWNncfm4TIU

    Often, IT infrastructure begins on a small scale. Perhaps you start with a single app that runs on a single server with one small database. At this point, it is usually fairly easy to determine if that server is down, since everything will simply stop working. If it is simply the database itself, the app will most likely return errors connecting to the database.

    At this level, you likely won’t feel any urgent need to set up a more robust form of monitoring. After all, there are only so many things that can go wrong. However, as your services grow, managing those services in an efficient manner becomes increasingly important.

    Once you begin having multiple apps, servers, or databases, you will find that keeping track of issues becomes more time-consuming and difficult, since it may not always be clear what part of the system is failing. For example, if you have two apps using the same database server and both are not responsive, you will need to determine whether both app servers are down or the single database server is down. This could require checking in several different places to ensure you identify the correct cause.

    The Solution: Using a Monitoring Service to Manage Your Services

    happyapps-blog-sample

    A monitoring service can quickly show you if you have any problems. Source: http://www.happyapps.io

    Time to resolution is important when diagnosing and fixing any downtime for your services. You can save yourself quite a bit of time by having your various services monitored. A monitoring service cannot only send you alerts when things go wrong, but can specify which service is misbehaving or down.

    For instance, if your database server has crashed for some reason, you are alerted immediately and know exactly where to go to fix the issue. If you have multiple database servers, this is even more valuable, since you will know which one it is without looking at each server until you find the one that is in error.

    With a monitoring service like Happy Apps, you also get to tailor the alerts to suit your needs most effectively. You can choose to have notifications arrive by e-mail, text messages, or push notifications to your mobile device. You can also limit your alerts if needed, so that you receive only messages when there is a critical issue as opposed to something being temporarily slower than normal. Incidents are automatically opened whenever a check fails, and once all checks in an incident are passing, the incident will automatically become closed. You can always drill down to a specific incident and view the details (i.e. issues, history, and members), and Happy Apps tracks your incidents so you can understand how you fixed previous problems if the incident were to arise again.

    So, why not setup your services with Happy Apps? The configuration process, often a time-consuming challenge, is made incredibly easy with Happy Apps: with just a few clicks and less than 60 seconds Happy Apps checks are watching your services. Furthermore, in DevOps style, there is an API to add checks as well. The time you save yourself in identifying where problems are occurring will make you and your end users happy!

  • API Discovery and Search with APIs.JSON

    API Discovery and Search with APIs.JSON

    If that sounds vaguely like UDDI (which dealt with discovery and search of WSDL then you’re on the right track.

    Glue is this week, and preceding the conference was the 2015 API Strategy and Practice Tech Un-Workshops. One of the lightning talks (and they were lightning fast, let me tell you) was all about APIs.JSON – a relatively new collaborative effort between Kin Lane, API Evangelist, and Steven Willmott and Nicolas Grenie of 3scale networks,

    The effort – which you can dig into at apisjson.org – is an attempt to provide a more formal and standardized definition of APIs designed for “public deployment and consumption by automated software agents (robots)”.  In a nutshell, automated agents (and people, too, if you like reading machine-consumable metadata) can access a meta description of the APIs available for an organization at a known (standardized) URI such as http://company.com/apis.json.

    It’s not quite a WSDL for JSON, as the metadata is not describing the actual interfaces, but more like UDDI entry that might have once (and maybe still is) hosted in a registry (repository). The current incarnation provides basic information about the APIs and includes basic properties like a name and descriptions and URLs and can also contain more (some might say usable) information such as links to documentation or an actual, real-life readable API definition such as Swagger or API Blueprint formats as well as WADL and WSDL.

    The effort is showcased in an open API search engine (http://apis.io) that allows individuals to seek out APIs (over 900 are listed today) based on a variety of criteria, all of which of course is derived from the metadata within an APIs.JSON file.

    What does this all have to do with DevOps? Well, as Steve Willmott astutely pointed out in his lightning talk, APIs.JSON is not just about describing APIs in a consumable format, but it’s about being able to have machines discover and bootstrap APIs. That means potentially being able to trigger and signal changes about an API to kickstart a new build and deployment process.

    This is a great example of the possibilities for collaboration between Dev and Ops when everything is treated like code and automation moves from simple tasks to workflows – to orchestration.

    And I probably don’t have to mention (but I will, because , me) that the same trigger and signaling process could (and probably will) hook into broader network infrastructure (the components that exhibit high application affinity like load balancing and caching and app security) to drive more automated change management.

    APIs.JSON is not the first (and won’t be the last) effort of this kind because the mobile and app economy of the future is being built on APIs and thus , as Steve Willmott stated in his talk, “the Web of APIs is the future of the web.”

  • Why I Dislike The Term ‘DevOps Culture’

    Why I Dislike The Term ‘DevOps Culture’

    Culture is critically important in an organisation. It’s all of the hidden stuff that actually matters. It’s what people value and it feeds through to how people behave when you aren’t watching them, driving thousands of small decisions per day across the enterprise. A broken culture is a horrible thing to work within and a really tough thing to change because it is so inherent to an organisations DNA.

    I also believe that DevOps is fundamentally a culture. If people aren’t approaching IT delivery in a collaborative, emphatic way with a focus on continuous improvement then it probably won’t happen despite all of the change initiatives in the world.

    On the flip side, we can have the slowest, most beuracractic, most legacy technology environment, but the right culture will usually transcend all of that and make good DevOps like ways of working happen.

    With all of this said, I really dislike the term ‘DevOps Culture’. Nothing tends to get me ranting more in the DevOps arena than hearing that phrase.

    Why? Because it is so inactionable.

    I speak with a lot of enterprises who are looking to adopt DevOps. Once they have decided to get started, the first question is ‘What Shall We Do First?’ If I was to say, ‘DevOps is about a culture and about people having empathy with one another’. They would say ‘Great how do we achieve it? What do we do tomorrow, next week, next month?’

    At this point, some people scratch their heads. In the past I’ve heard, ‘buy dev and ops a pizza or some beers – thats a good first step. Maybe try a rotation or two and the culture will develop.’

    Personally, I don’t think that will cut it in a 10,000 person globally distributed IT function. The pizza bill alone would bring down the organisation.

    Moving Towards A DevOps Culture

    Culture is very hard to influence directly, it’s emergent from much more concrete activities.

    The meat of the discussion needs to lie there – in the steps we perform to get the outcomes we want. Things like:

    • Moving to cross functional teams
    • Cross training or hiring people with polyglot skillsets
    • Giving people the same incentives across the IT function
    • Empowering people to self optimise their processes and the end to delivery lifecycle
    • Encouraging people towards cross-silo collaboration over being tied to a rigid process
    • Changing reporting lines in the business
    • Investing in optimising the path to production over new features
    • Training and coaching developers, testers and IT operations on new collaborative ways of working
    • Bringing in new tools to support collaboration across siloes
    • ….. & 1000 other concrete activities

    To me, roadmaps of the activities above and the challenges and subtleties involved in doing them are much more useful than a nebulous statement about DevOps being a culture. I can actually do something with these!

    DevOps needs a much more rigorous approach to achieving it within the enterprise. We need to be develop out all of the steps above and bringing the conversation down to earth. Only when we get to this level of detail will we actually succeed in moving the dial to a DevOps culture.

  • George Jetson Automation: Chasing the Dream

    George Jetson Automation: Chasing the Dream

    “His job was one simple thing—press a button. That’s all he had to do; press one button and sit back.” – Joe Barbera

    I wanted to be George Jetson when I grew up. Back in the days when watching Saturday morning cartoons in footed pajamas was the high point of my week, George’s life looked as sweet as a bowl of Super Sugar Crisp cereal. Flying cars, robots, and a two-hour-a-day, three-day work week lightened even further by 100% push-button automation.

    jetson_button1

    Contrariwise, my first tech job out of high school was a classic study in manual labor. From 9pm to 5am, I was solitary “Night Backup Operator” for a small data storage company, lone man responsible for continuously swapping reel-to-reel tapes on and off a literal wall of old magnetic drives.

    reels

    It was repetitive, monotonous and boring, and the tapes were prone to jamming and tearing. A lot.

    tapes

    One night I was thumbing through a tech catalog and came across a listing for a new cassette backup system. I mentioned to my boss the following day that our reel drives could potentially be replaced by a unit the size of a large book. He took it to heart, made a purchase, and one evening shortly afterwards I came to work, popped in a blank cassette, hit a button, and kicked back for the next eight hours as 100% of my work was done for me. It was a George Jetson moment. The future had finally arrived. I was blissfully complete.

    They fired me, of course. It actually took them a few weeks to realize that I’d been automated completely out of a job. To their credit, they were appreciative and regretful in parting, but there was hardly any point in paying me to sit on my can reading pulp SF for eight hours every night.

    Regardless, I’ve been chasing that George Jetson moment ever since.

    The magic behind the button

    In the decades since, with a number of (slightly more professional) IT automation projects behind me, I’ve discovered that the “automate-everything” button is usually a lot tougher to achieve, and near-impossible to buy off the shelf. To even get close, you often end up building a significant amount of infrastructure up from scratch.

    But say you could buy a “George Jetson” button; a self-contained, perfect automation solution off the shelf; what do you look for? Setting aside the nuts and bolts of a specific IT problem or project, what does an “automate-everything” button need to do, in essence?

    1.   “Do No Harm”

    At the first sign of an incident, Mr. Spacely (voiced by Mel Blanc, “Man of a Thousand Voices”) pops up and begins motivating with the bellow “JETSONNNNN!”. (I once worked outage calls with an IT director who had the same management style, I kid you not). We don’t want this to happen. So our “automate-everything” button needs, first and foremost, to mitigate risk.

    Security should be the first consideration in risk management, yet it’s an area where (oddly enough) a number of automation solutions fall flat out of the gate. Managed user accounts (ideally, integration with established account management systems), role-based permissions (for pushing the button in various situations, IT environments, and scheduled times), and sensitive information handling should all be covered.

    The ideal automation solution’s back-end infrastructure should be robust, flexible, and professionally engineered. If any pieces are open-source or community-designed, what they do and don’t do should be well-documented, including an understanding of potential situations likely to result in unintended consequences.

    We also want the automation button, once pushed, to never perform the action again if there’s no need to do so. This is idempotence, a valuable concept that’s been around for a long time but has risen to prominence over the last year. Idempotence is particularly important once you start to consider auto-remediation (why push the button manually if it can run automatically?), and efficiency (why spend effort building an automation action that can only be run once?).

    2.   “CYA”

    “Cover Your Automation.” George isn’t particularly smart for a computer operator. But maybe he doesn’t need to be. Let’s say he’s supported by a lower floor full of smart engineering robots. The robots set up the automation actions and push them into an approval queue with just enough information to make a decision on whether an action is needed or not.

    George evaluates each situation and pushes the button if everything looks good to him. Now, the “automate-everything” button becomes more of an “approval” button in a formal change management system. There might be more approvers besides George, each laying eyes on the proposed automation action and passing it along to the next approver as appropriate.

    Most operators aren’t as dumb as George, but everybody has “dumb moments”. Change management needs to be a core part of any automation system.

    Accountability supported by thorough logging is also a key “CYA” aspect of the ideal automation system. “What” happened, “when” did it happen, “who” did it, and so on… if your automation system doesn’t track all essential information, you might not be able to return to your job after Spacely mistakenly fires you.

    3.    “KISS”

    “Keep It Simple, Stupid.” Dealing with complex automation workflows is tricky if they involve a lot of step-by-step actions, as they traditionally have in the past. When complexity clashes with modern, large-scale IT environments, situations arise that are literally impossible to manage manually. “Scale x Complexity > Effort” is the equation desperately slashed across whiteboards in planning meetings these days. Modern automation systems often attempt to reduce complexity and equalize scale through a form of orchestrated states.

    The idea depends on two parts. A desired state is a recent Microsoft-championed concept where the steps required to reach an end result are black boxed in favor of defining a system’s state itself. The usual example: rather than considering a step-by-step recipe for a birthday cake, you describe “a white cake with pink frosting” as your desired outcome and pop your request into an automated system to make it happen. Recent configuration management solutions have made excellent headway in this area.

    But desired states aren’t enough in and of themselves. They almost always need to be orchestrated to reach the final goal. An orchestrated states effort runs more along the lines of: “I need a white cake with pink frosting at the same time as a bowl of orange punch, before the time of the birthday party, but after the house cleaning. Also, yellow balloons.” Real-life IT infrastructure requires at least this level of complexity and timing.

    For a complete “automate-everything” solution, our ubiquitous button needs to orchestrate the states of all necessary systems and services in a way that’s easy for George, our hapless operator, to process, and considers both transitory states and final states as well as the interactions between them.

    jetson_button2

    When evaluating whether an IT automation solution is right for you, you may not be able to find the ideal “automate-everything” button, but make sure you consider it from these three perspectives. The perfect solution may, in the end, just be a dream to be chased by the laziest as we move from one IT automation project to the next. But it sure is fun seeing how close we can come to that blissful, futuristic George Jetson moment.

  • Continuous Testing – Accelerated !

    Continuous Testing – Accelerated !

    Except for cases where test duration is the point of the test, as indicated in my prior blog “Isn’t Continuous Testing a Longevity Test Anti-pattern?”, faster continuous testing cycles are preferred because failing early and often is a DevOps goal. There are multiple reasons for this, but it should be evident that faster tests reduce the wait time to get results and since there are typically many development team members looking for results the developer time savings multiplier effect is huge for every minute of test time saved on each CI/CT cycle. When aggregated over multiple code branches a few minutes saved per test can be man-years of time saved over a year!

    So what can be done to accelerate continuous testing? Frankly a thorough answer to this topic could fill a book. Below are some suggestions in a checklist format intended to be useful for DevOps .

    1. Organize the team for speed: When team members and the organization are explicitly selected for CT speed the entire DevOps process will be accelerated.
      • A test architect familiar with the principles of best practices test environments and continuous test design is critical to design and tune continuous testing for speed. The architect establishes the CT strategy and speed goal relative to the coverage goal.
      • A test analysis team reviews test results so no time is wasted on results analysis.
      • Developers and test members are trained on best practices test design and their test scripts are peer-reviewed to ensure they comply with the strategy.
    2. Select powerful test resources: Powerful, dedicated, scalable resources will accelerate all test processes and shorten the time to results.
      • Select the fastest processors, low latency storage and I/O to initialize and execute both the test systems and system-under-test entities quickly.
      • Dedicate resources that have longer initialization times so they can be pre-initialized.
      • Virtualize resources that can be scaled horizontally without sacrificing speed.
      • If affordable, arrange enough resources to run ALL tests in parallel.

    3. Choose test tools that are designed for fast test execution: Look for the following features when you are evaluating test tools. Not only will this save you a lot of headaches in the long term, it will give you the flexibility to design tests that integrate with other DevOps tools.
      • Restful APIs that do not require wait states between commands and responses
      • Priority queuing of test cases
      • Creation of test topologies that can be pre-loaded
      • Ability to spawn out tests in parallel to run on any number of machines
      • The ability to park a test that needs to wait for an event and return to it after proceeding with subsequent tests
      • Caching features that enable initialization and results data to be processed for one test while the tool proceeds to execute other tests
      • Multiple devices, session types and results data processing utilities implemented as an embedded part of the tool and not requiring slow speed scripting
      • The ability to render commonly used test utility functions in a fast execution language.

    4. Organize test schedules and test suites to fail early: The sequence and approach for scheduling of test cases greatly affects the speed of testing. If possible the scheduler should launch all tests in parallel as soon as the build is ready. Otherwise priority schemes are needed.
      • Organize the test scheduler and test suites to avoid any unnecessary tests.
      • Cache initialization and topologies data and resources ahead of the next test execution.
      • Check the test environment before running tests, abort if invalid conditions are detected.
      • Organize tests so the most important ones are run first.
      • Set a failure escape threshold and abort the test if exceeded.
      • Eliminate dependencies between tests so that each one can run standalone or in parallel. Queue the next test while a test is running.
      • Use smart gray box testing methods to limit test selection to the most important tests according to the software change and skip tests that are low risk.
      • Run longer tests in parallel with shorter ones.

    5.Design test cases to fail early: The test cases themselves need to be designed with the strategy to get test results as fast as possible.
    • Design each test case with a single unique test purpose and make it self-contained so it may be scheduled to run standalone or in parallel with any other test case.
    • If a test case has multiple verdicts arrange the highest priority verdicts first and close the test at the first failure.
    • Prune or refactors tests that have a low failure history.
    • Shorten dead-script timers, and make any wait timers conditional so they can expire as soon as the condition is met.
    • Reduce the number of test iterations to fit a time budget.
    • Reduce communication wait times by using the fastest protocols. Optimize the most frequently used utilities.

    1. Arrange test results reduce to minimize analysis wait times: Arrange the test results to be consumable as soon as the tests are run so the system does not bottleneck.
      • Report test results as the tests are run and accumulate the results across parallel test targets.
      • Establish thresholds for aggregated test results and abort the tests and release test resources to be used by other tests if the thresholds are exceeded for any run.
      • Keep track of test timings and adjust the test schedules according the average and peak run times for each test case.
      • Separate test result report processes to persistent resources so no test process is waiting to finish a report and the test process can proceed to the next test in parallel with test results.
      • Correlate the test results to the changes and use trends analysis to help speed up diagnostics and as an input to test selection such that the most failing test cases are given higher weight in future test runs.

    The above is a partial list of suggestions for accelerating continuous testing that have been proven to yield good results for accelerating continuous testing and DevOps.

    At Spirent we think testing has a bright future in DevOps. You can read more about our views at Spirent.com/solutions/devops

    What do you think of these suggestions and do you have others that should be mentioned?

  • Isn’t Continuous Testing a Longevity Test Anti-pattern?

    Isn’t Continuous Testing a Longevity Test Anti-pattern?

    Accordingly to Jim Coplien: “an anti-pattern is something that looks like a good idea, but which backfires badly when applied. “ In DevOps context, continuous testing is an attractive solution for the narrow context of testing specific software components quickly (in cycles measured in minutes or hours) but may be “bad” if the system that the software is a component of has failure modes (E.g., effects of memory leaks) that will only be observed during long term testing over several days and if the time between releases is greater than that. In other words, the pattern of quick test cycles prescribed by continuous testing appears to be a contrary Anti-pattern to the fundamental concept of long duration “longevity” testing. So what are the well formulated positive patterns that are applicable in its stead?

    In my prior blog entitled “From QA to Continuous Testing” I indicated “QA test experts that are most skilled in the best practices of test design are valued because they will produce the best quality products.” QA test experts assert that it is unwise to release a software product that has not been tested for durations comparable to the lifecycle of a release. Only tests that are run for a significantly long time compared to the release cadence are deemed sufficient. Just how long is long enough? This is a subject for further discussion beyond the scope of this short article, but my own observation is that best practices test environments run accelerated level load and impulse load traffic patterns on a build candidate for at least 48 hours or more before a release is determined sufficiently tested for at least limited deployment. Even 48 hours is much longer than typical “continuous testing” cycles. So “what positive continuous longevity testing patterns are applicable in its stead?”

    Continuous Longevity Testing Patterns may sound like an oxymoron but in fact longevity testing is compatible within the context of continuous testing principles. Below I describe three Continuous Longevity Testing Patterns that are sometimes used.

    Pattern 1: Longevity testing time windows are reserved such as weekends. In this pattern the regular Continuous Integration/Test cycles are interrupted during the weekend and longevity tests are only run on the build that was last created prior to the weekend time window. This has the advantage of not requiring any special test resources other than the resources used for regular CT tests and does not require any sophisticated scheduling to orchestrate the test environment. The disadvantage is that the longevity test results are only available weekly, it is hard to diagnose which build caused a longevity failure and problems with release candidates will delay the release for a week until the next longevity test run validates the fixes.

    Pattern 2: Longevity parallel testing is scheduled frequently, perhaps as frequently as every few builds, or perhaps daily. This pattern has the advantages that the regular Continuous Integration/Test cycles are not interrupted any time (they run 24/7), the longevity test results are available for more builds than Pattern 1, which reduces diagnostic complexity and may reduce release delays, but has a disadvantage that separate test resources must be reserved for each longevity test in parallel with the regular CT tests. For complex systems under test with many test targets and lots of builds this can be very expensive so there is a tradeoff between test resource costs, and the cost of delays if not done frequently enough.

    Pattern 3: Intelligent longevity testing is scheduled only when certain conditions trigger the longevity tests to be started according to smart rules that correlate software changes to problems with longevity performance. This pattern has the same advantages as Pattern 2 and has the further advantage that the cost of test resources is usually much less than Pattern 2 if the rules for the triggers don’t fire too frequently. The disadvantage is the entire scheme depends on the creation of a rules engine and rules that understand the risk of changes for long duration testing. If the rules are too lenient then this pattern might allow too many longevity failures to escape but if the rules are too tight then this pattern is not any better than pattern 2 and yet more complex to implement.

    So which Continuous Longevity Testing Pattern is best? The best answer is the one that best matches organizations’ goals for release cadence, cost of testing, and risk.

    So indeed, Continuous Testing is a Longevity Test Anti-pattern but fortunately DevOps infrastructures implemented according to best practices have a variety of complementary Continuous Longevity Testing Patterns to choose from.

    At Spirent we think testing has a bright future in DevOps. You can read more about our views at
    Spirent.com/solutions/devops

    What do you think of these patterns or do you have others that should be mentioned?