The relationship—for lack of a better word—between developers and operations engineers, is more important than many businesses are aware. High-performing teams seem to operate in an easy, DevOps bliss, but for many enterprises, forging new connections to deliver the promise of DevOps ends in frustration and squabbling.

Even the basics, like creating and maintaining useful feedback loops between teams, requires changing attitudes of staff across the organisation. And the requirement for human enlightenment, not simply a yet another technology refresh, is the most critical and overlooked barrier to DevOps success. It’s anathema. We’ve built a world conditioned to seek technical “fixes” first.

The rise in the popularity of DevOps creates excitement—then concern—in boardrooms across enterprises, who hear the hype and fret they’ll fall behind the competition if they don’t embrace this new way of working. Leadership teams the world over have called shotgun weddings between developer and operational teams, many of whom had not only never worked together, but had even been rivals. In the weeks that follow, the scale of the cultural problem becomes apparent.

Developers and ops teams are fundamentally different: they work in different ways, they have different priorities, and they approach problems from different angles. Of course, this means there’s potential for brilliant collaboration, but without the foundations in place to achieve harmony between these disparate teams, “doing DevOps” is doomed to fail.

However, like any great relationship, many organisations discover DevOps teams grow over time, becoming stronger, and encourage a mindset where communication, integration, and real collaboration between dev and ops is welcome. But most significantly, it encourages IT pros and the business to accept a few necessary failures and continually improve—together.

While brilliant for spurring innovation and accelerating transformation, DevOps adoption usually includes some rough patches of disagreement, finger-pointing, and tension. But ask IT team members who’ve made the transition, and most will tell you they’re far more flexible, less stressed, and have higher customer satisfaction than before. Many go further to say they won’t ever go back to a job in a waterfall operation.

The tools for collaboration

While changing team culture is a prerequisite, close on its heels is a reassessment of the DevOps tools your team uses to drive technology change. A well-designed DevOps toolchain frees up software and infrastructure engineers to spend more time working on moving the business forward, like new projects, features, or improvements to architecture, systems, and quality end users notice.

As is always the case with automation, the more time you spend improving your systems, the more they improve. And with DevOps principles, those improvements become data-driven and repeatable, not based on hunches and opinion. Right-tasking your tools will help you break the cycle of primarily fixing things and not preventing incidents in the first place.

The tools employed will vary according to the nature of each organisation. However, some basic principles apply to ensure effective measurement, evaluation, and insight. Because DevOps is relatively new to many technology teams, it’s an opportunity to reintroduce disconnected teams using the tools they already count on, by using them more methodically. Consider tools which emphasise communication, collaboration, and integration first. When software developers, QA engineers, and IT operations all point to the same data in a common dashboard, you’ll likely already see a reduction in friction and faster MTTR.

But what does this look like at scale? With the right tools, developers have easy access to the same performance data operations relies on to monitor effects of their changes on performance.

Almost organically, dev and ops begin incorporating application performance monitoring (APM) tools to move past the limits of estimating user performance from infrastructure metrics. Further, they’ll incorporate APM tools into the development cycles, allowing them to confirm performance and scalability well before code makes its way down the delivery pipeline. Better still, scarce resources like DBAs aren’t pulled in for every CPU or memory alert and instead focus on service indicators like wait time and are free to collaborate on overlooked query or table optimization developers need.

At the production end of the spectrum, IT operations need tools to make collaborating with the extended IT organisation easier. It’s much easier to maintain control over production infrastructure, workloads, and storage with a unified view into application performance. DevOps-focused teams watch application behaviour for changes, anticipated or otherwise, from dev, through QA and perf test, to production. If there’s one driver for unplanned work in ops, it’s being handed an alien application or system with no idea how it’s expected to perform. And Ops hates unplanned work.

It’s important for leaders to ensure the tools supporting the engineers feel natural and valuable to them or they won’t be adopted. While we all have a preferred instrument, the underlying teamwork will discourage bespoke processes, hacks, or brittle workflows. There’s a cultural shift from “what works best for me?” to “what works best for our team?” As an added benefit, teams often incorporate security policy as another monitoring dimension, ensuring governance as business-critical data is dispersed across different dev and ops teams.

As in any relationship, successful DevOps teams have shared more than a few moments of one step forward, and two steps back. You’ll hear some war stories about passionate disagreement, and even occasional disruption between teams. And that’s okay; culture change and individual progress is usually messy, even when you know the endeavour is important.

But when leaders and IT pros alike take steps to minimise the risk of failure by addressing people first, and then the technology, you’re far more likely to use DevOps to full benefit. When colleagues can see the bigger picture and the motivation for change, changing working patterns and habits becomes natural because they all share in the result.

DevOps takes time

A DevOps culture enables most organisations to modernize, and some to even reinvent their use of technology and processes. High-performing, low-friction teams are much more likely to earn freedom to chart their own destinies, shifting from cost centre-like facilities to an agile partner for business growth. When DevOps adoption fails, it’s generally because a few initial failures scare us into retreat, and back to traditional approaches. It’s important to remember that a few rollercoaster moments are important and part of the growth process. Only by personal trial and error in your unique environment can you teams determine how to adapt DevOps principles to your organisation.

A Gartner report entitled New Insights into Success with Agile in Digital Transformation shed light on this. It found that teams with under 12 months experience with a new development process are successful only 34% of the time. By contrast, teams with between one and three years’ experience are successful 64% of the time, while those with more than three years saw that figure jump to 81%. In sum, DevOps requires patience, commitment, and the passage of time.

When we look to the second decade of DevOps, it’s possible we’ll see a rebirth of IT operations as a competitive advantage, not unlike the initial adoption of business computing. Those machines, coupled with a more academic approach to their use, allowed businesses to express their unique value with more speed and less resources. They were successful not simply because of all the tech in their room-sized cabinets, but because they were high-profile, with corresponding investment.

DevOps is a tool like any other, but one which may connect and transform understandably risk-averse, change-resistant teams into a versatile, responsive business partners. And nobody likes living on a cost centre budget.

Interested in hearing industry leaders discuss subjects like this and sharing their experiences and use-cases? Attend the Cyber Security & Cloud Expo World Series with upcoming events in Silicon Valley, London and Amsterdam to learn more.

Bobby Hellard

Adam Shepherd

In early June 2019, Google Cloud suffered a cascading set of faults that rendered multiple service regions unavailable for a number of hours.

This by itself isn’t totally unprecedented; what made it significant was the way it propagated through the very software that was designed to contain it. Moreover, engineers’ initial attempts to correct the issue were thwarted by the failure of that same software architecture. It was the interconnectedness and interdependencies of Google’s management components that contributed to the outage.

The outage

To understand this situation more fully, the following is a short summary of what happened. A maintenance “event” that normally wouldn’t be such a big deal triggered a reaction in GCP’s network control plane, further exacerbated by a fault in that code enabling it to stop other jobs elsewhere in Google’s infrastructure.

The distributed nature of a cloud platform means that although clusters in one area are designed to be maintained independently of clusters in another, if those management processes leak across regions, the failure spreads like a virus. And because these controllers are responsible for routing traffic throughout their cloud, as more of them turned off, network traffic just became that much more constrained, leading to even more failures. In technical terms:

• Network control-plane jobs were stopped on multiple clusters, across multiple regions at the same time
• Simultaneous packet loss and error rates increased across multiple regions
• As a result, key network routes became unavailable, increasing network latency for certain services
• Tooling to troubleshoot the issue became unusable because tooling traffic competed with service traffic

Once the root cause was identified, remediating the failures required unraveling the management paths to take the right processes offline in the right order and apply the necessary fixes:

• Google engineers first disabled the automation tool responsible for performing maintenance jobs
•  Server cluster management software was updated to no longer accept risky requests which could affect other clusters
• Updates were made to store configurations locally, reducing recovery times by avoiding the latency caused by rebuilding systems automatically
• Network fail-static conditions were extended to allow engineers more time to mitigate errors
• Tooling was improved to communicate status to impacted customers even through network congestion

Ultimately, the fault did not lie in Google’s willingness or ability to address issues, but rather in a systemic problem with how the platform reacted to unforeseen events. In a real-time computing environment, there is no margin during which management systems can be offline to fix a different problem located in the other system used to apply fixes to the first one.

So, what does this teach us about modern IT? It proves the theory that operations need to be centralised across footprints and infrastructure with bias towards platforms over point tools. Here are three specific features you want in a modern IT operations strategy.

A global view for local action

Having a global view of a highly distributed infrastructure is critical. Addressing issues in isolation has the potential of propagating faults into areas not currently under test. You need to create points of observation across all regions simultaneously in order to aggregate management data, thus enabling unified analysis to avoid compounding disparate events. This will also help you build a global service performance model by understanding activity throughout your infrastructure.

You must also consider how management tasks are carried out when systems become unresponsive; protect tooling traffic from service traffic and don’t share the network capacity between operational data and system status / events.

The ability to see impact, impactfully

Your enterprise should design a global impact model. IT operations personnel need to understand topology-driven impact before making changes – even automated changes. Google's automation did not consider an impact model, and instead was straight policy-driven automation that scaled mistakes automatically. It’s equally important to understand service dependencies via topology mapping, thus enabling impact analysis to take into consideration the cascading effects of policy-driven automation.

Configuration stores you can count on

Lastly, “backing up the backups” by storing configuration data locally instead of relying on a distributed hierarchy can reduce service restoration time. Retrieving this data regionally will increase recovery latency since competing network traffic during a fault will restrict bandwidth available for management tasks.

This outage was essentially a gift to enterprise-class IT operations teams everywhere who think they are prepared for any inevitable service disruptions. It’s taught us all the value in building an IT ops management strategy that includes a singular, global view of dependencies and impacts. Every business thinks they want to become Google. But this is one way you don't.

Interested in hearing industry leaders discuss subjects like this and sharing their experiences and use-cases? Attend the Cyber Security & Cloud Expo World Series with upcoming events in Silicon Valley, London and Amsterdam to learn more.

Dale Walker

Connor Jones

It’s a common question: what should a business executive consider when determining the best approach for adding cloud to an analytic ecosystem?

We at Teradata have thought a lot about this topic because our customers have substantial environments with significant amounts of data, many dozens or hundreds of applications, and thousands of users all over the world.

Planning for such a “large” scenario in the cloud is vastly different than thinking about what would be required for a “small” or greenfield system because the needs of the latter are orders of magnitude less taxing than those of the former.

And to be clear, I’m not suggesting that tiny is any less important than big; what I’m saying is that the solutions used to address the “large” set of challenges are vastly different than the solutions used to address the “small” set of challenges. This is the case regardless of technology, too: stocking your refrigerator is quite different than stocking an entire supermarket. It’s the same with analytics in the cloud.

As the saying goes, “Quantity has a quality all its own” – and good luck to the executive who assumes that what works in a small analytic proof of concept (POC) will necessarily scale up to work in a large, mission-critical environment. Throughout our history we’ve seen companies leave and then boomerang back once they realise that the grass is NOT greener on the other side of the fence. Buyer beware.

Do this – don’t do that

Advtice: when contemplating migration to the cloud, or when constructing a hybrid (combination of on-premises and cloud) architecture, one should never start with technology and see how it applies to their requirements.

The reverse is the best approach: start with business requirements and then evaluate which tradeoffs, architectures, tools, and mitigation plans are needed to meet the needs. Failing to start with business requirements often leads to an expensive, short-lived “project” rather than an effective, long-term solution. Don’t be “that guy” who assumes. Trust, but verify.

From a business requirements perspective, an ideal cloud analytic solution is one that:

• Blends seamlessly with existing (usually on-premises) infrastructure and applications
• Takes advantage of native cloud capabilities, including security and integration
• Avoids any sort of vendor lock-in which would constrain choice and flexibility in the future

Unfortunately, most folks tend to place too little thought on the first point, because while greenfield cloud deployments are extremely rare – especially for any organisation which is not a startup – it is easiest and simplest to talk about a scenario in which there is nothing to bring along. But, having zero legacy systems or technical debt is probably not (your) reality, so blue sky thinking can only take one so far.

Pick your partner with care

Some of the characteristics that go into what we advocate as a cloud solution include:

• Consistent user experience regarding the tools, languages, and operating procedures with which your users are already familiar – thus speeding time-to-value and creating an all-encompassing ecosystem rather than separate silos of analytics
• Consistent enterprise-class security that lines up with existing corporate policies and role-based access controls – thereby making it easy to operate, govern, and audit across all systems as a cohesive entity. Again, the integrated whole is MUCH more valuable than an itemised sum of the parts
• Advanced optimiser and workload management which enables users and administrators to monitor and manage performance and cost – and adjust manually or automatically to yield the desired mix of outcomes (benefit) vs. inputs (cost)

Let’s cut to the chase: the best (and fastest) way to achieve the right cloud solution for you is to partner with experts who have “been there and done that”. As with any complex undertaking offering high return yet also high risk, starting with a trusted advisor is the soundest approach to a successful outcome.

As the saying goes, “Only a fool learns from his own mistakes. The wise man learns from the mistakes of others.”

Interested in hearing industry leaders discuss subjects like this and sharing their experiences and use-cases? Attend the Cyber Security & Cloud Expo World Series with upcoming events in Silicon Valley, London and Amsterdam to learn more.

Bobby Hellard

If one other thing besides death and taxes is certain, it is that cloud security will remain a key talking point. Whose responsibility is it exactly – and why does the shared responsibility model continue to cause havoc?

Some areas however can be nailed down much more solidly. The Cloud Security Alliance (CSA) has issued what it calls the ‘egregious 11’ in its latest report, giving organisations an up-to-date list of the biggest cloud security concerns to aid better risk management decision making.

Many of the biggest security risks are ones which regular readers of this publication will be more than familiar. Data breaches, insider threats and account hijacking, along with account misconfiguration, are usually at the sharp end of any public snafus, from Capital One in the former, to Facebook in the latter.

As a result, the CSA recommendations are more mantras than anything new. Data is rapidly becoming the primary target for cyberattacks, while data accessible via the Internet is the most vulnerable asset to misconfiguration. Companies need to bring automation into the equation to remediate any misconfiguration issues.  

The section subtitled ‘lack of cloud security architecture and strategy’ is an interesting one – and it is here where the report notes the lack of awareness around shared responsibility as key. “The functionality and speed of migration often take precedence over security,” the report notes. “Implementing security architecture and developing a robust security strategy will provide organisations with a strong foundation to operate and conduct business activities in the cloud.

“Leveraging cloud-native tools to increase visibility in cloud environments will also minimise risk and cost. Such precautions, if taken, will significantly reduce the risk of compromise.”

There is some good news, however. The previous report from the CSA focused around what it called the ‘treacherous 12’. Even for those with a less-than-stellar grasp of mathematics, it is worth noting things are going in the right direction, albeit slowly.

The report argues that many traditional cloud security issues which fall to vendors are no longer seen as a major threat. These include denial of service, shared technology vulnerabilities, and CSP data loss.

Yet while these areas can be seen as being well addressed, the other interpretation is that security issues which are the result of management decisions around cloud strategy and implementation are of much more concern.

“The complexity of cloud can be the perfect place for attackers to hide, offering concealment as a launchpad for further harm,” said John Yeoh, CSA global vice president of research. “Unawareness of the threats, risks and vulnerabilities makes it more challenging to protect organisations from data loss.

“The security issues outlined in this iteration of the report, therefore, are a call to action for developing and enhancing cloud security awareness, configuration and identity management,” Yeoh added.

You can download and read the full report here (email required).

Interested in hearing industry leaders discuss subjects like this and sharing their experiences and use-cases? Attend the Cyber Security & Cloud Expo World Series with upcoming events in Silicon Valley, London and Amsterdam to learn more.

The rollout of 5G has begun in earnest. Verizon and other US carriers have already unveiled the tech and its groundbreaking speeds in a few key markets, and across the pond in the UK, some major carriers are widely expected to deploy 5G later this summer. Many expect 5G to be equally as disruptive – if not more so – than cloud computing has been over the past few years.

All of this raises questions when it comes to the cloud. How will 5G’s breakneck mobile speeds affect cloud computing and many of the most common applications of it? What are examples of the cloud – and technology more generally – that 5G will markedly improve versus those it may render obsolete?

Why 5G is such a big deal

Before we dive too deeply into how 5G will affect the cloud, it will be useful to have at least a layman’s understanding of what 5G actually is and how it works. Like the network standards before it, 5G employs radio frequency (RF) waves to transmit and receive data. The minimum speeds a network must provide to both downloading and uploading for it to be classified as 5G are 20 Gbps per second down and 10 Gbps up. For comparison’s sake, the minimum download and upload speeds for the first iteration of 4G were 150 and 15 megabits, respectively.

As big of an increase as these speeds represent, 5G also presents an equally groundbreaking decrease in latency. Latency is the time it takes for two devices on a network to respond to one another. 3G networks had latency of about 100 milliseconds; 4G is around 30 milliseconds; while 5G will be as low as 1 millisecond, which is for all intents and purposes instantaneous.

What 5G will improve

Thanks to the insanely low latency we mentioned above, things that rely on speed will be obviously improved. Near real-time control of robotics will open up new worlds – and indeed, already has – when it comes to remote surgery, which will literally save lives.

With 5G will come incalculable improvements to the Internet of Things (IoT), which is much more than just being able to tweet from your refrigerator. Smart cities rely on IoT to reduce traffic congestion, stay on top of water distribution needs, increase security, and even decrease pollution. Agriculture uses IoT devices to be more efficient and thus increase the globe’s food supply. 5G will also vastly improve truly autonomous, self-driving cars to the point where wide adoption may very well become a reality. All of these will help keep us safer, healthier, and alive longer.

If it seems like 5G will only being improvements, that might not be the case – especially for the cloud.

Possible impact to the cloud

Trying to come up with a definitive list of every possible aspect of cloud computing that 5G will affect is likely an impossible task, as we won’t fully know until it’s widely rolled out and customers and enterprises have had a chance to acclimatise to it. But even in these days of 5G infancy, there are definite known knowns.

First, as we have covered, 5G will effectively eliminate latency, allowing device to connect nearly instantly. What does that mean for the cloud? In theory – it could mean the death knell for cloud computing as a whole.

Think about it. One of the main reasons the cloud is so beneficial is for numerous devices – either in an organisation for a private cloud or any user with an Internet connection for a public cloud – to connect to and transmit data with a central machine or hard drive located on the cloud. For an employee to share a large video file with a colleague who’s working from home that day, the cloud made it simple – just put it on the shared drive, wait for it to upload, notify your co-worker it’s up there, and he or she can download it from the same shared drive.

But why go through all that if your device can connect with your colleague’s device with only a millisecond of latency and a minimum connection speed of 20 Gbps down and 10 Gbps up? That large 10 gigabyte video can be transferred from user to user directly in about eight seconds and there’s no need to go through an additional step or use an online repository.

While the cloud will still likely have significant use cases in a post-5G world – especially if cloud providers are ready to adapt – it’s not too much of a stretch to envisage a world where the cloud is largely a thing of the past.

Interested in hearing industry leaders discuss subjects like this and sharing their experiences and use-cases? Attend the Cyber Security & Cloud Expo World Series with upcoming events in Silicon Valley, London and Amsterdam to learn more.