Opinion Now that cloud vendors are delivering features constantly, which are backed with hard data and with good specs, the question which comes to mind is: shall we continue to measure, as we did in the days of the data centre, or shall we blindly trust the vendor and save ourselves plenty of time and duplicated effort?

This is a question I asked myself some time ago – and it has taken me some time to come up with an answer I’m happy with.

Round one: The beginning

A few months ago, I was invited to a meeting in which the aim was decide and weight the ‘need’ of measuring performance versus not in the company cloud. The reason I was invited was two-fold: one, it is part of my role and within my circle of competence, and two, I am all for cloud-native philosophy, methodology and application, and I have been using it for many years before Oracle Cloud infrastructure was born.

The meeting started with some attendees asking my team to perform measurements and find out if the infrastructure will or will not support our set of applications with the current network architecture. My response was: do we need to? In cloud, we need to trust our vendor. We usually must not over-measure and stress test a platform that is given to us with clear features and metrics. There are SLIs/SLOs/SLAs in place to assure the client – us – that the systems will perform adequately.

So far, this meant performance engineering was not needed for this task. We agreed on that and we called it a day. It was something the vendor made clear in terms of specs, and we were clear in terms of what we’ve got, from how many VM cores and how much memory per VM, to load balancing bandwidth and latency, and so on. In conclusion, with all these specs in place, there is no need to go overboard doing stress tests, smoke tests et al, in the same way we were – and still are – in a data centre.

Round two: The revelation

After that meeting, some performance tasks we were used to were less necessary, especially as different clouds kept adding features and guaranteeing they will perform up to the levels expected. After all, it’s their responsibility.

But a few weeks back, I was required in a different situation. The aim this time was not to ‘confirm’ what the vendor was saying; it was basically using the skillset, to go the extra mile the vendor couldn’t or wasn’t within the scope.

In this case, it wasn’t to measure networking specs but to compare native versus paravirtualization launch modes, and other related areas. Although the vendor is saying that it will be better or faster, nothing indicates how much better, or how much faster, and opinions can be very subjective, especially when dealing with many components in a complex architecture. This case was justified, as metrics were unclear, there was a grey area, and things got subjective quickly.

Round three: The conclusion

This means with cloud things are simplified, as they were meant to be, and we shouldn’t complicate things if we have a trusted vendor, because all those tasks were already carried by them.

That being said, there are situations in which the vendor was not able to, or not meant to run some performance tasks. These are very particular situations that may appear, and performance engineering will still be needed.

Now, my circle was closed and I understood when it was a good time for investment and when wasn’t. However, in some situations, two things happen. Firstly, we might want to have that extra assurance that the specs are valid. There’s nothing wrong with that, we just need to pick those situations well to avoid wasting gunpowder. Secondly, management wants to do it; and even though engineers sometimes know better, occasionally the business just wins.

Performance engineering is far from death, particularly so with new approaches such as failure injection, chaos engineering, and intuition engineering. New techniques, knowledge and tools are being created all the time – we just need to be able to leave pride to the side and acknowledge when that part of our role is not needed.

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

Dale Walker

Jane McCallion

UK supermarket chain Sainsbury’s is collaborating with Google Cloud on machine learning for greater customer insights – in another example of a cloud partnership among major retailers.

The company is looking at building machine learning solutions on Google Cloud Platform (GCP), in association with Accenture, to ‘provide new insights on what customers want and the trends driving their eating habits’, in the words of Alan Coad, Google Cloud managing director UKI in a blog post.

While that phrasing could be construed as peculiar, the overall goal, of building stronger customer profiles and providing greater value to customers through big data crunching, is one which resonates.

Sainsbury’s analyses data from various structured and unstructured sources, and is looking to Google to clean up the data, classify it, and deliver insights in real-time. Predictive analytics models have been deployed by the supermarket chain to sense trends and adjust inventory as a result. Google Cloud’s retail page outlines a five-step process to data nirvana: scaling infrastructure, developing new applications, unifying data streams and using collaborative tools to get insights faster.

“The grocery market continues to change rapidly. We know our customers want high quality at great value and that finding innovative and distinctive products is increasingly important to them,” said Phil Jordan, group CIO of Sainsbury’s. “With the help of Google Cloud Platform, we are generating new insights into how the world eats and lives, to help us stay ahead of market trends and provide an even better shopping experience for our customers.”

“The food sector is experiencing significant, rapid disruption, and this new cloud-based insights platform will help Sainsbury’s identify trends much earlier and adapt their product assortment in a faster, more informed way – all for the benefit of customers,” added Adrian Bertschinger, managing director for retail at Accenture.

Analysis

The rise in retailers partnering with the largest cloud providers is a trend which has been covered variously by this publication. In particular, the choice of cloud has frequently raised eyebrows. At the start of this year, US grocer Albertsons signed a three-year deal to make Microsoft Azure its preferred public cloud. Pharmaceutical giant Walgreens Boots Alliance signed a similar deal – albeit for seven years – in the same month.

This momentum, alongside a long-running saga last year where Walmart firmly placed its flag on terra Azure, led some to question whether top tier retailers were moving away from Amazon Web Services (AWS), the largest public cloud provider, whose parent company happens to be a rather large retailer. Indeed, according to the most recent Forbes Global 2000 list in May, Amazon surpassed Walmart as the leading retailer for the first time.

While it makes for a nice headline, this trend may be something of a red herring. AWS’ retail customers include Ocado, Under Armour and River Island. Perhaps its biggest customer is itself. Amazon had been gradually moving away from Oracle, and AWS chief executive Andy Jassy announced at the end of last year that Amazon’s consumer arm was now running the vast majority of critical system databases on AWS.

Speaking to CloudTech in April Jean Atelsek, digital economics unit analyst at 451 Research, dispelled the myth. “It’s easy to get the impression that retailers are fleeing AWS,” said Atelsek. “Microsoft’s big cloud partnership with Walmart seems to be the example that everyone wants to universalise to the entire cloud space. However since a lot of retailers also sell through/on AWS, they’re less likely than Walmart to see Amazon (and by extension AWS) as the devil.”

As the Sainsbury’s example shows, organisations across verticals are looking to utilise more mature machine learning models and techniques through the biggest cloud vendors. Even taking into account the buzzword factor, this year has seen an explosion of companies citing ML as a key factor, from media companies for content archiving (The Globe and Mail) to sporting brands for quicker insights (Formula 1), to both (NASCAR).

According to Kantar figures earlier this year, Sainsbury’s fell to third place in terms of the largest UK supermarkets, slipping behind Asda. The collaboration with Google Cloud will look to give the company a foot up; as Coad noted, the company’s vision is to ‘be the most trusted retailer’ and ‘make customers’ lives easier, by offering great quality and service at fair prices.’

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.

Nicole Kobie

Chaos engineering (CE) is the discipline of experimenting on a system in order to build confidence in the system’s capability to withstand turbulent conditions in production. This approach is becoming commonplace in DevOps practices; but how would its application extend to IT operations?

In truth, CE for IT operations offers a similar framework for stress-testing a technology platform to understand its weak points and performance pitfalls under heavy pressure.

CE tends to be used primarily in DevOps during bug testing: setting up experiments to run software under different conditions, such as peak traffic, and monitoring how it functions and performs. This becomes increasingly necessary in cloud-based systems where failure to understand extreme load responses could result in runaway cascade failures or, worse yet, spinning up thousands of extra nodes handling error conditions while not doing any actual work.

These same principles, applied to IT operations management (ITOM), help define a functional baseline and tolerances for infrastructure, policies, and processes by clarifying both steady-state and chaotic outputs when extremes are reached.

Applications in IT

The theory of CE in DevOps gained early traction at Netflix as they moved from physical to virtual infrastructure, with the team that implemented it on AWS breaking off to form Gremlin. However, chaos engineering is not typically used in IT operations, because ITOM has historically been separated from development (generally, IT monitors system dynamics, and when a problem occurs, engineering change management or ITSM is brought in to remediate the issue).

With the growth of containerisation in cloud applications today, IT infrastructure looks more like development environments than classical multi-tier architectures. But the limitless scale of the cloud means failures can also be limitless: microservices are well-served by testing elasticity and scalability, data flows, and resiliency through stressing the system to the edge of its tolerances and fixing their shortcomings before a public crash.

1, 2, 3… chaos

Implementing chaos engineering for IT operations management provides a systematic approach to identifying weaknesses in a microservices-world. In a monolithic environment, you have visibility into performance and event metrics that may be lost with microservices designs. As a result, the need for operational insights becomes even more critical when scaling to unknown workloads.

Netflix’s Chaos Monkey grew out of CE principles from their own cloud-native community, meant to address the gaps in common dev tools’ abilities to manage extreme complexities. This methodology is extendable to infrastructure and helps to set guardrails on platform behavior as a whole. So how should a team bring this thinking into their IT operations management? Follow these five fundamental steps:

• Define the current steady state: Performing baseline analysis is a standard concept in capacity planning, upgrade strategies, and other high-impact functions. Start with something relatively simple (and small) so that you don’t get overwhelmed by the data, or risk interfering with the business if something goes wrong (such as security Red Teaming). For example, monitoring CPU and network utilisation, which are common bottlenecks in any IT shop
   
• Define optimal conditions. There’s how your system generally operates, and then there’s how it should operate; these typically aren’t the same thing. CPU utilisation and network latency are always affected by application efficiencies, hardware conditions, and a host of other factors. Create a standard that outlines what engineers should expect on a normal day, on an easy day, and on a very hard day. These are the control groups, and the extreme day will be the stress test
   
• Form a hypothesis. Where will the system break? If you’re running an application scenario such as doubling the peak traffic that even your worst day so far has seen, will your CPU maintain optimum utilisation (or will the container provisioning engine smoothly deploy additional nodes) as in the variable control groups, or will it spike so severely that processes grind to a halt because there isn’t enough memory or network bandwidth left to manage the load?
   
• Execute a real-world event (but contain the blast radius). Do something extreme, like taking down a firewall that severs connectivity to one internet service provider. This will confuse the application as it tries to respond to requests with repeated failures, ramping up CPU processes as errors return from a dead network endpoint. Log events will mount, filling the database and saturating the backbone
   
• Validate the hypothesis. What happened? Monitor utilisation and network throughput during the test and see where the system fell over. Is it what you expected, or did something never previously considered take place? Did new chaos erupt from the fissures in your infrastructure? Stabilise, document, and remediate

Never stop not being afraid

Stressing a system to its absolute max—and a little bit further—to see where things go wrong allows you to understand steady-state behavior and error-handling, so you can fix it before something breaks in new and unexpected ways. What do traffic spikes look like? What are real-world events and their impacts on your organisation?

Chaos engineering is not just for DevOps. It should be a systemic practice for load-testing (out of your comfort zone) to the point of failure. It’s a responsibility for more than microservices deployments and applies to all sorts of disciplines within the IT organisation.

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.

Google Cloud’s European expansion continues with the launch of a new region in Poland, alongside unveiling strategic partnerships.

The new region will be hosted in Warsaw as part of Google’s commitment to Central and Eastern Europe. Prospective customers of the region will have access to the usual products, from Compute Engine to App Engine, to Google Kubernetes Engine, Cloud Bigtable, Cloud Spanner, and BigQuery.

“As part of our strategic partnership, DCP (Domestic Cloud Provider) will become a reseller of Google Cloud services in Poland and will build managed services capabilities around Google Cloud,” wrote CEO Thomas Kurian in a blog post. “With this DCP partnership, we will be able to boost our support for Polish enterprises, providing advanced infrastructure and software that suits their needs.

“Together, our goal is to accelerate cloud adoption by large and small businesses alike, across all industries,” Kurian added. “Over the next five years we’ll train experts to help Polish businesses onboard to the cloud, as well as provide insights and strategic advice on how companies can maximise the benefits of their cloud deployments.”

Michal Potoczek, chief executive of Poland’s national cloud operator, added: “We believe in a multi-cloud strategy. A Google Cloud region, together with our own infrastructure, will allow us to build hybrid services which will bring even more value to our customers.”

This marks the first data centre launch by one of the big three in Poland. While Microsoft claims to have the widest global reach its next European target is Norway, while for Amazon Web Services (AWS) Italy is the next port of call.

Google had previously opened the doors to its Zurich data centre region in March, while Microsoft, in the European data centre arms race, unveiled plans for Azure availability in Germany and Switzerland last month.

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.

Connor Jones

Now that operating in the cloud is officially mainstream, it’s gotten a reputation for costing more than expected. Cloud sprawl, however, is rarely the problem – in fact, we like to think of sprawl as a symptom. On the bright side, it’s often a symptom of creativity and innovation by your IT team. On the dark side, it’s also often a symptom of poor planning and a lack of governance.

Here’s a guide to structuring (or restructuring) your cloud adoption so that any growth in expenses is tied to commensurate improvements in outcomes.

Unplanned sprawl is always bad

The on-demand nature of cloud infrastructure and services make growth frictionless. It’s as easy to spin up a new server as it is to download a document. While that’s fantastic for a team’s ability to innovate and grow, it’s also a little frightening.

When there’s a complete elimination of hardship in commissioning new cloud services, it’s entirely too easy to exceed your budget. 

What we often see happen is that a company decides to dip a toe in cloud transformation. They don’t worry about creating detailed governance guidelines because they’re treating their cloud use as a trial – they want to see if it’s right for them.

But as soon as engineers see what’s possible in the cloud, they get ideas. They start to figure out creative solutions for the problems they’ve been dealing with for years. And because the cloud is frictionless, they can spin up new resources without batting an eye. Before you know it, the cloud bill is double what you budgeted and you have no plan in place for ensuring that any of your experiments become ROI positive.

…but sprawl itself can be transformative

Of course, the lack of friction is also what makes the cloud such an amazing tool.

For example, in the pre-cloud era, I was working at a hedge fund. A colleague and I wanted to take massive amounts of data and run it through a bunch of scenarios to start doing predictive data arbitrage.

We knew we’d be able to glean valuable insights if we ran our data through enough scenarios and models. But in order to process all the data we’d bought in time for our analysts and quants to evaluate and make decisions about it, we’d have needed about 200 servers, which would have meant millions of dollars in capex spend.

And keep in mind: this was just for research. We had no way to guarantee that our analysis would have a positive ROI. Of course we didn’t get it approved.

With the cloud, though, we could spin up enough servers in a few days, run the scenarios, and spin down the servers. The cost would be much lower, which means the additional revenue needed to justify the project would be lower.

And that’s true in nearly every situation: because you can provision resources on an as-needed basis, you can achieve much smaller returns to justify your investment. And as you discover ways to increase profit incrementally, you can, thanks to the way the cloud works, rinse and repeat.

To ensure positive sprawl, invest in planning and governance

So how can you enjoy the many benefits of cloud infrastructure without suffering from its pitfalls? Start with a plan. 

Even if you only have plans to run a cloud trial, start with a plan. 

The cloud offers near-infinite ways for your engineers to solve problems, and as soon as they get a glimpse, I guarantee they’ll want to try things out. Without a plan in place, they’ll do exactly that, and the next thing you know, you’ll have dozens of active cloud accounts paid for with dozens of different credit cards. (This is a real thing we see.)

So, again: make a plan. Make a plan for how new cloud spend is approved and paid for. Make a plan for reviewing cloud usage and spinning down resources that are no longer useful or active. Make governance guidelines.

If you’re not sure what should go into your cloud plan, consider working with consultants who have experience creating these plans. With a plan in place, you’ll have a clear idea of how you’ll be using cloud resources to improve your business’s operations. Without a plan, you will see sprawl. Most importantly, without a plan, you may end up spending much more than you expected – without achieving the outcomes you were after in the first place.

Creative solutions start with practical guidelines

Sprawl is almost inevitable when a company launches a cloud transformation: because the cloud is capable of more than in-house servers, moving to the cloud inevitably means that companies do more than they used to.

To ensure that you do more in a budget-conscious way, invest time and energy upfront in establishing a plan and governance rules for your cloud usage. Once you’ve laid out rules of the road, you can let your developers explore safely, without racking up unexpected bills.

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.