Roland Moore-Colyer

Clare Hopping

IBM has delivered its third consecutive quarter of growth – with cloud revenue up 20% and now representing almost a quarter of the company’s total revenue.

The company posted total revenues of $20 billion (£15.4bn) for the most recent quarter, up from $19.3bn this time last year, with six month revenues of $39.1bn, compared with $37.4bn from the year before.

Alongside cloud – which has hit $18.5bn in revenue over the past 12 months – IBM cited AI, analytics, blockchain and security as key strengths to its ecosystem. On the earnings call, Jim Kavanaugh, SVP and chief financial officer, told analysts that IBM was exiting the quarter with ‘as a service’ annual run rate of more than $11bn.

“This reflects our success in helping enterprise clients with their journey to the cloud and we’re becoming the destination for mission-critical workloads in hybrid environments,” said Kavanaugh. “We’re capturing this high-value growth with our unique differentiation of the innovative technology combined with deep industry expertise underpinned with trust and security, all through our integrated model.”

Among IBM’s cloudy highlights in the past quarter include a partnership with CA Technologies for the mainframe side, as well as European expansion. The latter was a momentum announcement with IBM having secured several Europe-based customers, including those in healthcare, logistics, and energy.

Meanwhile, SAP’s results saw cloud and software revenue going up to €4.94bn (£4.1bn) in Q218, up from €4,76bn this time last year – and the company has raised its ambitions for 2020 as a result.

At the start of this year, the company praised ‘stellar cloud bookings’ in Q417 causing them to reiterate its 2020 vision. By 2020, the company is aiming for non-IFRS cloud subscriptions and support full year revenue at a top point of €8.5bn, and ‘more predictable revenue’ – cloud support and software support revenue – to be between 70% and 75%.

Now, the company expects a top point of €8.7bn, with CEO Bill McDermott saying the company is presenting a ‘clear strategy’ and that raised guidance shows a ‘new wave of growth has been unleashed.’

“The fourth generation of enterprise applications has taken another major step forward with [in memory suite] C/4 HANA. Together with S/4 HANA, SAP customers are finally able to focus their entire business on delivering a personalised experience to their customers,” said McDermott. “The intelligent enterprise is the elixir to bridge silos inside fractured businesses and beyond so CEOs get a single view of the customer.”

Among the company’s highlights in the previous quarter included the launch of SAP’s Digital Manufacturing Cloud, helping manufacturing providers to deploy Industry 4.0 technologies in the cloud.

While these figures are impressive in isolation, it is worth noting that Alphabet, Amazon, and Microsoft are all declaring in the next week. According to Synergy Research, Amazon Web Services (AWS) leads across all geographies, with Microsoft second and Google third. The only exception is in APAC, where Alibaba secured the silver medal position.

You can read the IBM report here and the SAP report here.

As the enterprise world continues speeding towards complete digitization, technologies like cloud and multi-cloud are leading the charge. Yes, cloud offerings like Amazon Web Services (AWS), Microsoft Azure, and Google Cloud are changing the way enterprises consume IT resources. Having cloud-grade infrastructure at an enterprise’s fingertips opens up opportunities that simply did not exist before.

But are the effects of cloud limited to a collection of somewhat ephemeral infrastructure residing in someone else’s data centre? Or does cloud carry with it the power to change owned infrastructure as well?

The cloud’s impact on data centre architectures

Perhaps the most basic impact of the rise of cloud and multi-cloud is the effect on data centre architectures. In years gone by, enterprise data centres were sprawling collections of sometimes eclectic equipment deployed in support of point applications or use cases. With each new turn that the business took, the data centre was forced to bob and weave.

It’s understandable then that devices with robust sets of capabilities dominated. When IT cannot predict the next requirement, there are only two possible paths forward: deploy devices that support as much as possible, and when that fails, deploy snowflakes purpose-built for narrow use. 

But the cloud doesn’t work this way. Amazon, Microsoft, Google, and the others cannot build bespoke infrastructure for the varying application needs of their users. Doing so would utterly destroy the economies of scale that come from shared infrastructure. Rather, they must design the data centres that power their cloud offerings in such a way that they are robust in capability but uniform in design. Without resource fungibility, there simply is no cloud.

And so data centre designs have changed, favoring commonality over uniqueness. Modern data centres are not a mix of different shapes and sizes. They are a uniform fabric of fixed-form-factor devices, deployed explicitly because they are interchangeable. Servers and storage have long been in this mode. 

More recently, even the network devices that provide connectivity have moved this direction. Built on merchant silicon, these “pizza boxes” (so named because they are thin) are deployed in non-blocking architectures. When something fails, traffic is routed around it, and the device is replaced with an identical copy. 

Within the data centre, this means that racks and rows ought to begin to look identical. Where diversity served the legacy data centre well, it is the enemy of efficiency in the cloud era. This simplifies things like deployment and management, allowing for finer-grained grow-as-you-go strategies. It also makes space, power, and cooling a much more straightforward activity. When devices are the same, planning is reduced to understanding capacity requirements and physical constraints. 

Moving from device-led to operations-led

Ultimately, the cloud is probably more about operations than devices. Historically, data centres have been architected from the devices up. That is to say that things like capacity requirements drive what boxes are required, which then determine what operators must do.

The currency of cloud and multicloud, though, is not capacity so much as it is agility. And this means that physical devices must assume a supporting role while operations steps to the front.

As enterprises look to learn from the cloud movement, they should conclude that operations are the starting point. Enterprises that are not efficient in how they manage their infrastructure will be at a perpetual competitive disadvantage to those companies that have adopted cloud practices to drive their business. 

Operations certainly involve technology movements like automation, telemetry, and DevOps. But enterprises looking to become more efficient need to start with their physical infrastructure.  The enemy of fast is complexity, which means that enterprises need to be taking every opportunity to reduce complexity in their operating environments. One of the easiest ways to make progress here? Eliminate infrastructure sprawl. 

Because most data centres evolve organically over time, they are a collection of different devices. The more different they are, the more diverse the operational model must be. Every unique platform running every unique version of software configured for every unique feature is ultimately making the data centre more diverse. That diversity is an efficiency killer. 

Maintaining economic leverage

While one conclusion to draw here is that a single supplier can help drive data centre evolution, the reality is that enterprises will ultimately want to maintain economic leverage. Indeed, there are no benevolent rulers in IT, and a single-vendor approach to the data centre is likely to wreak long-term economic havoc. 

Instead, enterprises should be architecting their data centres for a common set of functionality that can be offered over two or more supplier solutions. By maintaining interchangeability across vendors, enterprises will find that their procurement teams can reap rewards even as their operation centres rejoice. 

This, too, has implications on the physical data centre. Understanding the underlying merchant silicon that drives solutions will allow architects to steer their designs towards common building blocks available across the industry. Adopting white box servers, for instance, enables things like common sparing, which helps improve repair times and maintain consistency of deployment. In the network realm, standardising on connectivity (25GbE to the server, as an example) allows enterprises to settle on common optics and cabling as well. Anything that drives uniformity will ultimately help the bottom line.

Process dominates

It is certainly true that the data centres of the future will converge on a fairly narrow set of architectural principles. But enterprises that really want to ride the wave of cloud and multicloud will need to evolve their overarching processes as well. 

Where most enterprises today are skilled at deploying new equipment, they struggle at decommissioning aging gear. For example, most enterprises have network refresh cycles of seven years or more. This means that a data centre will have seven years’ worth of equipment in it, built with varying components and supporting varying capabilities. 

Compare that with cloud companies that refresh their hardware every two to three years. It is tempting to argue that the cloud properties have more available spend, making this practice more economically palatable. But the driver behind this practice is actually the same efficiencies that enterprises want within their IT environments. 

By reducing operational divergence, cloud companies make themselves dramatically more efficient operationally, allowing them to grow their capacity exponentially while maintaining their current IT teams at or near current staffing levels. This allows them to divert operational spend back into their capital expenditures, helping maintain this aggressive refresh cycle. And as they deploy newer equipment, they can take advantage of increased scale and performance of newer platforms, frequently adding more capacity at lower per-unit prices.

Perhaps more importantly, these operational efficiencies allow teams to spend less time doing break-fix activities and more time driving value to the business. How much is it worth for an enterprise to be more automated? Or to have better documentation? Or to have robust automated testing? None of these happen when teams are maxed out merely maintaining existing infrastructure.

The bottom line

Data centres are at a point where they simply must evolve. The rise of common building blocks built on standard components has changed the way enterprises plan, build, and operate. By combining these principals with important shifts in both operations and refresh cycles, enterprises can apply the principles of cloud to their owned infrastructure, allowing for dramatic improvements in both utility and efficiency.

Bobby Hellard

Barry Collins

One of the most important but often missed steps in having a reliable infrastructure is disaster recovery (DR). Surprisingly, most companies decide either to not implement DR or to implement it halfway. Here, I intend to explore common terms and understandings in disaster recovery; how to leverage the cloud, different types, the plan and important considerations, as well as the economic impact.

Regional vs. zone/domain DR

DR can be implemented at regional or zone/domain level, depending on needs. I advocate and adopt having high availability (HA) at zone/domain level and DR at regional level; the cloud presents itself as a good alternative in terms of cost value for HA and DR – even more so with the plethora of providers that exist nowadays.

Levelling the field

First, some widely used terms:

RTO – recovery time objective. Essentially how long it will take to have the DR site operational and ready to accept traffic.

RPO – recovery point objective. Essentially to which point in time in the past of primary site the secondary site will return. It is also an indicator of data loss; if data is synced every hour, site A crashes at 11:59am, site B has data until 11am, so worst case scenario is about an hour is lost and the secondary site will be operational as primary site was operational at 11am. That is RPO 1h. The smaller the better – alas the more costly the implementation will be.

Regional – how far is too far and how close is too close? When is close too close? Having primary in London region and secondary in Dublin region, an asteroid the size of Kent falling over Wales can make the solution unviable, but the likeliness of that happening is negligible.

Cost – it is always a factor and in this case, it can make a difference since regions such as Ashburn (USA) are usually (significantly) cheaper than regions in Europe. Other than these main reasons, having a secondary site close to primary is priceless. Now, can it be too far? It depends. If the nature of the business depends on milisecond transactions, then analysts and customers in Bangalore cannot use a site in Phoenix. If it does not, the savings of having a secondary site (temporarily) in a different region are worth it. Also, it is not something permanent – the system is in a degraded state.

An alternative approach is having three DR sites – a primary site with a given RTO/RPO in case it is needed, and a secondary site in the form of pilot light only.

Hot, cold, warm standby

In some circles DR is covered on a hot/cold/warm approach. I usually prefer these terms in high availability architectures, although I have seen DR sites referred to as warm. A hot site is usually a site that is up and running and to which I can failover immediately. That is for me something I would relate to HA as mentioned, however a warm site can be a site that has the resources, and only the critical part is running or ready to run. It may take a few minutes until things are in order and can failover into that DR site.

A cold standby is one that, although it receives updates, they are not necessarily frequent, meaning that failing over may mean that the RPO is much larger than desired, and of course, the RTO and RPO are usually numbers bound to the SLA, so they need to be well thought and taken care of.

Domain/zone DR – worth it or not?

DR at zone/domain level is a difficult decision for different reasons; availability zones consist of sites within a region with independent network, power, cooling, and so on i.e. isolated from each other. One or more data centres comprise a zone and one or more zones (usually three) comprise a region. Zones are used frequently for high availability. Network connectivity between zones is usually very low latency – in the order of a few hundred microseconds – and transfer rate is of such orders of magnitude that RPOs can be made almost obsolete, since data is replicated everywhere in an instant.

As sometimes HA within zones is a luxury, a DR solution can be necessary within the zones. In this case, it is usually an active/passive configuration, meaning the secondary site is stopped.

Economic impact

It is a given that the economic impact is a big factor regarding RTO, RPO, compliance, security, and GDPR as well. It is not necessarily true that the more responsive the secondary site is, the more expensive it is as well. It will depend on the architecture, how it is implemented, and how it is carried on when needed. Basically, the economic impact will be given by the amount of information kept in different sites, not so much by the size of the infrastructure, nor the replication of that information; that which can be automated, and nowadays done with enough frequency as to almost have the same data in two or more regions at any given moment.

Also, as long as the infrastructure is stopped, it is possible to resume operations in minutes without a large impact. Of course, this will depend on the cloud provider. Some providers will charge even for stopped VMs or stopped BMs, depending on the shape/family – for instance Oracle Cloud will continue billing if the instance stopped uses NVMe and SSD, meaning any Dense/HighIO machine – so beware of these details.

Within the economic impact is also the automation. It can be automated, semi-automated, or no automation. For the most part, in DR cases I rather prefer semi-automated on a two-man rule fashion. What this means is even when everything indicates there is a massive outage that requires DR, it will take more than one person to say ‘go’ on the failover, and more than one person to actually activate the processes involved. The reason being: once the DR process is started, going back before completion can render a nightmare.

Pilot light

Although it is strange to see pilot light within economic impact, there is a reason for it; pilot light allows a DR site with the minimum of infrastructure. Although a data replica must exist, the DR site needs only one or two VMs, and those VMs, when needed, will take care of spawning the necessary resources. As an engineer, I sometimes steer towards pilot light with an orchestration tool, such as Terraform.

Having a virtual machine online that contains all the IaaC (infrastructure as code) files necessary to spin up an entire infrastructure is convenient, and usually it is a matter of a few minutes until the last version of the infrastructure is back and running, connected to all the necessary block devices. Remember, nowadays, it is possible to even handle load balancers with IaaC, so there are no boundaries to this.

The DR plan

This is a critical part, not only because it describes the processes that will become active when the failover is a reality, but also because all the stakeholders have a part in the plan and all of them must know what to do when it is time to execute it. The plan must be of course not only written and forgotten, but tested, not only once, but in a continuous improvement manner.

Anything and everything necessary to measure the efficacy and efficiency of it. It is adequate to test the plan with and without the stakeholders aware, in order to see how they will behave in a real situation – and it is also advisable to repeat every six months, since infrastructure and processes can change.

Leaving the degraded state

Sometimes, the plan does not cover going back to the primary site, and this is important, since the infrastructure is at the moment in a degraded state, it is necessary to bring the systems to the normal state so as to have DR again. Since going back to the normal state of things takes time as well, and all the data needs to be replicated back, this is something that needs to be done under a maintenance window, and surely all the customers will understand the need to do so; but just in case, when setting up SLO and SLA, bear in mind that this maintenance window may be necessary. It is possible to add them as a ‘fine print’, of which I am not a fan, or consider them within the calculations.

Conclusion

There are some considerations with regard to DR in different regions, specifically but not only for Europe, and these come in the form of data, security, compliance and GDPR. The new GDPR requires companies to have any personal data available in the event of any technical or physical incident, so DR is no more a wish list item – it is required. What this basically means is that under GDPR legislation, data held of a person must be available for deletion or freed up for transfer upon request. For those legally inclined, more information can be found in article 32 of GDPR. In case DR is found to be daunting, there are nowadays multiple vendors that offer DraaS as well.

Keumars Afifi-Sabet

Twas the week before earnings, and all in the cloud, vendors announced new customers, and took off the shroud.

That's certainly the case with Amazon Web Services (AWS), with Major League Baseball (MLB) extending its partnership with the Seattle cloud giant for its machine learning, artificial intelligence, and deep learning expertise.

MLB already runs various workloads, including its facts and figures base, Statcast, on AWS. The new initiatives aims to improve the experience for armchair fans as well as those in the stadia – the Amazon ML Solutions Lab is being utilised to beef up in-game statistics within broadcasts, including on MLB Network.

The system's success is such that MLB will utilise Amazon SageMaker, the company's product to build, train and deploy machine learning models, to be able to accurately predict the direction of the next pitch crunching statistics on the pitcher, batter and catcher, as well as the game situation.

On a more eyebrow-raising level, MLB also says it will also utilise SageMaker, as well as Amazon Comprehend, the natural language processing service, to "build a language model that would create analysis for live games in the tone and style of iconic announcers to capture that distinct broadcast essence baseball fans know and revere."

"Incorporating machine learning into our systems and practices is a great way to take understanding of the game to a whole new level for our fans and the 30 clubs," said Jason Gaedtke, MLB chief technology officer in a statement. "We chose AWS because of their strength, depth, and proven expertise in delivering machine learning services and are looking forward to working with the Amazon ML Solutions Lab on a number of exciting projects, including detecting and automating key events, as well as creating new opportunities to share never-before-seen metrics."

The baseball arbiter is not the only new or improved customer AWS has announced in recent weeks. 21st Century Fox has expanded its relationship with the company – again with machine learning and data analytics services at the forefront – for the 'vast majority' of its platforms and workloads. The media giant said it had reduced its data centre needs by half and moved more than 30 million assets – or 10 petabytes of data – to Amazon storage.

Earlier this month, Formula 1 selected AWS as its official cloud and machine learning provider, moving the majority of its infrastructure to Amazon from on-prem data centres, while earlier this week Walmart and Microsoft announced a major five year tie-up collaborating on moving hundreds of existing applications to cloud-native architectures.

This time next week all the major players will have reported their latest quarterly earnings. Watch this space for more – but for the time being the position is still one of dominance for AWS. With high levels of capex shoring them up, the growth of the hyperscalers continues, with Synergy Research describing the growth of the last two quarters as 'quite exceptional'.

With a steady stream of high value customers continuing to filter through, the next week's reports should be fascinating to explore.