devopsy.kinsta.cloud

Author: Tony Bradley

Continuous Security Key to Defending Your Data Well
Defending data isn’t easy. If it were, we wouldn’t see new data breach headlines on a weekly—or sometimes even daily—basis. That said, defending data also isn’t rocket science. A new report from Nuix highlights some of the major concerns with protecting data, and also illustrates some of the ways in which consistent vigilance is half the battle.

The Nuix report, compiled by principal researcher Ari Kaplan, covers a broad spectrum of concerns related to data security. Some of the key findings from the report include:
- Increased granularity of security budgets: Respondents report there is a growing trend to specify how the security budget should be broken down and allocated.
- Regulatory impact on spending has doubled: Government and industry compliance mandates continue to take a sizable bite out of security budgets.
- Greater focus on insider threats: More than 70 percent of respondents have some sort of insider threat policy or program.
- BYOD continues to play a role in security: 82 percent of respondents have some sort of BYOD (bring your own device) policy in place. A growing number of companies, however, are prohibiting remote access by employees.
- Cloud adoption slowing: According to the study, about 70 percent of companies are migrating data to the cloud—a number consistent with the previous year—but fewer companies are moving systems or servers to the cloud. More than four out of five respondents agreed that the cloud creates unique cybersecurity concerns, and only 43 percent indicated plans to move systems or servers to the cloud.
What sorts of unique security concerns does the cloud bring? According to the survey respondents, there are a variety of potential issues, such as:
- losing visibility into the management of data
- being at the mercy of the cloud provider’s security skills
- reduced control over access to data; and
- confusion about the privacy/legal issues when a government or law enforcement agency wants to access data.
In a nutshell, none of this is really new or different. Compliance, insider threats, BYOD and concerns over security and privacy in the cloud have been prevalent factors in network and computer security for years—and likely will continue to be for years to come. What has changed, though, is the focus on ways to implement better security and the tools to do it.

One of the primary issues with traditional computer and network security is that it’s reactionary. Scans provide moment-in-time confirmation that there are no known threats, but do little or nothing to protect against unknown threats or prevent exploits and compromises between scans. DevOps, and continuous security, change the game by enabling organizations to monitor for and detect security issues on a consistent, proactive basis.

“Security practitioners cannot continue to rely on manual, human controlled processes to defend against attacks,” agreed Andrew Storms, VP of Security Services for New Context. “Automation is a requirement for the next evolutionary phase of security protection.”

Nick Galbreath, founder and CTO of Signal Sciences, also believes that automation and continuous DevOps principles are key components of effective security. “I have argued that continuous deployment (how rapid the ‘continuous’ is up to the organization and risk-dependent on the nature of the code) is actually the most important security tool since without it, I don’t really know how you make things better rapidly.”

There are a lot of names tossed around for various aspects of DevOps automation. The actual name is not as important as the actual practice of proactively automating security processes for more effective security. Take a look at the report from Nuix to learn more about the general state of data security, but make sure you embrace DevOps and continuous security if you really want to do something about it.
January 4, 2016
7 things 2016 has in store for the future of DevOps and IT
With only a couple weeks left in 2015 it’s time to start looking ahead to what next year has in store. Let’s be honest—most of us have already mentally checked out for the holidays anyway, so it’s already 2016 for all intents and purposes. I spoke with a handful of industry experts to get some thoughts on what we have to look forward to in 2016.

Let’s just jump right in:
1. Log Management will play a larger role
According to Christian Beedgen, CTO of Sumo Logic, log management will emerge as the most underrated opportunity for IT. “Thinking about log data may seem too far in the weeds for most tech industry professionals. However, using analytics to monitor, manage and gather insights from logs will be the only near-perfect way to make sense of the increasingly complex and cloud-based architectures.” Log management isn’t exactly new or cutting edge, but Beedgen believes that 2016 will see more vendors trying to move into the log management space, and more organizations trying to use log management to make sense of their big data mess.
1. Business leaders will demand better insight
On a similar note, Rick Fitz, senior VP or IT Markets for Splunk, believes that analyzing data and metrics will also play a role from a business strategy perspective. “In 2016 we will see data science demystified, moving from Ph.D. to MBA, with easier ways emerging to consume, analyze and correlate machine data. As business leaders increasingly go digital, this will result in greater “digital insight” into engagement, satisfaction, competition, effectiveness, response, revenue and other business goals.”
1. Sharing economy will transform IT
Companies like Uber and AirBnB have transformed entire market segments. The sharing economy has changed the way businesses engage customers and deliver services, and that includes IT through aspects such as cloud services, microservices, APIs and more. Fitz predicts, “Next year this ‘Uberfication of IT’ will turn into a ‘Balkanization of IT,’ driving stakeholders to demand better insight, governance and control of federated technologies to integrate adoption, usage, monitoring, security, cost control and more across shared services.”
1. Enterprise DevOps will grow rapidly
The DevOps revolution has taken IT and app development by storm in recent years, but most of the traction has been in startups or smaller businesses that have more freedom to shift gears and embrace new concepts. Enterprise adoption has been growing, but at a much slower rate. Andi Mann, chief technology advocate for Splunk, said, “In 2016 we will see rapid acceleration of DevOps with 50 percent or more of large businesses finally adopting ‘Enterprise DevOps’ — a pragmatic, scalable approach to adopting the culture, process and technology changes at the heart of DevOps.”
1. The singularity approaches
OK. That may be an ominous over-statement. In a nutshell, Sumo Logic’s Beedgen claims that the line between machines and humans will continue to fade. The foundation of this is automation—leveraging technology to perform mundane or routine tasks and sift through mountains of data exponentially faster than a human can. As artificial intelligence evolves, though, the scope of what can be automated expands as well. “In automating processes, a human can today wield the power of a legion of operators with a single hand,” stated Beedgen. “Likewise, machine learning will increasingly be adopted for its usefulness in augmenting human understanding of complex interaction and large data sets by uncovering the unknown unknowns.”
1. Automation and analytics will improve IT service health
DevOps and microservices have transformed many areas of development and IT infrastructure, but many organizations still rely on decades-old monitoring tools, arcane metrics, and specialized admins dedicated to managing the cumbersome process. Splunk’s Fitz thinks that is getting ready to change. “In 2016, IT analytics will be liberated as easy-to-use dashboards will correlate all sources of service health—legacy tools, APIs, mobile apps, Web logs, wire data, containers and more—while predictive analytics will automatically respond to prevent quality issues.”
1. DevOps is here to stay
From the point of view of DevOps practitioners or companies that have adopted DevOps tools and practices, this may seem both painfully obvious, and yet still be good news as well. Christian Beedgen predicts not just that DevOps is here to stay, but that the importance of DevOps and the sphere of influence affected by DevOps will expand. “Increasingly, DevOps will permeate all manner of businesses that rely on information technology to compete. Bimodal IT (the practice of managing two separate, coherent modes of IT delivery) will become the equivalent to “private cloud”—the last forced resistance of the old guard. Both will be forgotten in a short number of years, as public cloud and lean and agile processes dominate the businesses that still compete.”

There you have it. Now you can enjoy your holiday break in peace and come back in 2016 with an idea of what you have to look forward to in the year ahead.
December 15, 2015
Automic amps up DevOps with continuous everything

DevOps is all about automation and continuity. I’ve written in the past about continuous as a DevOps buzzword, and the continuous continuousness of DevOps because it seems like everything is continuous. There’s continuous delivery, continuous integration, continuous testing, continuous deployment, etc. Perhaps the executives at AUTOMIC read my work and it inspired them to skip straight to Continuous Everything.

DevOps is fundamentally about culture more than tools, but once the culture is in place the tools make all the difference and many of the tools revolve around automation. Every task that is routine and repeatable should be automated so that actual human beings can devote their time to more complex or important tasks. The goal of DevOps, ultimately, is to enable developers, IT operations, and other teams to work more effectively and efficiently.

AUTOMIC—a play on words that has “auto” as its root, but is pronounced like “atomic”—is focused on driving DevOps automation. The AUTOMIC Continuous Everything business automation platform is designed to help businesses by combining continuous delivery, continuous operations, and continuous services into a single, unified platform.

“Never has there been so much pressure on businesses to increase their speed of execution”, said Todd DeLaughter, CEO of AUTOMIC in a press release statement. “We are at a turning point in how enterprises embrace change, manage disruption and deliver new services with pace. Point tools for automation are inadequate against this challenge. AUTOMIC’s approach through a unified business automation platform, One Automation, allows seamless integration from the business processes through the IT services supporting those processes and the delivery of applications to differentiate the business. AUTOMIC empowers businesses through automation – end to end.”

Since one of the primary goals of DevOps is efficiency it makes sense to combine tools into a unified platform. Giving DevOps teams a single, consistent interface to manage multiple facets of DevOps automation seems like a logical solution.

I have a couple issues with the AUTOMIC offering, though. First, I’m not entirely sure what it’s actually called. AUTOMIC uses Continuous Everything—capitalized as if it’s a proper name—but it also states that the AUTOMIC Business Automation platform delivers three levels of DevOps automation, and DeLaughter refers to One Automation. When all is said and done, I’m not really sure if AUTOMIC is referring to three different tools or just has three different names it uses to refer to the same platform.

The second issue I have is the use of the word “everything” for an automation solution that only covers three things. There is a wide variety of continuous automation solutions for DevOps: continuous delivery, continuous deployment, continuous improvement, continuous integration, continuous monitoring, continuous testing, and more. Providing continuous delivery, continuous operations, and continuous services in a unified platform is ostensibly better than delivering just one or two of those options, but it’s far short of being “everything”.

The names become an issue again when you try to buy the tools. They aren’t actually called continuous delivery, continuous operations, or continuous services. There is AUTOMIC Release Automation, AUTOMIC Workload Automation, and AUTOMIC Service Orchestration, which are each plugins that work with the AUTOMIC platform. All plugins are immediately available on the AUTOMIC Marketplace. Pricing is available on-demand.

November 18, 2015
DevOps success is everyone’s responsibility

For organizations with existing hierarchies and processes the shift to a DevOps mindset can be a challenge. The traditional departmental roles and separation of duties is anathema to an efficient DevOps culture. When it comes to DevOps there’s no room for finger-pointing—every team and individual is equally responsible for making sure everything is firing on all cylinders.

Gene Kim, coauthor of The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win and the upcoming DevOps Cookbook, took part in a podcast earlier this year and shared that two-thirds of the DevOps success stories he has seen are actually from established businesses with existing infrastructures and processes as opposed to “greenfield” projects that embrace DevOps from the start. In those situations, the drive to embrace DevOps has to come from somewhere, but in order for DevOps to work the organization has to overcome the urge to place the entire burden for the success or failure of DevOps on that one team or individual.

There is a reason that the word “culture” plays such a central role in any discussion of DevOps. Without a shift in the mindset of how teams and individuals communicate and collaborate a DevOps initiative isn’t much different than any other IT project in the organization. One team or person can use DevOps tools, but that’s not really a functional implementation of DevOps.

That doesn’t mean that DevOps is an all-or-nothing game. It’s possible for different departments or elements within a company to embrace DevOps without the whole company jumping on board. There has to be a quorum of sorts, though—a broad enough consensus between teams and individuals to cooperate and collaborate in a different way than how it’s laid out on the company org chart. An important part of that shift is for everyone to accept responsibility for the outcome and work together toward a common goal.

There’s a phrase that goes something like “When all you have is a hammer, everything looks like a nail.” Developers understandably view the world through the filter of developing. IT operations people look at projects from the perspective of operations. QA looks at things from the point of view of testing and quality assurance. Accounting considers projects from the financial angle. Security personnel tend to focus on the security aspects. You get the idea.

Kim shared an excerpt of the upcoming DevOps Cookbook with me. In the book Kim talks about the need to move from functional-oriented teams optimized for cost to market-oriented teams optimized for speed. He talks about the challenges and bottlenecks created when some teams or elements are moving at an accelerated pace while others struggle to keep up.

Part of optimizing for speed is shifting the perception of responsibility. Smaller, market-oriented teams are more agile and can deliver value to customers—both internal and external—while reducing or even eliminating reliance on other teams. Kim explains, “Taken to its extreme, market-oriented teams are responsible for not just feature development, but also testing, securing and deploying their code into production themselves, as well as being responsible production operations and availability.”

In order for DevOps to work effectively, everyone needs to forget that they’re a “hammer” and view the project as a more comprehensive toolbox instead. DevOps teams need to strive to break out of the traditional roles and silos and make a conscious effort to see things in terms of the common goals or greater good.

October 20, 2015
Continuous Deployment is king of the DevOps hill

One of the promises of DevOps is continuous deployment. DevOps is, first and foremost, a matter of shifting the traditional business culture more than the tools and technologies that enable it. Once that culture exists, though, one of the defining aspects of DevOps is automation and continuity.

Earlier this year I wrote about the seeming ubiquity of “continuous” solutions throughout DevOps:

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.

Taking a closer look at all of that continuous continuousness, however, continuous deployment stands out as one of the prevailing goals of effective DevOps. Continuous integration, continuous delivery and the other continuous tools and processes are all in some way related to facilitating the flow of continuous deployment or monitoring and managing it after the fact—which ultimately feeds back to the beginning of the loop and back to continuous deployment.

Chris Riley tried to muddle through the confusion of continuous integration, continuous delivery and continuous deployment. In his explanation of continuous deployment, he stressed the impact of this symbiotic loop that surrounds it: “Continuous deployment has additional costs, as it relies on instrumentation, to ensure that new functionality does not result in bugs and also on infrastructure that allows effortlessly backing out new features when a defect has not been caught by automated tests.”

I defer to Riley on most things, but I don’t agree with his summation that everyone should do continuous integration, some should do continuous delivery, but only the rare few should strive for continuous deployment.

I guess it depends on what perspective you’re considering it from. From the standpoint of ease or simplicity and the likelihood that an organization can execute it effectively I can see where Riley is coming from. From the point of view of the goal of embracing DevOps, though, I would reverse his order and say that everyone should do continuous deployment, most should implement continuous delivery to facilitate it, and some (or maybe most as well) should adopt continuous integration to drive continuous delivery.

The primary objective of DevOps, though, is to deploy apps. Everything else plays a supporting role.

That said, there is a difference between embracing DevOps with the goal of developing and deploying apps more efficiently and effectively, and adopting continuous deployment tools that automatically pass all changes that pass automated testing and are verified as deployable by continuous delivery tools into production.

A blog post from Puppet Labs explains, “There are business cases in which IT must wait for a feature to go live, making continuous deployment impractical. While application feature toggles solve many of those cases, they don’t work in every case. The point is to decide whether continuous deployment is right for your company based on business needs — not on IT limitations.”

There are many acronyms and various interpretations out there for DevOps, so my opinion certainly isn’t gospel on the subject. What do you think? Should continuous deployment be the primary goal and centerpiece of DevOps automation? If not, which of the many “continuous” solutions would you suggest as the central focus?

October 15, 2015
The business benefits of DevOps

As DevOps has become more of a mainstream concept it seems like there’s less need to define what it is or explain what it does. As prevalent as DevOps is for those of us who work in the world of DevOps or organizations that have already embraced DevOps there are still many businesses out there muddling along the old-fashioned way and wondering why they should care about DevOps.

The simple answer is that not caring about DevOps may be suicidal. The 2014 State of DevOps report found that organizations successfully implementing DevOps tools and practices lead competitors in almost every relevant metric. Two statistics that stand out from that report are that companies using DevOps are twice as likely to exceed profitability, market share, and productivity goals, and had 50 percent higher market capitalization and growth than rival businesses.

Why is that, though? What is it about DevOps that leads an organization to be more profitable and productive? It’s a combination of three things, really: faster delivery times, greater stability / reliability, and freeing up time to focus on value.

Let’s break those down some. DevOps is an evolution of the Agile development methodology. In fact, I’ve asserted in the past that DevOps is really just a matter of taking Agile principles and applying them to the rest of the company outside of software development. Whether Agile or DevOps the result when it comes to developing software is faster, more frequent delivery.

Next we have greater stability and reliability. It might seem that the traditional linear method of developing software and releasing it on a pre-defined schedule is more stable. Developers and the rest of the organization have plenty of time to refine the code before it’s deployed, they know exactly when it will be deployed, and they know it basically won’t change for another year or so when the next major release is scheduled. The reality is the complete opposite in many cases.

Developing with a rigid process methodology like waterfall means that only the changes and features identified at the beginning of the project are included in the release. As the need for improvements or additional features is identified during development those things are sidelined and added to a list to be pursued in the next release cycle. By the time the software is developed, tested, and deployed it is already out of date to some extent and bugs or issues that are identified take longer to address or get pushed to be handled in the next major release.

The whole process is slow and results in less stability and reliability. DevOps yields greater stability and reliability because the faster development and more frequent release schedule enables organizations to identify and resolve issues immediately.

Those two things combined mean that developers and others throughout the organization have more time available to focus on improvements and innovations that contribute to the bottom line. Organizations that have embraced DevOps also generally have tools in place to automate routine tasks which enables individuals to dedicate more time to growing the business and less time to pissing on fires and maintaining the status quo.

DevOps has come a long way in just a few short years. There may still be companies out there trying to figure out why they need DevOps, but those companies won’t be around long. They’ll either figure it out and jump on the DevOps bandwagon or they will no longer exist to worry about it.

September 29, 2015
4 big challenges of microservices

The rise of microservices as a means of developing and delivering software value faster is clearly on the rise. Containers have skyrocketed from a fringe technology to a mainstream imperative and organizations are scrambling to jump on the microservices bandwagon. Before you rush out to embrace microservices, though, there are a few things you should keep in mind.

First let’s talk about what microservices even are since it’s a relatively new term in a sea of relatively new terms.

Al Hilwa, research director, Application Development Software at IDC described microservices this way:

“Microservices is an architectural approach that draws on long evolving experience in software engineering and system design, including the SOA efforts of the last two decades. Microservices architecture is enabled by a spectrum of tool categories but is primarily an architectural approach to system design that also requires considerable organizational and cultural adjustment to execute successfully.”

Put more succinctly, microservices is an evolution of software development and deployment that embraces DevOps and containers and breaks applications down to smaller individual components. Organizations can develop and deploy faster because there is a modular approach that makes code more efficient and enables much of the common or routine elements to be automated.

Everyone seems to be doing DevOps and containers these days. If you’re not you may feel like you need to catch up quick or risk being left in your competitors’ collective dust. That may be true to some extent, but you have to approach microservices in the right way and for the right reasons. Jinesh Parekh, CEO of Idyllic Software, shared some thoughts about four challenges organizations should consider when venturing into the world of microservices.

1. Insufficient guidance

When it comes to implementing new technologies and embracing new strategies it can be a little like the “Wild West”. There are few hard rules in place and very little in the way of guidelines or documentation to help you navigate how to build and deploy software using microservices. Thankfully, sites like devopsy.kinsta.cloud and ContainerJournal are here to provide as much information as possible to give organizations some guidance.

2. Getting it wrong

There are a variety of “moving parts” involved in doing microservices successfully. Your organization should adopt a DevOps culture and have the appropriate infrastructure in place to avoid getting it wrong. Microservices architecture is generally built on a foundation of cloud and virtualization, and relies heavily on automation to ensure success and avoid failures.

3. No going back

You should be aware that it’s exceptionally difficult to switch back once you start down the microservices path. The changes that have to happen in terms of culture, tools, and processes to embrace microservices are not easily undone. The good news is that there is very little—if any—reason an organization would move to DevOps and containers as a development framework and then decide to revert to the old, monolithic way of doing things.

4. Deliver value

Parekh’s focus on delivering value is biased toward Idyllic Software. His company is in the business of delivering applications for clients via microservices and Parekh suggests that organizations outsource development to an experienced leader to ensure microservices meets expectations. You don’t necessarily have to outsource to Idyllic Software, though, or outsource at all. You just need to make sure that your approach to microservices benefits your organization—that it adds value and meshes with business objectives and isn’t just microservices for the sake of following the microservices trend.

Microservices seems to be here to stay, and seems to be on the same path as DevOps and containers from niche concept to mainstream business adoption. As you ramp up to jump on the microservices bandwagon just make sure you keep these things in mind.

September 21, 2015
DevOps and continuous innovation accelerate the evolution of technology

DevOps tools and principles have dramatically increased the pace of innovation and enabled the organizations that have embraced them and used them most effectively to achieve a major strategic advantage over competitors. The more the world runs and relies on software, the more DevOps can be the engine to automate and facilitate change.

There was a time it took almost half a day to build a single car. Henry Ford managed to bring that down to two hours and 30 minutes thanks to the assembly line, but for over a hundred years most of the changes year to year in automobiles have required retooling manufacturing plants so updates and modifications are developed at a relative snail’s pace. Then Tesla came along with a car that is more or less just a framework for the software that runs on it and that can have new features and capabilities the next day through over-the-air software updates.

John Jeremiah, technology evangelist and team lead for HP Software, was quoted in a post earlier this year saying, “It was just a few years ago when nobody had heard of Uber. Now, every single taxi company or taxi service is under pressure to react to a company that owns no taxis. Why is that? It’s because they’ve used software.”

Tesla has an advantage over other automobiles because it can change the way its vehicles work or improve them with new features at the push of a button. Uber has an advantage over the traditional taxi industry because it has streamlined its service through a mobile app available on hundreds of millions of mobile devices and it can modify and improve the way it works with a simple update. Software has increased the ability for organizations to adapt more quickly and DevOps accelerates that evolution even faster through continuous innovation and the automation of routine tasks.

There will still be things that require physical change—an updated vehicle frame in the case of Tesla or a new feature that relies on cutting edge technology only available in the latest smartphone models in the case of Uber. Software alone can’t do it all.

The areas where software makes a difference, though, DevOps has a major impact. A recent study conducted by Gene Kim and a team of researchers found that organizations that have embraced DevOps tools and principles effectively have 8,000 times faster lead times and 30 times more frequent deployments than their peers. They also have 12 times faster mean time to recovery when issues arise and are twice as likely to exceed profitability, market share and productivity goals. Those are all significant statistics that impact the bottom line and separate the companies that win from their struggling rivals.

Companies that can harness the power of DevOps and continuous innovation to develop new apps and capabilities faster and that have the capacity to push those updates out to existing customers have a significant advantage over competitors still slogging through “innovating” the old-fashioned way. It’s hard to compete with companies that are deploying 30 times faster than you and have twice the profitability and market share.

August 25, 2015
Microsoft and Docker provide progress report on Docker for Windows Server

In the fall of 2014 Microsoft and Docker unveiled a new partnership—a commitment to work together to bring native support for Docker containers to the next major release of Windows Server. Earlier this week the two talked about the progress made so far and gave some clues to what customers should expect once the next Windows Server hits the street sometime in 2016.

Mark Russinovich, CTO of Microsoft Azure, was in San Francisco this week at Docker headquarters meeting with his counterpart, Docker founder and CTO Solomon Hykes. The two met to talk about how their collaboration is progressing to bring Docker containers to Windows Server. The two didn’t share many specifics, but did say that the effort so far is achieving established goals and is proceeding according to the schedule they’ve laid out.

What is that schedule? We don’t really know. All Russinovich or Microsoft will commit to officially at this point is 2016. Whenever it arrives, though, it will represent a significant step forward in creating a platform-agnostic environment for developers. Windows developers will be able to integrate Docker containers natively with Windows Server, Visual Studio, and .NET applications.

The CTOs clarified that Docker support in Windows Server won’t allow Linux applications to run on a Windows operating system. Likewise, Windows applications in Docker containers won’t run on Linux. The value of the partnership and the integration of Docker support in Windows server is that developers will be able to leverage the same tools and common platforms for deploying, running, and managing the Docker container environment.

Microsoft Azure already added support for running Docker containers on Linux servers within the cloud platform. Once the new Windows Server hits, organizations will be able to run Docker containers on Linux or Windows and manage it all through Azure. It also enables developers to create application services running on opposing platforms and run it as part of a distributed application spanning both Windows and Linux.

The advantage from a Windows developer point of view is the ability to use the tools they’re familiar with. Developers will be able to use Visual Studio and .NET along with the built-in collaboration and workflow tools, as well as debugging and source-code control. It allows organizations to employ existing development practices and tools for creating and deploying Docker containers.

From a DevOps perspective the integration of Docker containers natively with Windows Server will enable better automation and continuity. DevOps and containers result in frequent changes to the app code and the underlying infrastructure, which is a bit of a culture shock for both traditional developers and traditional IT admins. Straddling the line between the two worlds by incorporating Docker containers and DevOps tools with the familiar Microsoft development platforms organizations are comfortable with takes some of the pain out of that cultural evolution.

Ultimately, the partnership between Docker and Microsoft will lay the foundation for completely platform-agnostic development. The app containers themselves may still require a specific OS to run, but at an organizational level the environment and infrastructure can be viewed and maintained as a holistic whole.

August 19, 2015
Alert Logic Cloud Insight brings cloud-based security to your cloud infrastructure

One of the primary driving forces behind DevOps is its fluidity. There is a domino-effect that cascades from the developers who create the apps to the IT admins who deploy and administer the apps to the individuals who download and use the apps and back again. Traditional security can’t keep pace so Alert Logic created Cloud Insight—a cloud-native vulnerability and configuration management solution for cloud infrastructures running on Amazon Web Services (AWS).

I’ve written previously about the continuous continuousness of DevOps. Anything and everything that used to be manual tasks on a static infrastructure is now automated to the Nth degree. “Continuous development and continuous testing lead to continuous deployment and continuous delivery, which requires continuous support. Continuous monitoring produces continuous integration and continuous change.”

All of that also means that it’s virtually impossible to keep up with the current configuration or accurately assess vulnerabilities in a constantly-changing environment. If your entire cloud infrastructure can change at the push of a button you also need to have security controls in place that are just as automated and capable of flowing with the changes and providing continuous, real-time security. Traditional security solutions simply won’t work.

Alert Logic agrees, which is why it developed Cloud Insight. Gray Hall, CEO of Alert Logic, explained in a press release announcing Cloud Insight, “Managing security while maintaining the agility of the cloud is fundamentally different than in any other environment. With Alert Logic Cloud Insight we are delivering an innovative solution that gives businesses an added layer of visibility for workloads running on AWS—actionable intelligence to identify and eliminate risk across instances and applications while not slowing the business down.”

Cloud Insight automatically tracks changes—additions, moves, deletions—within the AWS platform. It continuously identifies threats and vulnerabilities and potential exposure to risk within the dynamic environment. Alert Logic uses AWS APIs to integrate with the cloud infrastructure to detect any changes and inspect the new, change, or modified resources for vulnerabilities or configuration issues.

Cloud Insight generates a prioritized list of remediation actions so the organization knows in real-time what’s broken and what the exposure to risk is and it can focus on addressing the issues and maintaining a strong security posture rather than spinning its wheels just trying to keep up with vulnerability assessments in a fluid environment.

Terry Wise, VP of Worldwide Partner Ecosystem for AWS, said “Security-as-a-Service solutions built on AWS and designed to complement AWS-native security features enable customers to maintain the highest levels of protection while achieving the agility, elasticity, and cost savings of the AWS Cloud.”

Alert Logic Cloud Insight is pre-approved to run on AWS. You can use Cloud Insight to conduct vulnerability scans and penetration testing within AWS without any additional permission. Cloud Insight also includes customer-facing APIs that can be used to integrate with other DevOps tools, and it can be integrated into your existing DevOps pipeline.

Pricing for Alert Logic Cloud Insight is similar to the AWS pricing model. It functions on a pay-as-you-go basis based on the number of hosts or protected instances for a given day. Customers are billed $1 (USD) per instance per day. You can request a free trial of Alert Logic Cloud Insight to determine if it’s a good solution for your organization before taking the plunge.

August 13, 2015