devopsy.kinsta.cloud

Category: IT as Code

  • Perfect Sense Open Sources Gyro to Automate Cloud Provisioning

    Perfect Sense Open Sources Gyro to Automate Cloud Provisioning

    Perfect Sense has launched an open source project dubbed Gyro that provides an alternative approach to automating cloud infrastructure provisioning and management.

    Gyro was developed as an alternative to other open source projects such as Terraform and Pulumi, said CTO Jeremy Collins. It is designed from the ground up around a programming language that allows DevOps teams to define infrastructure as code, and features logic built into configurations to make it easier to create more precise workflows, he said.

    Adding logic to create equivalent workflows in rival platforms is more complex, Collins noted, adding the ability to add logic makes it easier to not only provision cloud infrastructure but also to roll it back when necessary.

    Perfect Sense developed Gyro to make it easier to manage the infrastructure for its Brightspot content management system (CMS). As such, Gyro can support multiple cloud computing platforms.

    In addition to making it possible to add cloud platforms to an existing configuration, Collins said it can be used to create custom commands and define multiple extension points directly within the Gyro language.

    Perfect Sense Gyro

    Perfect Sense developed Gyro to automate the provisioning of virtual machines. Since then, the company has extended its capabilities to add support for emerging cloud-native platforms such as Kubernetes.

    Collins said Gyro provides a single extensible tool spanning a broad range of DevOps processes, from provisioning infrastructure to discovering what services already exist.

    Despite the popularity of rival tools such as Terraform, it’s still early days in the adoption of infrastructure as code. Most IT organizations are a long way from standardizing on any one platform for automating the provisioning of infrastructure. In fact, it may not be uncommon for different DevOps teams within the same organization to employ different platforms for provisioning infrastructure.

    Gyro’s ultimate success will depend much on Perfect Sense’s ability to foster an open source community. The Brightspot CMS is used by the Los Angeles Times, Walmart, Mattress Firm, Univision, Sotheby’s and US News and World Report, so Collins said there is a base of support for Gyro on which to build a community. Perfect Sense is looking to build a community that will continue to extend the reach and scope of the platform by adding additional plugins.

    Regardless of the approach taken, as the number and rate at which workloads are being deployed on cloud platforms increases, it becomes critical for IT organizations to find a way to automate processes. It’s not clear to what degree those workloads will be provisioned by developers themselves versus traditional IT operations teams that have learned how to program. However, one way or another the provisioning of cloud infrastructure is going to be automated.

    — Mike Vizard

  • The Disservice of Cloud Consolidation

    The Disservice of Cloud Consolidation

    There’s no secret that over the past five years especially, the major (“tier 1”) cloud infrastructure players—Amazon, Microsoft and Google—have been snatching up smaller specialty providers, particularly cloud migration and security services.

    While this acquisition strategy immediately aims to strengthen and expand the provider’s direct and tangential cloud infrastructure offerings, the long-term goal is customer attraction and retention.

    In consolidating cloud infrastructure and related services, cloud vendors are targeting a basic human desire that often bleeds over into business decisions: convenience.

    • “Finding a cloud provider seems hard.”
    • “Switching to the cloud seems hard.”
    • “Managing more than one cloud seems hard.”
    • “Keeping up with more than one vendor seems hard.”

    The play is transparent; the marketing is already in your psyche. People don’t like doing more than they have to, whenever possible. So, why not apply that tick to the cloud infrastructure experience? Why not use a provider where everything is already in one place?

    Truthfully, the move toward cloud consolidation is a step in the opposite direction from where we should be going. The future lies in a multi-cloud approach, not a consolidated one.

    Multi-cloud approaches offer both businesses and their customers several advantages over consolidated infrastructure.

    • When a business’ cloud infrastructure exists solely with one provider, every cloud-related business activity—and every customer interaction with those activities—is beholden to the provider. A provider outage is a business-wide outage, and a business-wide outage is unacceptable.
    • Multi-cloud approaches allow businesses to take advantage of best-of-breed cloud infrastructure. A business can implement databases, containers and other virtual infrastructure in a more highly optimized way.
    • Data held in disparate systems can be better partitioned and more secure than data stored with a single provider. Also, these disparate systems can bolster adherence to existing (and likely coming) data privacy laws and compliance regulations both nationally and internationally.
    • Utilizing cloud infrastructure housed physically closer to a business or its key users can drastically influence business activities in industries where parts of seconds count (e.g., finance).

    Aside from the standard reasoning, I’d argue that there’s additional economic health in taking a multi-cloud approach. Competition naturally drives innovation, stabilizes costs and encourages improvement. Where one provider may falter, three others might specialize. If the majority of businesses consolidate their cloud resources with a single provider, though, the likelihood increases of services gradually worsening with no alternatives toward which to turn.

    Multi-cloud takes planning and coordination to properly implement, and careful monitoring to maintain. An additional tool or two, such as a cloud management platform or cloud integration solution (which, truthfully, many businesses are likely already utilizing), may be needed.

    But, the benefits far exceed the challenges. After all—to call upon Ken Jenkins’ iconic chief of medicine, Bob Kelso—nothing worth having comes easy.

    — Zack Busch

  • HashiCorp Tools Bridge DevOps, Legacy IT Environments

    HashiCorp Tools Bridge DevOps, Legacy IT Environments

    At its HashiConf EU 2019 conference this week, HashiCorp extended the reach of its Terraform Enterprise tools for automating the management of IT infrastructure beyond the realm of DevOps into legacy IT environments.

    Via integration with the Service Catalog from ServiceNow, IT administrators working with a traditional ITIL-based framework now can invoke Terraform Enterprise to provision IT services. HashiCorp CTO Armon Dadgar said rather than requiring organizations to hire an infrastructure engineer to automate the provisioning of IT infrastructure, IT administrators now can do the job.

    At the same time this week, HashiCorp announced that policy sets may now be configured using the source policies available in multiple version control systems (VCSs), including GitHub, GitLab and Bitbucket. The goal is to make it simpler to enforce policies that would limit, for example, the number of virtual machines a developer might be allowed to spin up within the context of a set of GitOps processes, said Dadgar.

    Finally, HashiCorp also announced that HashiCorp Consul service mesh networking software has been enhanced to include Layer 7 application traffic management capabilities alongside integration with the HashiCorp Nomad application and cluster scheduler software.

    In general, Dadgar said HashiCorp is moving toward enabling its portfolio of offerings to span multiple types and classes of IT environments. HashiCorp Consul, for example, can be run across both legacy IT environments as well as Kubernetes. Most organizations will need to support both legacy monolithic and microservices applications using a combination of DevOps and legacy ITIL processes, noted Dagar. Rather than having to master new tools for each environment, HashiCorp is making a case for a common set of tooling that can be applied across multiple IT classes of processes.

    While some organizations have fully transitioned to DevOps, many more organizations are still struggling to make the transition. Reasons for not making that transition faster range from simple inertia to a lack of skills. Rather than having to take an all-or-nothing approach to modernizing IT processes, Dadgar said HashiCorp is enabling each IT department to embrace IT automation wherever they happen to be on that journey, including being able to embrace new platforms as they become available.

    Dadgar noted that level of extensibility is critical because most tools are still being brought into organizations from the bottom up by individual members of the IT staff, rather than being championed from the top down. In the absence of an executive mandate, Dagar said the path of least resistance is to make IT automation tools as accessible as possible to members of the IT team regardless of skill level.

    There will, of course, come a day when IT leaders will try to rationalize processes around a common standard set of practices. The degree to which any IT organization has been able to achieve that goal, however, has been mixed at best. In the meantime, IT organizations will always need to keep their options as open and flexible as possible.

    — Mike Vizard

  • DevOps Chat: Identity Management with ForgeRock’s Peter Barker

    DevOps Chat: Identity Management with ForgeRock’s Peter Barker

    Two megatrends for 2019 and beyond is scale and automation. The identity management space is a perfect example. Considering all of the IP-enabled devices (machines) coming online and the billions of people and their identities, managing these billions and billions takes systems that will redefine scale and, almost by definition, have to be automated.

    Enter ForgeRock. The company is a leader in identity management for both consumer brands, IoT devices and more. In this DevOps Chat, we speak with Peter Barker, chief product officer, about the challenges to scaling at this level and how important identity management is.

    As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

    Transcript

    Alan Shimel: Hey, everyone, it’s Alan Shimel and you’re listening to another DevOps Chat. Got a nice chat lined up for today. I’m joined by Peter Barker, who’s the chief product officer at ForgeRock. Peter, welcome to DevOps Chat.

    Peter Barker: Hey, Alan, good to be here.

    Shimel: Thank you. Thank you for joining with us. So, Peter, let’s jump right into things ’cause time’s limited. ForgeRock is a company that I think a lot of people have probably heard of, but I don’t know if people are solid, you know, as a rock, on what exactly they do, so why don’t we start with that? Give us just a quick kind of “Who’s ForgeRock?”

    Barker: Yeah, so ForgeRock is recognized as the most visionary and market-leading identity and access management platform, and we serve the largest logos on the planet, solving a variety of use cases. We provide simple and comprehensive solutions for brands to serve their customers, with identity and access, to deepen their relationships with those customers. And as well to provide access management and identity solutions for employee and partner use cases as well, to really allow better productivity and connectivity in the employee base.

    Shimel: Excellent. And, Peter, I always like to ask my guest to give our audience a sense of your own personal journey. How did you come to be chief product office at ForgeRock?

    Barker: Yeah, it’s a great question and I think back on this journey I’ve been on for the last 25-plus years of my career. I originally started out on the customer side of the house in IT, doing systems development, application development for Kinko’s and FedEx, who acquired Kinko’s, but, later, the last 15 years, I’ve been in product companies, focused on enterprise software and security solutions. And that spanned mobile and mobile security, with good technology. I was at Oracle as well, running their identity and security business for a few years. And then, most recently, now with ForgeRock, over the last year, as their chief product officer.

    Shimel: Excellent. So, Peter, you spoke a little bit about ForgeRock’s mission and what’s going on, but one of the things that – I mean, it’s almost intimidating when we think about it. It’s just the sheer scale. You know, we look at ForgeRock and, I mean, you guys are doing everything from managing and working on identities of consumers coming to large consumer brand websites and applications, through to IoT devices. I mean, not to get all _____ and honest, but it’s billions and billions, right? I mean, it almost seems like an impossible job. How do you chunk that up? How do you go Agile on it? How do we manage it?

    Barker: Yeah, no, it’s – yeah, first of all, you’re absolutely correct. The world of identity, digital identity, is just exploding. It used to be, in the early days of this industry, it was around modeling identities of your employees and providing access and having governance around that access, but, as the world has shifted to consumer and business transformation around digital and having to know your customer across your digital channels, then scale started to explode in that direction because you have millions of consumers versus just thousands of employees.

    And now, in the world of things, where you have this entirely new economy that’s emerging, where things are interacting with the world on your behalf or with you, whether it’s smart devices, smart cars, smart payments, smart everything and the gig economy, it means that identity systems have to model the identities of all of those objects that are interacting in this new world we find ourselves in. And that is causing a massive need for scale.

    And, at ForgeRock, it’s been a really rich heritage and history for us to provide massive scale in our products. And we are, today, already solving some of the most demanding use cases globally, around scale and serving customers in this new digital economy.

    Shimel: A hundred percent. So let’s try to – Peter, you probably – I mean, as part of your responsibilities at ForgeRock, you probably have some metrics to put around this. Can you volunteer a little bit without divulging any _____ _____ –

    Barker: Yeah, for sure. I mean, right now, some of our largest customers are already scaled into the hundreds of millions of consumers and associated devices with those people. We have use cases defined right now with a lot of these customers that are pushing north of the billion-user mark – we’re proving that out in our labs – but, as we know, to meet the demands of scale, it really requires a new approach to the software deployment and how software supports the scale needs and becoming much more elastic and on-demand, as well as horizontally scalable, because it’s the only way that really, truly will continue to serve this need, as it continues to grow.

    Shimel: Sure. You know, Peter, I had an interesting conversation this morning with a CEO founder of an Israeli-based startup around AI. And what he was saying is the kinds of scale issues that you’re tackling at ForgeRock, it’s almost too big for the human mind to wrap around. Right? I mean, let alone at the speed. I mean, humans just can’t operate at that speed to conquer that scale. We just – it’s almost as if you need to invent or implement some sort of AI, machine learning, whatever you wanna call it, intelligence, that allows you to operate at that scale. And is that something ForgeRock is kind of building in, do you think, or is it still –

    Barker: Yeah.

    Shimel: Go ahead.

    Barker: Yeah, definitely. And we have a framework in our product called “Intelligent Authentication,” and it’s designed exactly to do what you’re describing, which is enabling our customers to continue to not only meet the current needs of scale, but the customers, they want to make the authentication and authorization function of their architecture be much more adaptive, much smarter, much more dynamic, to a conditional and contextual world that may exist.

    And, for example, our customers think about security and fraud pretty interchangeably. And if you just think about the scale problem around fraudulent activity, so, if you look at these large brands with hundreds of millions of consumers who they’re trying to provide services to, of course, there’s always some element of fraud that goes along with being in that type of business. And so they have to put in some very complicated algorithms and logic and what have you to continuously be evaluating whether a transaction that’s attempting to happen is actually fraudulent or, on the other hand, maybe it’s something going on from a malicious actor perspective, who’s doing something around security or attempting to breach.

    And so this is causing the sophistication of the techniques being used to go after these problems to really continue to elevate. AI and ML is a big part of that. Being able to integrate multiple services, who are all providing these functions into, essentially, a fabric that is evaluating the risk that’s occurring, and being able to do that at massive scale is how our customers are looking at this and they’re demanding requirements around that.

    And our Intelligent Authentication framework in our product really enables that to happen. We have the scale in the core engine. We have the framework to allow our customers to create these very sophisticated approaches to dealing with these problems that they’re dealing with, out there in the Wild West of their businesses.

    Shimel: Sure. Excellent. So, Peter, it’s December. We’re starting to look towards next year and everybody and their mother-in-law has a prediction and an opinion about what this next year’s gonna hold for us. What do you – if you had to make your best guess and place a bet, what do you think the big story is for ForgeRock and the whole identity community, in the next year or short term? Let’s say 18 months.

    Barker: Yeah, so I’ll just cover a few things that I think inform my answer. First of all, there’s some very interesting challenges that our customers are facing, that apply broadly within the market. First is really a skills gap. So, a few years ago, I started tracking a stat around cybersecurity job openings and how many of those are going unfilled and how many are projected to stay unfilled in the future. And the most recent estimate is that, by 2021, 3-and-a-half million cybersecurity jobs are going to be unfilled.

    And, if you think about that, that’s just a massive challenge for enterprises who are gonna have to continue to deal with and advance their security programs and their security capabilities, when there is a labor shortage, in essence, in the market. And what that’s requiring is vendors to provide solutions that increasingly automate their security program and to provide the security solutions in a much more automated way, so that’s one big area.

    The other is obviously cloud. You know, the most recent prediction by Gartner is that 75 percent of organizations, by 2020, will be running in multi-cloud or hybrid cloud environment, so that just keeps on marching on and forward, as we go on in time. And then, finally, our customers continue to wrestle with security and ease, where that balance between consumer convenience and security is always – it’s very delicate and it’s something that our customers are always trying to find the right balance for. And so they’re increasingly looking for solutions that both increase security but also increase the convenience for consumers.

    And so what all of that is really driving, from a prediction standpoint, over the next 12, 18 months, is our customers, they have many of the features that they really need right now and today. What they’re looking for, increasingly, is solutions to solve those problems. And so we at ForgeRock continue to innovate and deliver new, powerful capability, like Intelligent Authentication, as I talked about earlier, but the big, new element of the equation that customers have been looking for is “How can they transform their software delivery model to much more DevOps? How do they transform their identity program to be much more multi-cloud and multi-cloud approach, where they can be protecting workloads no matter where they are? And how can they do that in an environment where they have less people, less skilled people available to do the job and to do it in a much more automated way?”

    So we, on November 30th, we released a big, new release of our software, Release 6.5, which really addresses these three key things that we’re seeing with our customers. With that release, we’re now able to allow customers to dramatically increase their productivity and their competitive advantage and reducing their cost by deploying our software in these new methodologies.

    We’ve begun surveying our customers and, right now, the consensus is that customers can save as much as 25 percent on their implementation cost of software just by adopting our next release, which is a dramatic improvement over what they’ve been seeing before. And this release allows them, by providing some very simple cloud installation packages, to rapidly deploy production-ready software into a multi-cloud environment, in minutes, supporting hundreds of millions of identities. And so we’re just really excited and customers have been receiving this release very well ’cause it’s solving so many of these challenges that I talked about.

    Shimel: Absolutely. Absolutely. Peter, I know ForgeRock recently came out with some new announcements around product and so forth. Why don’t you share with us a little bit?

    Barker: Yeah. So I think, just continuing on with what I mentioned just a moment ago on Release 6.5, what we’ve done to really support the new deployment model that we’re providing to our customers is we’re giving our customers turnkey, complete DevOps-capable software to run in multi-cloud environment. And we’re providing not just images for our customers, but we’re providing all of the artifacts necessary to really do this successfully.

    That includes – we’ve standardized in Kubernetes for orchestration. We provide our customers the Helm’s Charts. We provide our customers not only that, we provide the reference architecture. We provide the reference configuration for them. We also do performance benchmarking and not only do the performance benchmarking but give our customers the performance testing tools and methodologies so that they can integrate that into the DevOps pipeline as well.

    And, finally, we give our customers all of the cost profiles of these various cloud providers – AWS, Azure, Google Cloud, and Red Hat, OpenShift are the environments that we’re supporting with this release. We’re dramatically accelerating what it takes for a customer to deploy these platforms to support the mega-scale requirements that we talked about earlier on this call.

    And the other thing we announced is that we have now surpassed 50 strategic partners in our trust network partner ecosystem. And what this does is allows customers to rapidly integrate some very innovative solutions around strong authentication or biometrics or identity proofing or risk analysis or fraud detection into their programs very rapidly because we’ve already pre-integrated, pre-certified, and pre-tested that they’re gonna work for our customers. So a very exciting release for us, here at ForgeRock, and, again, just having some tremendous response from customers on it.

    Shimel: Very cool. Excellent. Excellent. So, Peter, I think, when we started, I mentioned to you, once we start talking shop, the time goes. And we’re about out of time already, but I’m gonna let you have the last word. So I think we’ve educated some people; we’ve opened some eyes; we’ve talked about sorta what the issues, challenges are; and I’m sure there’re people listening saying, “I’m dealing with this challenge. I need this solution.” What’s the takeaway here? What’s the one thing people, if they’re gonna learn one thing, what do they need to remember out of this?

    Barker: Yeah, I think the one thing I would really encourage the listeners to think about, when it comes to identity, is, for employee identity, that’s a space that’s been very well supported and served for a long time now. But what we’ve seen is, as enterprises and brands are transforming their businesses to digital, they’ve taken identity – some have had good forethought around identity and really have put the necessary identity platform in place to support their transformation, but many have just sorta run ahead on their digitization. And they’re starting to discover that the way in which they’re supporting their customers – the customer journeys, in their digital channels, is just not seamless, and it’s because they didn’t think about the identity challenges that they’d be facing.

    And so the takeaway I’d really encourage is I think almost all brands on the planet, at this point, are in some stage of journey around digitization, digital transformation, business transformation to the new economy. And really take a look strongly at the need to bring in an identity platform to really support that because, if you don’t, you’ll find quickly that you’ll be underserving your customer experiences and your customer journeys. And, in this new world, customers really vote with their feet in the digital world, in terms of brands that they’re doing business with. And so we highly encourage folks to take a look at this.

    Shimel: Excellent. Peter Barker, chief product officer, ForgeRock, thanks for being our guest on this episode of DevOps Chat. Continued success with ForgeRock and we’ll have to have you back on soon to check in on the progress, but, in the meantime, keep us safe out there.

    Barker: I look forward to it, Alan, and thanks for having me today.

    Shimel: All righty. This is Alan Shimel for devopsy.kinsta.cloud. You’ve just listened to another DevOps Chat. Have a great day, everyone.

    — Alan Shimel

  • DevOps and the Identity Conundrum

    DevOps and the Identity Conundrum

    “Who am I?” It is perhaps the most basic question of consciousness. The answer could be subdivided by aspects of my life story … my career, my family, my beliefs, my education … the list could continue. But since I am unique, the challenge in this digital age is for me to somehow remain unique, and whatever descriptions are used to catalog who I am, I must remain at the center of them all. If my identity is stolen, how does anyone know, that I am who I say I am?

    This question is fundamental to every interaction I have with the digital world. And unfortunately, every system I interact with looks for me to redefine who I am, over and over again for each of them. I create a Facebook profile, a Twitter profile, a LinkedIn profile … and the list goes on again. But yet another weakness of our digital age is that there is no cross-reference between these systems to ensure I am who I say I am. This phenomenon remains true within DevOps tooling as well.

    The Career Identity Conundrum

    Let’s focus on only one aspect of who I am, my career. Who my current employer is dictates what electronic business systems and networks I should have access to. Switching jobs to another employer changes—or should change—the access I have. But getting more specific, what my role is at my current employer should also have an impact on what tools I have access to, and what I can do within them. And as my role changes, my abilities within a tool should change, as well. If I move from practitioner, to manager, to director, my abilities within a given tool should probably diminish, holding practitioners accountable for actions rather than superseding their responsibility by doing things myself.

    Then there is the area of focus I work on. Business segmentation differentiates my work from product or service “A” in contrast with product or service “B.” My role might be an application programmer, or database administrator, but then “who” I focus on within a company is yet another level of differentiation. The business may prefer that teams of people focused on product “A” are restricted from making substantive changes on product “B.” So two different database administrators need two different levels of access within the same tooling, segregated by line of business or product line to accomplish it.

    The Career Consistency Conundrum

    The problem with my corporate identity in the digital age is that it is fluid, like life. In the course of my career I will change employers at one time or another. But beyond this, I will change roles, and/or areas of focus within the same employer over time. I may be assigned to work a “special project” in addition to my normal duties during my time at a given employer. And where DevOps relies upon several types of tooling to facilitate the continuum, this fluidity in my career makes it difficult to keep up with, and can drive administrative costs quite high.

    For example, if I am an application programmer (normally), I will then have certain abilities within the build, deploy and release tools—likely high ability in build, moderate in deploy and low in release. If I am temporarily assigned as a release manager for a different product/service (in addition to my normal duties), it should radically alter my abilities within the DevOps tools, at least for a short time. But when I return to normal duties, the only mechanism that gets my abilities reset to what they should be is a strong process control system. The tools do nothing to facilitate this (no reminders, no examination of HR systems for roles, no look at each other to see what I am supposed to be).

    An Identity Architecture

    It occurs to me that the constants in resolving these kinds of problems are time and who I am. If I could hold an identification construct that identifies myself in career terms—which employer, which role, etc. and for how long—that identity construct could be employed into every system that accepted it. In effect, it would be the ultimate abstraction of user management, transferring the burden from companies and HR departments to the individuals who know, and need to know, the end user.  While companies would still need to interact with my personal identity construct for verification, assent and record keeping, having all electronic systems accept my ID construct takes all of the work out of programming those interfaces, makes permissions and roles common, and keeps up with life’s fluidity.

    In addition, who I am becomes the same in every system that accepts this construct. I cannot define myself as a release manager in one tool and a test manager in another and an application programmer in yet another to give myself god-like abilities in the DevOps tooling at my company. Each tool would examine the same identity construct I hold and receive from it, my normal duties, roles, permissions, etc. I would have a consistent profile across corporate tooling that would reflect my latest roles and use dates (beginning and end) to validate me against their own records.

    An Identity Lockbox

    The trick is, how do I keep this identity construct from being stolen? I believe this is where biometrics begins to play a key role.  Fingerprint technology is commonplace now, even in cell phones, which are usually chained to us like an additional finger or toe. We rarely go anywhere without them. And when carrying them, we use features such as Touch ID to replace the manual keying-in of passwords. If my identity construct was paired between information likely I alone would have and biometrics tuned only to me (retinal scans, fingerprints, etc.), the pairing could unlock the construct for either use or revision.

    Stealing the construct does little good, as without the pairing biometrics, it could not be used or revised. The applications for an identity construct like this are limitless—everything from securing the right to vote, work and collect social security to validating credit card purchases and opening up new social media accounts.  If Facebook employed (or accepted) this kind of construct, it would be more difficult to create spoof accounts of me, as the unbeatable pairing could decipher who really owns a photo, or document, etc. And looking forward, a standardized identity construct such as this could interact with the emerging world of IoT (internet of Things), where devices could know a lot about me, and know it was truly me.

    Impacts to the Bottom Line

    I am not suggesting some wild end-of-the-world scenario where computers control our every move. We already have that in some form or another (see banks – ha ha).  But I am suggesting that in the interest of reclaiming digital privacy we should be moving the ownership of identity constructs back to the people who own them: us. We should each own our own singular construct, keep it up to date and as filled out or complete as we want to, sharing only what we want to. The chief benefit of this would be an increased difficulty in stealing them from us. We can all skip the 666 tattoos, and instead try to reclaim a moniker of privacy by holding our own digital identities ourselves. Using them like a master key that will open systems we “should” have access to and abilities we “need” to have to perform the work assigned to us.

    The upside to corporations is increased security that requires less on their part to maintain. A single set of records with start and end dates validates IDs used or attempting access. The upside to the software industry as a whole is a common interface for logging into an application with discreet identification. It removes the doubt about “borrowing” an ID if unlocking access requires a biometric pair as well. It would allow every application to abstract user management and make it common. Roles would be abstracted. Permissions could remain unique to each application based on their interpretation of the role.

    Moving to a self-maintained identity construct could be taken further for benefits in other areas of our lives. While we have discussed some of how the career portions of our identity might be subdivided and cataloged, imagine for a moment the benefits of having our heath characteristics attached to the same kind of identity construct. Family records, memberships and associations … pick your classification of how a person is described for who they are. Having a way to retain ownership of those things in the digital age is key to keeping our unique position in the world unique. Losing control of those things becomes catastrophic. Where DevOps benefits from a construct such as this is but the tip of an iceberg compared to the benefits society reaps—or at least, our digital society could reap if we pursued it.

    To continue the conversation, feel free to contact me.

     

    — Kristian Nelson