J. CRAIG LOWERY, PH.D.

“If you are running your IT systems in a traditional private data center, you are already locked-in, and not in a good way.”

I was recently in a job interview before a panel of IT industry analysts, defending my positions in a hastily-written research note about the cloud service provider business.  During an interaction with one of the tormentors… I mean, interviewers… the topic of cloud vendor lock-in surfaced in the context of customer retention and competitive opportunities.

It is no secret that detractors of public cloud keep “lock-in” as a go-to arrow in their quiver, right alongside “insecurity.”  But that doesn’t mean it is manufactured FUD (Fear, Uncertainty and Doubt).  Cloud lock-in is very real, and organizations adopting cloud technologies, especially public cloud, must be have a relevant strategy addressing it.

But is cloud lock-in necessarily “bad?”

CSPs are continuing to build out their stack of services into higher layers of abstraction; databases, data analytics, even gaming platforms are being built and maintained by the service, freeing customers to focus on application-specific logic and presentation details to meet their business needs. This results in a high-velocity, nimble IT execution environment that allows them to respond quickly and effectively.  In short: they derive considerable value from being “locked-in.”  Clearly, if they later have reason to abandon their current CSP for another and haven’t planned for that possibility, it could be too intractable to attempt disentanglement.

Yes, there are ways to plan for and enable easier extraction.  Technologies like containers provide better isolation from the cloud infrastructure, as well as make it possible to “bring your own” services with you, rather than depend on the platform’s.  The challenge is knowing where to draw the line in just how much to “abstract away” the service: you could end up spending so much time insulating your application from the implementation details of a service that you lose the aforementioned benefits.  That could be worse than being directly “locked-in” if your competitors do it and get to market faster.

But a new thought was introduced during my interview, and I wish I could credit the person who gave it to me through the form of a question: Aren’t organizations who choose to remain in their private data centers even more “locked-in?”

This is a profound question, and it underscores the fundamental shift in thinking that must occur if organizations are to successfully survive the shift to cloud-based IT.  If you are running your IT systems in a traditional private data center, you are already locked-in, and not in a good way.  You’re much more isolated from the riches of the Internet, unable to take advantage of economies of scale, forced to re-implement otherwise common services for yourself, burdened with highly customized infrastructure and attendant support systems that will get more expensive to maintain over time as others abandon the model.

Privacy and control underpin the rationale continuing to feed this model, and although privacy is a good reason, control – specifically, the ability to customize infrastructure to the n^th degree – is not.   CSPs build and maintain infrastructure faster, cheaper, and with higher rates of successful outcomes. IT departments that see cloud as an extension of their data center, that must conform to their data center’s operational paradigms, and disrupt as little as possible the routines and processes they have developed over the years will be at a major competitive disadvantage in the future as their more prescient and capable competitors adopt DevOps and cloud models to drive their businesses at higher velocity.  Private cloud, when done properly, is a good intermediary solution that provides the control and privacy while bringing many (but certainly not all) of the benefits of public cloud.  A hybrid cloud solution that marries public and private seems to offer the best compromise.

Oh, the interview? Apparently they liked my answers enough to offer me a position.  So for now, this is the last of any real cloud-related technical blog you’ll see from me outside of the company’s official channels.  After all, one must not give away the store:  All product must be secured!

That is… locked-up. 🙂

I’m a big believer in formal education because of the importance of understanding “first principles” – the foundational elements upon which engineers design and build things.  The strengths and weaknesses of any such product are direct results of the designer’s understanding, or lack thereof, of immutable truths endemic to their discipline.  Software engineering is no exception:  A disciplined, experienced software engineer most certainly includes first principles in the set of precepts he or she brings to the job. Unfortunately, it’s the experience that can be a problem when they approach building cloud-based systems.

An expert can often confuse a first principle with an assumption based on a long-standing status quo.  Cloud software design patterns incorporate distinct differences from historical patterns because compute resources are more plentiful and rapidly acquired than in the past.  Here are three deeply ingrained best-practices, based on those assumptions that have served us well, but do not pertain to cloud software systems:

Fallacy #1 – Memory is precious

Only 30 years ago, a megabyte of RAM was considered HUGE, and a 100MB disk something one only found in corporate data centers.  Now one is hard pressed to find anything smaller than 5GB even in consumer grade USB solid-state drives.  Even so, most seasoned programmers (I am guilty) approach new tasks with austerity and utmost efficiency as guiding principles.  Many of us are conditioned to choose data structures and their attendant algorithms that balance speed with memory consumption.  B-Trees are a great example, with trees-on-disk and complicated indexing schemes the backbone of relational database management systems. Boyce-Codd and Third Normal Forms are as much about minimizing data duplication as they are about proving data consistency, which can be achieved in other ways.

In the cloud, memory (both RAM and disk) is not only cheap, it is dynamically available, and transient – therefore, not a long-term investment.  This allows a programmer to choose data structures and algorithms that sacrifice space for speed and scalability.  It also explains the rise of “no-SQL” database systems, where simple indexing and distribution schemes (like sharding) are the rule, and one is not afraid to replicate data as many times as necessary to avoid lengthy future lookups.

Fallacy #2 – Server-side is more powerful than client-side

For years, the “big iron” was in the data center, and only anemic clients were attached to it – this included the desktop PC’s running on Intel x86 platforms.  Designers of client/server systems made great use of server-side resources to perform tasks that were specific to a client, such as pre-rendering a chart as a graphic, or persisting and managing the state of a client during a multi-transactional protocol.

In building cloud software, clients should take on as much responsibility for computation as is possible, given constraints of bandwidth between the client and server.  Squandering underutilized, distributed client-side resources is a missed opportunity to increase the speed and scalability of the back-end.  The server ideally only performs tasks that it alone can perform.  Consider file upload (client to server). Traditionally, the server maintains elaborate state information about each client’s upload-in-progress, insuring that the client sends all blocks, that no blocks are corrupted, etc.  In the new model, it is up to the client to make sure it sends all blocks, and request a checksum from the server if it thinks it is necessary.  The server simply validates access and places reasonable limits on the total size of the upload.

Fallacy #3 – Good security is like an onion

The “onion” model for security places the IT “crown jewels” – such as mission critical applications and data – inside multiple layers of defenses, starting with the corporate firewall on the outside.  The inner “rings” comprise more software and hardware solutions, such as identity and access management systems, eventually leading to the operating system, middleware, and execution runtime (such as a Java virtual machine) policies for an application. The problem with defense-in-depth is that software designers often do not really understand it, and assume that if their code runs deep inside these rings, then they are not required to consider attacks against which they are mistakenly thought to be protected by the “outer layers.”  True defense-in-depth would require that they consider those attacks, and provide a backup defense in their code.  (That’s real “depth.”)

In the cloud era, all software should be written as if it is going to run in the public cloud, even if it is not. There are certainly a set of absolutes that a designer must assume are being provided securely by the service provider – isolation from other tenants, enforcement of configured firewall rules, and consistent Internet connectivity of the container are the basics.  Beyond those, however, nothing should be taken for granted.  That’s not just good security design for cloud software – its good security design for any software. Although this may seem like more work for the programmer, it results in more portable code, equipped to survive in both benign and hostile environments, yielding maximum flexibility in choosing deployment targets.

Experience is still valuable

None of the above is meant to imply that experienced software hands should not be considered in producing cloud-based systems.  In fact, their experience could be crucial in helping development teams avoid common pitfalls that exist both in and outside of the cloud.  As I said earlier, knowing and adhering to first principles is always important! If you’re one of those seasoned devs, just keep in mind that some things have changed in the software engineering landscape where cloud is concerned. A little adjustment to your own internal programming should be all that is required to further enhance your value to any team.

“The need for a common language requirement is the chief problem microservices solve.”

Part 6 – Episode IV: A New OOP

Our series exploring the six independent yet related threads that are converging to drive dramatic transformation in information technology is entering the home stretch today.  I’ve been visiting each of these threads in turn, as shown in the diagram below. Each has been evolving on its own, rooted in decades of research, innovation, and trial-and-error.  They are coming together in the second decade of the 21st century to revolutionize IT in ways the scope of which has not been seen since the 20th.

Today, the wheel turns to “microservices.”

Most definitions of microservices explain it as an architectural concept in which complex software systems are built from interconnected processes; the interconnection is typically facilitated by Internet Protocol transport and is “language agnostic.”  As with everything else in the above wheel, microservices are nothing more than the natural evolution of software architecture as it changes to take advantage of the ubiquitous Internet in both senses of its geographic reach and the adoption of its core technologies.

I like to think of microservices as the natural evolution of Object Oriented Programming (OOP).  OOP models software components as objects.  Objects are typically instances of classes, a class simply being a pattern or blueprint from which instances are built.  An object’s interface is the set of externally visible methods and attributes that other objects can use to interact with this object.  A simple example is class Point, which has attributes X and Y to represent the point’s coordinates in a Cartesian plane, and methods such as move() to alter those coordinates.

Classes are typically defined using languages such as Java.  Indeed, most modern languages have an object concept, though their implementations differ. After defining the classes, one writes executable code to create object instances, and those instances themselves contain code in their various methods to interact with other objects: creating new objects, destroying them, invoking them to do work of some kind – all of which amount to a coordinated effort to solve a problem.

Class libraries are pre-written collections of classes that solve common problems. Most languages come with built-in libraries for things like basic data structures (generic queues, lists, trees, and hash maps).  Open source and the Internet have created a rich but chaotic sea of class libraries for literally hundreds of different languages that solve even more specific problems, such as an e-commerce catalog or a discussion board for social media applications.

Until recently, if you wanted to build an application that used pre-built libraries from disparate sources, you chose a language in which there was available an implementation of each:  The easy way (there are hard ways, of course) to have the code work together – to have objects from one library be able to see and use the interfaces of objects from the other libraries – was to use the facility of the underlying language’s invocation mechanism. The need for a common language requirement is the chief problem microservices solve.

A microservice is really nothing more than an object, the interface of which is available as a network addressable target (URL) and is not “written” in any specific language.  The main difference is that the interface between these objects is the network, not a memory space such as a call stack or a heap.

Every interface needs two things to be successful: 1) marshaling, which is the packaging up and later unpacking of a payload of information, and 2) the transmission of that payload from object A to object B. Interfaces inside of an execution environment achieve both of these things by simply pointing to data in memory, and the programming language provides an abstraction to make sure this pointing is done safely and consistently.

Microservices are loosely coupled – they don’t share a memory space, so they can’t marshal and transmit data by simply pointing to it.  Instead, the data has to be packaged up into a network packet and sent across the Internet to the receiver, where it is unpacked and used in a manner the caller expects. The Hypertext Transport Protocol (HTTP) is the ubiquitous standard defining connections and transfers of payloads across the World Wide Web, atop the global Internet.  When used in a particular way that adheres to the semantics of web objects, HTTP can be used to implement RESTful interfaces. The definition of REST and why it is important is beyond the scope of this article, but there are good reasons to adhere to REST.

HTTP does not dictate the structure (marshaling) of the payload. Although XML (eXtended Markup Languae) and JSON (JavaScript Object Notation) give us ways to represent just about any data in plain text, they require additional logic to build a functioning interface. One such standard, the Simple Object Access Protocol (SOAP) is exactly that – it defines how to use XML to marshal objects for transmission.  However, many people see SOAP as too complicated, so they use their own flavor of XML or JSON to build their payloads. If there is a fly in the microservices ointment, it has to do with this aspect of undefined interfaces, and the lack of a heavily adopted service definition discovery and access protocol.

Even so, the use of the microservices model is exploding, and we’re seeing more hyper-reuse of code and services to build software. When “shopping” for a service, application developers typically follow this workflow:

1. If a service already exists, we simply pay for it (if required) and knit it into our application.
2. Else, we need to create an instance of the service, so we “construct” an instance on our favorite cloud provider by spawning a Docker container from an image from a Docker repository, like Docker Hub.

It’s a new age of software architecture. For the purposes of this article (and because it supports the contrived title), I’m going to call it the Fourth Age, and compare it to the previous three as shown in the diagram below. (This is a related but different concept than the familiar “programming language generations” concept.)

The First Age of Software Architecture was characterized by a lack of abstraction. Setting binary machine language aside as something only a masochist codes directly, assembly language provided a convenient shorthand, but very little else in the way of supporting problem solving.  The Second Age added procedural languages and data structure abstractions; however, languages were designed with an emphasis on general purpose code execution, and not the support of best practices in creating and operating upon data structures.  The Third Age was the OOP age, where languages evolved to support a more regimented, system-supported means of curating data within a program.  However, those structures were limited to software written in a specific language; interfacing with foreign code was not addressed.

The Fourth Age is the ability to combine code drawn from multiple sources and languages to create a solution.   Microservices are only the latest and most unifying attempt at doing so.  Previous attempts include Microsoft’s “Common Object Model” and the Object Management Group’s Common Object Request Broker Architecture (CORBA).  There are many others. The point is, until we saw things like HTTP/REST, Docker containers, cheap cloud hosting services, and freely available open source libraries like Docker Hub become common place, the Fourth Age couldn’t reach maturity – it was held back in many ways that microservices now have the opportunity to transcend.

So it is the age of the microservice, and the transformation of IT as we know it is reaching the peak of its powers.  If train for this new era you will, clear your mind you must, and changes accept.

May the Fourth be with you.

“…the direct to consumer aspect of the container model is at the heart of its transformative capabilities.”

Part 4 – The Tupperware Party

This is the fourth installment of a multi-part series relating six largely independent yet convergent evolutionary industry threads to one big IT revolution – a major Transformation.  The first installment gives an overview of the diagram below, but today’s excursion is to consider the one at the top of the diagram because, at least for me, it’s the most recent to join the party, and the catalyst that seems to be causing acceleration of monumental change.

Why? The emergence of Docker as a technology darling has been atypical: Rarely does a startup see the kind of broad industry acknowledgement, if not outright support, it has garnered.  For proof, look to the list of signatories for the Linux Foundation’s Open Container Initiative. I am hard pressed to find anyone who is anyone missing from that list: Amazon, Google, Microsoft, VMware, Cisco, HP, IBM, Dell, Oracle, Red Hat, Suse, …  That’s just the short list.  (Ok, Apple isn’t in there, but who would expect them to be?)

The point is, it isn’t all hype. In fact, the promise of Docker images and the flexibility of the runtime containers into which their payloads could be deployed is one of the first real glimpses we’ve seen of a universal Platform as a Service.  (More on that when I talk about Microservices.) It takes us one step away from heavy x86-type virtualization of backing resources – such as CPU, disk, and memory – and closer to abstractions of things that software designers really care about, which are things like data structures, guaranteed persistence, and transactional flows.

At the risk of being overly pedagogical, I feel I should at least make a few points on “containers” and “Docker” about which many are often confused.  Understanding these points is important to reading the tea leaves of the IT industry’s future.

First, “containers” is used interchangeably to refer to the image of an application in a package (like a Docker image), as well as the runtime environment into which that image can be placed. The latter is actually the more accurate definition, which is why you will see references in more technical literature to both Docker images and Docker containers.  Images are the package.  Containers are the target for their deployment.

To understand what’s in the package, let’s first understand what the containers, or runtime environments, are.  The container concept itself is pretty broad: think of it like an apartment in an apartment complex where a program is going to spend its active life.  Some apartments are grouped together into units, perhaps intentionally sharing things like drainage and water, or unintentionally sharing things like sounds.  The degree of isolation, and how much of it is intentional or unintentional, is dependent upon the container technology.

Hypervisor-type virtualization such as VMware vSphere (ESX), Microsoft Hyper-V, and open source KVM create containers that look like x86 computer hardware.  These containers are “heavyweight” because, to make use of them, one must install everything from the operating system “up.”  Heavyweight virtualization basically “fakes out” an operating system and its attendant applications into thinking they have their own physical server.  This approach has the merit of being very easy to understand and adopt by traditional IT shops because it fits their operational models of buying and managing servers.  But, as a method of packaging, shipping, and deploying applications, it carries a lot of overhead.

The types of containers that are making today’s headlines are commonly called “lightweight,” which is common parlance for the more accurate label “operating system-level virtualization.”  In this scenario, the operating system already exists, and the virtualization layer “fakes out” an application into thinking it has that operating system all to itself, instead of sharing it with others.  By removing the need to ship entire operating system code in the package, and not imposing virtualization overhead on operating system intrinsics (kernel calls), a more efficient virtualization method is achieved.  The size of the packages are potentially smaller as are the runtime resource footprints of the containers.  It is generally faster to create, dispose, and modify them than an equivalent heavier-weight version.

The most well-known contemporary lightweight containers are based on Linux kernel cgroups functionality and file system unioning.  Going into the details of how it works is beyond the scope of this ideally shorter post.  More important, is that Linux containers are not the only lightweight containers in the world. In fact, they are not the only lightweight containers that Docker packaging will eventually support, and is in part why Microsoft announced a partnership with Docker earlier this year, and has signed on to the Linux Foundation OCI.

Perhaps the biggest misunderstanding at this juncture is that Microsoft’s Docker play is about running Windows applications on Linux in Docker containers.  It isn’t, although that is a somewhat interesting tack.  Instead, it is about being able to use Docker’s packaging (eventually, the OCI standard) to bundle up Windows applications into the same format as Linux applications, then use the same tools and repositories to manage and distribute those packages.  Microsoft has its own equivalent of containers for Windows. It also recently announced Windows Nano Server, a JEOS (just-enough operating system) to create lightweight containers that Docker images of Windows payloads can target.

The figure below demonstrates what an ecosystem of mixed Linux and Windows containers could look like. Imagine having a repository of OCI-standard (i.e., Docker) images, the payloads of which are mixed – some being Linux apps (red hexagons), others being Windows apps (blue pentagons).  The tools for managing the packages and the repo are based on the same standard, regardless of the payload.  A person looking for an application can peruse an intermediate catalog of the repo and choose an application.  Then they press “Purchase and Deploy,” the automation finds a cloud service that expresses a container API with the qualifier that it supports the type of payload (Windows or Linux), and the instance is deployed without the consumer of the application ever knowing the type of operating system it required.

Self-service catalogs and stores aren’t new, and that isn’t the point of the example.  The point is that it becomes easier to develop and deliver software into such marketplaces without abandoning one’s preference of operating system as a developer or becoming deeply entrenched in one marketplace provider’s specific implementation, and it is easier for the application consumer to find and use applications in more places, paying less for the resources they use and without regard for details such as operating system.   There is a more direct relationship between software providers and consumers, reducing or even eliminating the need for a middleman like traditional IT departments.

This is a powerful concept!  It de-emphasizes the operating system on the consumption side, which forces a change in how IT departments must justify their existence.  Instead of being dependency solvers – building and maintaining a physical plant, sourcing hardware, operating system, middleware, and staff to house and take care of it all – they must become brokers of the cloud services (public or private) that automatically provide those things.  Ideally, they own the box labeled “Self-Service Catalog and Deployment Automation” in the figure, because that is the logic that both enables their customers to use cloud services easily, while the organization maintains control over what is deployed and to where.

This is a radical departure from the status-quo. When I raised the concept in a recent discussion, it was met with disbelief, and even some ridicule.  Specifically, the comment was that the demise of IT has been predicted by many people on many previous occasions, and it has yet to happen. Although I do not predict its demise, I do foresee one of the biggest changes to that set of disciplines since the x86 server went mainstream.

If there’s anything I’ve learned in this industry, it is that the unexpected can and will happen.  The unthinkable was 100% certain to occur when viewed in hindsight, which is too late.  Tupperware (the company) is best known for defining an entire category of home storage products, notably the famous “burping” container.  But more profound and what enabled it to best its competitors was the development of its direct marketing methods: the similarly iconic Tupperware Party.  For cloud computing, the container as technology is certainly interesting, but it’s the bypassing of the middleman – the direct to consumer aspect of the model – that is really at the heart of its transformative capabilities.

Welcome to the party.