devopsy.kinsta.cloud

Tag: configuration automation

  • There’s No Innovation Without Automation

    There’s No Innovation Without Automation

    Companies of all sizes and across virtually every industry today have ready access to hyperscale compute, storage and myriad other technologies — without needing the significant budget or technical expertise of a hyperscale cloud provider like AWS.

    This is a boon for innovation. Cloud opened the door to cost optimizations, previously out-of-reach cloud-native tools, security improvements and other tangible business benefits. This also created something of a myth in the industry: people commonly think of cloud as “easy.” Yes, migrating existing applications to the cloud can create significant business value. But saying “cloud is easy” can be dangerously misleading.

    There are reasons for this perception. A developer with a credit card can create an account and spin up a new environment in a matter of minutes, for example. That’s a far cry from the days when that same IT professional might need to submit a ticket to an internal Ops team days (or weeks) in advance to provision a new Dev environment.

    Operating in the cloud at any kind of enterprise scale is not necessarily easy, however. In fact, cloud can be much more complicated than on-premises infrastructure. Consider the sheer number of new tools and services a platform like AWS rolls out in a given month—keeping up with the pace of change and innovation can itself seem like a full-time job.

    Complexity becomes an even bigger issue when teams migrate to cloud (or begin pursuing greenfield cloud-native projects) while simultaneously trying to move with greater speed and agility, often driven by a new or ongoing digital transformation project in the company. Think about a team that’s undergoing a shift toward DevOps while also migrating a major legacy system to a cloud—that’s a lot to tackle at once.

    Fortunately, cloud complexity is an eminently addressable challenge — so long as you embrace automation. Automation, including the use of embedded or native tools from the hyperscalers themselves, is absolutely critical to cloud success.

    Automation is what enables today’s IT teams to achieve the benefits of a cloud migration without saddling themselves with an untenable operational burden. Furthermore, automation is what makes a lot of popular mantras in business and IT today — such as “fail fast” and similar ideas — actually possible.

    Automation is the foundation of innovation. There is no such thing as meaningful innovation without automation. That’s because sticking with largely manual operations turns IT into a bottleneck. Technology hampers the overall business rather than drive its most pressing strategic priorities. Organizations that don’t adapt to this reality face big headwinds. Cloud on its own does not solve the problem; cloud paired with automation is what is needed.

    Consider the various operational requirements of any IT environment: provisioning, configuration, security, scaling, resource management and optimization, and change control/change management. Without effective automation, each of these alone can require an intensive amount of manual effort to manage in the cloud and quickly become more complicated than their counterpart in a plain-vanilla on-premises environment. If you can’t quickly scale up as your application needs change, whether due to a demand surge or other factors, then you’re not achieving the speed and agility that cloud promises, for example. Likewise, if you can’t scale down machines that are no longer needed, you’re almost certainly wasting money on idle resources. This is where a cloud platform’s autoscaling capabilities come into play.

    Similarly, consider your organization’s existing change control or change management processes. It’s a necessary function of many enterprises, especially those who must manage regulatory compliance. When applied manually in the cloud, it can quickly become a byzantine effort that severely limits agility. That’s a nonstarter for most modern businesses. This is another challenge that can be addressed with automation in the cloud.

    It’s also important to understand that automation drives quality as much as it drives agility. It enables you to deliver new products and services faster and more frequently while fostering top-notch user experiences. The autoscaling scenario above can reduce capacity-related outages that damage customer experience and the bottom line, for instance. In this way, automation and cloud together form the basis for true operational excellence and its hallmark characteristics of capacity, elasticity, performance, and security.

    This is not just the purview of customer-facing applications, either. Competitive businesses must bring the same philosophy to their whole IT portfolio. Innovation depends on internal systems becoming as nimble as a web front-end.

    Think about an ERP system like SAP; change on SAP for enterprises has traditionally moved at the speed of an elephant when today’s businesses operate at the speed of a gazelle. You must apply the processes, tools and culture of cloud and automation to back-end systems, too. You can automate operational tasks in the cloud, such as system refresh and other system-level operations. This paves the way to zero-downtime maintenance, patching the database at the OS level while getting rid of the hours of downtime that task would previously have required. Or think of the necessity of backup-and-restore: Via cloud-based automation, you can deliver point-and-click restores that greatly reduce time to recovery.

    Again, this is about quality just as much as agility. Applying automation appropriately to a cloud-based ERP system can reduce or eliminate human error, too, further boosting system performance and reliability.

    In short, cloud offers great opportunities for enterprises to access transformational innovation.  However, you can’t be innovative without being agile, and you can’t be agile without automation.

  • The Pros and Cons of Configuration-as-Code

    The Pros and Cons of Configuration-as-Code

    Configuration-as-code, or “GitOps” as many are now calling it, is a simple but astounding idea: Standardize configuration, check it into version control; no need for each Operations/DevOps person to develop their own set of scripts to get the job done. Configuring or reconfiguring an environment is as simple as checkout and run, assuming everything in the configuration is tested. For a project or a team, this is a serious time-saver and limits the amount of human error introduced into our systems. For projects rolling out code frequently, it is pretty much required.

    But like everything, it has its limits. I worked with a product management engineer once who had concocted a script that had tens of thousands of lines of code and was every bit as complex as the product he used it to manage. His scenario was the typical precursor to configuration-as-code: He would go show off the product and whatever functionality he needed could be managed through his script. The problem was maintenance; as the script was central to how he did his job, changes to it were a big deal. And even though he was the only one maintaining it, he did get burned a couple of times by changes he’d made, because it was that complex.

    When our configuration-as-code starts to cross teams, or we take it to the enterprise level, we risk finding its limitations. Our environments are complex, very complex. And we can do a lot with configuration-as-code, but throwing everything plus the kitchen sink into that system will create issues we need to overcome.

    A single project is constrained. We know what we need to do to spin up the environment. We can identify weak points and build checks and balances around them.

    The enterprise environment is not a project. Agile projects and DevOps thrive because they have a stable working environment to run on. The volume of change in things such as storage allocation, routing and VLANs is not the volume of change that an agile project sees. Good documentation is as solid a solution as configuration as code for something that changes rarely and the size/number of scripts and configurations that need to be maintained is smaller.

    There is a good use case for corporatewide configuration-as-code for recovery purposes. It is far easier to restore the environment in a disaster if you have all configuration and the scripts to install that configuration available. Unfortunately, that use case is minimized by the march of technological change. During the one total destruction restoration I’ve been involved in (was in charge of), many of our configurations were no longer usable because the products we were running in production at the time of the disaster were not the products we could purchase for the rebuild. We ended up with a shiny new data center from building to servers, but it still involved a lot of manual configuration. So while the use case is good, it is not a panacea unless you are constantly replacing your infrastructure with the newest products, limiting the usefulness of this use case also.

    Some organizations have already moved to configuration-as-code via methodologies such as chaos engineering, but most of us are just starting to consider moving configuration-as-code beyond the project level. When the (admittedly large) step of truly moving infrastructure management toward configuration-as-code, start with inventorying what your operations team does on a daily basis. There are a ton of things—the famous low-hanging fruit—that can be boiled down to scripts or standardized configurations and checked into version control. This gives a central point of truth for how things are configured, tracks changes for when things go wrong, and shortens startup time for new DevOps/Operations staff by giving them a repository of tools to review and work with. When working in the cloud, everything is scriptable, so make that side of operations is completely configuration-as-code. In the data center, you end up with diminishing returns after daily tasks are automated, but assigning someone to codify all possible changes is a worthy goal, as long as the work is prioritized to make the most frequent or error-prone configuration issues a priority. Once the focus is down to hardware, the rate of return for those invested hours is going to go down a bit, since specialized hardware is full of proprietary or market-focused config info. To draw on a comparison I’m familiar with: An F5 ADC has very specific use cases that must be reconfigured centrally, whereas restoring your Kubernetes cluster will generally require less focused configuration and teams spinning up containers will take it from there. Not that Kubernetes configuration is simple; but each project handles the details they require while corporate-shared resources tend to need all of the details handled by the infrastructure team.

    We can discuss this at length, and I have with others who think differently, but small tools are better. Do one thing, and do it well—the original Linux mantra—then make scripts that call the small ones. This contains changes over time and doesn’t create dependencies or touches on things that might not need it in a given situation.

    And keep rocking it. All configuration-as-code does is reduce manhours and opportunity for human error, so embrace it, but be controlled about it. Don’t throw everything in there and then forget about it. Make a plan, make a maintenance plan. Iterate. Improve. And use that extra time to solve user problems, which is why we’re here in the first place.

  • Webinar: Unifying your Application Release and Configuration Automation

    RECORDING

    SLIDES

    [seoslides embed_id=”25ec04fb3359″ script_src=”https://devopsy.kinsta.cloud/embed-script/unifying-application-release-configuration-automation/18313/” overview_src=”https://devopsy.kinsta.cloud/slides/unifying-application-release-configuration-automation/” site_src=”https://devopsy.kinsta.cloud” site_title=”devopsy.kinsta.cloud” title=”Unifying your Application Release and Configuration Automation” /]

     

    — Jules Louis

  • Rugged DevOps: Good, Bad & Ugly

    Rugged DevOps: Good, Bad & Ugly

    The Good: DevOps has been a success for Dev.

    With higher expectations, better processes, more management focus and new tools like advanced PaaS and containers, developers are churning out more and more software faster than ever. Success! Or is it?

    The Bad: DevOps has been a success…for Dev.

    For Dev teams, this may result in pats on the back and high fives. But for Ops, this can look like one thankless tidal wave of work after another. The same software velocity that is praised in Dev is currently overwhelming their counterparts in Operations. And frankly, many DevOps tools released in recent years happen to benefit Dev much more than their counterparts in Ops. (My pet theory is that developers at IT automation firms are acting and thinking like…developers – focusing their creative energies on solving Dev problems.) A similar problem holds true for IT Security teams who want to build quality in by “shifting left” – see  https://devopsy.kinsta.cloud/2015/12/10/getting-rugged-devops-right/ . From the vantage point of IT Operations and Security teams, they are doing more work than ever but without any more human or IT automation resources. To add insult to injury amid their increased workloads, many IT Ops teams have to invest countless hours (away from family and personal time) in training courses and migrations to reorient their processes to fit into shiny, new Dev-centric “DevOps” tools and paradigms. 

    The Ugly.  

    Work. Overwork. Glitch. Search. Find. Rework. Repeat.

    A quick glance at IsItDownRightNow.com will show you which IT Operations teams are in a living hell at the moment. The other thing you will notice is that these IT Ops teams are from some of the most reputable companies on the planet. They are talented teams but stuck in rework cycles of web performance problems, security vulnerabilities and outages.

    These problems get the attention of everyone. Operations…and Dev…and Security…and customers…and Finance…and auditors and the press.

    No one likes rework. And no one likes the panicked fire drills that cause panicked rework. So what causes those rework cycles?

    Drama-free IT. Visibility Cures Chaos.  

    Much of this chaos can be tied to miscommunication. Boring? Maybe. Simple? No. Part of miscommunication is cultural. (Hint: OrcaConfig’s “How to Screw Up DevOps” white paper covers the cultural aspects of miscommunication). But miscommunication is also cured by automation solutions that promote transparency and visibility.

    If we want drama-free IT we need IT automation solutions that eliminate miscommunication and missed assumptions between Dev, Ops and Security.

    What better way to do this than with full transparency and visibility?

    Bird’s Eye Views:

    Many IT automation tools cater to SysAdmins who are interested in managing configurations of individual servers. That’s great if your focus is on individual severs. But IT Operations, eCommerce teams, Application Owners, Compliance & Security teams and IT Managers often care more about the health and performance of their application ecosystem (including related applications, middleware, databases and configurations that tie them together). So there is often a mismatch between the tools that SysAdmins and Developers have versus what IT Ops needs.

    Operating at Enterprise Scale Requires at-a-glance Visibility:

    IT Ops teams need bird’s-eye views of applications, databases, middleware and ecosystems to promote ease of ongoing operation. They need to be able to see, at a glance that a configuration compliance problem exists and they need to know right away the location and nature of the error. Large scale IT Ops teams do not have the luxury of toggling back and forth between multiple reports and multiple screens searching for that non-compliant, broken needle in an ecosystem haystack. If they are faced with a glitch or an outage, they need to find and fix it right away. One size does not fit all. Dev, Ops and Security each have their own interests and their own need to view their application through a lens that is most meaningful for them. Multiple ecosystem views eliminate guesswork between Dev, Ops and Security and save precious time in the find-fix cycle.

    Forrester Research spells it out well in their 7 Habits of Rugged DevOps white paper, Habit 1: Increase Trust And Transparency Between Dev, Sec, And Ops:

    “I&O pros pride themselves on understanding the interconnectedness of the hardware and software environment, and they are unnerved by complexities that poorly governed delivery practices create because the firm rates I&O pros on their ability to improve the performance and stability of the production environment. To maintain the environment, they must reduce the chances of an outage or interruption of service, and they must reduce the MTTR when an issue does occur.“

    Understanding that interconnectedness depends greatly on how much intuitive ecosystem visibility we provide to our colleagues in IT Operations. But it’s not just IT Ops that benefits from visibility, Dev and Security do too.

    Developers are able to write more secure code when they get early, in-context feedback. As David Mortman, distinguished engineer and Dell chief security architect, said, “Security issues are product quality issues, and no one wants to write buggy code.”

    Even better than efficiently finding and fixing errors is of course to prevent them in the first place and to proactively eliminate the damage they cause. Here too, the answer is better visibility. With true application ecosystem visibility, Dev and Ops teams would be able to model relationships between applications, middleware and their configurations so users will know that “changing this, affects that”.

    My teenage son has better visibility via his smartphone as to his driving route and weather conditions than I have for my multibillion dollar IT operation.

    Visibility into the Future:

    Ecosystem visibility is a key to communicating between Dev, Ops and Security and running complex application environments in the present. But what about the future?

    Release automation tools and custom scripts are excellent at deploying changes across large environments. Unfortunately they can be just as efficient at deploying typos and other mistakes across large environments, causing the chaos that we discussed earlier. Here again Operations teams would benefit from improved visibility – the ability to preview and pre-validate proposed changes across the entire ecosystem well before those changes are deployed. This is the real promise and savings of ecosystem visibility. Better visibility, with more use-case lenses cuts out the miscommunication that causes too many performance glitches, security vulnerabilities and outages. This chaos takes a toll on our IT Operations teams, our employers and our customers.

    What Next?

    We are soon entering a new season with new budgets. The temptation to “buy something” will be great. In the spirit of Rugged DevOps my recommendation is to take a full, bird’s eye view of your SDLC and to shift Ops and Security leftwards, building their critical considerations into your processes and into your IT automation tool selection.

  • Dev loves Open Source. Ops needs Scale. Now What?

    Dev loves Open Source. Ops needs Scale. Now What?

    Crossing the divide from Dev-Ops to DevOps:

    At the heart of the divide between Dev and Ops are the very different needs and constraints of each organization. Traditionally their day-to-day lives are very different. So are their war stories. And so are the metrics that are traditionally used to judge Dev and Ops. Predictably, the two organizations can end up internally competing with one another over (among other things) resources and IT automation tool selection. Part of the driving force behind the DevOps movement is to reduce this unproductive internal competition. Even with the increased levels of trust and communication that DevOps fosters, IT Operations teams will still have different criteria for IT automation than their colleagues in Dev.

    My company is considering implementing (or has just implemented) an open source configuration management tool. That’s great for Dev. But as far as I can tell my job, and my team’s job, is about to get a LOT harder

    ~ VP IT Operations

    Dev loves Open Source:

    Take configuration and release automation as example. Like so many other areas of enterprise software, many developers naturally gravitate to open source options. It’s no wonder that 90% of code in modern applications is open source – after all, open source provides developers with

    • Immediate gratification: Just Google it! Choose the right key words to describe your situation and you might find a good match.
    • Community: Don’t reinvent! Find out what have others done.  Opinions and suggestions might be plentiful across your favorite user groups. Maybe someone has solid sounding advice. Maybe someone even has specific settings or scripts that they have used. If so, you might be in luck.
    • Free: Enough said.

    But while Dev is drawn to prebuilt open source components that they can then modify,

    Ops has completely different needs including scale, stability, support, security and speed.

    Let’s look at each of these in turn:

    • Scale: It’s great that the code works in Dev and in Test. In Operations, I need it to work everywhere, all the time. And we need to add 10s of thousands of servers with no new resources.
    • Stability: Don’t force me to rebuild my infrastructure to be stable in a production environment.
    • Support: Someone, somewhere needs to be on the hook for this software, with enforceable SLAs. This cannot be left to chance. I need a phone number. Now.
    • Security: Failure is not an option. Our financial future and reputation is on the line. We cannot allow our customers to become vulnerable due to security issues. According to a study by Forrester Research, consider:
      • “One out of every 16 downloads of open source component requests are for a component with a known vulnerability.”*
      • “31% of companies have had or suspect a breach in an open source component, gaining control over open source risks is essential to improving security.”*
    • Speed: We need quick time to market and low total cost of ownership that comes from quick learning curves.

    In the context of configuration and release automation, can we satisfy both Dev and Ops?

    Yes. Here’s why:

    A new generation of application configuration automation solutions have been introduced in recent years. (To be transparent my company, OrcaConfig is one of these).  These solutions cater to Ops’ need for fully supported, central, secure control, ecosystem visibility, workflow automation and compliance enforcement – all at enterprise scale and without relying on open source, community driven scripts.

    But what about Dev’s needs?

    I will answer a question with two questions.

    1. Does Dev need open source?
    2. Or do they want the benefit that open source often brings?

    If those sound like product requirements document (PRD) type questions, they should. In an era with tightening constraints on budgets and headcount, selecting the wrong tool based on incorrect assumptions is a major self-inflicted wound.

    These next generation DevOps solutions provide Dev with application-centric modeling (after all it is all about the application), templated workflows (immediate gratification) and versioned full stack configurations (time and money savings) while providing accountable, knowledgeable support (community is great. Community and support is even better.)

    While there are no silver bullets in the drive to DevOps success, my hope is that we can dispense with the open source “requirement” and instead focus on needs and results.

  • Red Hat to Acquire IT Automation and DevOps Leader Ansible

    Red Hat to Acquire IT Automation and DevOps Leader Ansible

     Red Hat advances frictionless IT with simplified management for hybrid clouds, OpenStack environments and container-based services

    RALEIGH, N.C., Oct 16, 2015 (BUSINESS WIRE) — Red Hat, Inc. RHT, +3.43% the world’s leading provider of open source solutions, today announced that it has signed a definitive agreement to acquire Ansible, Inc., a provider of powerful IT automation solutions designed to help enterprises move toward frictionless IT. Ansible’s automation capabilities, together with Red Hat’s existing management portfolio, will help users drive down the cost and complexity of deploying and managing both cloud-native and traditional applications across hybrid cloud environments. With today’s announcement, Red Hat expands its leadership in hybrid cloud management, OpenStack and containers.

    Ansible’s simple and agentless approach, unlike competing solutions, does not require any special coding skills, removing some of the most significant barriers to automation across IT. From deployment and configuration to rolling upgrades, by adding Ansible to its hybrid management portfolio, Red Hat will help customers to:

    Deploy and manage applications across private and public clouds.
    Speed service delivery through DevOps initiatives.
    Streamline OpenStack installations and upgrades.
    Accelerate container adoption by simplifying orchestration and configuration.
    The upstream Ansible project is one of the most popular open source automation projects on GitHub with an active and highly engaged community, encompassing nearly 1,200 contributors. Ansible automation is being used by a growing number of Fortune 100 companies, powering large and complex private cloud environments, and the company has received several notable accolades, including a 2015 InfoWorld Bossie Award, recognizing the best open source datacenter and cloud software.
    With the addition of Ansible, Red Hat’s open hybrid cloud and IT management solutions will include:

    Red Hat CloudForms, an open management platform that provides orchestration, governance and policy-based control across hybrid clouds enabling self-service provisioning, and resource management as well as quota enforcement, metering and chargeback.
    Red Hat Satellite, a comprehensive lifecycle management solution with integrated infrastructure provisioning, software distribution, patch management and auditing capabilities.
    Ansible and Ansible Tower, an IT automation and DevOps platform that provides significantly simplified multi-tier application deployment and IT automation across hybrid clouds.
    The acquisition is expected to have no material impact to Red Hat’s revenue for the third and fourth quarters of its fiscal year ending Feb. 29, 2016 (“fiscal 2016”). Management expects that non-GAAP operating expenses for fiscal 2016 will increase by approximately $2.0 million, or ($0.01) per share, in the third quarter and approximately $4.0 million, or ($0.02) per share, in the fourth quarter as a result of the transaction. Red Hat calculates non-GAAP operating expense by subtracting from GAAP operating expense the estimated impact of non-cash share-based compensation expense, which for fiscal 2016 is expected to increase by approximately $1 million for each of the third and fourth quarters, and amortization of intangible assets, which for fiscal 2016 is expected to increase by approximately $1 million for each of the third and fourth quarters, in addition to transaction costs related to business combinations, which are expected to increase by approximately $1 million in the third quarter. Management expects GAAP operating expense to increase for fiscal 2016 by approximately $5 million, or ($0.02) per share, in the third quarter and approximately $6 million, or ($0.02) per share, in the fourth quarter as a result of the transaction. Excluding the operating expense impact as noted above to GAAP and non-GAAP operating margin and GAAP and non-GAAP earnings per share, Red Hat is otherwise re-affirming its fiscal 2016 third quarter and full year guidance provided in its Sept. 21, 2015, earnings press release.

    The transaction is expected to close in October 2015, subject to customary closing conditions.

    Webcast

    Executives from both companies will host a webcast to discuss this announcement on Thursday, Oct. 22, 2015, at 11 a.m. EDT. Following executive remarks, press and analysts are invited to participate in a live question and answer session.

    To join the webcast or view the replay after the event, visit https://vts.inxpo.com/Launch/QReg.htm?ShowKey=27948.

    Read more about the acquisition on Red Hat’s website including in the Red Hat blog.

    Supporting Quotes

    Saïd Ziouani, co-founder and CEO, Ansible

    “We’re thrilled that Red Hat, a global leader in open source, has chosen Ansible to tackle the future of IT automation and systems management. This is a strong validation that Ansible’s simplicity, enterprise customer base and robust community is winning in enterprise IT automation, from compute to networking to cloud to containers.”

    Joe Fitzgerald, vice president, Management, Red Hat

    “Ansible is a clear leader in IT automation and DevOps, and helps Red Hat take a significant step forward in our goal of creating frictionless IT. Red Hat is transforming IT management, driving innovation that is 100% open source, built on an open management platform, and relentlessly focused on reducing cost and complexity through ease of use and automation. I am thrilled to welcome Ansible to Red Hat to help us expand that commitment.”

    Doug Carlisle, managing director, Menlo Ventures

    “I commend the entire Ansible team for their execution over the past two years and congratulate Red Hat for their leadership in cloud and recognition of the growing importance of DevOps via this acquisition. I believe the addition of Ansible to its cloud management portfolio will help to place Red Hat at the forefront of cloud and DevOps.”

    Worldwide Cloud Systems Management Software Forecast Update, 2015–2019 – July 2015, IDC #257928

    “According to IDC’s worldwide analysis as of July 2015, the worldwide cloud systems management software market achieved total revenue of $2.3 billion in 2014, representing growth of 29.9% from 2013. The market is currently forecast to grow to $8.3 billion in 2019 at a compound annual growth rate (CAGR) of 28.9% for the 2014–2019 period.”

    About Red Hat, Inc.

    Red Hat is the world’s leading provider of open source software solutions, using a community-powered approach to reliable and high-performing cloud, Linux, middleware, storage and virtualization technologies. Red Hat also offers award-winning support, training, and consulting services. As a connective hub in a global network of enterprises, partners, and open source communities, Red Hat helps create relevant, innovative technologies that liberate resources for growth and prepare customers for the future of IT. Learn more at http://www.redhat.com.

    Forward-Looking Statements

    Certain statements contained in this press release may constitute “forward-looking statements” within the meaning of the Private Securities Litigation Reform Act of 1995. Forward-looking statements provide current expectations of future events based on certain assumptions and include any statement that does not directly relate to any historical or current fact. Actual results may differ materially from those indicated by such forward-looking statements as a result of various important factors, including: risks related to the integration of acquisitions and the ability to market successfully acquired technologies and products; the ability of the Company to compete effectively; the ability to deliver and stimulate demand for new products and technological innovations on a timely basis; the effects of industry consolidation; delays or reductions in information technology spending; uncertainty and adverse results in litigation and related settlements; the inability to adequately protect Company intellectual property and the potential for infringement or breach of license claims of or relating to third party intellectual property; risks related to data and information security vulnerabilities; ineffective management of, and control over, the Company’s growth and international operations; fluctuations in exchange rates; and changes in and a dependence on key personnel, as well as other factors contained in our most recent Quarterly Report on Form 10-Q (copies of which may be accessed through the Securities and Exchange Commission’s website at http://www.sec.gov), including those found therein under the captions “Risk Factors” and “Management’s Discussion and Analysis of Financial Condition and Results of Operations.” In addition to these factors, actual future performance, outcomes, and results may differ materially because of more general factors including (without limitation) general industry and market conditions and growth rates, economic and political conditions, governmental and public policy changes and the impact of natural disasters such as earthquakes and floods. The forward-looking statements included in this press release represent the Company’s views as of the date of this press release and these views could change. However, while the Company may elect to update these forward-looking statements at some point in the future, the Company specifically disclaims any obligation to do so. These forward-looking statements should not be relied upon as representing the Company’s views as of any date subsequent to the date of this press release.

    Red Hat and the Shadowman logo are trademarks of Red Hat, Inc., registered in the U.S. and other countries. Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries. The OpenStack mark is either a registered trademark/service mark or trademark/service mark of the OpenStack Foundation, in the United States and other countries, and is used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

    View source version on businesswire.com: http://www.businesswire.com/news/home/20151016005177/en/

    SOURCE: Red Hat, Inc.

    Red Hat, Inc.
    Media Contact:
    Stephanie Wonderlick, +1-571-421-8169
    swonderl@redhat.com
    or
    Investor Relations:
    Tom McCallum, +1-919-754-4630
    tmccallum@redhat.com

    Copyright Business Wire 2015

    For Red Hats take on Why Ansible?

  • Announcing Orca v2.0: Application Configuration Automation for Linux and Windows

    Austin, TX September 17, 2015 – www.orcaconfig.com

    Announcing Orca v 2.0: 
    Application Configuration Automation with New Linux Support and New Job Summary Views for Reporting and Compliance

    Orca now supports Linux.

    With its version 2.0, Orca introduces Linux support for Apache, MySQL and System Services with even more coverage to be announced. Now organizations with mixed Windows and Linux environments can centrally and securely automate their application and middleware configuration management and workflows.

    Orca meets a previously unmet need.

    Customers who need continuous delivery and increased software velocity have many well-known application release automation options available to them. Similarly customers who require server and OS-layer configuration management have several reliable, purpose-built commercial alternatives.

    But the ongoing configuration management at the middleware and application layers has been a DevOps area that has stubbornly resisted drag and drop workflow automation, until now…until Orca.

    No compromises

    Now, Orca users 1) automatically detect drift, 2) automatically correct drift and 3) bulk-deploy app and middleware configuration changes across hundreds or even thousands of servers in both Windows and Linux environments.

     

    Orca delivers
    continuous configuration of apps and middleware at enterprise scale.

    New Job Summary Views for simplified reporting and compliance. New levels of transparency.

    Orca 2.0 users can now see manager level summaries which provide a single pane of glass view for audits and compliance reporting, a powerful new level of transparency and time-savings.

    While Orca has always reported the full detailed history of a job including the outcome, configurations affected on each node, timing, approvals and workflows, version 2.0 also logs whether a job had been validated prior to execution. These new management views and enhanced job logs reflect Orca’s commitment to taking the pain out of audits, compliance and reporting.

    __________________________________________________________________

    Team Orca has created powerful DevOps tools before

    Team Orca founders are veterans at improving and automating once-painful IT processes. They started Build Forge (now part of IBM) to accelerate software delivery through build process automation. Later they started VaraLogix (now part of BMC) to take the risk and uncertainty out of web application deployment. Now Team Orca is excited to improve life for IT teams by streamlining time consuming, money wasting, overly complex configuration processes that many have just taken for granted for too long.

    For more information on Orca or to request a product demo, contact us at teamorca@orcaconfig.com or visit www.orcaconfig.com.  Follow @orcaconfig on Twitter.