Category: Features

  • The DevOps Donkey represents the rest of us

    The DevOps Donkey represents the rest of us

    Yesterday I wrote about a session that I wanted to see by Michael Cote’ called The Coming Donkey Apocalypse. In my article I said on its face I didn’t agree with calling the mainstream adopters Donkeys. I also felt that their adoption would not result in an apocalypse.  I also said that you can’t judge a book by its cover and you can’t judge a session by its title and abstract. I was really looking forward to see what Cote’ was getting at in this session.

    So I eagerly grabbed a near front row seat when he took the stage right after Damon Edwards excellent opening keynote. One of the first things Michael addressed was his use of the term Donkey. Actually he started off with his conclusions which I thought was a very effective way of delivering a session as it focused the audience on what the takeaways are supposed to be. Anyway Michael says that donkeys are hard working beasts of burden, gets no respect, has to do more with less and represents the “rest of us”.  The donkey as a jackass connection is not part of this. It is more that while Unicorns are magical, horses are actually regal but most of us are more like donkeys.  Put better as one of Michael’s co-workers said “the donkey is real people with real problems”. DevOps Donkeys are what is coming as more mainstream adoption of DevOps takes place.

    Michael had a lot of data showing that DevOps adoption is very much on the rise. Multiple sources showed a continuing further penetration by DevOps in the marketplace.  Also the idea of what DevOps is understood enough to  move on beyond that. The jist of the message was that the people attending the session had to do what they could to help these donkey’s in their adoption and journey to DevOps.

    But what about the apocalypse? This is important.  It is not that “bending DevOps to their will” is the apocalyptic event. Rather the apocalypse is the fact that according Ian Head of Gartner says that “by 2018 90% of I & O organizations attempting to use DevOps without specifically addressing their cultural foundations will fail.”

    This is something I agree with. All too often the tendency is to “bag dive” into tools and features. While everyone gives lip service that DevOps has a strong cultural element which trumps tools, to too many people it is just lip service. They will talk about the cultural aspects then go run out and buy tools to implement.  Then they wonder when their DevOps projects fail.  That is apocalypse we need to avoid.

    I spoke with Cote’ briefly after his session and clarified some of his message and thoughts. I am embedding a slide share of his presentation from slideshare. Though marked draft, it seems to be complete. I will update it when a later copy becomes available.

    So the take away from me is something that I have seen time and time again. How do you help donkeys or anyone else implement a cultural foundation for DevOps in their organization. This is a different problem than picking the right tool. In talking with Michael he mentioned that transforming corporate culture is something that companies such as McKinsey and Bain literally wrote the book on.

    The problem is can donkey’s afford McKinsey or Bain? Probably not. So how can they get practical, affordable counseling and advice on transforming their culture.  I don’t know any companies offering that today.  But if any of you do, leave a comment so perhaps others looking for this will be aware of them.

    Anyway, it was a great session by Michael Cote’ in a day full of great sessions and DevOps learning in Austin today.  I am looking forward to another great day tomorrow.

  • Netskope Draws Strength from DevOps In Support Of Scrum Development

    Netskope Draws Strength from DevOps In Support Of Scrum Development

    Netskope keeps enterprises and their data secure despite the unbridled mix of approved and unapproved mobile apps in the market and on employee devices. Employees use unapproved mobile apps (BYOA) on their BYOD smartphones, tablets, and laptops when connected to networks away from the enterprise. IT professionals are keenly interested in tools that help them to have visibility into these apps and devices and to secure them.

    Enterprises face many issues with mobile apps. They confront challenges where data location and access as well as security are concerned when complying with PCI DSS, HIPAA, SOX, GLBA, FISMA, FERPA, and the ISO standards. Netskope works to control app usage, protect enterprise data, and maintain compliance on various endpoints whether the device is on premise or remote / mobile, all in real-time.

    “Netskope uses a distributed policy enforcement model that lets your people use these apps securely so you don’t have to block them completely,” says Abhay Kulkarni, VP of Engineering, Netskope.

    Netskope’s Security Duties Dictate Its Development Path

    “We do not follow Continuous Delivery,” says Kulkarni. Here are two of the many reasons for that.

    First, Netskope’s customers demand that software releases are predictable. “Our customers are large enterprises that want predictable change windows so they can ensure that they make the necessary changes on their side or that they prepare for our updates,” says Kulkarni.

    Second, because Netskope is a SOC-1 Type-II and SOC-2 Type-II certified company, it must comply with the requirements that comprise these certifications. Tightly-knit change management is critical to SOC certification. “As we do each change, we need to make sure that all changes meet the security, availability, integrity, and confidentiality criteria of these certifications by testing the entire product end-to-end,” says Kulkarni.

    But Netskope follows other DevOps principles such as using its own adaptation of a well-accepted source control workflow model as well as an automation model, a model for bootstrapping machines, and also models for software installation and change management.

    Netskope performs a balancing act between complying with SOC-1 and -2 trust services criteria and principles and maintaining rapid feature development. On the one hand, they manage to limit what individual developers can do on production machines—many times disallowing access. On the other hand, they use Sumo Logic to enable their coders to peruse anonymized logs in order to gauge how the service they instantiated is working.

    Goals, Tools, & Challenges

    “The key goal for Netskope’s DevOps approach is to ensure developer responsibility for running, monitoring, and scaling their services,” says Kulkarni. Netskope’s developers and operations staff work together from design through development while complying with a common framework, which helps in resolving development issues and brings consistency to data center operations, according to Kulkarni.

    Netskope holds developers individually accountable for making their software ready for automated deployment. To help with that, Netskope uses familiar tools such as Ansible, which helps Netskope to automate everything in production. “Right from bootstrapping a machine to changing network configurations, we automate all commonly repeated tasks,” says Kulkarni.

    Netskope deploys Sumo Logic agents using Ansible as a part of bootstrapping so that machines are configured from the get go to send logs to Sumo Logic. “Each service has standard logging methods that allow Netskope to create performance dashboards and to track errors,” says Kulkarni. Netskope uses a number of other tools that are commonplace in DevOps, such as Nagios, a monitoring tool and various external monitoring tools for tracking end user performance.

    The biggest challenge for Netskope was not in tooling but in building a DevOps culture where developers lead the charge in responsibility for quality, error-free operation of their services. “In a non-SaaS world, developers ship a version of their product and celebrate. However, shipping a SaaS product is just the beginning. There is really no celebration since you are now responsible for the upkeep of the services,” explains Kulkarni.

    A Trip Through Netskope’s Development Process

    Netskope starts with a Scrum sprint planning meeting where in they decide what features to address for the given sprint. “We try to be realistic about our expectations in delivering code in a sprint by applying quality criteria—i.e. we expect code to be of a certain quality or else we cannot deploy it,” says Kulkarni.

    Then developers bundle various modules on a single branch, which they test for functionality, security, performance, and integration. As the modules and the branch increase in stability, the developers upgrade them from one stack to the next until everything is deemed fit for a production deployment, explains Kulkarni.

    Results

    “Often we see proactive notifications from developers about issues they see in production. Detecting problems before our customers see them is a key benefit of the DevOps model,” says Kulkarni.

  • Security, DevOps and the shift to a software supply chain

    Security, DevOps and the shift to a software supply chain

    Last week at the DevOps Connect event held in conjunction with RSA Conference, the security and continuous delivery worlds united to deliver an overarching message that security teams that can embed themselves in DevOps patterns can not only secure IT at speed, but they can actually contribute to a more reliable, repeatable and higher quality release cycle.

    “DevOps extended the value of Agile so that we went from just continuous integration to continuous integration and continuous deployment,” says Josh Corman, CTO of Sonatype. “If the three measures of any software manufacturing lifecycle is speed, efficiency and quality/risk,  then I think this Rugged DevOps era ideally allows you to go even faster, be even more efficient because of fewer break fixes and faster mean time to repair and better quality and lower risk.”

    To read more about security and DevOps, check out our eBook on Rugged DevOps. 

    Corman and Gene Kim, author of The Phoenix Project, developed on this idea in their talk, which pushed the thought that the ultimate Zen state of software delivery to strive for is a software supply chain.

    “The way we can get more safety and security into digital infrastructure, is to move to the ultimate evolved posture of software development as a supply chain,” Corman explains. “This makes you even faster than DevOps–even more efficient and with higher quality and risk mitigation without tradeoffs.”

    The idea of the software supply chain further builds on the lean manufacturing principles of W. Edwards Deming, who many in the Agile and DevOps worlds see as the spiritual grandfather of these movements.

    “If you take Deming to his logical consequence, we’re going to start paying attention to the quality of our suppliers, the quality of our supply and the traceability and visibility of which parts went were, such that when there’s another Heartbleed, we can do a prompt and Agile response,” he says, explaining that that avoiding known bad parts, such as a bad version of struts in car manufacturing or a faulty SSL component like the one that caused Heartbleed, “will make you keep top speed, halve your blowouts, faster meantime repair, better traceability and make the auditors go away with less pain”

    Security teams have traditionally been known as roadblocks rather than speed enhancers to development processes. But looking at it from the perspective of creating an effective software security supply chain, security actually plays a role in further speeding up production if it is helping organizations depend on higher quality components of production code and the code running infrastructure.

    “If we get better at our component selection and our traceability of what we’re using where, we can reduce the number of break-fixes or reduce the number of unplanned unscheduled work,” Corman explains

    He emphasizes that security debt tracks roughly with technical debt and CISOs should be having conversations with DevOps teams to that end. In the end security work pays down principle on technical debt, making it possible to spend more time writing code and less time on rework

    “I’d love to give us a more defensible opportunity which embraces what devops already cares about and doesn’t articulate how we can make them safer, instead articulate how we can make it faster and more efficient,” he says.

    As security pros start to do so, they might be surprised at their reception by the developers and operations folks. As Kim explained in their talk, in the end everyone does want the kind of quality that a cooperative security team can bring to the DevOps equation.

    “When security imposes itself on day-to-day DevOps processes, dev and ops say ‘thank you,’” he says.

  • Q & A Cloud Security Alliance’s Jim Reavis on securing the IoT

    Q & A Cloud Security Alliance’s Jim Reavis on securing the IoT

    Cloud Security Alliance CEO and co-founder, JIm Reavis

    Earlier this month at the RSA Conference 2015 the Cloud Security Alliance released security guidance for the Internet of Things (IoT). The guidance came out of the CSA’s Mobile Working Group — IoT Initiative. Many security researchers I’ve interviewed in recent years have repeatedly cited frustrations around what they see as lax security design and implementations of IoT devices. There is rarely an adequate threat and risk assessment conducted on devices, there’s no secure software development lifecycle, and access controls and usual patch processes for deployed devices is often non-existent.

    If their perceptions are accurate, a good way to think of IoT security maturing is to think of the way software and eCommerce sites were developed in 1999.

    This is why it’s important to help early adopters understand the security challenges associated with IoT, and share information on how these devices can be security designed, built, and deployed. With that in mind, along with the CSA’s recent IoT security announcement, we reached out to Jim Reavis, co-founder, CEO and driving force of the Cloud Security Alliance to get some of his thoughts about the issues. Reavis has been named as one of the Top 10 cloud computing leaders by SearchCloudComputing.com.

    devopsy.kinsta.cloud: Do you think it’s important to have the IoT security discussion now, and what do you see as the CSA’s role?

    Reavis: We think IoT is an area that’s not a future security challenge, but a present one. Not only because there is so much that’s happening right now, but because the application of IoT is so broad as to range from personal devices to those in the critical infrastructure. We also felt that we have a place here because all of these devices are going to be cloud-provisioned, cloud-managed, and their data stored in the cloud.

    We actually have 30 people on this guidance, and we tried to provide a lot of examples of different IoT implementations and we thing it is a good first cut of guidance directed at what we think the issues around IoT are, and what we need to be looking at. The guidance is also a call for action, because we are going to shortly publish about five additional, and more detailed, papers. We are hoping this generates a lot of interest, because now is the time to really start solving this problem.

    devopsy.kinsta.cloud: Where do you see the big challenges here? Is it with the device makers, or with the implementation? Or all or none of the above?

    Reavis: It’s a very wide problem. We think some of the device makers know that security is important enough, and that there’s an economical incentive for them to get this right. However, other devices are going to be so cheap, 3D printed and such, that it’s not going to be possible to get to the manufacturers – and so security there is going to have to come from the network. This is an area where standards can help.

    Security practices such as the secure development life cycle makes sense for certain aspects of securing the IoT. In other areas, security will come from cloud-delivered technologies like encryption and strong authentication. It is a broad ecosystem thing that we’re looking at and so there’s also governance challenges.

    And, right now, it’s not apparent to me that there’s a huge advantage in going to one, or a handful, of stakeholders here.

    devopsy.kinsta.cloud: That’s fascinating, so do you see this as a bigger challenge than securing eCommerce was 15 years ago?

    Reavis: Yes, we are looking at seven, eight billion Internet connected devices right now. Maybe it’s going to be a trillion in a few years. And if you go look industry by industry, and look at what companies are saying they’re going to do, that one trillion figure is not a crazy number to reach in about seven years.

    With that kind of scale, the Internet model is going to break. The Internet has worked very well, and I think we felt that it can handle anything we throw at it. But we think we’re really going to have to change the model for the growth that is associated with IoT.

    Part of that is the network needing to overlay a type of dark net on top of the open Internet, and that’s our software-defined perimeter. We’ve had the software-defined perimeter around for more than a year now. We’re creating the specification so that it separates the data channels and the control channels. It essentially knows the devices, knowing who’s authenticating on the devices, and then deciding what parts of networks are visible to them.

    devopsy.kinsta.cloud: What do we you in the future with IoT guidance coming from the CSA?

    Reavis: We are going to align each facet of IoT security with the corresponding cloud security standard and best practices. And upcoming research will identify and document critical vulnerabilities found in IoT in enterprise environments. We will provide guidance on how to mitigate those risks as well as give developers secure development guidance.

    The full report released can be found at New Security Guidance for Early Adopters of the IoT.

  • DevOps style performance monitoring for .NET

    DevOps style performance monitoring for .NET

    Editors note: This article represents the authors own opinions on the tools he mentions. We welcome others to join in the conversation about their opinions and experiences with these tools and similar ones. Important to note that they do not represent the opinion or beliefs of devopsy.kinsta.cloud or its editors.

    Recently I began looking for an application performance management solution for .NET. My requirements are code level visibility, end to end request tracing, and infrastructure monitoring in a DevOps production setup.

    DotTrace is clearly the most well-known tool for code level visibility in development setups, but it can’t be used in a 24×7 production setup. DotTrace also doesn’t do typical Ops monitoring.

    Unfortunately a Google search didn’t return much in terms of a tool comparison for .NET production monitoring. So I decided to do some research on my own. Following is a short list of well-known tools in the APM space that support .NET. My focus is on finding an end-to-end solution and profiler-like visibility into transactions.

    New Relic was the first to do APM SaaS, focused squarely on production with a complete offering. New Relic offers web request monitoring for .NET, Java, and more. It automatically shows a component-based breakdown of the most important requests. The breakdown is fairly intuitive to use and goes down to the SQL level. Code level visibility, at least for .NET, is achieved by manually starting and stopping sampling. This is fine for analyzing currently running applications, but makes analysis of past problems a challenge. New Relic’s main advantage is its ease of us, intuitive UI, and a feature set that can help you quickly identify simple issues. Depth is the main weakness of NewRelic. As soon as you try to dig deeper into the data, you’re stuck. This might be a minor point, but if you’re used to working with a profiler, you’ll miss CPU breakdown as New Relic only shows response times.

    net 1
    Dynatrace is the vendor that started the APM revolution and is definitely the strongest horse in this race. Its feature set in terms of .NET is the most complete, offering code level monitoring (including CPU and wait times), end to end tracing, and user experience monitoring. As far as I can determine, it’s the only tool with a memory profiler for .NET and it also features IIS web request insight. It supports the entire application life cycle from development environments, to load testing, to production. As such it’s nearly perfect for DevOps. Due to its pricing structure and architecture it’s targeted more at the mid to enterprise markets. In terms of ease of use it’s catching up to competition with a new Web UI. It’s rather light on infrastructure monitoring on its own, but shows additional strength with optional Dynatrace synthetic and network monitoring components.

    net 2

     

    Ruxit is a new SaaS solution built by Dynatrace. It’s unique in that it unites application performance management and real user monitoring with infrastructure, cloud, and network monitoring into a single product. It is by far the easiest to install, literally takes 2 minutes. It features full end to end tracing, code level visibility down to the method level, SQL visibility, and RUM for .NET, Java, and other languages, with insight into IIS and Apache. Apart from this it has an analytics engine that delivers both technical and user experience insights. Its main advantages are its ease of use, web UI, fully automated root cause analysis, and frankly, amazing breadth. Its flexible consumption based pricing scales from startups, cloud natives, and mid markets up to large web scale deployments of ten-thousands of servers.

    net3
    AppNetta‘s TraceView takes a different approach to application performance management. It does support tracing across most major languages including database statements and of course .NET. It visualizes things in charts and scatter plots. Even traces across multiple layers and applications are visualized in graphs. This has its advantages but takes some time getting used to it. Unfortunately while TraceView does support .NET it does not yet have code level visibility for it. This makes sense for AppNetta, which as a whole is more focused on large scale monitoring and has more of a network centric background. For DevOps in .NET environments however, it’s a bit lacking.
    net4

    Foglight, originally owned by Quest and now owned by Dell, is a well-known application performance management solution. It is clearly meant for operations monitoring and tracks all web requests. It integrates infrastructure and application monitoring, end to end tracing, and code level visibility on .NET, among other things. It has the required depth, but it’s rather complex to set up and obviously generates alert storms as far as I could experience. It takes a while to configure and get the data you need. Once properly set up though, you get a lot of insight into your .NET application. In a fast moving DevOps scenario though it might take too long to manually adapt to infrastructure changes.

    net next
    AppDynamics is well known in the APM space. Its offering is quite complete and it features .NET monitoring, quite nice transaction flow tracing, user experience, and code level profiling capabilities. It is production capable, though code level visibility may be limited here to reduce overhead. Apart from these features though, AppDynamics has some weaknesses, mainly the lack of IIS request visibility and the fact that it only features walk clock time with no CPU breakdown. Its flash-based web UI and rather cumbersome agent configuration can also be counted as negatives. Compared to others it’s also lacking in terms of infrastructure monitoring. Its pricing structure definitely targets the mid market.

    net5
    Manage Engine has traditionally focused on IT monitoring, but in recent years they added end user and application performance monitoring to their portfolio called APM Insight. Manage Engine does give you metric level insight into .NET applications and transaction trace snap shots which give you code level stack traces and database interactions. However it’s apparent that Manage Engine is a monitoring tool and APM insight doesn’t provide the level of depth one might be accustomed to from other APM tools and profilers.

    net 6
    JenniferSoft is a monitoring solution that provides nice real-time dashboarding and gives an overview of the topology of your environment. It enables users to see deviations in the speed of transactions with real time scatter charts and analysis of transactions. It provides “profiling” for IIS/.NET transactions, but only on single tiers and has no transaction tracing. Their strong suit is clearly cool dashboarding but not necessarily analytics. For example, they are the only vendor that features 3D animated dashboards.

    net7

     

    Conclusion: There’s more buzz around on the APM space than a Google search would reveal on first sight and I did actually discover some cool vendors to target my needs; however, the field clears up pretty much when you dig for end-2-end visibility from code down to infrastructure, including RUM, any web service requests and deep SQL insights. And if you want to pair that with a nice, fluent, ease-of-use web UI and efficient analytics, there’s actually not many left …

     

    About the Author/ Thomas Kunz:

    thom_4001I am an innovation architect focusing on IT in the context of the disruptive changes through the convergence of Social, Mobile, Information and Cloud and digital business transformations. After more than 20 years of experiencing one of the biggest IT enterprises in the world and its projects, programs and people, I am now helping customers overcoming the challenges through the omnipresent trend of digitalization. Follow me here http://twitter.com/@thom1309 or find me at my blog http://blog.smile-it.at  or at http://www.productwings.com

  • How machine learning could head off security quality failure

    How machine learning could head off security quality failure

    With so many players in the mix from operations to developers, from PMs to technical leads, to Q&A, most of their activities are automated. Systems record all their email, Wiki, and chat conversations and other notations about these activities. This gives the devops community the opportunity to learn from that data in order to improve future projects.

    “We have access to a massive amount of data that can in total define what the process is that’s going on and define it in-flight in real-time,” says Aaron Cois, Researcher, CERT Division, Software Engineering Institute, Carnegie Mellon University. Through exploratory research, Cois is learning that by using machine learning tools, enterprises can analyze security activities in the development process based on data from issue trackers and commit logs.

    Valleys in Topic Density Point to Software Development That is Missing the Mark

    Natural Language Processing, a subset of machine learning, uses systems to process text in unstructured data and to perform topic detection, determining whether or not a portion of the text belongs to a given topic category. “In our work, we’ve taken text from issue trackers and used machine learning to classify each issue as security-related or not security-related,” says Cois.

    This has practical applications for detecting the course of a project and steering it in the right direction. If the PM expects the developers to raise the quality of security for an iteration of the software package, he can monitor the chatter among developers about the issues they are adding to the issue tracker or he can monitor the comments on the code.

    “By using machine learning to classify issue tracking or source code commit messages as security-related, we can see a reasonable measure of the amount of work that’s being done to ensure the security of the software system,” says Cois.

    If the PM can determine based on a shortage of security chatter that in actuality not much security work is going on, he can ask why, what is the challenge? “Is the security stuff more difficult? Did we do our due diligence to allow our developers to adequately address security?” asks Cois. Then the PM and the teams can work together to remove any roadblocks before any more scope creep or veering off course occurs.

    Machine Learning for Physical Modeling and Trends Analysis

    If the industry can build statistical models of what a healthy software project looks like as it progresses, then it should be able to determine whether a given project is on track and what risks it may face along the way.

    Issue tracking data, commit logs, wikis, chat server logs, build/deployment logs—every type of data that can lead to a full picture of project activities—would form the basis of these models, according to Cois.

    Through Natural Language Processing, machine learning can help determine from this data what the rates of creation and resolution of issues are and what the rates of commits and overall progress are for the software project.

    Machine learning can help PMs look at how their project’s rates in these areas compare with rates of similar projects, which developed certain problems or turned out in certain ways. If there is a strong correlation between rates of projects that had known outcomes and rates in your project, then you might want to use that information to make corrections early on, in cases where the outcomes of the other projects were undesirable.

    Over time, the models become stronger and their predictive value increases, leading to some strong correlations between current projects and the models collected. With the increasing density of the data available in models as they grow, even the weakest numbers in early models can become stronger, giving the model strong correlative value in areas where strong correlations did not appear at first.

    “If I have collected both activity and outcome data on thousands of projects, and a large number of them are highly similar to the current project, I’ll have much more confidence in my predictions about the potential outcomes of the current project given the behaviors I am observing,” says Cois.

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

  • We are sponsoring DevOpsDays Austin. Why?

    We are sponsoring DevOpsDays Austin. Why?

    devopsdaysaustinI am really happy to announce that we have signed on as a media sponsor for DevOpsDays Austin, May 4-5. While we have served as media sponsor for any number of events over the last year, this is the first time we have signed on to sponsor a DevOpsDays event. I am going to Austin and will be there to participate and report first hand.

    Why DevOpsDays? Why Austin? Why now?  All good questions. I wanted to ask and answer them right here on devopsy.kinsta.cloud to be totally transparent.

    Why DevOpsDays?

    We do hold DevOps Connect conferences (our RSA event this week had 700 people there) and at first blush one might think they are competitive to DevOpsDays. But they never were in my mind and shouldn’t be in real life either.  In InfoSec we have conferences like BlackHat, InfoSecurity Europe and RSA Conference, but we have Security Bsides too, which are much more like DevOpsDays.  It is a big world and there is plenty of room for both. Not only plenty of room but plenty of need.  One thing I have learned travelling all over the place these months is that there is still a lot of DevOps learning, sharing and as Gene Kim says, tribe building that needs to be done.

    From everything I have seen and heard about DevOpsDays they do a great job on all of these fronts. I think as DevOps continues to gain acceptance there will be a much clearer difference in the audience and agendas at different DevOps conferences.  The difference between a DevOpsDays versus a DevOps Connect will be obvious. The respective audiences will recognize this. There will be overlap at some levels and at other levels there won’t be.

    But at the end of the day devopsy.kinsta.cloud is about spreading knowledge and learning about DevOps and DevOpsDays is too. So really the question is “Why shouldn’t we sponsor and support DevOpsDays?”

    Why Austin?

    That is easy. It’s not that Austin is weird (it is), it is the people and the history of what they have built in their DevOps community. I met first Boyd Hemphill about 6 or 8 months ago. He introduced me to Ernest Mueller, both of these guys were willing to hop in their cars and drive hours to come to San Antonio and Dallas to help educate people on DevOps at the recent DevOps Connect @ Innotech Conferences we held.  They represent to me anyway, the very best of what the DevOps community should be.  They weren’t territorial, judgmental or anything else but helpful.  With people like that in leadership roles Austin has to be a great place to sponsor our first DevOpsDays.

    In addition to Ernest and Boyd, I am familiar with what James Wickett has done with Rugged DevOps and Gauntlt (if you are not familiar with James and Gauntlt check out our new Ebook). Lastly, everyone you speak to say that Austin DevOps Days year in and year out is one of the best DevOpsDays anywhere. This year’s lineup looks like another stellar one.

    Why now?

    The answer is I think this is the right time for devopsy.kinsta.cloud to be involved with this part of the DevOps Community. I am not naïve or tone deaf enough that I have not seen or heard (how is that for a double negative) that some in the early adopter community were not big fans of what we have built at devopsy.kinsta.cloud. But I am also really proud of what we have accomplished in a little over a year. I am confident enough in our audience, our content and our place in the market to think that we can and have added to the discussion.

    I believe that devopsy.kinsta.cloud has to offer value to the entire DevOps community. That includes people just looking to adopt DevOps, people who are just starting to learn about DevOps and all the way to people who have been leading and teaching about it for all these years now.

    So we venture out into what is for us new territory. We are excited to support and be part of this great event. We hope that this will be the beginning of supporting other DevOpsDays around the world. Hope to see you in Austin, May 4-5.

    What is in it for you?

    Besides seeing coverage of the event here on devopsy.kinsta.cloud, there is more. As part of our sponsorship we were given two tickets to the event.  I am only using one. We have another one available. The show is just about sold out and the tickets are a couple of hundred dollars at this point.  If you would like to attend DevOpsDays Austin on us write me at editor@devopsdays.com with why you deserve this free ticket and it is yours. If more than one person rights I will pick the one with the best reason (in my opinion). I am not making the winners public or the reason they deserve it. So that is what is in it for you.

  • The continuous continuousness of DevOps

    The continuous continuousness of DevOps

    Defining DevOps is getting easier, but it’s still an elusive goal. Part of the challenge is that DevOps is more of a culture than a specific “thing” and how that culture exists is subjective and varies from one organization to the next. DevOps is what you want or need DevOps to be to some extent, but one thing seems to be consistent no matter how you define DevOps—it’s continuous.

    If DevOps is the buzzword du jour for tech, then continuous is the buzzword du jour of DevOps. Everything is continuous. Continuous development and continuous testing lead to continuous deployment and continuous delivery, which requires continuous support. Continuous monitoring produces continuous integration and continuous change. Continuous security results in continuous incident response…or vice versa. To top it off, all of the continuous activities continuously feed each other to drive more continuousness in some sort of DevOps Mobius strip of continuity.

    What does it all mean? I mean, aside from being a catchy buzzword and making that new DevOps tool or service sound sexy and impressive?

    In a nutshell it means there’s no end. You don’t really reach a point where everyone can shut down their PCs and grab a beer to celebrate the completion of the project. The project—whatever it is—is more of a living, evolving thing than a deliverable.

    There’s also no beginning—or at least no new beginning. All of the continuous activities cycle back over each other like a Spirograph drawing. Have you ever tried to find the beginning or end of a Spirograph drawing? Good luck.

    DevOps is the Alpha and the Omega, the beginning and the end, the first and the last.

    When you strip out the buzzwords what it really means is working in a more effective and efficient way. I’ve worked on software development projects the old-fashioned way. No, not Agile—Waterfall. The cascading tasks feed each other in what appears to be a logical progression. It makes sense to define requirements, design the software, implement it, test or verify it, and then kick back and go into maintenance mode…on paper at least.

    In the real world new requirements are discovered when you’re ready to implement, and testing results in new design elements. Those new requirements need to be designed and the new design element needs to be implemented and it all needs to be tested and maintained which inevitably creates new requirements, design elements, and so on.

    Waterfall was already DevOps—it was just dysfunctional because each “continuous” loop was treated as a unique and separate project. Items that were identified after the design phase were just accumulated on a list to be incorporated into the next phase or iteration. The net result was producing a somewhat stable product that you already knew was flawed, but that you’d get to fixing eventually.

    Agile development accelerated some of the feedback loops of Waterfall and resulted in faster refinements to projects, but it still had issues. The primary issue is that developers can’t go faster by themselves. Developers are just one cog in the machine and producing software faster just creates a bottleneck if operations isn’t prepared and the infrastructure isn’t ready to handle it.

    Chris Riley explained the challenge of Agile. “However, the Ops department was inherently left behind with deployments piling up faster than they could be released and customers never actually received the value they demanded. This trend ultimately gave rise to DevOps, a new-age version of Agile methodology encompassing the Dev and Ops segment to enable service delivery agility and quality.”

    Another way of looking at it is that DevOps is an evolution of Agile. I wrote recently, “DevOps is just a natural extension of Agile. It takes the guiding principles and best practices that Agile brought to developers and applies them on a much broader scale across the organization.”

    So now everything is continuous. There is no top of the waterfall that cascades through multiple layers until you reach the bottom of the waterfall. Now there’s a continuous culture of continuity. It may sound confusing when viewed through all of the various buzzwords, but when you step back it makes sense. It makes sense because that’s really the way it worked—or should have worked—all along.

    DevOps gets processes and policies out of the way to enable people to get things done more efficiently. For some reason we’ve decided that every element should be labeled continuous—which actually makes it sound a little frenetic or overwhelming. Maybe we should use “efficient” instead. That can be our new buzzword.

  • Are You Embedding Security for a Rugged DevOps Experience?

    Are You Embedding Security for a Rugged DevOps Experience?

    ebookcover

    As security thinkers try to wrap their heads around what’s broken in today’s security architecture and processes, DevOps and continuous delivery patterns may seem like yet another potential problem for already overwhelmed risk managers. But once security gurus get past the intimidation of working within a cycle of fast iterations, they could well find that continuous delivery model could actually provide a  blueprint for fixing what’s wrong with security today.

    Security leaders that work with operations, developers, architects, QA and the rest of the team to build continuous delivery momentum are helping their organizations develop a more rugged development life cycle that not only produces more secure software but that also supports faster fixes to security problems as they’re found.

    Learn more about how to start moving toward a Rugged DevOps mentality in our inaugural eBook, Rugged DevOps: 10 Ways to Start Embedding Security into DevOps Patterns. Some of the insights security and DevOps experts shared with our reporter Ericka Chickowski in this special issue:

     

    • The bad guys are already delivering malicious code continuously. Security can respond faster by working within the DevOps patterns.
    • Security can a learn a lot from the DevOps propensity for smart automation.
    • The DevOps model really can be compatible with compliance.
    • The DevOps paradigm shift may give security pros the opportunity to finally bake security into IT processes rather than add it on as an afterthought.

    We will be distributing printed copies of the book at the DevOps Connect event at RSA Conference this week, as well as at a special Rugged DevOps Breakfast Tuesday morning at Jillians.  But you don’t have to be at RSA to download your own copy. Fill out the form below to download a copy.

    The Ebook is sponsored by Evident.io and Incapsula. Thanks to them for their support.

    Enjoy!

    Download Rugged DevOps Ebook

    • This field is for validation purposes and should be left unchanged.

     

    *downloading the Ebook will add your email to our newsletter mailing list which you can opt out of at anytime.