Let’s go ground up


By Prasanna Padinhareveetil, Head of Cloud Solutions | Hybrid Cloud, Memorial Sloan Kettering Cancer Center

The Z-layer is composed of several layers, making it the most exciting part of any cloud journey for small or large organizations. It is a key success factor that many firms tend to forget or delay worrying about. And it becomes a costly misstep they end up realizing soon after.

Cloud transformation is multi-faceted. Instead of the rate of change of “x to y” (y is dependent on x, when x changes, so do y) on a grounded coordinate plane, we look at the change based on 3 dependent variables x, y, and z. This view will help us model the changes from all possible directions. Coordinate (x, y) gives you only the grounded view, which is the platform you are building, and often cloud adoption programs are content with that achievement, and fail to observe the 3rd dimension to invite failure.

There are 4th and 5th dimensions that go beyond visualizing an object, so let’s start with the 3D view and progress to higher dimensions. These higher dimensions encompass building DevOps as a culture which overlaps with automation at different levels and operational transformation, training, and upskilling—all of which organizations often struggle with as they approach application adoption space after an acclaimed platform build.

Those lacking the vision at the start and making these sequential or a sequence of reactive events to emerging situations, are putting their organization at peril because moving to the cloud is a major “earthquake” on an otherwise stable land (on-prem) and it further complicates the matter because cloud itself is under constant change. The compartment is rolling in all directions while your train is climbing a difficult hill. And, the passengers are not being told much about the nature of this journey.

DevOps tooling and automation are listed in the Z – layer component (please refer to the diagram) beyond the ground-level platform build. However, building a DevOps culture across the technology organizations is an entirely different animal to tackle. Technical experts can handle the tooling part with a prescribed timeline but building the culture is an evolving and time-consuming phase that demands great communication, collaboration and organizational skills. 

While tooling is a transition, creating the mindset and building the culture is transformation. Yes, the former can be done fail-proof with technical talent, but the latter is error prone and could kill the purpose entirely if not done meticulously.


The Layman View
The Z layer

Let me make it plain and simple. Take the length and width of a room as x and y coordinates; so, your 2D point lies on the floor. Now bring it up several units higher, taking the intersection of the 2 walls as the z-axis. Move up a unit at a time. With this understanding and refresh of our coordinate geometry basics, we take a look at the diagram and the cloud model.

Platform maturity is on the floor level or 2-D. Essentially, it is dependent entirely on building the cloud platform. For example, the AWS organization, Guardrails, basic Networking, IaC templates, IAM policies, Security and Encryption make up the foundational layer and thus, it’s crucial that the ground layer is solid prior to the development of the 3rd layer. The challenge is that this is not a sequential process. The intricate interdependencies will act as a barrier in your every move as you work through this layer.

Now, you cannot set every component of the floor level “in stone.” The shift from 2D to 3D is an iterative process. For that, you need to accurately identify components as well as transition elements of the 2D with the “cwrf” model (crawl, walk, run, and finally fly, but you stay still on the floor level) and then move each component up on the z-axis. Interestingly the “fly” at the floor level is only be achievable in a complete sense as you mature your Z-layer. For this accurate identification, you need expert guidance, from someone who has done this before.

Operational Challenges

How might we make the cloud model operational?

To begin to answer this, we must first recognize that traditional operational skills won’t cut it. Specialized training and making resources think in innovative ways are necessary for a successful operation in a cloud model. When you bring automation and self-service as an integral part of this model, roles and responsibilities (the much-loved RACI in an on prem model) of individuals sometimes step on each other, creating confusion and chaos, and this creates a precarious management issue.

For instance, the networking team is segmented by those with the traditional capabilities and a small fraction of those devoted to cloud networking. When there is an operational need or an emergency change required, a major part of the team is unable to contribute, despite the fact that there are available team resources. In a self-service scenario, a developer can now create a database not going to the database team as it used to be, but the structure and organization of the database, protection mechanism of data, troubleshooting, backup, and performance are all subjects in themselves to master. Based on the complexity of applications or team structure, it’s most meaningful to strategically place DBAs in each team along with development resources so that each team is self-sufficient in a self-service model, though individual developers may not be.

Operational maturity is crucial not only to the adoption but also to the productivity of the organization. As you move the platform components (from the x-y ground) up through the Z-layer, consider the key elements of the interdependent factors and disruptors to the current on-prem model. That’s where an organization actually starts to “feel” the cloud.

This feeling could turn good/bad based on how thoughtful you are in understanding the multifaceted nature of cloud adoption BEFORE you get started. So have a true visionary in charge from day-1.