CloudBolt Blog

Modern IT environments are subjects of constant change, and thus are likely to be incapacitated by unexpected effects of one of these alterations. Storage, network, server configuration, passwords, DNS, VM templates, and applications are modified frequently, and any of these changes could have ripple effects that are not caught by traditional monitoring solutions.

Traditional monitoring systems are great for ensuring that any one specific infrastructure component is healthy, but they typically do not/can not cover the end-to-end use case that IT consumers depend on every day. In this way, traditional monitoring can be thought of as unit testing for your data center. Unit tests are vital, but they are not a substitute for functional tests that ensure that all the individual components work together to fulfill end-users’ needs.

Enter C2’s Cloud Supply Chain Validation (CSCV). This feature, new in C2 v4.0, empowers CloudBolt customers with a new way to test the end-to-end processes that are most sensitive to environmental change. CSCV ships with a set of tests that can be run on demand or on a schedule, the most prominent among them being a provision and decommission test. This test, run nightly by default, executes a series of provisioning orders, decommissioning each server that was built as it goes. C2 admins decide how many tests they want run each night and for each one they provide an environment, group, OS build, and any other provisioning parameters that may be needed for that environment. If the tests fail, the admin is notified and can act proactively to resolve the situation.

The CSCV test configuration

Provisioning is the ideal workflow to test the health of infrastructure, because it is so far reaching. Fully automated provisioning will hit the network, storage, virtualization systems, public cloud providers, and potentially DNS, asset tracking systems, monitoring, backup, hostname reservation systems, change management systems, and any other infrastructure that CloudBolt has been configured to interact with via its orchestration hooks and external orchestrators. Knowing that provisioning is healthy, administrators can have confidence that the bulk of their systems are behaving properly and able to interact with each other as expected.

Run and view CSCV test results directly from C2.

At any time, administrators can check the health of the tests in C2’s web interface, drill down into results, and kick off ad-hoc runs of the tests. The end result of Cloud Supply Chain Validation is that the owners of the IT infrastructure will find out about breakages and have the opportunity to resolve them well before users encounter the problem when they urgently need the system to work. Admins and end consumers of IT both gain increased confidence in the state of their systems and can sleep a little better at night.

A couple of us were speaking to an industry analyst the other day who was asking about our technology stack when he remarked:

“The selection of Python and Django three years ago was either truly visionary or borderline crazy, but it’s exactly what you would choose if you were to start today.” – Bernd Harzog, The Virtualization Practice

I’d like to take the credit associated with the visionary part of that statement, but the truth is that Python has been a solid, logical choice for enterprise development longer than it usually gets credit for.   Python has been used for years at the core of intensive, production systems by everyone from Google to NASA, and it has performed admirably under the pressure.

Some might say that the choice of a back-end technology should be irrelevant to consumers of a product, but the fact is that a language, though unseen by end users, makes a huge impact on their experience.  A language should inspire a development team to deliver functionality quickly and reliably and allow engineers to focus simultaneously on the dual goals of robust architecture and an excellent end user experience.  In a similar way to how dogs and their owners tend to start looking like one another after years together, programmers’ thought patterns and behaviors are influenced by the attributes of the language and framework they use every day.  For example:

• C programmers think overwhelmingly in computer science terms, at the expense of user experience.
• .Net teams tend to think excessively graphically, at the expense of creating architectures that are not as interoperable and ready for integration and scale as they should be.
• Perl encourages developers to think of the most obfuscated way of accomplishing a task, rather than the most transparent.

Just as dogs and their owners begin to look alike, developers begin to think in their "native" language (photos courtesy of Cesar)

In contrast to other options, Python influences programmers to constantly consider extensibility, simplicity of design, ease of installation/management, and the principle of least surprise, all through the example that it sets.  It does this while enabling more rapid and responsive development than any other language I have used. 

Though CloudBolt C2 was introduced later than some other cloud management systems, we have seen it leapfrog other solutions and gain acknowledgement as being easier to install, more flexible and scalable, and sporting a cleaner and simpler user interface than other products in the space.  There are several factors that enabled us to surpass other solutions, but at the core of these is the Python programming language.