The Tenets of Cloudify

(Originally posted at Cloudify, as the head of marketing & our open source community, to help define our mission.)

When we set out to build Cloudify, we had a few guiding principles that were the backbone that drove us from our early version 2.x, through our evolution to 3.x and now 4.x.

We discovered that basically all of our tenets strengthen each other, with the same basic ideology, starting with the open source core. Now with 4.0, a major milestone in our growth as a product and company, we felt it’s time we shared these basic tenets that tie together into the underlying fabric of our product, company and culture.

Open

The principles behind open source are well-known, and so I won’t drone on too long about why open source. If you need to read more on why open source, here are some places to start.

If I need to borrow a quote (in the open source way), from those who have likely said it better than me, and are fostering a safe place for such projects (our own ARIA among them), then I’d quote the Apache Software Foundation’s principles for code:

• collaborative software development
• commercial-friendly standard license
• consistently high quality software
• respectful, honest, technical-based interaction
• faithful implementation of standards
• security as a mandatory feature

While open source is only one attribute of openness, there are many other aspects of being open including open governance, standards, and agnosticism. Since there will never be a one size fits all scenario, inclusivity and openness are increasingly important to enable interoperability and portability of all types of stacks.

Then when I think about it further, if I had to establish categories of thought, “open source” falls under the “how” category, whereas the real questions that we needed to ask ourselves were “what”. What are the primary challenges of typical IT organizations today? What can we do differently?

I feel that the other core tenets are those that ultimately answer this.

Technology-Inclusive

Based on the same principles as openness, if there was something we understood early on, it was the importance of inclusivity (vs. exclusivity) — building a collaborative, integrative platform. Because a “Jack of all trades,” is a master of none. And one company alone simply cannot deliver on all of the important technological features that enterprises require today. At least not well.

An integrative approach enables companies to build their own best of breed stack, whether it’s homegrown tools or favorite tools that dev and ops teams simply don’t want to replace. We respect all code and, even more so, our peers. While it may sound cheesy, we’re not looking to compete with anyone. We have often times collaborated with projects and tools that very much overlap with what we do, and have found the places to be better together.

It’s not a surprise that our internal motto, turned t-shirts, turned banners…without even planning, has been “the only constant is change” all along. With the complexity of the adoption model, and the tooling, infrastructure, technology landscape changing so rapidly you must take an integration and adaptation approach in order to survive. We have learned through collaborative projects we are involved in, that many times they combine and fuse together because, most times, as it turns out… you just can’t go it alone. This is the DNA that makes projects timeless and sustainable.

Think: Collaborative, Technical-based interaction, Consistently high-quality

Model-Driven

Nati Shalom, Cloudify CTO, who drives the DNA of the project, code, and company, is whom I often quote as my personal thought leader. When we set out to rewrite Cloudify from 2.x to 3.x — in order to get closer to other open source projects through code; but likely one of the more critical aspects was to drive standard-based templating for cloud applications. That’s what we initially called the horse before we identified its real name. Model-driven design.

We’ve referenced this in the context of the model T assembly line, and in the context of Boeing and Computer Aided Design (CAD), but it took us an evolution all the way through to Cloudify 4.0 to understand what we were really preaching by being early adopters of TOSCA.

Standards, or service models, are important on numerous levels. By driving a unified service model you are building a canonical, repetitive, best practice for making applications so portable, so replicable in distributed environments you will never have to reinvent the wheel. The modeling language is essentially the enabler for automation, as it was for the manufacturing industry. This type of standard needs to be open and nonproprietary to any vendor, to enable true community-level adoption and contribution.

Another important aspect of such a model-driven approach enables you to include security and hardening into the service model, and replicate this across environments — providing inherent security features from the ground up, and not as an afterthought.

If we can drive a common standard for cloud applications, the software will be in the driver’s seat, not the infrastructure. However, for the skeptics among us, we don’t mean standardization in the sense that forces mediocrity such as a standard API, or “a least common denominator”. We understand the importance of enabling different parts of the puzzle to take part in the same automation task, and the best way to do so is enable finer-grained modularity of the service model itself, and not via a restrictive API.

Having to rewrite code into complex models, like the 12-factor model, will no longer be relevant. We can concentrate on writing excellent code and refactoring existing good enough code that drives our business — this ties into being application-centric. Having to constantly be concerned about interoperability or compliance of code is only a hindrance. This is true for traditional stacks, and hybrid stacks, you will be able to plugin to any infrastructure (including new and exciting technologies, read: containers today, the new thing tomorrow).

Think: Faithful implementation of standards, Security as a mandatory feature, and truly free (in the autonomous sense) software.

Web Scale

When I reference web-scale as a tenet, it’s not the quantity I’m referring to, but rather the school of thought that has arisen as a result. The by-product of web-scale, and learning how to do things more efficiently, is based on principles of automation, scale, redundancy, repeatability, and modularity, all during runtime. No need to elaborate on the need for automation — that too has been discussed to no end — human error, exact replication of activities, bottlenecks, testing, etc. etc.

When we discuss Cloudify in the context of web-scale, it’s because web-scale is a fact. Data is growing along with load, usage, and more. You need to build your applications to be ready for this type of growth, and build for the diversity of people in the process. Remember inclusivity? Not everyone is a power user, not all tools are yet known, not all workflows worked out.

Under this bucket falls the concept of DevOps, but not in its buzzwordy sense, more in instilling a shared ownership across the organization from the application owner all the way through central IT, and this can only be enabled through common tooling, frameworks, and common interfaces. This means that tooling needs to be adoptable by end users and power users alike to build a common management platform to serve both the IT and business unit, as opposed to the NoOPS school of thoughts.

Think: Respectful, honest more humane code through automation, Security, high availability, collaboration through roles and responsibilities in the process

Application First, Network Aware

We chose the application-first (aka orchestration-first, application-centric) approach because we know that organizations that want to adopt new technology simply do not have the luxury to just “throw out” all their existing, in-house technology and start over. Most “legacy” technology (and yes, some of the most popular frameworks and tools — from LAMP to JBoss — have received the “legacy” stamp already), is still around because it is a company’s core business. Telling organizations to get rid of it all if they want to be innovative is simply unrealistic, and a non-starter many times.

The way to approach such a problem is by being pragmatic, and optimizing first, building new in the background. Demonstrating time-to-value for companies looking to adopt new technology. This is a top-down, application-centric approach versus an infrastructure-first approach. Many times, to achieve the benefits of the cloud, you can only start small. Work with what you have — plugin existing applications, drive innovation through automation, workflows, breaking down of silos, unifying tooling, terminology.

Another important and often overlooked aspect of the stack is the networking. Where web-scale and DevOps best practices were only made possible once data centers began to adopt principles of being software-driven, the same revolution needs to be more widely adopted on the networking layer.

We believe that building standard cloud management practices for running core network services is part and parcel to the application lifecycle, and should be treated similarly to compute and storage by being driven by the application and not externally from it. This is even more true in a multi-cloud environment which opens a whole new set of network security vulnerabilities. Once this occurs, central IT will be able to deliver services to organizational business units much like a service provider, preventing technology fragmentation and bypassing of IT, addressing all aspects of the stack.

Cloud Native

Like web scale, when we reference cloud native, it’s more in the sense of the concept and what it signifies, rather than the strange twist of fate where cloud native is associated with containers only. Similar to cloud applications, we believe that the diversity in this area will only expand, and interoperability will be of the essence. This warrants a standalone category as it’s somewhere between the service model, and the application layer. We believe that in order to be able to build for web scale and be technology inclusive you need to architect for independent services. This doesn’t need to be tied to a specific platform or technology. That is the true essence of cloud native.

Conclusion

It took us a long time to put these elements down on paper, as we ourselves were still undergoing an evolution, and learning what exactly we were driving at. We had the instincts, but were lacking the terminology. We have been working hard behind the scenes to deliver on these promises through our latest release and our ongoing roadmap. If there is a line I have used from day one it’s been “Cloudify was built for integration”. This is what we know how to do best. We are hoping this school of thought will help us drive an open standard and collaboration model.