s0x IT Services Cloud Is performance engineering still needed when it comes to cloud?

Is performance engineering still needed when it comes to cloud?

Is performance engineering still needed when it comes to cloud? post thumbnail image

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.

http://s0x.org/wp-content/uploads/2019/10/is-performance-engineering-still-needed-when-it-comes-to-cloud-3.pngInterested 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.

Related Stories

Related Post

AWS to appeal ‘biased’ JEDI contract rulingAWS to appeal ‘biased’ JEDI contract ruling

<div class="teaser-image"> <a href="/cloud-essentials/public-cloud/8300/aws-to-appeal-biased-jedi-contract-ruling"><img src="http://s0x.org/wp-content/uploads/2019/11/aws-to-appeal-biased-jedi-contract-ruling-1.jpg" alt="Trump on phone" title="Trump on phone" /></a> </div> <span class="field field-name-field-article-type field-type-taxonomy-term-reference field-label-hidden"> <span class="field-item even"><a href="/news">News</a></span> </span><div class="field field-name-field-published-date field-type-datetime field-label-hidden"> <div class="field-items"> <div

Adopting cloud securely: minimise risk; maximise performanceAdopting cloud securely: minimise risk; maximise performance

<img width="640" height="409" src="http://s0x.org/wp-content/uploads/2020/03/adopting-cloud-securely-minimise-risk-maximise-performance-1.png" class="webfeedsFeaturedVisual wp-post-image" alt="Adopting cloud securely: minimise risk; maximise performance" style="float: right;margin-left: 5px" /><p>The post <a rel="nofollow" href="https://www.comparethecloud.net/articles/adopting-cloud-securely-minimise-risk-maximise-performance/">Adopting cloud securely: minimise risk; maximise performance</a> appeared first