Cloud promises a lot. Much of what the usual suspect big behemoth cloud platform companies offer is as real, achievable, flexible and as powerful and expansive as cloud computing’s central raison d’être and technology proposition has always promised.
But not everything the cloud evangelists, futurists and advocates tell us always comes to pass in quite the picture-perfect ‘serving suggestion’ way it is supposed to. Over and above the more basic implementation snags, nuances and incompatibilities associated with any given cloud project, there are some wider gaps in terms of what is practically achievable in many cases.
Could these implementation gaps represent cloud computing’s three biggest lies?
Do go back to Rockville
Rockville, Maryland-based CloudBolt Software thinks it can point to where some of these shortfalls exist. The company is an enterprise cloud management services provider that seeks to give its customers workable and efficient cloud orchestration systems that run with self-service, security and automation acceleration.
The company’s latest industry insights report, The Truth About DevOps in the Hybrid Cloud Journey is perhaps contrived in the way any cloud service management organisation’s ‘industry findings’ would be i.e. highlighting shortfalls as a prelude to offer solutions.
Pre-loaded tech survey subterfuge notwithstanding, CloudBolt clearly wants to highlight what might be some of the bigger problems experienced at the coalface. In particular, this snapshot of cloud DevOps leaders in substantially sized businesses (at least 1000 employees) may suggest that there is a lack of self-service, a crack in testing pipelines and an unwelcome slack in the tautness we need for real continuous CI/CD computing to happen on a 24x7 basis.
Lack, crack & slack
The lack factor is self-service. Clearly, we’re not talking about vending machines or buffets here. Self-service in terms of cloud is meant to describe a deployment where daily operations run without the undue need to call on the services of the Cloud Services Provider (CSP).
This means that self-service cloud runs with minimal effort in relation to tasks such as daily processing and throughput, then onward to reporting, patch updates and maintenance, autoscaling tasks and ultimately to provisioning new or changed instances of cloud.
CloudBolt says that the dearth of self-service (which of course its professionals can help fix) is tough because manual processes and inconsistency plague cloud application and data pipelines.
While the goal of CI/CD is to deploy applications rapidly and continuously, the survey carried out here suggests that as few as 15% of cloud customers deploy even once per day. Among the key issues is cloud plumbing; setting up pipeline infrastructure components of cloud takes a lot of hands-on manual coding and heavy lifting by software engineers. The golden promise of ‘we handle it all for you’ cloud automation may have some gaps in it.
Continuous crack factor
The crack factor is in testing pipelines. There is a perceived (and often real) lack of reliability in CI/CD infrastructures. CloudBolt says that for CI/CD to work efficiently, developers need to be able to deploy infrastructure ‘pipelines’ and reliably test their apps as they are developed.
Despite 85% of CloudBolt’s survey respondents saying they continuously test their infrastructure, only 11% consider that infrastructure reliable.
Thirdly then the slack factor. Continuous continuity for CI/CD needs to be tight rather than slack, clearly. The company says there is a real and present need to put the ‘continuous’ back into CI/CD.
To advance the vision of what CI/CD was always supposed to deliver and make it workable, CloudBolt suggests that between a third to three-quarters of enterprise organisations want faster access to infrastructure for their pipelines (70%), but they also want the ability to continuously detect pipeline infrastructure issues (e.g., unexpected changes to compute, storage, configurations, passwords, etc.) before they happen (62%), thereby improving reliability.
“[Our] report reveals that while key DevOps processes and tools, such as continuous integration/continuous delivery (CI/CD) and infrastructure-as-code (IaC) have made significant strides in broad adoption, opportunities for marked improvement still exist,” said Jeff Kukowski, chief executive officer of CloudBolt Software.
Kukowski points to what he calls ‘notable gaps’ in infrastructure provisioning speed, testing and overall reliability that are hindering efforts to advance CI/CD in modern cloud-native environments.
“When we look at Infrastructure as Code (IaC), it should be used to enable non-technical teams to reap its benefits and enjoy better governance and visibility. These are key ways of creating a competitive advantage for users,” added Kukowski.
Be the cloud, Danny
CloudBolt CTO Rick Kilcoyne wrote his own take on this topic in a blog post entitled ‘If it isn’t self-service, it isn’t a cloud’. With an amusing reference to the 1980 movie Caddyshack scene where Chevy Chase urges a young man to ‘be the ball’, Kilcoyne’s intent is to suggest the modern IT teams should ‘be the cloud’ i.e. it should just be natural and it should just work.
Kilcoyne references the National Institute of Standards and Technology (NIST) definition of cloud computing and says that any given instance of good cloud should have the five following essential (not just nice-to-have) characteristics:
- Broad network access
- Rapid elasticity
- Measured service
- Resource pooling
- On-demand self-service
“For the last of these, on-demand self-service, the cloud test is simple. If users can request systems or applications and get them right away – without directly involving IT – they are getting on-demand self-service. If they have to submit a ticket and wait for an intermediary to review and fulfill their request, it’s not a cloud,” said Kilkoyne.
No more C-I-no
Although we have pointed to infrastructure pipeline testing, continuous loop fails and just exactly how we deploy infrastructure as code as key sensitivities, it is probably the self-service element of this story that comes across most tangibly.
The idea of the nasty CIO who says no to new IT deployments (they get known as the C-I-no) because the IT management function can’t sanction change quickly enough is not a model that fits in the post-Covid world of cloud-native. With self-service and automation accelerators that work inside approved secured systems, teams can get more out of cloud, without creating shadow IT.
Get it right and it’s not a lack, crack or slack situation, instead, cloud becomes a good craic.