Företagens IT blir allt mer komplicerad, och en av följderna är att det blir svårare att ge användarna snabba applikationer och molntjänster.
Detta kan lösas med hjälp av lastbalansering, men många företag är inte nöjda med hur deras lösningar för detta fungerar.
”Många IT-avdelningar efterfrågar idag hjälp med att lösa de olika utmaningar som finns ifråga om överbelastade nätverk och applikationer med långa svarstider”, menar Andy Redman, chef för lösningsteknik, Nord- och Sydamerika, på Progress.
För att inte dåligt presterande applikationer ska hämma produktiviteten och till och med skada företagets rykte krävs det noggrant utformade lastbalanseringslösningar i nätverksmiljöerna. Idag kan man se flera trender som handlar om hur lastbalanseringen kommer att förändras och behålla den prestanda som behövs för att användarna ska få en bra upplevelse.
”För att möta företagens behov måste lastbalanseringen vara enkel att implementera och mycket säker, eftersom detta är några av de mest efterfrågade egenskaperna hos nya tekniska lösningar”, säger Andy Redman.
Implementeringen behöver bli enklare
När företag väljer vilken lastbalansering de vill ha är en enkel implementering den viktigaste faktorn, visar en undersökning från EMA, en ledande branschanalytiker. EMA har frågat 350 större företag om deras lastbalansering och nära hälften (43 procent) tyckte alltså implementeringen riskerar att bli för komplicerad.
En svår implementering innebär inte bara en större risk att få problem utan också att kostnaden kan bli större. Det är en stor investering att se till att tekniker får den kompetens de behöver för den nya lösningen, och ju mer kompetens de behöver desto större blir den initiala kostnaden.
Handlar lastbalansering egentligen om säkerhet?
EMA frågade också vad som är den viktigaste typen av funktioner, och nätverks- och applikationssäkerhet var då det mest populära alternativet. Nära hälften (47 %) såg säkerheten som viktig, vilket var fler än de som prioriterade snabbare applikationer. Framför allt är säkerhetsrisker och incidenter den viktigaste drivkraften till att byta lösning.
Detta fokus på säkerhet kan tillskrivas branschens mest välkända lastbalanseringslösning som för närvarande har fler än 800 kända kritiska sårbarheter (CVE:er – se https://www.cvedetails.com/). Ett så stort antal sårbarheter försämrar dess rykte och påverkar även de leverantörer som erbjuder lösningar som har bättre säkerhet.
Centraliserad styrning
De flesta verksamheter vill idag styra sin programvara från en centraliserad hantering som levereras av leverantören. Detta kan ses som ett exempel på att man vill se mindre komplexa lösningar. En central styrning gör det enklare att få en överblick av de trånga sektorer och andra problem som uppstår. Likaså vill man gärna ha alla säkerhetsvarningar på ett enda ställe och snabbt kunna få tillgång till all tillgänglig information som finns om dem.
Ett allt mer splittrat moln leder till ökat behov av lastbalansering
De senaste åren har många företag placerat sina applikationer i en rad olika molntjänster. Nyligen har dock trenden vänt, och företag har tagit tillbaka en del av applikationerna, ofta beroende på att de upptäcker att kostnaderna blev högre än de tänkt sig. Slutsatsen är därför att olika applikationer kräver olika lösningar. Vilket också gör att allt fler verksamheter hanterar multimolnlösningar och att komplexiteten i fråga om lastbalansering därför ökar. Det gör också att verksamheter som tidigare inte märkt av behovet av lastbalansering nu upptäcker att de behöver en lösning.
Andy Redman menar att detta också gör att missnöjet med existerande lösningar ökar: ” Många verksamheter har inte tillgång till de specialister som behövs för att styra de mer svårhanterade lösningarna. Det gäller inte minst de som precis investerar i sitt första lastbalanseringssystem.”
Det här kan också vara orsaken till att 80 procent av verksamheterna enligt undersökningen från EMA sa att det var mycket eller ganska sannolikt att de skulle byta leverantör inom två år, varav 27 procent sa att det var mycket troligt.