From Silos to Services: Cloud Computing for the Enterprise

Nov 22 2015   1:32PM GMT

Some Cloud Native Terminology you should Learn

Brian Gracely Brian Gracely Profile: Brian Gracely


If you’ve been following the discussion about how applications are now being written to be more “cloud native”, you might have seen some terminology that was strange or unusual. This is because the operational model around these newer types of applications makes a few assumptions which are very different than applications and infrastructure in the past. Let’s look at a couple of the concepts:

  1. Infrastructure as a Software: While there will still be underlying hardware for servers (some acting as storage) and networks, the core idea is that the way to interact with these systems is if they are built primarily from software, which is decoupled from the underlying hardware.
  2. Infrastructure as Code: Using software development techniques to define, test and manage the infrastructure software. This means that teams use structured automation frameworks (e.g. Chef, Puppet, Ansible, etc.) instead of random scripts, and the code is kept in versioned, software repositories.
  3. Avoid Patching: Instead of patching existing systems, the core believe is that new “versions” of a system should be deployed instead. This avoids the feature-patch-dependency creep.
  4. Abstract where Possible: Being able to abstract specific components within an architecture helps avoid lock-in to a specific element, and eventually leads to more programmatic ways to interact with more parts of the system.

Terminology to Learn

Durable – “survives failure of its parts” – This aligns to Abstract where Possible. Elements will fail and this is expected, but the overall system should be durable enough to survive either HW or SW failures.

Declarative – “user of the abstraction declares the desired state, and the service providing that abstraction attempts to maintain the abstraction in that desired state.”  – This aligns to Infrastructure as Software and as Code. The owner of a system defines (in programmatic software) what it wants it to look like and how it should act. The system should be managed not to vary from this state or “promise”.

Immutable – “unchanging over time or unable to be changed” – This aligns to the idea of Avoiding the Patching elements of an applications, or the popular “Pets vs. Cattle” notion of managed resources.

Ephemeral – “lasting for a very short time.” – This aligns to both the idea of Infrastructure as Software and Abstracting where possible. Some elements are only needed for short periods of time, or will only remain as long as a dependent element is in use. This is partially why people are beginning to like using containers, as they are designed like processes, to bringing them up or down is simple and fast.

Remotable – “is an interface that allows IPC (Inter Process Communications) among other things. As you may know, all apps (most of the time) run on their own process and cannot directly interact with apps running in other processes directly. One method you can use to create an intercation between is by using a IBinder. IBinder allows communication between those “remote” objects.

We discussed many of these topics on a recent The Cloudcast podcast –

 Comment on this Post

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: