Hyperscale offentlige skyer er veletablerede som den nye platform til registreringssystemer. Udbydere af ERP-, forsyningskæde-, marketing- og salgsprogrammer er i dag overvejende eller udelukkende baseret på offentlige skyer i overskala. Oracle alene har tusinder af kunder til sit front-office og back-office SaaS. Og kundelisten vokser med en hastighed, der langt overstiger den for traditionelle front-office og back-office applikationer.
Offentlige skyer i hyperskala er naturligvis også et passende sted at køre nye cloud-native applikationer, der forbedrer eller udvider disse system-of-record-applikationer. Disse nye applikationer er arkitekteret forskelligt. Mens registreringssystemer typisk er store, monolitiske applikationer, der kører i virtuelle maskiner i skyen, skrives cloud-native applikationer normalt som mikroservices, pakkes i containere og orkestreres for at levere en komplet applikation til brugerne. Blandt fordelene ved denne tilgang:
- Hurtigere innovation
- Evnen til at give specifik tilpasning til hver applikationsbrug
- Forbedret genbrug af kode
- Omkostningsbesparelser i forhold til konventionel virtualisering på grund af større distributionstæthed for containere og mere effektivt ressourceforbrug
Alt dette er almindelig viden, endeløst udråbt, ikke længere debatteret.
Mindre diskuteret er imidlertid galaksen af applikationer, der ikke nødvendigvis er velegnede til central implementering af hyperskala sky. I stedet trives disse applikationer i distribuerede computermiljøer, potentielt baseret på cloud-tjenester, ved eller tæt på kanten af netværket. Disse applikationer er systemer til engagement og kontrolsystemer.
Systemer på kanten
Engagementssystemer er defineret af et førende brancheanalytikervirksomhed som “forskelligt fra de traditionelle registreringssystemer, der logger transaktioner og holder orden i den økonomiske regnskab: De fokuserer på mennesker, ikke processer ... for at levere apps og smarte produkter direkte i sammenhæng med hverdagslivet og real-time arbejdsgange for kunder, partnere og medarbejdere. ” Engagementsystemer, der er designet til at lette menneskelige interaktioner, er i sagens natur mere decentrale end systemer til registrering.
En tredje type applikation, der skal skelnes, er, hvad jeg kalder styringssystemer. Disse applikationer giver kontrol i realtid mellem intelligente enheder. Måske er det klassiske eksempel på selvkørende køretøjer. Hvis to biler kører langs motorvejen med 65 miles i timen, vil de ikke automatisk koordinere deres afstand ved at sende data om hastighed og position til et eksternt datacenter til behandling. De kommunikerer direkte med hinanden og reagerer i mikrosekunder. Uanset om det drejer sig om hurtige biler, fremstilling af samlebånd eller robotkirurgi, er minimering af netværksforsinkelse et nøgleproblem for tingens internet.
Udviklere, der bygger systemer til engagement og kontrolsystemer, omfavner også devops-modellen baseret på mikroservices og containere. Til denne slags applikationer tilbyder containere:
- Omkostninger ved implementering på næsten nul på tværs af et stort antal systemer (tænk hundreder af tusinder køretøjer)
- Hurtige opstartstider med øjeblikkelig afspilning og nulstilling
- Større bærbarhed på grund af reducerede problemer med platformskompatibilitet på tværs af muligvis mange forskellige typer computere på netværket
Hvor vil disse containere køre? For kontrolsystemer kører containere typisk i de intelligente enheder selv - for eksempel inde i en selvkørende bil.
For at køre systemer til engagement skal virksomheder udstede digital ejendom i udkanten af netværket tæt på deres kunder, medarbejdere og partnere - ikke i hyperskaleskyer, men snarere i meget mindre skyer, der er velegnede til lette containerbaserede applikationer . Kald dem cloudlets.
Indtast cloudlets
Cloudlets er en måde at flytte cloud computing kapacitet tættere på intelligente enheder i udkanten af netværket. Som Carnegie Mellon-forskere definerer cloudlets, er de det midterste niveau i et tredelt hierarki: intelligent enhed, cloudlet og cloud. Cloudlets kan ses som et datacenter i en kasse med det formål at bringe skyen tættere på enheden. På baggrund af CMU-forskerens ideer mener jeg, at cloudlets skal have fire nøgleegenskaber:
- Lille, billigt, vedligeholdelsesfrit apparatdesign baseret på standard cloud-teknologi
- Kraftfuld, godt forbundet og sikker
- Vedligeholder kun blød tilstand (bygget til mikrotjenester og containere)
- Placeret ved kanten af netværket tæt på de intelligente enheder, som det kommunikerer med
Konsekvenserne er væsentlige. For eksempel, mens mange mennesker har en vision om, at den virtuelle virksomhed kører applikationer centralt i et enkelt hyperscale-datacenter i skyen, er virkeligheden, at innovative virksomheder vil implementere engagement- og kontrolapplikationer i hundreder eller potentielt tusinder af cloudlets globalt.
For en forhandler kan det være indlysende, hvor cloudlet-infrastrukturen og de containere, de kører, skal placeres: i forhandlerens forretninger. For andre virksomheder, der ikke har en lokal tilstedeværelse inden for mursten og mørtel, tilbyder telekommunikationsudbydere skytjenester i metropol datacentre eller endda så geolokalt som det nærmeste mobiltelefontårn.
I stedet for at eje hundreder af datacentre, uanset hvor en tilstedeværelse ønskes, kan virksomheder leje en sky af en sky i en periode - effektivt et hotelværelse til deres anvendelse i et lokalt datacenter. Applikationen tjekker ind og ud efter behov af personer, enheder eller sensorer i udkanten af netværket.
Besætningscontainere
En anden vigtig implikation: Den traditionelle, manuelle tilgang til løsning af problemer giver plads til automatisering. Med hundreder eller tusinder af containere skubbet til et stort antal cloudlets, er dagene til fejlfinding i produktionen forbi.
Har du hardwarefejl? Autoskalering af containere kan automatisk starte en ny container på redundant cloud-hardware efter behov. Systemsoftwarefejl? Defekte containere kan slettes og en ny container læsses. Fejl i applikationssoftware? Ret kilden en gang, og skub en ny bølge af containere ud globalt. Lapp eller opgrader aldrig containere i marken.
Dette kaldes "kvæg versus kæledyr" -modellen for anvendelse og administration af applikationer som beskrevet af Gavin McCance fra CERN. Kæledyr er unikke. De er håndopdragne og plejes kærligt. Når de bliver syge, plejer du dem tilbage til helbredet. Meget det samme kan siges om traditionelle OLTP- og beslutningsstøttesystemer bygget med massive, komplekse monolitiske applikationer.
På den anden side behandles systemer baseret på mikrotjenester og beholdere mere som kvæg. Kvæg er næsten identiske med hinanden. Du kan have hundreder eller tusinder af dem. Når man bliver syg, erstatter man den med en anden.
Så det grundlæggende syn på it-operationer for containerbaserede systemer til engagement og kontrol er anderledes. IT vil producere mange containere og skubbe dem ud til cloudlets tæt på brugere og data til kortvarig brug, typisk timer eller dage. Hvis en container har en fejl eller bliver forældet, er den ikke patchet eller opgraderet: Den er slettet, og en ny container skubbes til cloudleten.
For at en virksomhed kan fungere som en sammenhængende helhed, skal registreringssystemer, engagementssystemer og kontrolsystemer integreres. En fælles infrastruktur for hele livscyklussen - udvikle, bygge, distribuere, overvåge og administrere - kan bruges til at opbygge og implementere distribuerede skytjenester i form af containere. Store monolitiske SaaS-applikationer forsvinder ikke, men de kan være undtagelsen og ikke reglen.
De teknologier, der er nødvendige for at gøre dette koncept til virkelighed, kommer i fokus. Der er en voksende erkendelse af vigtigheden af at have en række værktøjer, der forenkler livscyklussen for containerudvikling, implementering og styring.
Microservices-baseret applikationsudvikling er typisk afhængig af værktøjer såsom scripting-sprog, udviklingsrammer, kildelager, bug tracking-værktøjer, kontinuerlige integrationsværktøjer og binære arkiver. Andre værktøjer pakker og implementerer mikrotjenester som containere. Ledelsesværktøjer til implementering og konfiguration er designet til hyppige implementeringer af identiske tjenester på tværs af identiske servere. Orkestreringsværktøjer bruges til at oprette logiske samlinger af containere, der hører til en applikation til klyngestyring, planlægning, serviceopdagelse, overvågning og mere.
Mange virksomheder leverer disse værktøjer, og industristandarder begynder at dukke op. I sidste ende kan disse værktøjer og standarder gøre det muligt for virksomheder at drive et virtuelt datacenter, der består af mange skytjenester på tværs af potentielt snesevis eller hundreder af fysiske datacentre.
Hvordan kan du komme i gang med denne større vision om et virtuelt datacenter? Der er to øjeblikkelige trin. Først skal du registrere dine systemer til den offentlige sky og frigøre dine interne ressourcer til at fokusere på nye innovative systemer til engagement og kontrol. For det andet skal du etablere en devops-disciplin inden for din it-organisation. Begge trin kan være lange og vanskelige, men de kan betale for sig selv, mens du går. I slutningen af rejsen ligger et virtuelt datacenter med den skalerbarhed, pålidelighed og lydhørhed, der er nødvendig for en ægte realtidsvirksomhed.
Robert Shimp er gruppedirektør for Linux og Virtualization Product Management hos Oracle.
New Tech Forum giver et sted at udforske og diskutere nye virksomhedsteknologier i hidtil uset dybde og bredde. Valget er subjektivt baseret på vores valg af de teknologier, som vi mener er vigtige og af største interesse for læserne. accepterer ikke markedsføringssikkerhed til offentliggørelse og forbeholder sig retten til at redigere alt bidraget indhold. Send alle forespørgsler til [email protected].
