devopsy.kinsta.cloud

Tag: Configuration Management

  • DevOps Survey Says! State of DevOps, Reliance on Scripting and IT Automation

    DevOps Survey Says! State of DevOps, Reliance on Scripting and IT Automation

    What our surveys told us about the state of DevOps, Reliance on Scripting and IT Automation

    DevOps Survey Results: Scripting & IT Automation

    A lot of IT Operations teams including application owners, configuration managers, middleware specialists and database administrators are managing infrastructure configuration change with manual processes, spreadsheets and scripts. They are spending a lot of time writing and maintaining a lot of scripts. Even with all those scripts, spreadsheets and processes and the resources they consume, teams are still not getting the visibility, control and error-proofing that they require.

    That is the message from five recent surveys conducted by Orcaconfig among IT industry pros. Perhaps these results should not be that surprising. But several years into the DevOps and IT automation movements, there is still plenty of room for improvement.

    About one-third of respondents said they spent more than half of their time writing and maintaining scripts.

     

    In complex application environments with multiple relationships and dependencies between applications, databases, middleware and operating systems, “changing this can easily (and unwittingly) change that.” Gartner refers to this as a domino effect. So, scripting to deploy changes becomes more and more tricky and thus, requires more and more time to do, test, redo and retest.

     

    		  what_percentage_of_time_is_spent_writing_or_maintaining_scripts_-_survey_from_orcaconfig-com_2

    Because of the risks involved with release or configuration-related scripting errors in production environments, some organizations hand these typical operations responsibilities to developers. The question is worth asking: Is release and configuration-released scripting the best use of Dev or Ops’s time?

     how_do_you_maintain_scripts_when_the_author_is_no_longer_available_-_survey_from_orcaconfig-com_3 With all these scripts holding key configurations together, are organizations at risk of “losing the recipe” if key employees leave? Apparently so. In our surveys, 30 percent of respondents admitted, “It’s a problem, we don’t really have a solution in place,” when asked about maintaining the spaghetti-works of scripts if some of those key employees suddenly leave the organization. Nearly half mentioned that they rely on transfer of information (TOI) before a key employee leaves.

     

    Employees exit companies for a number of reasons and some are in a bigger hurry than others to move on. Does TOI provide all the safeguards needed for the enterprise?

    Scripting might consume a great deal of IT resources and introduce a considerable risk with the loss of key talent. But does it at least accomplish the functionality that teams need? The next few charts provide insight to how well scripting achieves the visibility and error-proofed automation that teams need.

    Ecosystem Visibility

    Configuration Drift Detection

    For performance, security and audit reasons, organizations have an ongoing need to maintain configuration compliance in their application ecosystems. So detecting configuration drift is essential. Automatically detecting configuration drift is the goal. Despite complaints about the method, approximately half of respondents relied on scripting to accomplish drift detection.

    		  how_does_your_organization_detect_configuration_drift_in_complex_application_database_middleware_environements_-_survey_from_orcaconfig-com_2

     

     how_do_you_know_which_databases_are_being_used_by_which_applications_across_your_ecosystem_-_survey_from_orcaconfig_2 Mapping Databases to Applications:

    Sometimes IT operations are asked simple sounding questions such as, “What are all the applications that use this database?” and vice versa, “Which databases support this application?” Once again, nearly one-third of respondents admitted, “We really don’t know which databases are being used by which applications. Wish we did.” Another 36 percent relied on scripting or other manual processes to get that answer.

     

    Is it reasonable (in 2017!) to still rely on scripting to get basic information about interrelationships between applications, databases and middleware? Is it acceptable to operators, managers and auditors simply do without this information? Will Visio and similar static files always provide up-to-date information that IT Operations needs?

    Automation & Error-Proofing

    Environment-Aware Releases
    When moving an application through pre-production stages and into production environments, Release Managers want to ensure that the new release will just work … as planned … drama free.  This requires among other things that

    1. the configurations are up to date and production-ready, and
    2. that those business-critical applications are promoted simultaneously with their production-level configurations.
    		  how_does_your_organization_achieve_environment_aware_releases_

     

    Thirty-eight percent of respondents said they relied on scripting and other manual processes to try to accomplish environment-aware releases.  To ensure ‘everyone is on the same page’ many organizations use multiple planning meetings, sharing and updating spreadsheets and SharePoint files with (hopefully) the latest configuration information. Even among this group, respondents commented that scripting just does not work well for them.

    scripting_does_not_work_well_for_environment_aware_releases_-_survey_from_orcaconfig

    Despite the security, compliance and performance implications of configuration and release problems, 15 percent of survey respondents admitted they “really don’t achieve environment-aware releases.”

    Scripting isn’t Free; IT Ops Needs More

    Scripting is quite naturally the go-to method for many application owners and IT Ops teams. The cost of scripting or even finding and fixing a scripting-based error hardly ever appears clearly in budgetary line items. In the moment, it can feel like it is free. But over time, maintaining scripts and homegrown tools can build a hidden but costly mountain of technical debt. It might well be worth these costs and risks if scripting effectively resolved ongoing operations needs such as ecosystem visibility and drama-free deployments. However, time and again our respondents said they lacked basic capabilities such as configuration drift detection, mapping applications to databases and middleware or ensuring environment-aware software releases.

    — Scott Turner

  • 7 Causes of Continuous Delirium

    7 Causes of Continuous Delirium

    When we think of CD, we typically think of continuous deployment as a result of continuous delivery, which is a goal of DevOps.

    In this article, I coin the phrase, “Continuous Delirium,” to mean unending confusion or bewilderment in development environments. There are probably several examples that could fit the bill here, but for now I offer seven real-world examples. I bet you’ve seen or heard about at least one of these.

    Now that I have your attention, here are seven causes of Continuous Delirium, each with cures rooted in DevOps:

    No. 1: Insufficient Configuration and Build Management

    Insufficient configuration and build management in software builds leads to the same or similar software impurities rearing their ugly heads again and again. You build, test, discover the defect, fix it—or so you think—build again, retest and boom: The same coding error or software malfunction recurs.

    “You can cure this malady with a rational approach to the build and configuration management process, checking software in and out with established procedures for each software module using a tracking sheet that identifies the revision of the sub-modules for the entire software product,” notes Jon M. Quigley, founder of Value Transformation, a product development consultancy and training firm based in Lexington, North Carolina.

    No. 2: What’s Going On? Who’s Doing What?

    When there is no reasonable understanding of the work, who is doing what work and who is responsible for what—and there is no consistent measure of what is good work or bad work—you have a breeding ground for anarchy.

    “You cure this ill by establishing what constitutes the appropriate quality of work as well as by periodically reviewing the state of the objective with the receiving or depending entity,” says Quigley. Make sure everyone is on the same page with the same definition of what constitutes quality work and make sure the objectives have not changed. Also, ensure these goals are also clearly understood by all.

    No. 3: Confusing Clean Daily Compiles with Testing

    When you do not test the software as early as possible and throughout the development process, you can’t really say it has no bugs. Error-free compiling is not error-free software. Software compilation does not have the same investigative effect as using the software in the customer environment.

    “Test throughout development using complimentary testing approaches such as testing to requirements, combinations of stimulus testing and exploratory testing, for examples,” says Quigley.

    No. 4: Planning Too Far Out to Control

    The further you try to plan things out into the future, the less control you have as you follow the project through to conclusion. “When we treat a plan as though we know everything associated with the project for the next 12 to 18 months, we are fooling ourselves,” says Quigley. By breaking projects into bite-sized increments, you can better assure successful completion of sub-projects and of the project as a whole.

    No. 5: A Lack of Customer Involvement

    Customer involvement is critical to customer satisfaction. “By getting the product or a prototype into the customers’ hands for exploration, you can retrieve feedback for developers,” says Quigley. This may expose the project to risk in the form of the potential for a great deal of change at the customers’ request, but the other side of the coin is the risk that nothing changes and the customer doesn’t use the product at all.

    “Rather than try to deliver one incarnation of the product at some future date, break down the delivery into separate iterations that meet prioritized customer expectations one by one as you refine the product and add features as you go along,” says Quigley.

    No. 6: Isolating Change Management from Customer Involvement

    Customer involvement means there will be change. Change requires change management. There is a given—and correct—assumption that customer involvement will trigger change management at some point. You cannot isolate the one from the other.

    Further, just as you can better address customer requests for changes by breaking the project into smaller subsections, so also can you manage budget through change and change management. Project subsections enable you to see the need for change a little at a time so you can create change in a more targeted and cost-effective manner.

    No. 7: Forget About Collaboration—at Your Own Peril

    It is necessary for DevOps team members to collaborate at all levels, except those where the work on software is so minor that it wouldn’t benefit from shared thought. To maintain development as an expedient process that benefits from all stakeholders, open communications and collaboration must reach and pull from all team members. Otherwise, the project could suffer from a lack of critical input.

  • FLAP, Part 3: Full Data Center Provisioning

    FLAP, Part 3: Full Data Center Provisioning

    In the first two parts of this series (Part 1, Part 2), we covered server provisioning and application provisioning. Knowing a bit about each of these tools is useful (although one blog is hardly a thorough evaluation of strengths and weaknesses—I strongly suggest you do more research), knowing how they work together is the point of full layer automated provisioning (FLAP). Automating one or the other helps, but automating both—and integrating that automation—brings us to the level of “Oh, engineering needs a new test environment, and it has to be internal …” and, with a push of a button, it is delivered. That should be the long-term end goal for your organization, so staff time is free to attend to some of the many other issues that plague any given IT organization.

    The thing is, these tools combine in both better and worse ways. Some are designed to work together as if one product; some take some work to get going but the combination adds value once connected; and some combinations are painful to put together and almost never are worth the effort.

    One thing you’ll note is a repeated discussion of OS support for combined solutions. The reason we address it here, even though we have limited words and it’s already been mentioned in product write-ups, is simple: The limitations of these combinations are compounded. That is, if the server provisioning tool doesn’t support Windows, then the complete solution does not, no matter what the application provisioning tool does. This applies both ways, and is an important consideration for most shops, so we mention it here.

    Tools Built to be Together

    First off, we’ll take the easy ones. These are the combinations that were designed to work together, and do so pretty well. They vary in maturity level, but otherwise, they’re good options if they fit into your environment.

    Razor and Puppet

    This is the easy one. Razor was built to be the server provisioning part of Puppet. While the solution set is relatively new, and it shows in the installation phase (which has several manual configuration steps both before and after Razor install), it is maturing rapidly, and the two dev teams work pretty closely together. This is one of only two solution sets that uses a single UI for all provisioning—in this case the Puppet UI. Support for operating systems is broad, including all versions of Linux and Windows to boot. (get it? To boot?) If your data center is highly heterogeneous, or you are already a Puppet shop, it is worth looking closely at this combination. You just have to keep in mind that it is improving at a rapid rate, so those things you don’t like likely will change soon.

    Satellite + Puppet + Foreman

    As of version 6.0, Satellite is a collection of tools knitted together that include Puppet with Foreman. This means that Red Hat has a vested interest in making certain the two tools work well together. And they certainly seem to. While the operating systems support is limited to Red Hat OSes, the solution is pretty rock solid, and like Razor and Puppet, it is improving at a rapid rate since the switch to this new platform. The UI is independent of the tools underneath, and this is the other solution that offers a “single pane of glass” for all installation activities. The one catch with Red Hat, as mentioned before, is that the functionality of underlying systems is only supported when used with Satellite. How that fits into your organization’s plans is up to you.

    Close Enough to be Second Cousins

    There are some combinations that, while not officially interdependent, have a long history of mutual support, and thus make them strong combinations. These tools tend to come with straightforward directions to make them work together, and those instructions generally work well. Once paired, they can manage complete automation in a relatively integrated fashion.

    Note that these combinations are not even a little exclusive. They are pairings the project teams saw made good sense, and have grown out of closeness. Both sides of these solution sets interoperate with other tools (see the next section).

    Ansible + Cobbler

    Ansible and Cobbler both trace their genesis to Red Hat, and they share some employees/team members—and have for a long time. That makes it natural that the two are closely integrated. Before Ansible started discussing all of the other server provisioning tools out there, it already had Cobbler integration.

    As one would expect, there is Ansible setup, Cobbler setup, and then integration. But once combined, Cobbler can do for bare metal, Ansible can do for cloud, and together they provide a full-stack solution. Since both support most operating systems, the final solution does, too.

    Juju + MaaS

    Juju and MaaS have interoperated for a long time. Both are projects of Canonical, so it is no surprise that their interoperability continues. Years ago this author used them together and it was … difficult. But that was years ago, and just in the last year both projects have made strides in documentation and ease of use. Like most solutions in this category, there are separate installations and then integration configuration. Since both support a large number of operating systems, this solution can manage the full data center also.

    Their traditional home, and the one you’re most likely to be comfortable with them in for the short term, is Ubuntu-heavy shops. But they do support most platforms out there, so it’s worth the time to look into them even for non-Ubuntu shops.

    The Extended and Mixed Families

    Then there are the ones that have not forged solid one-on-one relationships, some because they are forging a separate path and some because they want to interoperate with everyone. Note that some of the above systems meet this category—Puppet is integrated with most of the server provisioning tools out there—but due to space considerations, we’re not going to go over those products again here. This list contains both application provisioning and server provisioning tools not mentioned above.

    Chef

    Chef has put the bulk of its focus on cloud and virtualization, with the notable exception to this trend being in AIX, where it does support server provisioning. “The bulk of its focus” is not absolute, though, and that’s on purpose. Chef has had presenters at the annual conference talk about using it with server provisioning tools, so it isn’t unaware of the integrated solution space, just that’s not where their focus has been.

    SaltStack

    The Salt crew is happy to support everyone. While they don’t talk loudly about whom they are integrated with, the product is in use with most major server provisioning tools out there. As mentioned in the SaltStack write-up in part two of this series, cloud integration is pretty broad also, making Salt perhaps the most versatile of the application provisioning tools with regard to full data center automation.

    Stacki

    Originally built to interoperate with SaltStack, Stacki (disclaimer: this author’s employer) has moved on to support most of the availableapplication provisioning tools. The catch with Stacki is that some are supported with sample integrations and video tutorials at the open source layer, while others require a license and engagement of Stacki core engineers to obtain support. So there is a video showing Ansible and open-source Stacki working together and talking about the integration, but it would require a paid license and negotiation to get SaltStack or Chef with Stacki. Because of the way Stacki is designed, it is perhaps the easiest of all these products to integrate—simply add the appropriate “Pallet” and tell Stacki to include it in installations. It is getting the correct pallet that requires licensing for some platforms.

    Conclusion

    Since any server provisioning tool that allows users to customize the install can have the agents for a given application provisioning tool be the last step of a given install, these overviews are at least a little bit arbitrary. To be precise, they are easier to use in the given configurations, but all application provisioning tools can be forced to interoperate with any of the server provisioning tools listed.

    The point of this series was really to help those looking into full data center automation quickly get up to speed on what’s available in the marketplace, and as much information as a few 1,200-word blogs will allow to help shorten the list to ones relevant to your organization. It is by no means complete, and there are issues and concerns with each of the products that only further research will bring to light, so don’t stop here.

  • 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.

  • Avoiding Common AWS Security Risks

    Avoiding Common AWS Security Risks

    According to IBM’s Cyber Security Intelligence Index, 95% of all security incidents involve human error. That’s beyond significant, and when rapidly deploying multiple iterations in a DevOps shop, that means there are lots of opportunities to fail.

    Our own independent analysis based on customer configuration data shows that security control mechanisms Amazon Web Services (AWS) makes available to its customers are not always being used consistently due to human error, creating unnecessary security exposures while operating workloads in cloud.

    In this article, we’ve highlighted the five of the most common AWS security risks detected in the first half of 2015, and share simple steps you can follow to address them.

    EBS volumes are missing optional EBS volume encryption…

    EBS volume encryption uses AES-256 and is a convenient mechanism for meeting data-at-rest encryption compliance mandates. An unencrypted EBS volume cannot be converted to an encrypted volume after creation. It is a setting that must be applied on creation of an EBS volume.

    EBS volumes contain no snapshots less than two weeks old…

    Snapshots are a low cost way to recover EBS volumes and they can be made while a system is online. We have seen a number of occasions where clients have benefited from snapshots in IR scenarios by enabling them to forensically analyze systems that had been compromised from recent snapshots in virtual private cloud sandboxes.

    Unused EC2 Security Groups…

    Keeping your EC2 security groups clean eliminates the risk that an unauthorized security group policy will be used by mistake to open attack surface. Often clients have had relatively new AWS users mistakenly launch EC2 instances using insecure security groups that lead to incidents. Practice good security hygiene and remove your unused EC2 security groups.

    Unused or unmaintained ELB Security Groups…

    Keeping your ELB security groups clean eliminates the risk that an unauthorized security group policy will be used by mistake to open attack surface. In large multi-tier architectures, ELBs frontend fleets of backend systems, and ELBs have security groups that should use authorized security group policy. Practice good security hygiene and remove unused ELB security groups.

    Global permissions to access TCP or UDP ports in a security group that is attached to an active instance/ELB…

    Restrict access to known static IP addresses or CIDR ranges within your control. Many clients have experienced scenarios where they found themselves conducting incident response efforts due to unauthorized EC2 instances that were launched using insecure globally accessible security group policies. Monitoring active security groups enables clients to shorten time to detection and time to remediation of firewall related vulnerabilities and enables clients to minimize attack surface.

    About the Author/Justin Lundy

    justinlundyJustin Lundy, CIO & CTO, co-founded Evident.io after leading Adobe’s Cloud Security efforts to identify, implement, and manage security controls and strategies during rapid adoption of the cloud at scale. He has spent more than a decade in the infosec industry, and is a subject-matter expert in multiple domains. Justin previously defended the castle at Adobe, MTV/Viacom, Sun, and CA.

  • Upcoming SANS Webinar: Orchestrating Security in the Cloud

    Upcoming SANS Webinar: Orchestrating Security in the Cloud

    Organizations are increasingly migrating to cloud-based services to handle sensitive data and business processes, meaning security teams need to carefully review and understand what security controls are available to help protect them.

    Given the pace of cloud adoption, security teams need to increase security automation efforts and employ tools that can better secure their cloud assets through improved visibility.

    SANS is hosting an informative webcast on Wednesday, September 23, at 1:00 PM EDT (17:00:00 UTC) to present the findings from a new survey that examines the organizational use of public and private clouds and outlines best practices for assuring a robust security posture.

    The webcast is scheduled in conjunction with the release of the highly anticipated SANS whitepaper on cloud security titled Orchestrating Cloud Security (PDF), written by analyst and network security specialist Dave Shackleford.

    The whitepaper presents the results from a survey 485 IT professionals who use different cloud providers and service models for a variety of business needs, including collaboration services, email, managed services, backups for disaster recovery, and other common use cases for cloud services.

    Although cloud services provide the functionalities businesses need today, the survey reveals that they also come with inherent security risks.

    The SANS survey found that 40% of the respondents acknowledge they process sensitive data in the cloud, and are facing increasing challenges related to access control, configuration management, compliance demands, overall visibility, and the implementation of security controls.

    New technologies are emerging as part of the security-as-a-service (SecaaS) model, which are security-oriented cloud-based services that integrate with provider platforms to protect data in cloud ecosystems.

    “Although many controls are still managed internally, SecaaS is emerging as a viable means to enhance security in the cloud environment. Security teams should start considering the use of SecaaS options when designing and architecting cloud security models,” the SANS survey notes.

    In the upcoming webcast, Shackleford will be joined by myself (Evident.io’s Andrew Maguire), Intel Security’s Margaret Diego, CloudPassage‘s Sami Laine, and Mark Painter from HP Enterprise Security to discuss:

    • How organizations use the cloud
    • What types of information they store in the cloud
    • What concerns they have about data security
    • How much they rely on cloud service providers and what difficulties they face
    • What security and data protection technologies they use in the cloud environment
    • How they manage cloud users
    • And much more

    The SANS survey clearly highlights and validates the challenges of cloud migration across companies of all sizes. Organizations moving workloads to cloud architectures such as Amazon AWS understand the flexibility and cost efficiencies gained – but often struggle with new best practices and the shared responsibility needed to maintain a secure cloud-computing environment.

    The porting of traditionalsecurity technology and Agent-based solutions used in the past do not translate well to cloud environments, leaving customers with too much data and poor visibility into critical service configuration or controls that could eventually lead to compromise.

    Webcast attendees will be among the first to receive the whitepaper. Join us Wednesday, September 23, at 1:00 PM EDT (17:00:00 UTC) for this timely and informative webcast!

  • 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.

  • 5 Steps for Black Friday, Cyber Monday and Holiday Readiness

    5 Steps for Black Friday, Cyber Monday and Holiday Readiness

     5 Steps for Black Friday, Cyber Monday and Holiday Readiness

    Ho. Ho. Ho. It’s that time of year again. Seriously. It is.

    It’s too late for April Fools but it’s definitely not too early for Holiday ecommerce readiness planning. In fact now is the perfect time to get your ecommerce house in order well before the planned lockdowns of your critical web based applications.

    Balance is important in any holiday ecommerce planning. On the one hand, you obviously couldn’t and shouldn’t make too many significant changes to your ecommerce environment too far into November. But you also need to actively seek out and evaluate new processes and new tools that will improve your customers’ and your employer’s experience during the upcoming holiday season. Making too many or too few changes can land you in hot water. So for starters, perhaps we can agree that a reasonable goal is to avoid earning hall of shame status at http://www.isitdownrightnow.com/

    Christmas Downtime can have multiple root causes but can often be traced back to

     

    1)      Sins of Omission: Lack of proper planning for the anticipated burst in traffic on Black Friday, Cyber Monday and the entire holiday season and

    2)      Sins of Commission: Really frustrating situations where you were trying to upgrade, trying to improve, trying to modernize but sure enough, “changing this breaks that”. You don’t want to spend the holidays remediating one problem after another. Do you?

    Rudolph the Remediation Reindeer from OrcaConfig

     

    The focus of the remainder of this article is to help you with the latter – those seemingly innocuous, “routine” changes to your ecommerce app and all of the related apps, databases and configurations in your ecommerce ecosystem.

    So what’s a DevOps team to do?

    Life is tough enough dealing with “unknown unknowns.” Let’s not make it any tougher by failing to plan for the “known unknowns”. So here are a few keys that we have picked up over years working with e-tailers and retailers who prioritize Christmas ecommerce:

    1. Blackout Periods: Make sure your automation tools know you’re in a blackout period. Whether you use homegrown tools, commercial automation tools, or a combination thereof, users should not be allowed start automated jobs against Production systems during the holiday blackout without approval.
    2. Role Based Access: If your automation tools don’t support blackout periods (and probably even if they do), now is the time to double check that the role based permissions in each tool are set up correctly and adhere to your organization’s guidelines. The most well intentioned engineer can accidentally select Production as a target environment for an automated job, and if they have permission to do so, it can cause an accidental catastrophe during a business critical time.
    3. Restrict Direct Access: Most organizations have an initiative to lock down all their Production servers from direct access, and if you don’t it’s time to add it to the docket. An engineer logging directly into a server to make a seemingly innocuous configuration change to one application can easily bring down another application in the process. Now not only do you have an outage, you have no way of knowing why the outage occurred and who caused it.
    4. Monitor Changes, Not Just Performance: Don’t just monitor the performance of your Production systems, monitor everything you possibly can including configuration changes. Especially if your engineers still have direct access to Production systems, it is imperative you have the tools and processes in place to monitor for configuration changes to the environment.
    5. Experiment Now, Well Before Show Time: All year you’ve been going to conferences, chatting with your colleagues, and in general hearing about all the new tools you should try out. Now is the time to do it! Plenty of vendors offer free trials of their solutions. Some even offer free, full featured trials (ahem). Make good use of your time now by evaluating new time-saving, error-proofing solutions before the calendar catches up with you.
  • Ansible Best Practices : Automation, Provisioning and Configuration Management

    Ansible Best Practices : Automation, Provisioning and Configuration Management

    What is Ansible?

    Ansible is an IT automation engine, and a trouble-free model-driven configuration management and command execution framework. Made for multi-tier deployments, it designs your IT infrastructure by describing how all of your systems are interrelated instead of just managing one system at a time. Written in Python, Ansible does not use any agent. It makes uses the SSH server on the target, and no additional custom security infrastructure is required, making it easy to deploy.

    Ansible comes up with following uses:

    1). Normal configuration management

    • Creates system files through the medium of templates
    • Manages software installation with the help of yum, apt, gem, or the like
    • Manages services or daemons such as start, stop, enable, disable

    2). Orchestration tasks

    • Removing server from load balancers
    • Disabling monitoring or altering
    • Perform deployment of your code by git

    3). Continuous integration

    • Deploy code to QA servers
    • Run tests and promote software to production if tests pass

    How is it different?

    Ansible is a configuration management, deployment and an ad-hoc task execution tool, all in one. It does not require daemons or any other software to start the remote machines’ management. Since it uses the SSH, it easily passes a security audit, and can be used in places resistant to run a root-level daemon with a custom PKI infrastructure.

    The Ansible modules can be written not only in Ruby or Python, but in any language efficient enough of returning JSON or key. In this way, Ansible manages to sidestep the popular Python vs Ruby language war, and is of interest to people who like both or neither of them.

    Ansible Architecture:

    ansiblenew

    Coming with a simple framework, Ansible connects with your nodes and pushes out small program termed as Ansible Modules, which are considered to be the workhorse of the system and are responsible for performing all heavy liftings. These programs are written to be resource models of the anticipated position of the system. Thereafter, Ansible carries out these modules upon the SSH by default and eliminate them when finished.

    Without using servers, daemons and databases, your library related to modules can be inherited in any machine, thus giving the advantage of working with your favorite terminal program, a text editor, and most likely a version control system to keep a track of alteration to your content.

     

    SSH keys your biggest companion

    Though passwords are supported, the finest method to practice it is by using the SSH keys along with SSH-agent. The root logins are not required; you can login as any user. Ansible ‘authorised-key’ module helps in controlling which machines can access or which hosts. You can also use other available options like Kerberos or identity management systems.

    Management of your inventory in simple text files

    Ansible by default uses an INI file to represent the machines being managed. These files help in placing all of your managed machines in groups of your own choosing. In order to add up new machines, you do not require any additional SSL signing server. So by no means, there will be a problem in deciding about why a particular machine didn’t get linked up due to obscure NTP or DNS issues.

    Ansible can also be plugged into another source of truth, if available in your infrastructure like drawing inventory, group, and sources suchlike EC2, Rackspace, OpenStack, etc,. As soon as the inventory hosts are listed, variables can be assigned to them in simple text files in a subdirectory called ‘group_vars/’ or ‘host_vars/’ or directly in the inventory file or, as already mentioned, you can use the dynamic inventory to pull inventory from the data sources like EC2, Rackspace, and OpenStack.

    Playbooks, a simple and powerful automation language

    Playbooks are Ansible’s configuration, deployment and orchestration language. They can explain a course of action you want the remote system to apply, or a set of steps in a general IT process.

    At a fundamental stage, playbooks can be used to manage configurations and for deployments of the remote machines. At a more advanced level, they can sequence multi-tier rollouts involving rolling updates, and can delegate actions to other hosts, interacting with monitoring servers and load balancers along the way. Most importantly, the language remains readable, transparent and is developed in a basic text language. You don’t need to declare explicit ordering relationships or write code in a programming language. There are ample of ways to organise playbooks and the files they include.

    Widen up Ansible: Modules, Plugins and API

    Ansible modules can be written in any language that can return JSON, such as Ruby, Python, Bash, etc,. The inventory can also plug into any data source by writing a programme that speaks to that data source and returns JSON. There are multiple Python APIs for spreading Ansible’s connection types callbacks — SSH is not the only transport possible — and even for adding new server side behaviours.

    AnsibleWorks (AWX)

    AnsibleWorks, which also sponsors the Ansible community, also produces the AWX. It is a web-based solution to make Ansible simpler, and to provide a trouble-free usage for the IT companies. It is also designed to be complete all kinds of automation tasks.

    AWX permits you to regulate the access and even allows sharing of SSH credentials, without someone being able to transfer those credentials. Inventory can either be graphically managed or synced with a wide variety of cloud sources. It keeps log of all your jobs and integrate them with LDAP. It also has an amazing browsable REST API. If required, the command line tools are also available for easy integration with Jenkins.

    Conclusion

    Ansible’s simplicity and ability to decrease the complexity of other tools has made it a reliable applicant for your environment. Its foremost concern is on security and reliability. It uses OpenSSH for transportation, and the language is designed around auditability by even those who are not familiar with the program. Ansible is suitable enough for managing both small setups with a handful of instances as well as the enterprise environments.

  • 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.