Av Techopedia Staff, 21 juni 2017
Takeaway: Värd Eric Kavanagh diskuterar den mobila arbetskraften med Dr. Robin Bloor och IDERAs Bill Ellis.
Du är för närvarande inte inloggad. Logga in eller registrera dig för att se videon.
Eric Kavanagh: Okej, mina damer och herrar, det är onsdagen den 21 juni. Det är 4:00 östlig tid och det betyder naturligtvis i världen av företagsteknologi att det är dags för Hot Technologies! Ja verkligen. Jag heter Eric Kavanagh, jag kommer att vara din värd och moderator för dagens evenemang. Det är ett hett ämne, det är ett stort: “En Marche! Aktivera den mobila arbetskraften. ”Och jag tog inte avsiktligt taglinjen från Mr. Macrons kandidatur i Frankrike. Det var ganska slumpmässigt, jag lovar er, men det är fortfarande ganska spännande. Så vi pratar allt om den mobila arbetskraften och hur du kan se till att dessa människor får det de behöver och att de kan göra det de gör bra. Massor av utmaningar, massor av problem där ute. Vi arkiverar denna webcast för senare visning, så om du missar något kan du komma tillbaka och kolla in det. Dela det också med dina vänner och kollegor.
Och jag skulle säga inte vara blyg; det bästa sättet att få riktigt anpassat innehåll och den information du behöver från ett evenemang som detta är att ställa frågor. Så du kan ställa en fråga från chattfönstret eller från Q & A-komponenten på din webcastkonsol. När som helst under evenemanget, skicka det på så kommer jag säkert att ta tag i det och väva det i frågan och svaret i slutet. Vi kommer att ha ett par presentationer och sedan hör vi av Bill Ellis från IDERA Software. Naturligtvis är vår egen Robin Bloor på väg idag. Och med det, låt oss dyka rätt in.
Så jag har fått bra statistik från RCR Wireless om vad som händer, och det är verkligen ganska sinne. De säger att den globala mobila arbetskraften kommer att drabba 1, 87 miljarder människor år 2022. Det är över 40 procent av den totala arbetskraften på planeten. Så om du tänker på det, så plötsligt var du brukade ha, när det gäller IT-kapacitet, när det gäller funktionalitet på enheter som datorer, där du brukade ha 99 procent eller mer av det i lokalerna i din kontor - det var jämnt, låt oss säga för 15 år sedan, för 10 år sedan var det förmodligen 85-90 procent, för fem år sedan var det som 70 procent? Något sådant? Nu är det hela vägen ner, nästan till 60 procent. Och det här är en stor sak. Så vi har sett denna enorma förändring när det gäller tekniken, de verkliga verktygen som människor använder flyttar utanför kontoret, in i arbetskraften.
Det finns otaliga fördelar med detta. Jag menar, bokstavligen om du tittar på sjöfartsbranschen till exempel, som UPS, eller om du tittar på killar som går ut till riggarna i oljefält, om du tittar på något av de olika jobb där det hjälper till att ha djup funktionalitet med dig, på vägen, den mobila arbetskraften förändrar allt. Nu är ett av problemen - och vi kommer att prata om det här något större djup - att vi har ett par olika saker på gång, varav ett är mångfald av arbetskraft. Så 2020 - jag såg bara statistiken idag - kommer det att finnas fem generationer människor i arbetskraften. Det betyder att du kommer att ha mormor och morfar och sedan mamma och pappa och även barnen, men teoretiskt kommer du att ha väsentligen morfar och morfar och farfar och mormor där ute. Nu är det uppenbarligen inte inom en viss familj, men poängen är generationsmässig, du har fem olika kategorier av breda individer i arbetskraften, var och en har sina egna tendenser, sina egna förutsägelser, sin egen benägenhet att arbeta med teknologi.
Självklart tenderar barnen att vara mobila först när det gäller hur de interagerar med världen. Och tänk bara på kommunikationskanalerna som det ändrade - vi pratade om detta på en annan show nyligen; SnapChat är hur många tonåringar kommunicerar, de vill inte ens prata med dig i telefon, de vill bara skicka små SnapChat-meddelanden fram och tillbaka. Det är bara ett exempel i konsumentvärlden på hur saker och ting förändras, och det kan spridas över hela spektrumet av teknik, funktionalitet, individ, företag, affärsmodell. Det är bara över hela kartan, men poängen är att den mobila arbetskraften är verklig, den är ute och om inte ditt företag har ett solidt program för att förstå hur det påverkar dina affärsprocesser - och jag talar mycket specifik teknikdriven data- drivna processer - om du inte förstår vad det är och inte hanterar det genom en IT-infrastruktur och en process och ett styrningsperspektiv kommer du att ha alla slags problem.
Så det finns iPhone. Jag kommer ihåg när den suckaren kom ut, det verkar som för en miljon år sedan. Men det var bara som vad, 2007 eller '08? Det var inte så länge sedan att vi inte hade iPhones, och naturligtvis formfaktorn bara grundläggande förändrade teknik, och verkligen aktiverade den mobila arbetskraften. Och jag minns naturligtvis vid den tiden, iPad kom ut och sedan iPhone, ungefär samma gång. Jag kommer inte ihåg vilken som var först, men iPad var verkligen en av de viktigaste förändringskrafterna för företagets IT, kanske sedan stordatorn. Och orsaken är för att uppriktigt sagt, många mycket ledande befattningshavare, C-svitfolk i stora organisationer älskade det rätt ut ur fladdermusan. Och sa: ”Jag vill ha det. Jag tar med det till jobbet. ”Tänk på det - plötsligt måste IT vända sig och hantera problemet som de förmodligen inte ville ta itu med, vilket handlade om alla dessa nya enheter.
Så nu, om du hade iPads - ja, hur väver du det i matrisen? Hur upprätthåller du styrning över det? Dessa är alla riktigt stora utmaningar och den gamla iPad och iPhone var verkligen en oerhört störande kraft inom IT och inom IT-hantering för många organisationer, stora som små. Så vi har fortfarande detta spektrum av utmaningar och fördelar som sträcker sig över ungefär en så bred grupp som du kan föreställa dig med mobila enheter. Och naturligtvis förändras de fortfarande, eller hur? Så nu är det inte bara BYOD, det är BYOA många gånger, där chefer och proffs tar med sin egen enhet. Vi brukade kalla det "skugga IT", eller hur? För er i er i den äldre generationen kanske ni kommer ihåg de gamla radioprogrammen, de hade radiodrama och en av dem var Skuggan - ”Vem vet vad ondska lurar i människors hjärtan? Skuggan vet. ”Och jag kommer ihåg det eftersom jag var liten. Tja, skugga IT frickar överallt i dessa dagar; alla gör skugga IT.
Så detta är en verklig utmaning för IT-hantering och affärsprocesshantering, alla verksamhetsfolk. Du vill kunna utnyttja mobila enheter, men du vill kunna binda det tillbaka till dina system, och det finns massor av konstiga, små problem som kommer in. Inte minst är den visuella upplevelsen och den tillhörande funktionaliteten du får när du använder en mobil enhet. Och någon av er som har använt flera enheter som en iPad, kontra en bärbar dator, kontra ett skrivbord, kontra några av de nyare mobila smartphones som kommer ut, efter att ha upplevt att funktionaliteten inte fungerar riktigt, och det här är ett verkligt problem. I själva verket borde webbläsarkrig ha förberett oss för detta, eftersom webbläsarna alla gör saker något annorlunda också. Och det är en annan stor utmaning för att inte bara design, inte bara utseendet och känslan och den eleganta karaktären i applikationen du använder, utan den faktiska funktionaliteten. Hur får du rullgardinsmenyn för att välja vad du vill ha på den enheten? Det är en stor sak.
Så det är vad vi ska prata om lite idag, och vi kommer att höra från Robin och Bill Ellis, som jag nämnde, som är en riktig expert på detta område. Så detta är en av de stora frågorna som människor har - det är bara att darn-sorten och det finns ingen enda metod för att kunna arbeta över plattformar. Du har fått Samsung och Apple mestadels att göra dessa saker, men det finns alla typer - det finns så många enheter! Jag såg nyligen att iPhone vann när det gäller försäljning, och jag blev chockad över hur lågt antalet var - det var som, jag tror inte att det var ens 20 procent! Och de var nummer ett, vilket innebär att det finns bokstavligen poäng - om inte hundratals - av enheter där ute som kan användas. Du kan bara tänka dig hur IT-avdelningen känner för det, och naturligtvis förändras det utbudet av teknik; det blir mer varierande med dagen.
Allt förändras, vi har alla typer av saker som händer - containrar, bara för att kasta en ny skiftnyckel i verken här. Och så har vi naturligtvis mångfalden i arbetskraften. Många millennials, de är bara mycket annorlunda vad gäller deras preferenser, hur de använder teknik, vad de är villiga att vada igenom, hur snabbt de kan räkna ut saker. Vanligtvis är det snabbare än hos oss gamla tidtagare, men ändå allt som måste kartläggas tillbaka till dina on-prem-system, eller åtminstone upp till molnet. Och det är en stor, stor utmaning.
Och med det ska jag överlämna det till den oändliga Dr. Robin Bloor. Robin, ta bort den.
Robin Bloor: OK, tack för den korta introduktionen. Låt oss prata om mobil. Det var inte särskilt uppenbart - Eric hänvisade till introduktionen av iPhone - det var inte särskilt uppenbart när iPhonen kom in exakt vad detta meddelade. Jag tror att det blev uppenbart när iPad kom in att vi faktiskt skulle ha en ganska mångfaldig mobilvärld. Jag är en typ av Apple bigot, verkligen, så jag tror inte riktigt vad gäller Android, men naturligtvis, även om Apple gör majoriteten på lång väg, är den stora vinsten från både pad-marknaden och från telefonmarknaden, det har inte siffrorna längre, vilket är typ av intressant. Och det betyder att det kommer - bortsett från allt annat - det kommer att finnas nya enheter, människor kommer att ta upp dem och de kommer att sälja in miljoner. Så det skapar en väldigt mångfaldig miljö som du kan behöva gå igenom.
Skämtet här om "Jag skulle fråga Siri var i helvete är vi om jag kunde få en signal." Det som gör mobila enheter något annorlunda är att stationära datorer är anslutna hela tiden. Och mobila enheter är inte nödvändigtvis anslutna och de är inte nödvändigtvis dygnet runt, eftersom människor kan stänga av dem. Du kan också få dem till flygplan och liknande saker, och därför är det en annan typ av enhet än allt du någonsin haft tidigare. Jag skulle säga att mobiltelefonen faktiskt är den riktiga persondatorn, för det är den du har med dig hela tiden. Det är den definierande mänskliga mobilenheten. Tabletten är något annorlunda; det är en sorts konstig situation, att när du tänker på det, att det på ett eller annat sätt finns mer än en funktionell typ av mobil enhet.
Hur som helst, vad det betyder att vara mobil. Internet förändrades. Vi märkte inte att det hände - jag märkte inte att det hände - men numera 80 procent av internetaktiviteten kommer från mobila enheter, och det är en extraordinär siffra när du tänker på det. Men 47 procent av dessa 80 procent är surfplatta. Det är möjligt att tillhandahålla de flesta applikationer i en mobil inställning. Med andra ord, om du har applikationer som redan finns och, du vet, de är tillgängliga på skrivbordet, kan du antagligen sätta dem på en mobiltelefon, men det finns uppenbarligen begränsande faktorer. Formfaktor och tangentbord är ett av dem. Tabletterna själva kommer enligt Microsoft och Apple båda gradvis att ersätta mobila datorer. Och de har särskilda applikationer inom vissa områden, eftersom de är mer robusta.
En av de saker som jag minns att jag pratade med IT-folk inom sjukvård, var det faktum att innan tabletten fanns, om du gick in i en miljö som var en isoleringsavdelning, skulle du veta att du skulle behöva ha dina enheter som du tog in med du skulle faktiskt behöva desinficeras på något eller annat sätt. Det är verkligen lätt att göra det med en surfplatta, det är inte alls lätt att göra med det de brukade ha, som var stationära datorer som var rörliga på grund av att de var i en vagn och anslutna till miljön. De brukade behöva typ av vistelse i den typen av miljöer, eller genomgå en extraordinär typ av desinfektion som tas ut från dessa miljöer. Och vi tänker inte så mycket på dessa miljöer om vi inte arbetar i dessa miljöer. Men surfplattorna och mobiltelefonerna har gjort att arbeta i dessa miljöer verkligen ganska naturligt att vara anslutna och fungera i dessa miljöer.
Och när den stat som Eric satte 1, 7 miljarder tror jag att det var mobilarbetare fram till 2020. Är jag mobilarbetare? Jag tycker sånt att det är, jag är en mobil arbetare i den meningen att jag ibland arbetar utanför kontoret och när jag gör det kommer jag att arbeta på en surfplatta eller göra saker på en mobiltelefon. Så när du faktiskt tittar på det och du tänker på det beror det antagligen på människor som bara kommer att använda mobila enheter för sin arbetskraft, så människor som faktiskt grundligt rör sig. Hur som helst kan du tänka nu när det gäller tre typer av användare: stationära användare, surfplattaanvändare och telefonanvändare. Och de behöver olika applikationer. Och det är anledningen till att nämna det.
Kamera och röst är nu en inneboende del av mobila enheter, men de är också en inneboende del av stationära datorer. Men de används på olika sätt på mobila enheter och de har olika gränssnitt på mobila enheter. Och hela karaktären för varför du använder det är annorlunda på en mobil enhet. Så det är om du bygger mobila applikationer, du bygger inte den typ av applikationer som du brukade bygga av en hel mängd skäl - varav många fanns på den bilden. Så om du var ett företag som redan på ett eller annat sätt byggde applikationer som körde på webbplatser, är frågan: borde det också vara mobila applikationer? Och den här bilden ser på det. En webbapplikation, du kan göra mer på det, helt enkelt för att de är byggda på ett eller annat sätt, de är byggda utan att egentligen bry sig om formfaktorn, så att människor kommer att bygga en webbsida som du inte kan använda med rimligt sätt, eller du kan inte enkelt använda på en iPhone eller en Android-enhet, som kanske bara kan användas på en surfplatta, men även på en surfplatta kanske inte är särskilt bra. Normalt skulle det vara OK.
Eller så kan du bygga en mobilapp. Om du bygger mobilappar, finns det en applikationsutrymme på olika nedladdningsbutiker, och den typen driver ned deras motstånd. Om du tittar på min speciella iPhone är den bara full av applikationer som jag inte verkar bli av med; Jag tar bort dem, men de verkar alltid hämta igen på något konstigt sätt. Jag vet uppenbarligen inte hur jag ska hantera en iPhone ordentligt. Men du vet, du slutar bara med en mängd applikationer och det är inte meningsfullt. Jag har mer, jag misstänker att jag har fler applikationer på min iPhone än vad jag har på mitt skrivbord, vilket är konstigt när du tänker på det. Mobilappar är ett lakmustest för framgång. Det är lite intressant att vissa webbföretag - Yelp är en av dem - gjorde det mycket bra genom att skapa en app och låta folk ladda ner den. Och det verkar som om de områden där det var ganska bra framgång faktiskt fanns i finanssektorn; det är banker men också e-handel och företag som det, för att människor gillar att kunna handla saker i farten, ibland. Matapplikationer, så inte bara letade efter restauranger utan också skapa receptwebbplatser, de gjorde det riktigt, riktigt bra när det gäller appar.
Och många människor gjorde det inte särskilt bra alls, och det är anledningen, jag tror mest är att det bara finns så många appar som du någonsin vänjer dig att använda, och om du bara använder en app en gång varje dag eller så, då glömmer du det. Om det inte har ett stort personligt värde för dig, glömmer du det. Så det är svårt att skapa en mobilapp som är tillgänglig i allmän mening, men uppenbarligen kan du skapa dem för din egen personal och använda dem inom organisationen. Mobilappar har riktigt stora utvecklingskostnader, och det är ett antal skäl till det. Ett av orsakerna till det är att du faktiskt pekar på ett tydligt olika antal enheter.
Och du kan få utvecklingsmiljöer som riktar sig till flera enheter, men vissa applikationer, särskilt när du tittar på säkerhet, måste du verkligen göra kodning för själva enheten. Du skulle skriva en annan kod för iPhone eller Android-miljön. Kanske annorlunda. Ibland hänvisar du till maskinvarufunktioner. Så den allmänna mobilappen, ja, kanske finns det utvecklingsprogramvara där ute som du kan bygga en som är typ av hybrid och kommer att ströva de flesta av målmiljöerna. HTML5 gör det mycket mer möjligt än det någonsin var tidigare. Men du får också denna situation där vissa appar faktiskt inte kan göra det; det innebär att du faktiskt gör samma arbete flera gånger för varje enhet som du riktar dig till, och det kommer inte att hindra människor som hävdar att de har rätt att ta med sin egen enhet; det kommer inte att göra någon skillnad på det, så du kan inte riktigt komma runt det.
Tydligen visar analys av mobilappar att de driver mer försäljning, eller hur? Och detta är en konstig typ av webbplatsen och mobilappen som, om du vill, komplement. Apparna ökar försäljningen. Webbplatserna är bättre på att hämta nya kunder. Appar är bättre på att behålla kunder som du redan har hämtat. Kunder spenderar mycket mer på webbplatser än på appar, men kunder spenderar ofta på appar. Och det är en väldigt konstig sak, och det talar till det faktum att om du ska bygga något, så behöver du antagligen en webbplatsinkarnation och en mobilinkarnationsinkarnation, om du förväntar dig att den ska användas i stor utsträckning. Och det är på ett eller annat sätt det är en dramatisk kostnad att lägga till ett mjukvaruprojekt, som i alla fall kanske gör en hel del andra saker.
Som en allmän idé är en webbplats en katalog och en app är en lojalitetsmaskin. Utveckling av mobilappar - och det här är bara för att slags bryta problemet - olika utvecklingsmiljöer, olika problem med avseende på hårdvara, olika användargränssnitt designprinciper och förmåga, du kommer att behöva ha offline kapacitet - för en många appar som människor förväntar sig att kunna använda dem om de är frånkopplade - de vill inte förlora data; en del av uppgifterna måste lagras lokalt. Du bygger en annan app än du kan bygga, låt oss säga för skrivbordet. Och sedan har du den mobila back-end-frågan, det kommer att behöva vara mellanvaror där, det kommer att finnas säkerhetsförfaranden där. Ganska troligt kommer det att finnas en serviceorienterad arkitektur i bakgrunden, där du stickar ihop olika saker. Och vad detta säger är att du inte bara tar något team som är van vid att utveckla applikationer på servern och grejer. Om du kastar dem en mobil behöver du verkligen mobilutvecklare. Och personer med mobilupplevelse.
Hur som helst, efter att ha sagt det, är det bara en sak att säga - framför allt är mobilappar i de flesta fall en kundpunktspunkt, så de måste vara riktigt bra, eftersom en kund kommer att bedöma företaget utifrån mobilen erfarenhet, eller så kommer det att påverka deras omdöme. Och i vissa fall, som jag nämnde, är mobilappen faktiskt det som bestäms affärsframgång. det kan vara det som verkligen gör en organisation. Och naturligtvis kan det också vara en fuktig squib.
Och när det är sagt, ska jag skicka tillbaka bollen till Eric.
Eric Kavanagh: Bra, och jag ska överlämna det till Bill. Bill, om du vill gå till snabbstart där och dela din skärm?
Bill Ellis: Ja. Här?
Eric Kavanagh: Det övre vänstra hörnet.
Bill Ellis: Ja. Tack för instruktionerna, jag uppskattar det. Robin, jag gillade din diskussion, det var roligt. Jag har jobbat på ett virtuellt team i 18 år nu, så jag tror att jag kan räkna mig som en del av den mobila arbetskraften. Ibland oroar jag mig för att jag ska se, om jag har en funktion efter arbete, måste jag ofta klä mig för att gå till den. (Skrattar) Och jag kanske börjar tappa perspektivet på vad "klädd" är, så hur som helst. (Skrattar) Med det, låt oss gå vidare och komma igång. Jag vill bekräfta att kanske Eric bara kunde ringa in och berätta för mig, kan du se min skärm OK?
Eric Kavanagh: Ja, ser bra ut.
Bill Ellis: Okej. Så jag heter Bill Ellis, jag arbetar med IDERA på produktserien Precise, och vi ska prata om att möjliggöra mobilitet. Och vi pratar verkligen om att mäta det och se till att det fungerar till din tillfredsställelse. En av de stora poängen där, var att det är något som människor interagerar med, med ditt företag. På ett sätt är det väldigt intimt - telefonen har rätt i någons hand och så gör intrycket, hastigheten, stort intryck på alla användare.
Så detta var en kundupplevelse som jag trodde att jag skulle dela. De fick gå live, det gick inte bra. Och eftersom det initiala belastningstestet inte helt avslöjade förändringar i den underliggande applikationsinfrastrukturen, och så är en av de saker jag gillar att betona med mobil, vare sig applikation eller HTML5, det finns också en hel del teknik som är beroende av. Börjar med nätverket, på webbservern, i affärslogik, i meddelanden, och om de gör ett köp, du vet, en betydande affärstransaktion, interagerar de med journalsystemet.
Och ironiskt nog stötte vi på ett par nätverksproblem när vi kom igång, så allt detta är mycket relevant även för att leverera detta webbinarium. Och så kan du ha en applikation, minst sex tekniker, många slutanvändare, och det är mycket svårt att besvara även de enklaste frågorna. Har en slutanvändare problem? Vad är problemet med en applikationsstapel, vilken kod orsakar problemet? Och det är verkligen inte trivialt att få tag på dessa saker.
Vad vi nu ska göra är att vi ska titta på några mätningar som gjordes på en plats för att hjälpa till att urskilja var problem finns i applikationsstacken. Och det vi tittar på här är en graf, där Y-axeln är responstid, X-axeln är tid över dagen. Och stapeldiagrammet är ett mått på var slutanvändartransaktionerna spenderar sin tid. Och så får du typ en fin trend här, och sedan går det upp och upp och upp. Och det är i princip avgränsningen av utskärningen, och så kan du, med hjälp av stapeldiagrammet, börja se att det finns en hel del problem i J2EE-nivån. Du ser också problem i webbservernivån, och sedan finns det några ganska stora hissar, faktiskt också i databasnivån.
Och nu, när vi har identifierat att det finns flera nivåer, med flera problem, måste vi gå lite längre för att ta reda på exakt vad som händer, för att få ett intelligent svar på det nya användningsmönstret och detta mycket långsamt, vi pratar om fyra eller fem X långsammare prestanda. Och så en av de första sakerna vi vill göra är att säga, "Detta är en transaktion", och så vi har tittat på omfattningen på vänster sida av alla transaktioner och de kan, konsultera, det är riktigt enkelt att titta på svarstidsdiagrammet för att i princip se att du ser i samma klientwebserver Java för vissa transaktioner mer än andra, databastid. Men det är verkligen över hela linjen när det gäller alla transaktioner.
Och detta tittar på användare, och så börjar du få, detta är en global distribution, så du tittar på de primära kontinenterna i världen, så det är alla användare, alla platser. Detta är ett globalt problem, det händer, så det börjar isolera, det är inte en eller en viss grupp användare - det är något som mer händer på datacentrets sida. Och så vi börjar diagnostisera, var i data? Vilka applikationsnivåer? Och så vi börjar titta på att den genomsnittliga responstiden byggs upp, även i lager över det med antalet avrättningar, för att få en uppfattning om skalning. Detta är väldigt intressant - den nedre halvan visar faktiskt den längre sikthistoriken, och du kan se mycket höga åtkomsträkningar, men den andra sidan är antalet samtidiga anslutningar relativt låga. Efter att vi gått över till en mobil HTML5-applikation fördubblas antalet anslutningar mer än mycket mindre - vi talar om storleksordningar - det är 100 gånger mindre åtkomst, så vi skalar inte; vi har åtminstone dubbelt så många anslutningar som vi haft tidigare. Så vi börjar urskilja vilka nya krav som mobilapplikationen ställer på de underliggande infrastrukturerna.
Så låt oss gå in ytterligare, för vi måste isolera var frågor uppstår. Och så, här, du tittar i princip på saker som går upp, och vi behövde verkligen inte denna stapeldiagram här för att säga att vi inte uppfyller våra SLA, men vi kan lätt se det i den övre grafen. Men vi har en sekundär bekräftelse när det gäller exekveringsräkningar för att SLA inte uppfylls. Nu, här, börjar vi faktiskt titta på låsning, och det är inom - det här är WebLogic men inom affärslogiknivån. Och du kan se här, och det här kan vara lite svårt att läsa, men du trycker på 31 000 låsförvärv under en sammanlagd låsetid på 12 timmar, 30 minuter. Så detta är helt klart ett enormt problem.
Nu visar låskonsekvensen att det alltid finns en viss härledning av 80/20-regeln. Det handlar verkligen om en metod, en grupp metoder som verkligen orsakar problemen. Nu börjar vi isolera problem inom en viss nivå. Så vi går in lite längre, och här är meddelandesystemet. Och vi börjar se detta, över tid grafen som jag cirklar uppe till vänster, du kan se den grova responstiden går upp, och den rosa, nyckeln, detta visar faktiskt kö och det finns faktiskt en mycket annorlunda kö som händer, som skjuts upp på grund av antalet anslutningar. Och så gör meddelandesystemet mycket mer arbete; det finns mycket mer - om du gör en analogi med den livsmedelsbutiken finns det mycket fler vagnar i varje körfält vid kassadisken - och det är vad som driver kön och du kan se det tydligast i domänen. Var och en av domänerna ser mycket, mycket hög kö.
Hittills har jag identifierat låsning inom WebLogic, jag har identifierat kö i meddelandesystemet, och det här är Tuxedo. Och då, det vi tittar på här är en liknande typ av analys, men vi tittar på exekveringsstatus inom systemet för registrering. Och det råkar vara exekveringsstater inom Oracle. Anledningen till att vi fokuserar på tid är att tiden har två utmärkta egenskaper. Nummer ett: det är så slutanvändarna och applikationerna upplever prestanda. Nummer två är att det mäter resursförbrukningen. Och så identifierar den automatiskt var flaskhalsarna är. Och så kan jag se här, i databasnivån, att jag har ytterligare I / O-tid, så jag stressar lagringsundersystemet. Varje nivå är beroende av nedströmsnivån, så databasen är beroende av lagring. Jag kan också se att inom databastiden låser jag. Så jag måste bli lite mer granulär innan den informationen blir lite mer användbar. Och så, låt oss gå in, skala tillbaka löken ännu ett lager.
Nu är det faktiskt en titt på exekveringsräkningar, Y-axeln i det här antalet, det är i tusentals, du tittar på 9 000, nio miljoner, och så kör exekveringsräkningen också upp och upp och upp. Så den nya mobilitetsapplikationen betonar applikationen en hel massa sätt. Låsning, bara för att sammanfatta: låsning på webbnivån, kö i meddelandesystemet, ytterligare exekveringsräkning på databasnivån, ytterligare I / O, ytterligare låsning i databasnivån. Så vi är, jag påverkar faktiskt varje nivå inom applikationsspecifikationen. Och så är det mycket viktigt att kunna ha statistik från alla nivåer i applikationsbunten. Här delar jag faktiskt databasaktiviteten i program, och jag kan se att jag verkligen har två program: den turkosa färgen kartlägger applikationslåset. Och så, den här, distributionsservern som applikationslås, appen, det här är den mobila delen, det här har också applikationslås. Och du kan se att ett antal av dessa är en flaskhals på själva lagringsutrymmet.
Nu får jag och skalar löken för att se vad jag kan göra i varje nivå. Och anledningen till att jag gör detta är att många tittar på det ur kapacitetsplaneringssynpunkt. Och de flesta molntjänster, de talar om att utöka servrar, CPU och minne. Den andra sidan av myntet är lika viktigt, är att applikationskoden som kör och driver förbrukningen av dessa resurser. Och när du vet om applikationskoden kan du nu adressera kapacitet genom att bearbeta effektiviteten. Så du har båda sidor av samma mynt, och det ger IT-proffs ytterligare alternativ för att lösa problemet. Det är inte bara att lägga till fler servrar, det är också vad vi kan göra för att rensa upp saker och fungera mer effektivt? Den gamla "Arbeta smartare, inte svårare."
Så här kan vi faktiskt, Oracle har en snygg sak som heter Moduler och åtgärder, där du faktiskt kan börja dokumentera koden, och så kan du också undersöka saker på ett annat sätt, som här, applikationslåset som vi såg? Tja, det kom in via utgiftsarkskoden, det kom också in via distributionsservern, och så det är de två primära drivrutinerna för den nya låsningen. Och den nya lagringen kommer via onlinesystemet, och så börjar du verkligen bygga en profil, där drivrutinerna är för denna ytterligare resursförbrukning. Det är en annan sak att kunna identifiera drivrutinerna i den underliggande koden. Och så att gå in på detta tror jag att vi tittade på det här kostnadsbladet, och så går vi in här.
Nu när du tittar på de underliggande objekten som utövas börjar du se den här meddelandeloggen. Tja, varje gång de gör meddelanden - och vi såg att det går upp med en multipel - berör vi faktiskt den här meddelandeloggtabellen och du kommer faktiskt att se på en minut att det faktiskt orsakar mycket av låsningen inom databasnivå. Så dessa nya användningsmönster har stor inverkan upp och ner på applikationsbunten. Nu till höger är SQL-koden, och så är detta faktiskt applikationskoden och vi spårar vad SQL-uttalanden gör genom körningstillstånd. Och så är det mycket enkelt genom färgkodningen att se vilka SQL-uttalanden som är involverade i dessa lås. Anledningen till att detta är väsentligt viktigt är att om du går till din DBA och du säger: "Hej, vi tror att det finns ett problem på databasnivå." De kanske bara tittar på databasen och det kan se ganska lika mycket ut det gick igår.
Men när de kan korrelera hur applikationen använder databasen kan de då fastställa exakta SQL-uttalanden som de borde fokusera på, och sedan kan de komma in på några av dessa avancerade metoder, titta på exekveringsplaner och alla dessa saker att de kan finjustera, så att skivsystemet körs mycket snabbare. Och så, de korrelerande tvivlarna om koden, är det verkligen viktigt att tekniksexperten kan lösa och åtgärda underliggande problem. Nu, här, pratade vi också om lagring - här ser du antalet fysiska läsningar, du kan se när det hände, och detta börjar komma in i hårdvaruarkitekturen, för när du planerar att utveckla ett system, en av saker du kanske väljer att göra är att du kan välja olika typer av lagring och de har en mycket annan kostnadsprofil. Och i vissa fall är det bra att uppgradera och betala för flash-lagring; Om jag gör mycket mer slumpmässiga läsningar, kommer den flash-lagring verkligen att betala för mig.
Och det övergripande meddelandet om detta är att med en ny applikation ställer nya krav på systemet och den underliggande applikationsstacken måste utvecklas för att tillgodose dessa behov. Och du vill också titta på vad dessa behov är och kan koden justeras för att göra den effektivare? Och äntligen, ner i CPU, kan du se på nedskärningsperioden, vi hade kört på cirka 10 procent och sedan, en gång med den nya koden, är vi på 4X, nu är vi på 40 procent, och det här är verkligen viktigt för fysiska såväl som virtualiserade miljöer för att se till att du har tillräckliga serverresurser för att uppfylla applikationens behov. Och så, här är bara en mer närbild, så att du kan se några av dessa nummer lite på förhand. Intressant på servernivå hade minnesförbrukningen inte förändrats så mycket, men antalet CPU-cykler som krävdes visst hade haft.
Och detta är i grund och botten en sammanfattning av att titta på kostnadsrapporten, titta på skalningen, det faktum att antalet avrättningar faktiskt minskade, men körningstiden gick upp. Och så visade det att under mobiliteten var kostnadskomponenten i applikationen verkligen problem. Och det kommer definitivt att ha en användareffekt på saker, för om du inte kan göra ditt jobb kommer människor i princip bara att sluta använda rörligheten. Och det fina med mobilitet är att det verkligen stärker arbetskraftsproduktiviteten, och det är väldigt bra för lönecheck och så vidare, så du vill definitivt att det ska rulla. Nu tittar vi på samma sak här, bara ur en platssynpunkt, så det är Europa och Mellanöstern, Asien VPN-anslutningar och sedan själva huvudkontoret. Och USA totalt sett. Så vi tror att ett sätt att få den värdefulla informationen på varje nivå i applikationsbunten är genom den exakta produktlinjen.
Jag ska bara mycket snabbt, Robin och Eric, jag är bara snabbt bara att ge en översikt över vad Precise gör och varför det är utformat på samma sätt som det är designat. Och vad händer om slutanvändaren försöker göra något, det finns mycket teknik i datacentret, slutanvändaren verkligen bryr sig inte, de vill bara göra sitt jobb. Samtidigt har du många människor inom IT, välmenade, väldigt smarta, men de är inte ens medvetna om ett problem förrän denna slutanvändare rapporterar om de rapporterar. Och sedan, många gånger kommer detta att starta en mycket dyr tidskrävande slutligen frustrerande process, där människor tittar på en delmängd av applikationsstacken, men det är väldigt svårt att svara på de grundläggande frågorna om vem, vad, när, var, varför
Så, vad vi tror är genom att mäta slutanvändartransaktioner som börjar i deras enhet, via nätverket, på webbservern, i Java, genom att fånga den informationen kan vi svara på frågorna om vem, vad, när, var, varför, ge rekommendationer, men förmodligen är det viktigaste att fylla i återkopplingsslingan. Vi behöver alla feedback för att förbättra, det är det enda sättet att du vet att något går fel. Genom att historien läggs in i ett centraliserat arkiv, ger det ett musikblad för alla att läsa från. Och så blir det väldigt enkelt att ta reda på var problem är, så återigen handlar designen om att mäta slutanvändartransaktionen; detta kommer att identifiera långsamma transaktioner, segmentera det, detta kommer att berätta vilken teknik som är ett problem och sedan ge en expertvy över var och en av de enskilda nivåerna så att du kan ta reda på vad som händer. Precise kommer att ge lärande såväl som rapportering och instrumentpaneler för alla intressenter, oavsett om du bara vill ha en översikt, eller om du vill ha en djup teknisk bild av vad som händer.
Vad kan hända, som en dag i livet, antingen kan du som IT-specialist ringa en slutanvändare, eller ibland kan en slutanvändare ringa dig. Logga in på Exakt, du kan fokusera igen, Y-axeln är svar, X-axeln är tid över dagen. Här är vi varje delstat, så du har klienttid, webbservertid, Java, smoking, databastid. Här nere har du körtransaktioner, du kan ta fram en meny för att identifiera en viss slutanvändare, och på det här sättet har IT förmågan att ta itu med den specifika slutanvändarnas problem. Och så kan du se exakt när de var upptagna, du kunde se att de använde innehållshantering som du kan fokusera på den transaktionen och sedan kommer Precise att ge dig en analys av transaktionen.
Procentandelen i slutet läggs till med procent, exakt, och det berättar hur mycket tid, men en procentandel tid som spenderas på det enskilda steget, ner till enskilda SQL-uttalanden, det här är sammanhanget. Och en av de saker som vi säger är att alla har verktyg, men få butiker har sammanhang. Och sammanhang gör det möjligt för Java-administratören att fokusera på applikationskoden, DBA för att i detta fall identifiera det specifika SQL-uttalandet. Och så med den informationen ger det dem mycket mer synlighet på hur man kan hantera den underliggande grundorsaken till den specifika transaktion som påverkade den specifika användaren. Så du laser verkligen fokuserat på grundorsaken. Och du kan analysera SQL-uttalande, var tillbringade den sin tid, verkligen? Och däremot en hel del verktyg som Enterprise Manager bara för att välja dem. De är stora, de kan ta det. De tittar på saker från ett instansperspektiv, och det är inte tillräckligt med fokus för att komma in i dessa applikationer.
Vanligtvis kommer dina OLTP-mobilitetsapplikationer att vara låg latens, hög genomströmning, så att fokusera på topp tio-listan, det är en början men det är verkligen inte tillräckligt bra för den här typen av applikationer. Och den andra saken är att särskilt för internt värd applikationer är identifiering med användar-ID verkligen viktigt, eftersom det inte bara handlar om applikationen och infrastrukturen, det handlar också om hur slutanvändarna använder applikationen. Och slutanvändarna har vanligtvis mycket bättre beteende när du kan identifiera dem. Och så detta är bara en slags skärm med olika transaktioner och klientupplevelsen, och sedan subsegmenterad, (skrattar) antar att jag har pratat lite länge. Lite trött här ute; Jag ska plöja framåt.
Här tittar vi på en instrumentbräda som vi sätter ihop som skulle visa varningar och sedan visa olika nivåer i applikationsbunten. Här är dina webbservrar och du kan kontrollera genom körning av responstid att saker är lastbalanserade. Du kan titta på webbläsartillgångar, du kan titta på behålla användning och skräpkollektioner, se till att du har det trevliga sågtandmönstret, att du inte har ett minnesläckage, etc. Och tanken med detta är att ge lite lite av en mer teknisk instrumentbräda för var och en av komponenterna i applikationsbunten. Så den exakta produktlinjen som erbjuds av IDERA erbjuder produktionsövervakning, 24 och 7, mycket detaljerad information. Det är ganska enkelt att distribuera detta; du behöver inte kartlägga transaktioner, oavsett vad slutanvändarna gör, Precise ansluter automatiskt prickarna över applikationsstacken.
Om en nedströmsnivå inte är instrumenterad, kommer Precise att erkänna det och ge in- och uttid och rekommenderar att du instrumenterar nedströmsnivån. Och så är det väldigt lätt att värdesätta; Vi är mycket starka i databasen, detta är IDERAs typ av anspråk på berömmelse. Och anledningen till att det är så viktigt är att varje betydande affärstransaktion interagerar med journalsystemet, så databasen blir grundläggande prestanda. Och så de andra verktygen på marknaden gör de ett OK jobb, men OK är inte riktigt bra nog; du behöver verkligen veta exakt vad som händer med SQL-uttalanden. Och vi gör en hel del avancerade saker, som är för mycket för detta, som att hålla en SQL-uttalandeshistorik och spåra exekveringsplaner över tid. Och så, det är ett område som vi kan utforska vidare om du kanske är intresserad.
Så med det, det är den exakta plattformen för applikationsprestanda, inbjuder vi dig att begära ett ytterligare möte via idera.com-webbplatsen, om du har ytterligare intresse för lösningen och de ämnen som vi diskuterade idag.
Och Eric, med det tror jag att vi fortfarande är under ledningen, jag kommer att skicka stafett tillbaka till dig och Robin. Tack.
Eric Kavanagh: Nej, det är fantastiskt och jag älskar innehållet som du har satt samman här, för du gör ett fantastiskt jobb med att visa hur komplex miljön är under huven. Och naturligtvis, hela jobbet med Precise, är syftet med Precise att hjälpa till att navigera den komplexiteten och förstå vad som faktiskt händer och kunna vidta några åtgärder för att förbättra något. Och jag är bara förvirrad över hur komplex det är. Jag antar att Precise också låter dig identifiera vissa beteendemönster och sedan namnge dem, eller åtminstone spela in dem eller bokmärka dem eller något liknande, är det inte rätt?
Bill Ellis: Ja, en av de saker som kommer att hända, är att du inte vill gå efter din svans; du vill inte bara spendera mycket tid på en engång. Så du vill titta på vad som är mönstren, vad är trenderna, eftersom det finns mycket teknik att hantera. Och så är en av sakerna att prioritera och kunna rangordna, veta var du ska spendera din tid, veta vad som måste fästas. Och du vill också ta en konservativ strategi med lägre risk och lägre kostnader. Du vill inte nödvändigtvis göra en dyr global förändring, utan att bedöma eller ha en mycket god känsla av att veta att det, detta kommer verkligen att hjälpa problemet. Så, vet vad som händer över tid och denna trend är avgörande för att intelligent hantera de underliggande frågorna.
Eric Kavanagh: Det är helt meningsfullt. Och hur stort är virtualisering för att kunna se vad som händer och kommer du in i organisationer som använder containrar - använder du till exempel Docker? Och hur skulle det påverka vad Precise kan göra?
Bill Ellis: Ja, så ordet "container" kan betyda olika saker beroende på olika leverantörer. Och så arbetar vi med VM, nästan alla använder VMware - jag anser att det är de facto-standarden på denna punkt; Jag vet att det finns konkurrenter där ute. Och vi utvidgar det vi stöder, men VMware är det dominerande inom Oracle-stacken. Det finns containerdatabaser och så allt detta är mycket viktigt för att kunna utveckla ditt system mycket snabbt. Det är också väldigt viktigt att veta i en virtualiserad miljö när den fysiska värden inte kan tillgodose behoven hos alla gästernas containrar, eftersom var och en av dem tävlar om resurser.
Och en av de saker som faktiskt inträffade internt var jag förvånad över, att vi faktiskt hade inom IDERA så många lediga VM-apparater, men var och en av dessa lediga VM-apparater förbrukar resurser, att de började orsaka ett problem övergripande för de VM-apparater som faktiskt var använde som var viktiga för oss för att driva vår verksamhet. Och så det var lite intressant. Nu stöder vi inte alla tekniker under solen; det finns en supportmatris förknippad med den här lösningen, och så det är en av de saker som vi skulle vilja borrla ner för, för en viss kund eller en viss kund, bara för att se till att vi kan tillgodose teknikbehovet och de enskilda teknologier som deras applikationsbunt körs under.
Eric Kavanagh: Ja, det är mycket meningsfullt. Från din erfarenhet, vad är några av de stora krafterna nu som driver utmaningar på mobilen? När du och jag pratade före denna webcast för några månader sedan, gjorde du en riktigt bra poäng om hur bara funktionaliteten och utformningen av en iPhone eller någon mobil enhet kan vara en verklig utmaning för företaget, eftersom plötsligt slutanvändaren kan jag kan inte ta reda på hur man får en specifik process i arbetsflödet, eller hur? Och till det tillfället, vad du möjliggör i mobilapputveckling är att du visar utvecklarna var problemen uppstår och sedan kan du kartlägga det tillbaka till vad appen gör på den här enheten eller den specifika enheten. Och det är mycket användbart, rätt, för utvecklaren, för nu kan de se vad som orsakar problemet, de kan göra några ändringar i appen, för att lösa det, eller hur?
Bill Ellis: Ja, det är en slags överläggning av otroligt höga förväntningar - alla förväntar sig att allt fungerar på ett sätt, men det finns så mycket variation där ute. Du har alla dessa olika smartphones, de har olika skärmdimensioner, och sedan har du olika leverantörer av kommunikation, Verizons, AT & Ts, Sprints, de är bara de populära i USA. Och det finns bara så mycket variation där ute, det är som bra, hur lindar du armarna runt allt detta, för att börja upptäcka var frågorna är? Och så finns det många mätvärden som finns tillgängliga och en av de saker som vårt produktledningsteam har gjort, är att försöka dra in de statistik som är viktigast eller mest nödvändig av IT-teamet, för att kunna fatta intelligenta beslut .
Och så är det typ av en utmaning och vi gör att vår produkt är som marknadsplatsen utvecklas och så vi får feedback från våra kunder och det finns alltid förbättringsförfrågningar, så "Hej, den här metriken skulle vara till stor hjälp för oss." Så, vår produkten utvecklas precis som marknaden, men om jag var tvungen att säga, verkligen Eric, det är verkligen intressant för mig, är det hela förväntningarna. Människor är som, det brukade vara tillbaka på dagen människor skulle vänta fem, sju sekunder för att en skärm skulle ruta upp, nu är det som en eller två sekunder, människor är som "Åh, den här applikationen fungerar inte alls!" (Skrattar)
Eric Kavanagh: Det är roligt. Det är så sant!
Bill Ellis: Det är galen.
Eric Kavanagh: Ja, det är lite orealistiskt, ärligt talat. Och jag tror att vi kanske börjar se lite mer realism kring det ämnet, men ändå är det ett faktum i livet att människor har mycket, mycket höga förväntningar. Och jag antar, Robin, jag kommer att få dig tillbaka på riktigt snabbt de senaste par minuterna här. Jag älskade din bedömning av webbplatsen som en katalog och app som en lojalitetsmaskin. Och till den punkten, det vi har pratat om här är hur man gör det möjligt för utvecklarna av dessa appar att förstå vad som händer: Är det användbart? Är det inte användbart? Och vad kan du ändra för att justera det? Och till Bills punkt här, bara för en sekund sedan, har cykeltiden för att fixa det problemet verkligen förkortats, eller hur? Det är bara inte som det brukade vara - du måste fixa det snabbt. Eller kommer du bara att ha en enorm drop-off i bruk, eller hur?
Robin Bloor: Ja, det finns en hel massa andra saker som spelas in i detta, så du har den här smidiga utvecklingen och du har förväntningar på många ställen nu, att du kommer att släppa en ny version av något som håller på att utvecklas, eller som håller på att förändras, varje par veckor. Och det säger, det gör när du tänker på det, om du tänker på implementeringsmiljöerna, och du tänker på hur stor stacken är när du kommer in på mobil, har du faktiskt flera potentiella enheter i slutnoden, och sedan kommer du att ha middleware i mitten. Och du kanske väl har under och under den du kanske väl har databaser. Så du kanske berör många, många applikationer; du kanske rör vid flera databaser och du kanske gör mycket komplicerade saker vad gäller säkerhet. Och allt måste fungera, och förväntningarna är att det kommer att fungera rimligt bra.
Och det fantastiska är att det ibland gör det, men min tanke på detta är om du verkligen, om du bygger mobila appar som verkligen är nyckeln till företagets framgång och många av dem visar sig, många av dessa saker verkligen är. Om du gör mobilt underhåll på oljeriggar och oljeledningar och liknande saker, måste det fungera. Konsekvenserna av att det inte fungerar är bara besvärliga. Och om du inte har denna förmåga att faktiskt skära upp applikationen och veta var saker går fel, för det mesta är prestanda. Vi har riktigt bra testsele nuförtiden, så ja, det finns buggar och buggar kommer igenom. Men främst om något går fel är det prestationsproblem. Och om du inte kan placera stetoskopet på 18 olika platser, är det verkligen svårt att fastställa vad som går fel. Och du har också nätverket en faktor i detta, och du har också verkligheten att varje given komponent i en applikation kan stressas vid olika tidpunkter på dagen på grund av den specifika applikationens natur. Du måste ha sofistikerade övervakningsverktyg om du kommer att ha en chans med allt detta.
Eric Kavanagh: Ja, jag måste acceptera och jag tror att det verkligen är styrkan hos Precise av IDERA i dessa dagar. Och Bill, antar jag bara några avslutande kommentarer från dig? Jag tycker att den här tekniken är fantastisk. Jag inser också att du som användare av denna teknik verkligen måste förstå komplexiteten i informationssystem och beroenden och kunna ta reda på var, när och hur du syntetiserar all denna information för att bedöma vad som faktiskt händer. Och det kräver en intelligent och utbildad människa, och ärligt talat är det en anledning till att jag inte alls är bekymrad över att maskinlärande tar bort jobb. Jag tror att maskininlärning kan vara mycket användbart under en teknik som denna, för att identifiera vanliga mönster och sedan lämna förslag till slutanvändaren om vad som kan hända här. Men vad är några avslutande tankar från dig om att verkligen få företaget vikten av att ha den här typen av felsökningsförmåga och vad borde de veta om det, förutom vad du sa redan?
Bill Ellis: Ja, så Eric, jag håller med om att det finns en enorm mängd komplexitet. Jag tror att den exakta produktlinjen genom att fokusera på den metriska tiden, att en användare som kan läsa ett stapeldiagram kan använda Precise framgångsrikt och jag vill bara säga tack till deltagarna och till dig och Robin för att vara värd för dagens webinar.
Eric Kavanagh: Du satsar! Och som jag sa, vi kommer att vara värd för detta arkiv under en tid nu, så känn dig fri att dela det med dina vänner och kollegor; vi arkiverar alla dessa webbsändningar. Jag skickade en länk till bilderna för några minuter sedan, känn dig fri att kolla in det, men bra jobb igen, Bill, idag. Du känner verkligen dina saker; det är alltid kul att arbeta med en professionell som dig själv. Och jag tror att detta verkligen kommer att vara den möjliga tekniken för den mobila arbetskraften! Så tack för din tid, folkens, vi kommer att komma ikapp dig nästa gång, ta hand. Hejdå.
