devopsy.kinsta.cloud

Author: B. Cameron Gain

  • DevOps Ethics: The Danger of Unethical Code

    DevOps Ethics: The Danger of Unethical Code

    The accident could not have come at a worse time for Uber. Already under scrutiny following several high-profile lawsuits for sexual harassment, intellectual property theft and other accusations that played at least as significant role in founder and former CEO Travis Kalanick’s departure, the ride-hailing firm’s driverless test vehicle was involved in a fatal pedestrian accident earlier this year. It was later revealed the test driver, who was paid to take over driving in case of an emergency, was watching an episode of “The Voice” and thus too distracted to notice a pedestrian who suddenly appeared out of the darkness directly into the car’s path.

    Pending the final verdict of the National Transportation Safety Board (NTSB) investigation, it remains to be seen whether the Uber test driver could or should have been able to avoid the pedestrian or had time to apply the brakes to lessen the impact. However, the Uber SUV’s self-drive sensor system reportedly failed to detect and react to the pedestrian due to software failings—in other words, the system failure likely can be attributed to just plain bad code.

    Prior to the accident, Uber software developers and engineers were already struggling with ethical concerns regarding algorithms they created that, among other things, allegedly were designed to exploit underpaid drivers, deny services to passengers and skirt governmental regulations. A former software engineer, Susan Fowler, also described a toxic culture when filing a sexual harassment legal complaint against Uber.

    However, the allegations levied against the company, even if true, can be seen as an anomaly in software development and DevOps culture in general. One can suppose, for example, that basic human decency dictates most software developers refrain from engaging in unethical behavior and designing code for nefarious reasons. Data from recent studies supports this assumption.

    According to a recently published meta study by Stack Overflow, only a fraction of more than 100,000 developers surveyed said they would write unethical code or “that they have no obligation to consider the ethical implications of code.” When asked what they would they do if asked to write code for an unethical purpose, 58.5 percent reported they would not, while 36.6 percent said it depended on what it was. Only 4.8 percent said they would.

    However, the report describes a lot of “ethical gray.” “Developers are not sure how they would report ethical problems and have differing ideas about who ultimately is responsible for unethical code,” Stack Overflow said in a statement.

    Meanwhile, the fact that many of Uber’s arguably poor ethical choices originated from upper management and its DevOps team points up how, conversely, it is up to DevOps to instill ethical guidelines for organizations to follow. To that end, DevOps must create, among other things, “full audit trails showing who developed what code and when and a culture that enables developers to voice ethics concerns without fear,” said Torsten Volk, an analyst for Enterprise Management Associates (EMA).

    “Knowing that a full audit trail is in place will make DevOps more likely to raise a red flag with their team leads,” Volk said. “Then, ideally, the outcome of this discussion should be documented in a source code management system.”

    In addition to sending the message to their developers that following ethical principles during code creation is the right thing to do, organizations should support an ethical culture for software development—as well as for the entire enterprise.

    “It is critical for the entire business to understand the net positive impact of ethical conduct in development on the businesses risk profile and overall bottom line,” Volk said. “Similar to GDPR compliance, there should be awards for outstanding ethical conduct in coding that can be published to the outside, showing customers the value of doing business with this company.”

    — B. Cameron Gain

  • Why Database Development is in a League of Its Own

    Why Database Development is in a League of Its Own

    Despite how the database is the lifeblood of many organizations, its management remains siloed and is more often than not left to a separate team of resident experts outside of the sphere of DevOps. Database developers also may work separately from the database administrators, thus further slowing down deployments.

    The end result, of course, is that database management generally fails to benefit from the same level of agility DevOps offers application development. Bottlenecks thus occur when slower and less-agile database development holds up DevOps-managed application releases and deployments.

    Determining the role DevOps needs to play for successful database development hinges on a number of things, including making sure everyone is on the same page when it comes to database changes.

    Database changes can mean different things to different people. For example, a database change can mean applying a patch or fix, or it can mean deploying database changes. It’s thus important to add context to avoid confusion. “When you talk about deploying database changes, it involves changing the structure and the logic of a database to keep it in sync with the applications it supports,” said Ben Geller, vice president of marketing for Datical.

    “Database release automation” also calls attention to how DevOps needs to address both the application-code pipeline and the database-code pipeline, Geller said. “When you’re doing application release automation, you’re automating the build, deployment and release of application code. When you’re doing database release automation, you’re automating the build, deploy and release of database code.” Geller said. “You need both of those things to happen in sync to in order to ship software.”

    An example of a database change that can be processed with Datical’s rule engine. Source: Datical

    The ability to rely on a DevOps teams to successfully deploy and manage database schema and logic changes is also contingent on adopting the right tools.

    This is not to say that making the shift to using DevOps to give database development the attention it requires is easy. Getting there often can require major changes to an organization’s DevOps’ processes, including making cultural and job-definition adjustments. Realizing what exactly is involved conceptually as well as adopting the necessary tools, for example, represent the starting points.

    Meanwhile, the resulting advantages and improvements to an organization’s ability to deploy database schema and logic changes in ways described above should pay off in both the near and long term. This likely will lead to improvements in agility measured by deployment speeds and other key performance metrics.

    — B. Cameron Gain

  • Why Serverless Needs DevOps

    Why Serverless Needs DevOps

    EDITOR’S NOTE: This article was updated July 2, 2018

    Serverless, like Kubernetes and microservices, is a new technology. Yet, despite the amount of blog, forum and news-related posts published about serverless, it represents only a fraction of all IT deployments.

    Aside from the new factor, serverless shares few similarities with Kubernetes and microservices. Organizations turn to Kubernetes and microservices platforms to add more agility and, in many cases, computing power to their IT operations. Serverless deployments, meanwhile, are seen mainly as a way to save resources by relegating server management to third parties.

    Ultimately, cost savings is the main benefit. A successful migration largely hinges on DevOps, especially at the early adoption stage.

    “There are ways to use serverless while delivering a very rich customer experience,” said Sanjay Challa, senior product marketing manager at Datical. “It is about putting the pieces together in a very right way to do that.”

    More specifically, Challa said DevOps is relevant to serverless deployments because:

    • DevOps promotes collaboration between development and operations — a core mantra is “you build it, you run it,” Challa said. “Serverless deployments essentially embody this central tenant: it’s frankly difficult to separate development from operations because any edit to a serverless function needs to be in the context of its operation in the cloud (the cost of the resources the function will incur and the net user experience),” Challa said.
    • With serverless architecture, there is no longer a line between cloud operations engineers and developers. This is because “the roles are collapsed into one, thus embodying the fundamental core of DevOps, to collapse and harmonize the development and operations functions.” Challa said.

    For data and database management, Challa said it’s also important for teams not to forget about the underlying database and data architecture, when moving to the cloud and to new serverless architectures. “If teams only focus on the application code and forget about the database, they are setup to fail as changes to the data/persistence layer simply will not be able to keep up and scale with application changes,” Challa said. “This potentially leads to quality issues, outages or even data loss in the event of a hastily made or erroneous database change.”

    Serverless Not 

    The definition of serverless can vary, but among the many offerings available, it usually refers to functions-as-a-service (FaaS) and backend-as-a-service (BaaS) services. Despite its name, serverless has a lot to do with servers—but organizations delegate the management of those servers and the associated infrastructure to third-party cloud providers. In this way, organizations upload code or applications and the third party maintains and runs the servers. Amazon Web Services’ (AWS) Lambda, Google’s Cloud Functions, IBM’s OpenWhisk and Docker’s Serverless Docker are among the leading offerings.

    When an organization decides to migrate some or all of its data to a serverless platform, it’s important to note the technology’s drawbacks, especially as they relate to DevOps. Common downsides include slower computing performance and less capacity to run code compared to what is available when using servers on-premises or on the cloud. In the case of AWS Lambda, for example, the maximum total of concurrent executions per account is set to 1,000 by default per region and memory capacity for applications is limited to just over 3GB.

    Also, by shifting server management to a third party, organizations also are delegating those management functions, including many associated server-related security and monitoring capabilities.

    Ultimately, it will be up to the DevOps group to weigh the advantages versus the disadvantages when deciding whether to migrate to serverless platforms. While serverless technologies could potentially frustrate some developers because of the performance constraints on computing, memory, etc.; the key issue is to choose the right tool to solve the right problem, Challa said.

    “Each tool has its place,” Challa said. “Serverless is not a cure-all – but is just another tool for enterprises to consider.”

    Job Description

    Migrating to serverless also means job responsibilities will be affected, which will require DevOps to manage. “When you move to serverless, a lot of roles are disrupted. You need your network and infrastructure guys less than you did before, for example,” Challa said. “So, your team will look very different, since serverless teams in general looks very different compared to traditional IT operations.”

    It is also necessary to solve any existing DevOps challenges you have first before you make the switch to serverless, Challa said. “Otherwise, you are setting yourself up to fail,” Challa said. “Without transparency and strong coordination, moving to the cloud and to a serverless architecture will only slow things down—or, worse, lead to outages and quality issues.”

    However, once a serverless platform has been successfully set up and is running, DevOps’ workloads should decrease, since there will be less server maintenance work to do, said Holger Mueller, an analyst for Constellation Research.

    “With FaaS, DevOps is less relevant as deployments take place within the FaaS framework,” Mueller said. “There is no need for DevOps to write scripts or manually do anything. Normally, everything should just run itself.”

    However, Challa disagreed that serverless deployments completely run on their own once deployed. “Someone had to set up and configure a pipeline to enable developers to validate, build and ultimately deploy their serverless code. That someone must also play a DevOps function in enabling a path from a developer’s workstation to the cloud that supports the serverless capabilities—not to mention the work that needs to be done to connect the serverless application code running in the cloud to meaningful data,” he said.

    — B. Cameron Gain

  • How DevOps Replaces the BYOD Mindset

    How DevOps Replaces the BYOD Mindset

    The impasse is clear: users often have no formal way to effectively communicate to IT departments how certain devices and apps are useful for work and should be allowed to connect to the enterprise’s network. Since the debut of smart phones well over a decade ago, so-called bring-your-own-device (BYOD) policies as a potential solution have served as a solution, but have also fallen short for reasons we’ll discuss below. The idea behind BYOD is to allow users to connect their devices in limited circumstances and often without full access to the network.

    BYOD also predates DevOps and serves as one of many precursors for IT and security working more closely with other teams within the organization. This mindset of collaboration that BYOD fosters, of course, is essential to DevOps, said Holger Mueller, an analyst for Constellation Research.

    “The tension between the business and IT really is about scaling an organization’s operations in a way that is both flexible and business-focused,” Mueller said. “Compromise really matters.”

    However, DevOps, in part, can remove the need for BYOD and even replace it from IT jargon. BYOD first came about when IT, operating in isolated silos, struggled with accommodating users who used their own devices for work and, even more worrisome, often connected their devices to the network without permission. This worry is eliminated with DevOps when business, IT operations, QA, InfoSec and development teams, in the spirit of fostering collaboration across the enterprise, decide together what devices and apps are adopted, and then lay the security groundwork.

    “With the advent of more agile and distributed infrastructures, DevOps teams don’t have a walled-garden assumption anymore, which makes BYOD less of a problem in general,” said Siri Oaklander, advanced technologies principal for CloudPassage. “When BYOD started, the concern was these devices represented an unknown inside the corporate walled garden, and now we are not depending on the walled garden nearly as much for security.”

    New Mindset

    Enabling users to bring new devices and apps into the network certainly falls under the culture part of DevOps. Someone in DevOps who is a business team leader might suggest a very useful app or platform the IT department, the developers, and InfoSec readily review and test because it makes good business sense. Again, this type of interdepartmental collaboration is difficult without DevOps.

    For organizations without DevOps, suggested changes from users requesting the IT department accommodate new devices and apps, even when BYOD policies are in place, are often met with hostility, since it means more work with little perceived direct gain for an isolated IT department. Those working in IT, in this context, thus have little motivation to do the legwork to make room for new devices to manage. DevOps, of course, helps to change this mindset.

    “DevOps-style security  completely changes the boundaries and gateways, eliminating a lot of the concerns associated with BYOD,” Oaklander said. “It’s not so much that DevOps directly addresses BYOD as that the security model used in DevOps is far less vulnerable to having unmanaged devices inside the network.”

    Bring-Your-Own-IaaS

    BYOD came into play before the emergence of massive cloud deployments and the monumental shift many organizations have made to the cloud. Then, operations were often exclusively tied to the data center. Smart phones and other devices, once behind the firewall, were connected to the network that ran on on-premises servers. These servers, as well as virtual machines, were the core parts of the business and often mission-critical, noted Ed Smith, product marketing principal, for CloudPassage.

    “Now DevOps teams no longer have to rely on IT for servers either, they simply go to AWS with their credit card and bring their own infrastructure as a service,” he said. “The similar challenges apply here as they did with BYOD: How does the company control cost and risk without slowing down innovation? And there’s more at stake here because these are back-end servers used by many people as opposed to a device with a single user. BYOD happened because business users demanded it to be agile and competitive, and I think we’re seeing the same thing with what may be called ‘BYOIaaS.’”

    DevOps should thus be ready to take advantage of new cloud solutions, as well as cloud-exclusive applications, in ways BYOD would never have allowed.

    — B. Cameron Gain

  • Using CALMS to Assess an Organization’s DevOps

    Using CALMS to Assess an Organization’s DevOps

    Of the tried-and-tested frameworks that allow enterprises to assess DevOps in their organization and how it can be improved, the CALMS model remains particularly useful.

    CALMS, which stands for Collaboration, Automation, Lean, Measurement and Sharing, is particularly helpful for analyzing an organization’s DevOps structure, and ultimately, its utility in any organization. The CALMS framework covers all stakeholders within DevOps, including business, IT operations, QA, InfoSec and development teams, and how they collectively deliver, deploy and integrate automated processes that make business sense.

    “DevOps as a technique is slowly but steadily maturing, so it’s good to see general assessment methods like the CALMS model,” Holger Mueller, an analyst for Constellation Research, said. “The CALMS model gives a good frame of reference to compare the maturity of a DevOps team, and as such,  is invaluable for assessing the state of teams for the transformational change that goes with it.”

    Applying CALMS

    Here are a few ways CALMS can be applied to DevOps for enterprises either thinking about shifting to a DevOps structure or seek to make improvements to an existing deployment.

    Culture

    It is long-established that technology adoption must be to serve a business need rather than investing in technology for its own sake. This shift in mindset applies to how the “culture” component of CALMS supports how the forecasted ROI associated with automating a process must be championed across the DevOps team. This mindset is especially important for getting the non-technical business teams onboard, Mueller said.

    “DevOps must have the backing from the business executives. That’s a crucial factor in the culture part,” he said. “One thing software teams can do is use successful software deployments to help convince the business executives in DevOps to make the investments. Those are the kinds of tribal events that every DevOps organization needs.“

    Automation

    Netflix is well-known as an exemplary case study for DevOps automation. Among other things, it can deploy code and software updates in a matter of minutes across its entire massive infrastructure, many times throughout the day. But Netflix’s example of automation does not take into account what can go wrong at firms that want to follow Netflix’s example when automating their software deployments and updates, Mueller said.

    “The risk is always deploying too fast and you end up deploying bad code,” Mueller said. “Automation, of course, needs to take this into account and compensate. But not everybody can do that.”

    Lean

    Once completed, it is relatively easy to document cost savings by eliminating resources. Within the CALMS framework, the corresponding “lean” component in DevOps is thus relatively easy to assess, Mueller said.

    The good thing about DevOps, Mueller said, is companies can come to a consensus ahead of time regarding what they consider to be a lean operation.

    However, he added, “There is always the risk of being so lean you begin to err on the QA side.”

    Measurement

    The success of software deployments is relatively easy to measure once completed. However, attempting to measure future deployments as part of a forecast model is, of course, much more challenging.

    “It can be surprisingly tricky to measure how good DevOps is ahead of time,” Mueller said. “Measurements should thus allow errors to be pinpointed  quickly during the post-deployment stage to fix the code if needed very quickly.”

    Sharing

    Sharing, in many ways, overlaps with culture. This is where assessing whether all of the different teams within DevOps are working together and communicating comes into play.

    “Thanks to  DevOps, the days of the lone developer are long gone. But sharing is not always easy,” Mueller said. “Even within separate teams, it is easy to fall into the trap of wanting to get your own work done without necessarily thinking about the team as much as you should.”

    The End Result

    While applying CALMS to assess DevOps never hurts, the framework is still not as important as one of the main objectives of DevOps—namely, using technology to make organizations’ operations more agile and reactive to customer needs, Mueller said.

    “At the end of the day, assessment methods such as CALMS are great, but they are never as important as focusing on implementing next-generation applications,” he said.

    — B. Cameron Gain

  • How DevOps Helped One Firm Get GDPR Right

    How DevOps Helped One Firm Get GDPR Right

    There has been a lot of press about how many, if not most, enterprises are still unprepared to comply with the European Union’s (EU) General Data Protection Regulation (GDPR) just days before it takes effect.

    However, executives from Cybric, a security platform provider, said their company has been ready for some time—and they thank DevOps for that. Their case study also shows how firms that are still struggling to get started before GDPR takes effect can do what is necessary as they integrate compliance with their operations.

    As soon as GDPR appeared on Cybric’s radar screen more than a year ago, the firm began to prepare. GDPR quickly became a compliance and data management process discussed among others on a regular basis and, as part of its DevOps, it involved the participation of all the stakeholders involved.

    “One core part of the culture of DevOps is about collaboration, sharing and communications and making sure you have automated processes in place,” said Mike D. Kail, chief innovation officer at Cybric. “That is, in part, how we were able to do what had to be done for GDPR.”

    Standard Procedure

    Before GDPR was announced, Cybric already had its data flow management processes in order, Kail said. This included keeping transparent records of data sources and the corresponding geographic locations of the individuals in the databases. “We were already analyzing how we processed our data and knew where it was going,” he noted. “We were also always looking at all the ways we could automate how we handled data flows.”

    The different infrastructure, development and business teams, of course, have also played a collaborative role in Cybric’s data flow management processes and resulting GDPR compliance. “Each team figures out how they how they can help, which goes back to the collaborative culture of DevOps,” Kail said. “It’s everybody’s responsibility and not just one team’s concern in the company. In the case of GDPR, the fines and levies can be significant, so everybody should take this seriously and not put it off and say ‘that’s not my problem.’”

    In this way, Cybric was in a position to respond to the demands of GDPR compliance long before the deadline.

    “One result of DevOps is you always take care of where the data is and how it’s being processed in an automated way,” Kail said. “The wrong way consists of manual, out-of-bound efforts for processes and tasks that people ultimately screw up or forget to do on a regular basis. And when that happens, you now have potential compliance issues.”

    GDPR’s Long Arm

    Some firms may be led to believe they are not concerned by GDPR if they do not store customer data from European customers. What they may not realize is that any data—whether it’s personal data for vendors, sales leads or general third-party business contacts for individuals based in a EU country—is protected by the GDPR mandate.

    Cybric, for example, outsourced its customers’ personal data. However, the firm still must comply for individuals who visit its website and submit personal information to download marketing collateral.

    “I think marketing is an area that a lot of people don’t think about too much,” Kail said. “They are like, ‘I don’t have any personal data directly,’ but indirectly, they do have personal data and must be GDPR-compliant.”

    Many organizations have not yet prepared for GDPR since they have not fully understood the regulation and whether it applies to them or not. But although some of GDPR’s terms are opaque, organizations still should not delay compliance just because they do not completely understand what is involved. “I think a lot of people are trying to delay their compliance even though the GDPR deadline is just three weeks away,” Kail said. “And sadly, their databases are just not ready since they have not thought about the complexity of GDPR compliance and certainly not in a DevOps way.”

    Small-to-medium-sized enterprises should also not be concerned about having to invest a disproportionate amount of resources to become compliant compared to what large firms will have to spend. Cybric’s small size—with fewer than 20 full time employees—has actually played to its advantage, Kail said. Additionally, Cybric’s story offers a look at how a small-to-medium-sized enterprise can use DevOps for GDPR.

    “As a small company, putting together a collaborative process with all of the different departments made it much easier for us,” Kail said. “That is also the approach people have to take.”

    — B. Cameron Gain

  • Despite DevOps, Firms Unprepared for GDPR

    Despite DevOps, Firms Unprepared for GDPR

    Most organizations are not fully compliant with the European Union’s (EU) General Data Protection Regulation (GDPR) before it takes effect in May, analysts report.

    While DevOps certainly gives organizations the mean to turbo charge the compliance process, stakeholders outside of IT departments often are failing to greenlight this necessary project ahead of the deadline, due largely to uncertainties about the regulation.

    Not being in compliance could hit organizations hard, with fines up to 4 percent of their annual revenues or €20 million.

    The Cloud Security Alliance (CSA) and Netskope, for example, recently released the results of a survey of more than 1,000 respondents about their organizations’ GPDR readiness. The survey revealed a full 83 percent were not very prepared for GDPR. While 85 percent had taken steps for compliancy, only 31 percent had well-defined plans for meeting the provisions of GDPR.

    The GDPR’s “right to erasure,” (53 percent) “data protection by design and by default,” (42 percent), and “records of processing activities” (39 percent) were deemed the biggest stumbling blocks for compliancy, according to the study.

    A separate survey of 700 network security and IT professionals by Enterprise Strategy Group (ESG) showed only 11 percent of firms were completely ready for GDPR ahead of the May 25 deadline. Thirty-three percent said they were prepared to publicly disclose data breaches within the GDPR-mandated 72-hour period, and 33 percent and 44 percent percent of the firms surveyed were mostly or somewhat prepared, respectively.

    Most organizations ESG surveyed also reported they are investing in GDPR, reflecting the seriousness in which they are regarding the mandate. While only 10 percent said they had made or were planning to make major investments in GDPR, 63 percent said they would make or had made incremental investments.

    Analyst firm Varonis made similar findings after completing a survey of 500 IT security experts in the United States and Europe in October, out of which 200 were in the United States and the rest of those surveyed were equally split between the UK, France and Germany.

    Varonis also found 60 percent in the EU and 50 percent in the United States faced serious challenges before they could be GDPR-compliant. However, 70 percent of the firms represented were also convinced GDPR compliancy would give them a competitive edge.

     

    IM000302.JPG

    Where Is the Data?

    Much of the uncertainty about GDPR reflects how organizations often fail to understand where exactly their data is located. While not specific to GDPR, Varonis found many organizations lacked fundamental data-protection protocols. Those surveyed revealed, for example, 21 percent of their organizations’ electronic folders were “open to everyone.” The survey also revealed 54 percent of the firms’ data was stale. Effectively tracking data extending from on-premises servers to across the cloud was often cited as an issue, making it difficult to track the exact origins of customer data and to determine whether it might be subject to GDPR protection or not.

    “We live in a hybrid world in which data isn’t stored entirely on-premises or completely in the cloud. The hybrid model creates additional challenges and potential risk from a security and data governance standpoint,” Ken Spinner, vice president of global field engineering at Varonis, said. “You can’t assume your data is safe in the cloud. If your cloud environment isn’t secure, your data won’t just be in danger of being exposed to your entire organization—it could be accessible to the world.”

    Uncertainties Abound

    A lack of understanding about what GDPR compliance involves is often cited an impediment to making necessary changes for compliancy. Much has been reported, for example, about whether EU citizens, residents, or simply those who are only temporarily on European soil are protected by GDPR. How the EU will impose fines against non-EU organizations also remains murky.  According to ESG data, less than one-third of the respondents of the organizations that took part in its survey fully understand all the GDPR’s requirements.

    These questions, of course, largely need to be resolved by legal counsel. Meanwhile, many legal departments are waiting for more guidance from the EU about uncertainties mentioned above, as well as other remaining questions about the GDPR’s scope.

    In other words, DevOps is ready to do the necessary, while legal and other stakeholders who fully understand what needs to be done must pull the trigger first. Only then can DevOps, consisting of IT operations, QA, InfoSec and development teams take over. When that happens, DevOps’ role will remain critical for making compliance more agile, automated and, ultimately, reliable.

    “DevOps can assist companies in complying with regulations like GDPR by ensuring that key regulatory requirements are part of the initial design criteria, and taken into account when applications are updated,” Varonis’ Spinner said. “GDPR, manual methods of enforcing data policy aren’t realistic solutions because large organizations could have millions of files. DevOps can support GDPR requests with processes and solutions that ensure personal data that falls under the new regulations is protected and used appropriately.”

    — B. Cameron Gain

  • Google Analytics Adapts to GDPR, But Questions Remain

    Google Analytics Adapts to GDPR, But Questions Remain

    The  General Data Protection Regulation (GDPR) will have an effect on how Google Analytics collects and processes data and how DevOps uses the tool—at least, that is what is known for sure at this time. These changes also should almost certainly impact DevOps for any organization that relies on the tool to collect and analyze user data. It is also known DevOps teams will have to reconfigure their Google Analytics implementations, even if an organization has no users based in the European Union (EU).

    However, while Google has recently offered some guidance about modifications to Google Analytics that impact DevOps, the company has yet to clarify some key points about changes ahead of when the new mandate takes effect May 25. In the immediate, here are some changes Google has communicated so far and actions DevOps will need to take ahead of the regulation’s deadline.

    Immediate Action Required

    The GDPR’s “right to be forgotten” provision offers users options to demand the deletion of personal data third parties store and share. To meet the terms of this provision, Google Analytics will allow organizations to manage how long their users’ data remains on Google’s servers. In this way, Google Analytics will automatically delete user and event data older than the date specified. Organizations can specify that the data remains on Google Analytic servers for 14 months, 26 months, 38 months and so on, for a maximum 50 months. It is also possible to opt for data to not expire automatically. Google Analytics says it will not delete information based on aggregate user data.

    Google Analytics also will allow organizations to delete data for individual users in an EU country that can be used to identify them under the GDPR’s “right be forgotten” clause. This data will include common identifiers that Google Analytics stores—including standard Google Analytics first-party cookies, user ID or App Instance ID.

    However, Google Analytics has yet to specify details about how organizations will be able to delete user data. While the process will be animated, Google says more information “will be available shortly,” presumably ahead of the GDPR deadline.

    Google says it is also drafting a new “EU User Consent Policy” ahead of GDPR. This policy that customers will have to agree covers organizations’ “responsibilities for making disclosures to, and obtaining consent from, end users of your sites and apps in the EU.”

    Another key modification Google has yet to reveal is the interfaces Google Analytics will offer that will allow organizations to make changes to how their users’ data is stored. Whether DevOps will be able to automate these processes or not will depend largely on whether Google Analytics will offer a GUI, an API or both.

    “If Google Analytics offers a GUI with no API, there is not much a DevOps team can do to automate it outside the existing functionality, since you need a person to do that. But if it’s an API, DevOps teams can weave the controls into their existing frameworks,” said John L. Myers, an analyst for Enterprise Management Associates (EMA). “If both are available, then you’ve got the best of both worlds.”

    Additionally, an API would allow the retention and deletion tools to work within existing DevOps frameworks and to become automated as part of business processes, Myers noted.

    The DevOps Challenge

    DevOps will obviously need to be prepare for GDPR in other ways outside of the scope of changes to Google Analytics or face fines up to 4 percent of their annual revenues or €20 million ($25 million), whichever is greater. Indeed, GDPR applies to all organizations worldwide that collect data from users in EU countries. In fact, it is often incorrectly reported the new privacy mandate applies to just EU citizens, while instead, the regulation concerns data collected from any user who is physically located in an EU country, regardless of nationality. Regardless, it is also obviously impossible to determine whether user data protected by GDPR including cookies, names, email addresses, social media posts and other information belongs to a user with an EU IP address who might just be visiting the region or is a full-fledged EU national.

    Given the far-reaching provision of GDPR that places strict controls on how third parties store and share data and protect their online privacy, GDPR likely will fall under an urgent DevOps project category, requiring the input of the change advisory board (CAB), as well an organization’s IT operations, QA, InfoSec and development teams. The degree to which GDPR will change code deployments and processes will depend on the organization’s business model, of course. GDPR compliance should also require review of qualified legal counsel.

    Meanwhile, Google Analytics says its tools can help organizations to comply with GDPR for data collection policies. These features include cookie settings, privacy controls, data sharing settings, data deletion on account termination and IP anonymization.

    However, as mentioned above, Google still need to provide DevOps with more clarification about certain changes to Google Analytics affecting organization ahead of the May 25 deadline. Many in the DevOps community are also very likely waiting to learn about other ways DevOps can use Google Analytics for GDPR compliance.

    — B. Cameron Gain

  • DevOps to the Rescue as GDPR Deadline Looms

    DevOps to the Rescue as GDPR Deadline Looms

    The stakes are high: Organizations failing to comply with the European Union’s (EU) strict General Data Protection Regulation (GDPR) face fines up to 4 percent of their annual revenues or €20 million ($25 million), whichever is greater.

    But while the threat of what happens if organizations ignore the mandate when it takes effect at the end of May is clear, how DevOps teams will lay the groundwork to comply is less cut and dry.

    At the same time, DevOps can allow organizations to meet the regulation in an agile and relatively quick way by integrating the working efforts of an organization’s stakeholders, IT operations, QA, InfoSec and development teams.

    “GDPR is the new boogeyman in tech, kind of like Y2K was years ago,” said John L. Myers, an analyst for Enterprise Management Associates (EMA). “Ideally, all of this will be handled with automation and DevOps.”

    The Right to Disappear

    An especially strict GDPR provision is any individual user’s right to both opt out of having their data collected by a private enterprise as well as their right to be forgotten. The so-called “Right to Erasure” Provision gives EU-based individuals the right to demand the removal of access to their personal data on an organization’s servers, either on-premises or the cloud. An individual’s right to have personal data “forgotten” also applies to personal information an organization may communicate to third parties.

    “The challenge lies with tracing personally identifiable information spread across multiple platforms, including third parties and CRM, ERP, payments, ordering, etc.,” Myers said. “Most organizations don’t have that level of visibility and transparency.”

    The challenge is thus understanding where all the instances of a person are within a data landscape, he said. If an individual in the EU decides to be forgotten and to opt out, an organization must know all the places where that person is identified within data management platforms and files, such as spreadsheets. For organizations that have a relatively small number of places where they store data, the process is easier, of course.

    However, there is one important footnote in the right-to-be-forgotten provision: Organizations do not have to actually delete personal data and records if individuals choose to be forgotten, Myers said. Rather, DevOps can encrypt their information, allowing organizations to keep transactions, customer counts, inventory, etc., but without identifying the individuals. DevOps also can be used to rapidly deploy code and processes to validate requests to be forgotten and to “unforget” individuals who later opt in.

    “With encryption, DevOps keeps one key for the company and sends or stores the other key for the EU individual in case they change their mind,” Myers said.

    However, using DevOps to automate compliance might be delayed in some cases, as organizations may first have to improve their data inventory management practices to better visualize the often-various places where individuals’ data is stored, Myers said.

    “Without an inventory of all the ‘wheres’ of customer, partner or supplier data that might be listed in the various data platforms, it will be difficult to automate out of the gate in May or even June,” Myers said. “As organizations get a better understanding of the inventory of their data landscape, they can add DevOps automation to the process. But at the earlier stages, it might be a manual process that is monitored, managed and standardized so that DevOps can take over and make it a reality.”

    Some Good with the Bad

    Discussions about GDPR tend to focus on the associated pain and potential costs organizations face to meet the mandate. But with every change comes opportunity. With respect to the GDPR clause giving individuals the right to be forgotten, for example, DevOps will have the freedom to deploy code and processes to boost their organization’s transparency for individual data storage, both in-house and what third parties access.

    “Having this inventory or visibility into all the components of a data landscape is a key for digital transformation,” Myers said. “Companies can use it as a good reason or excuse to move toward a more standardized and transparent environment that will accelerate those initiatives.”

    Some DevOps team members may also take pride in knowing achieving compliance for GDPR could also arguably be a step in the right direction to improve data protection for the common good of society.

    “There is the issue with actually securing the data that is collected to keep others from obtaining and exploiting it. Since identity theft is a raging problem, protecting personal information is paramount,” said David Monahan, an EMA analyst. “If we had usable federal legislation in the U.S. like GDPR, we would have had a much likelier outcome of Equifax being severely fined or even closed down for its poor data-protection practices. Credit bureaus are predatory when it comes to data, and since individuals have no right to refuse collection, all of that information is bought and sold without our consent.”

    — B. Cameron Gain

  • DevOps Isn’t Getting Cloud Security Right (and What Can Done About It)

    DevOps Isn’t Getting Cloud Security Right (and What Can Done About It)

    The song title of Billy Joel’s 1977 hit, “Get it Right the First Time” aptly describes what DevOps teams need to take to heart when making the jump to the public cloud. But in most cases, security is lacking in the pipeline when making the shift—and a change in DevOps culture and mindset is necessary to “get it right the first time” for cloud security, according to McKinsey analysts.

    It seems commonsensical to make sure adequate security protocols are extended to the DevOps pipeline before migrating to the public cloud. But in practice, statistics tell a different story.

    According to analyst firm McKinsey, a full 78 percent of more than 100 firms recently surveyed are not reconfiguring their security tools when migrating to the cloud. Similarly, most security standards in place among the enterprises listed in the survey are non-sustainable for cloud networks.

    “There are, of course, many security configurations for a public cloud for DevOps that need to be in place,” said James Kaplan, a McKinsey partner and cybersecurity lead. “Creating your server image in a public cloud can create many vulnerabilities [compared to in-house data centers].”

    Security improvements will obviously need to be made on an industrywide scale in the near future as more companies embrace the cloud for DevOps. Currently, only 10 percent enterprises McKinsey surveyed have ported more than 40 percent of their workloads to the cloud. Within three years, that percentage is expected to jump, as 80 percent plan to migrate more than 40 percent of their workloads to a public cloud platform.

    Culture Lag

    At issue is how DevOps teams’ cloud projects very often remain straddled by security practices dating back to the 1990s.

    “Most DevOps security is still with a ticket-based model,” Kaplan said. “They just called Joe in security and asked him to do x, y and z.”

    Porting legacy infrastructure and operations to the cloud can also be problematic. A startup, for example, might make the jump more easily than a 30-year-old Fortune 500 company with data centers located in the North America, Europe and Asia. “It’s one thing if you’re building greenfield, such as creating a video streaming service from the ground up,” Kaplan said. “It’s much tougher to go to an agile DevOps cloud platform world if you are dealing with 30 years of legacy applications, eight mergers and all that type of good stuff.”

    The Big Meld

    Cloud servers can be fired up and ready to use in minutes. But it can take weeks before standalone security departments catch up. This might mean waiting on a security team to manually complete vulnerability scanning, penetration tests and firewall installation before cloud deployment. Or, in the worst case, these steps remain incomplete, leading to relatively easy-to-exploit vulnerabilities on the public cloud.

    “DevOps cloud security requires particularly high levels of sophistication and capabilities, as well as agility,” Kaplan said. “There has also traditionally been less focus on speed.”

    The solution is to converge security with the DevOps from the outset ahead of cloud development. In this way, security controls, reviews and deployment are integrated with DevOps, to create DevSecOps for the cloud migration process. This heavily involves developing APIs for security automation, Kaplan said.

    Implementing DevSecOps also requires investments in training and culture. This consists of ensuring DevOps teams receive additional training  to ensure security is integrated into every step of development work and for developers to maintain security support once the switch to the cloud is complete, Kaplan said. Training ensures DevOps team members have working knowledge of security APIs and orchestration technologies, and are eventually able to create new security APIs for DevSecOps, Kaplan said.

    The end result is that cloud deployment remains agile, as it should be. Cloud migration is done more swiftly and efficiently compared to traditional security models, once the DevOps team has acquired the security knowledge it needs, Kaplan said.

    “DevOps teams really need to expand their purview to think more about security. They must create more rigor around the security services and how the developer journeys should involve security,” Kaplan said. “And they then need to think about how to incorporate those security APIs into the application scripts for infrastructure APIs, capacity scaling and what have you.”

    — B. Cameron Gain