J. CRAIG LOWERY, PH.D.

Part 1 – The New Steely Eyes of IT

Just like the Star Trek episode “Where No Man Has Gone Before” depicts the wondrous, perhaps frightening aspects of traversing a Big Cosmic Line, we’re likewise coming to a barrier of sorts… a barrier synchronization point, to be specific, in the Information Technology industry.  It’s a juncture where at least six things in confluence are profoundly disrupting IT usage patterns that we’ve built up over the past three decades.

I’ll dispense with the shameless co-opting of the Shrine of Nerdom, and instead turn to those of you familiar with computing in the parallel. I suspect you already get why I’m using the “barrier synchronization” pattern as a metaphor for this change: Many independent threads are running in parallel, but they arrive at a synchronization point (the “barrier”) where they must wait until all the related threads have arrived. Once that happens, they can move forward and make progress in solving the problem together.

But it’s more than just synchronization. There truly is transformation awaiting on the other side of that rendezvous. Here’s my reasoning as to why: In order for “Real IT Transformation” to occur, we’ve been waiting on six related industry threads to come together: 1) containers, 2) the API economy, 3) microservices, 4) composable hardware and software systems, 5) cloud and software defined networking, and 6) a host of use cases that place demands on these things so as to evoke transformative application of them in concert.  These threads and their convergence are shown in the figure below.

What’s interesting about these threads is that each has an origin independent of the others, yet they are all highly interdependent when it comes to maximizing their potential.

Most of these threads have been evolving on their own for decades, following paths to maturation shaped by a number of influencing vectors brought to bear by real world application.  But one point has been exerting gravity on all of them, drawing them toward an inevitable point of union where 2+2 really does equal 5. When put together, these six threads transcend themselves and we see an incredible transformation of how we think about and use “information technology.” Ready to bow to your new god, Jim?

The customer-facing values of this emerging pattern are in providing more choice in sourcing, developing, deploying, and managing applications without requiring the complex dependency requirements that traditional IT departments have solved.  Let me say that in plain English: The system is learning how to automate the bread-and-butter tasks that complex IT departments have grown up over the years to solve.

So, let’s talk about that: Why do IT departments even exist in the first place?  The answer is that IT departments historically solve the dependency requirements chain that stretches from the business needing an IT solution to actually making the solution available to the business.  Their customer (the business) wants an app/functionality that makes the business go. Once identified, IT solves the dependencies:

1. What application software solves the problem?
2. What operating system and middleware does that application require?
3. What hardware will be required for all of that?
4. What kind of hardware will be needed?
5. Where will that hardware be housed?
6. Who will make sure it stays up and running, and the dust is occasionally removed?
7. Who can explain to the business how to use it and get value out of the solution?

You, no doubt, can come up with many others.  The point is, in order to make that dependency solving task more efficient and scalable within the enterprise, IT departments and business that house them have standardized on things like hardware (x86 servers, Dell vs. HP, SAN vs DAS, etc.) and software (Windows, System Center, etc.) so that the scope of things they must become expert at is tractable. This creates constraints on choices, which counter productively reduces the amount of value the business might get from IT.  “Sorry, we know app X is best for that function, but it runs on Windows and we’re not a Windows shop.”

In the next generation IT scenario at the center of the figure, the dependency requirements-solving function that the IT department has historically provided is now made less onerous for the business. This is because the maturing technologies (around the circle in the figure) automate everything from solving the dependencies as well as sourcing, deploying, and operating the components in solution.  In other words, the system is learning do what IT departments historically have done: given a business request for IT functionality, choose the best path to fulfillment.  As a result, the IT department is becoming more of a broker of services and less a dependency requirements solver.

In my next installment, I’ll start going around the wheel of the figure and describing each of the threads and how it is becoming an essential part of the transformative model.  What will emerge at the end of our tour is a list of characteristics that sets the “Real IT Transformation” apart from similar failed visions that have preceded it, and why this time success of the model is inevitable.

Well, assuming a second super-god doesn’t emerge from the barrier and they kill each other.  But, let’s think positively, shall we?

Part 2 – A Universal Service Model

In my previous post, I introduced the idea that all cloud services are “platform as a service,” especially when we think of the entire Internet as the platform, and the various services available to applications at run-time.  These services include, but are certainly not limited to, what is broadly called Infrastructure as a Service. IaaS has been extremely popular and successful with traditional IT practitioners because it fits relatively easily into their operational models.  Still, it is the most basic and least developed of the spectrum of services the net has to offer.

It is a strategic blunder to think that cloud’s ultimate value can be tapped by simply applying traditional IT datacenter concepts and patterns.  In fact, the quest to add cloud to one’s IT portfolio without undertaking significant software development and operational reform will likely lead to failure. Certainly the outsourcing of infrastructure as a service reduces risk, simplifies operations, and potentially reduces overall costs to a business if implemented properly.   But to stop there is to cheat one’s self of the true riches the cloud model can unearth when fully pursued.

To understand this better, consider that the only purpose of IT operations is to provide data processing and storage that enable a business to meet its objectives:  “It’s all about apps and data.” IT becomes a drag on the business if it fails to adopt capabilities and transformative operational models that are more directly relevant to providing the application and data storage facilities the business needs.  Whereas in the past, the most directly relevant capabilities may have been providing raw compute power and storage capacity tailored to custom applications, the reality of our current environment is that the various wheels that make apps and data go have been reinvented so many times that they are easy to find and often free.  The global Internet and open source software are the primary reasons for this change.

The idea of transformation is at the heart of cloud computing’s real value.  One must go beyond IaaS to fully reap its rewards, and most have done so, perhaps unknowingly, by using the service model at the opposite end of the spectrum: “Software as a Service” or SaaS.  In this model, the service presented is the application itself, and using the service is just a matter of paying subscription fees to cover a number of users, connections, queries, etc., then accessing the application with a standard web browser or via an API.  This service model is decades old, but standing up such a service has historically been very difficult. Until recently, none but the largest organizations had the expertise, resources, and fortitude to build them.

It has been mentioned that IaaS is at one end and SaaS at the other of a spectrum. But spectrum of what?  I contend it is the spectrum of services available from all cloud sources, distributed across a continuum of cloud service abstractions and the types of applications built upon them.  I’ve created a diagram, shown in the figure below, to help facilitate a complete discussion of this concept, which I’ll tackle in my next installment. For now, take a look and start thinking about the implications of this “universal service model.”

Part 2 – How Privacy Could Cripple the Cloud

Security and privacy are often mentioned together. This is natural, because they are related, yet distinct topics.  Security is a technical concept concerned with the controlled access, protection, integrity, and availability of data and computer system functions.  Privacy is a common policy objective that can be achieved in part by applying security principles and technical solutions.  In previous posts, I’ve discussed how cloud security is not really a problem, any more so than it is in IT in general, when it is approached properly in the cloud environment.  Privacy, as discussed in Part 1 of this series, is unfortunately not so “simple.”

I’ve already made the case that some commonly held beliefs about what is inherently secure or insecure are based on control of the physical infrastructure and ownership of the premises where the infrastructure is located.  I’ve further posited that these ideas are outdated, and at the very least insufficient to insure secure cloud systems (as well as traditional data centers, for that matter).

In the discussion of privacy, we’ve seen governments urged to action by their citizenry to combat the erosion of individual control of personal information.  Unfortunately, lawmakers have approached such legislation from the outmoded perspective of physical security.  Privacy laws are rife with injunctions that PII must only be stored or transmitted under circumstances that derive from a physical location.  The European Union, for example, forbids the PII of any EU citizen from being stored or transmitted outside of the EU. Although treaties such as the EU-US Safe Harbor Framework, established in 2000, facilitates some degree of data sharing across the EU-US boundary, it is showing signs of failure when applied to cloud-based application scenarios. Although laudable in their intent, privacy laws that dependent upon containing data within a particular jurisdiction can prove to have more negative effects on both privacy outcomes and achieving the full benefit of cloud-based global services to the individual being “protected.”

First, given the highly-publicized data breaches of large corporations and government entities, it is obvious that data behind a brick wall is still quite vulnerable.  Laws that mandate limits on where data can be stored may convey a false sense of security to those who think that meeting the law’s requirements results in sufficient protection.  Socially engineered attacks can penetrate all but the most highly guarded installations, and once the data has been extracted, it is impossible to “undisclose” it. Again, it is the perimeter-based model that is not up to the task of protecting data in a hyper-connected world. Second, limitations on how data can be shared and transmitted can negatively impact the owner of PII when they cannot be serviced by cloud vendors outside of their jurisdiction.  Frameworks such as Safe Harbor are band-aids, not solutions.

One solution is to endow sensitive data with innate protection, such that wherever the data goes, its protection must also go. A container model for self-protecting data allows for the owner to specify his or her intentions regarding the data’s distribution and use, regardless of its location, and is the zero trust model for data.  Rather than depend on a perimeter and control of physical infrastructure to insure privacy objectives are met, the policy is built into the data container, and only when the policy is followed will the data be made available.

Of course, such a solution is easier described in a paragraph than implemented, although many valiant efforts have been attempted to varying degrees of success.  Still, a viable implementation – one that is scalable, robust, and easily made ubiquitous – has yet to be created.  Unfortunately, the wheels of governments and legal systems will not be inclined to wait for it.  Without educating policy makers to better understand the real threats to privacy rather than the perceived ones, we invite a continued spate of ill-conceived requirements that could make the problem worse while ironically robbing “protected” citizens of the full value of cloud technology.

Part 1 – Privacy Ain’t the Same As Security

Most people consider the word privacy solely in the context of cloud deployment models, where a private cloud is one reserved strictly for the use of a specific group of people that have a common affiliation, such as being employed by the same company. But it is becoming quickly evident that the more broad context of global legal systems and basic human rights are where cloud computing may meet its privacy Waterloo.

The concept of personal privacy is present in all cultures to varying degrees.  Western cultures have developed the expectation of universal individual privacy as a right.  As such, privacy is a legal construct, not a technical one.  It is founded upon the idea that information not publicly observable about a person belongs to that person, and is subject to their will regarding disclosure and subsequent use.

By default, most legal systems require the individual to opt out of their rights to privacy, rather than opt in.  This means that, unless there is specific permission from the owner of the data to allow its use in specific ways, the use is unlawful and a violation of that person’s privacy rights. Examples include the United States healthcare privacy laws, and the European Union’s privacy directive.

There are instances to the contrary, where opt-in is the default.  One is the privacy-related right to not be approached without consent.  An example is the US Federal Trade Commission’s National Do Not Call Registry, which one must actively join in order to supposedly avoid unwanted marketing telephone calls. This solution also demonstrates the difficulty in balancing privacy of the individual with the free-speech rights of others.

The details of privacy law vary across jurisdictions, and historically have been somewhat anemic.  Before the printed word, propagation of personal information could only occur by word-of-mouth, which was highly suspect as mere gossip.  The printed word resulted in more accurate and authoritative data communication, but the cost rarely allowed for transmitting personal details outside the realm of celebrity (in which case it was considered part and parcel of one’s celebrated position). These limitations rarely tested the laws, and when they did, it was infrequently enough to manage on a case-by-case basis. But, as with so many other legal constructs, computer systems and networking have strained the law to breaking points.

The modern, democratized Internet has enabled the near instantaneous propagation of data at little expense, by almost anyone, to broad audiences.  In supposed acts of public service, “whistle blowers” purposefully disclose private information to call attention to illicit activities or behaviors of the data owners: Whether their ends justify their means is hotly debated, though it is a clear violation of privacy. Vast databases of personal information collected by governments and corporations are at much greater risk to be copied by unauthorized agents, which most people agree is data theft.  In these cases, it is fairly easy to spot the transgressor and the violation.

But the free flow of information in the cloud computing era brings ambiguity to what once seemed straightforward.  Individuals who volunteer personal information often do not realize just how far their voluntary disclosure may propagate, or how it might be used, especially when combined with other information gleaned from other sources.  The hyper-connected Internet allows data from multiple sources to be correlated, creating a more complete picture of an individual than he or she may know, or would otherwise condone.  The data may come from a seemingly innocuous disclosure such as a marketing questionnaire, or from public records which, until today, were simply too difficult to find, much less match up with other personally identifiable information (PII).  Attempts to ensure data anonymity by “scrubbing” it for obvious PII such as name, address, phone number, and so on, is increasingly ineffective as something as simple as a time stamp can tie two datum together and lead to an eventual PII link in other data sets.

This particular problem is one of the negative aspects of big data analytics, by which vast sources of data, both structured like database tables and unstructured like tweets or blog posts, can be pulled together to find deeper meaning through inferential analysis.  Certainly, big data analytics can discover important trends and help identify solutions to problems by giving us insight in a way we could never have achieved before. The scope, diversity, size, and access of data combined with cheap, distributed, open source software has brought this capability to the masses.  The fact that we can also infer personal information that the owner believes to be private, and has not given us consent to use, must also be dealt with.

As cloud computing continues on the ascendant, and high-profile data breaches fill the news headlines, governments have been forced to revisit their privacy laws and increase protection, specifically for individuals.  In jurisdictions such as the United States, privacy rules are legislated and enforced by sector.  For example, the Health Insurance Portability and Accountability Act (HIPPA) established strict privacy rules for the healthcare sector, building upon previous acts such as the Privacy Act of 1974.  Although the Payment Card Industry (PCI) standard is not a law, it is motivated by laws in many states designed to protect financial privacy and guard against fraud. In the European Union, the Data Protection Directive of 1995 created strict protections of personal data processing, storage and transmission that applies in all cases.  This directive is expected to be superseded by a much stronger law in coming years.

In an environment where there are legal sanctions and remedies for those who have suffered violations of their privacy, one is wise to exercise caution in collecting, handling, storing, and using PII, regardless of the source.  Cloud technologies make it all too easy to unintentionally break privacy laws, and ignorance is not an acceptable plea in the emerging legal environment.  Clearly, for cloud to be successful, and for us to be successful in applying it to our business problems, we need systematic controls to prevent such abuses.

But is a failure to guarantee privacy in the cloud enough to kill the cloud model, or hobble it to insignificance?  More on this line of thinking in Part 2.

Part 3 – Leaping the Chasm

In my previous posts (Part 1, Part 2) in this series, we established the theory that the human species has come to rely on physical ownership and control of something as necessary and sometimes even sufficient to securing that thing.  This theory doesn’t hold in the cloud-era IT world where virtual objects such as applications and data, backed by physical machines, are more vulnerable in that virtual world than they are in the physical one in which they are rooted.  This line of reasoning is challenging for those who insist that “private” clouds will always trump public cloud services when it comes to providing the ultimate security.

The key to security in the cloud is to make the application responsible for its security, not the supporting infrastructure.  This implies that not all applications as they may currently exist in a private data center are suitable for “true” cloud deployment.  In fact, it is likely that very few are ready to make the jump into the cloud, because there is a gap in application fitness that must first be addressed.  Perhaps the staunch supporters of private cloud as the bastion of security take their positions not understanding or simply being dismissive of the fact that application transformation is a requirement to achieving the most secure public cloud deployments.

When the distributed perimeter pattern is followed by cloud application developers, the CSP is left to focus on creating the most secure service possible, meaning that it is generically configurable for each application, and that those configurations are difficult if not impossible for interlopers to modify to their own advantage.  Because CSPs operate on such large scale, they are arguably more likely to do a better job of securing these basic services than all but a handful of enterprise data centers could.  Of course, this model can only succeed when the application properly configures and uses the service.  To do otherwise could invite a security breach.

But even in the case where an individual cloud application is misconfigured and vulnerable, it is important to note that the cloud service itself and other applications are not likely affected by the vulnerability.  If a poorly designed app is compromised, the attacker can only gain control over what that app controls.  Even if the app has “superuser” privileges for the tenant (a very bad thing to do!), it cannot impact other tenants except possibly by side effect, such as launching a denial-of-service attack by saturating the network or CPU.  Even then, good CSPs will enforce limits that prevent the DoS attack from having significant negative impacts on other tenants. In effect, the CSP approaches each tenant as a potential security risk that could behave poorly, even if not officially “compromised.”

This is not to say that private cloud has no place in cloud-era IT. In the security context alone, there are many applications that will never be refactored for cloud, and for good reasons. It’s expensive to refactor.  The application may not have a very long lifespan, anyway.  It may be that the nature of the application is such that a full public-cloud makeover won’t add much value to it where users or the organization are concerned.  In these cases, it is best to either leave the application as is, or recast it partially to a cloud model to take advantage of efficiencies in the private cloud, while still depending on the existing security controls.

For new application development, however, there should be no question of adopting the full-on cloud model because it maximizes deployment flexibility.  Even if you don’t think you’ll ever deploy the app to public cloud, write it as if you will!   When we design and write applications to take responsibility for their own security, we are subscribing to the zero trust security principle at a fine level of granularity (the application, or its container).   By not trusting anything beyond the boundaries of the application’s container, and designing the application accordingly, we endow it with the strongest possible security profile, and thus the potential for greater mobility between cloud service providers and locations, regardless of deployment model.