Nul
For en større anvendelse som en industriel control system (ICS), et content management system (CMS), eller et hospital management system (HMS) til at være “cloud-indfødte,” hele dets livscyklus skal eksistere på en cloud-platform. Det er udviklet eller samlet der, det er iscenesat, og testet er der, det er indsat der, fejlrettet der, og løbende opdateret der. Det er ikke “installeret” på en server i et datacenter, som en form for permanent opholdstilladelse. Og det er ikke omdannet til en virtuel maskine billede bare for at gøre det bærbare på tværs af servere. Det er designet til cloud, som ikke kun mandater grundlæggende ændringer i sin arkitektur, men af hele DEN økonomi, der understøtter det.
Også: IT-beskæftigelse: at Bekæmpe den lurende digitale kløft
På en måde, udviklingen af server-side applikationer er en tilbagevenden til den kurs det havde taget, før PC ‘ en æra, når x86-processorer skubbet mainframes og minicomputere ud af de data center. En cloud-oprindelige program er lavet for de systemer, der er vært for det, snarere end at skulle konverteres eller iscenesat i et virtuelt miljø, der skjuler karakter af skyen fra det.
Returnering af time-sharing
“På vores nuværende system omkring 35 brugere kan få gode samtidige service, hver med den illusion, at han har fuld kontrol over maskinen. Hver bruger sidder på en fjernskriver skrivemaskine, typer ud af, at hans program, og holder indtastning af korrektioner, indtil hans program endelig virker. Dette gør, at det både er praktisk og behagelig at bruge computeren.”
-John G. Kemeny og Thomas E. Kurtz
Den Dartmouth Time-sharing Computing System, April 1967
Siden begyndelsen af computere, software, der er blevet formet efter de maskiner, der er udpeget til at køre det. Det burde ikke overraske nogen. Dartmouth ‘ s John Kemeny og Thomas Kurtz væsentlige opfundet moderne design og ved at udvikle et sprog beregnet til at modstå trial-and-error programmering: GRUNDLÆGGENDE. Den første ægte cloud computing platforme, og de mest succesfulde sådanne platforme i dag, er direkte efterkommere af deres arbejde. Deres princip var, at programmer, der kan gøre den bedste brug af maskinen, de kører på, skal plejes og udvikles inden for disse maskiner, i stedet for hashet ud på papir og opstilles separat.
“Triumf af Kraft og Adel over Uvidenhed” af Giovanni Tiepolo, ca. 1745. Fra Norton Simon Museum.
Stillet til rådighed gennem Creative Commons CC0 1.0
Platforme som service
“Cloud-native” computing er det samme princip, udvidet til også at omfatte cloud-platforme. Hvis vi skal være ærlige (nu ville være et godt tidspunkt), så bør vi erkende, at “skyen” er en enkelt maskine, i det mindste set ud fra perspektivet af de programmer, der kører der. Det er egentlig ikke en tåget eller andre ikke-jordiske omgivelser, men en klynge af processorer er forbundet med høj hastighed til netværk, der bare sker for at spænde den planet. De sprog, der er designet til tekniske cloud-native programmer på denne store klasse af maskinen, er direkte efterkommere af Dartmouth ‘ s GRUNDLÆGGENDE.
Også: at Bruge cloud som en platform for digital transformation
Først og fremmest, cloud fødselskirken gør spørgsmålet om, hvor en organisation vælger at være vært for sine ansøgninger, en evigt åbne spørgsmål. Cloud applikationer, platforme er designet til at transportere. En cloud-infrastruktur i dag ofte kommer med en ansøgning platform som Cloud Foundry (stewarded af Pivotal), Apprenda, eller Red Hat OpenShift.
Snart selve udtrykket “cloud-native” kan falde i udlandet, ligesom det tag på 1990’erne og begyndelsen af 2000’erne TV-serier, læse, “Optaget i high definition!”
Få mening ud af alle de abstraktioner
Siden fremkomsten af C++ og høj-niveau programmeringssprog, design af software, der blev adskilt fra den underliggende hardware af et eller flere lag af abstraktion. Programmører-nu kendt som udviklere — typisk har aldrig haft til at overveje arkitektur af hardware eller den infrastruktur, der understøtter det.
Også: Linux nu dominerer Azure
“Skyen” (som er alt for sent at omdøbe) er en maskine, omend en, der dækker planeten. Nogle af de første cloud-tjenester, herunder den oprindelige “Windows Azure” tilbage i 2008, blev etableret som et middel til iscenesættelse nye software, der er udviklet med den hensigt at køre der. På trods af, hvad den oprindelige branding stiltiende, software, hvis hensigt er at blive distribueret og ikke centraliseret — med andre ord, at blive kørt over Internettet, snarere end en PC, der fungerer som en server — tager på sit eget design.
Den Docker revolution i 2013 aktiveret tre ideelle situationer samtidig:
Docker afkoblet ansøgninger fra de servere, der kørte dem, ved engineering en standard klasse af bærbare, software-baseret container.Det er etableret en self-service indsættelse mekanisme, der gjorde det muligt for udviklere at bogstaveligt talt bygge lokalt, så handler globalt — at iscenesætte en distribueret applikation på en enkelt maskine, og derefter skubbe det til skyen i en simpel, automatiseret måde.Det for evigt ændrede arkitektur server-baseret program, du opretter mindst én stil programmering, måske mere, det var specielt egnet til installation i cloud: cloud-native applikation.
Dette er den samme “cloud” vi har talt om før?
Før vi går videre med denne sætning, så lad os slå sig spørgsmålet om, hvad vi mener, “the cloud” er i dag. Vi, der dækker teknologi for levende, der har en tendens til at trække en hård grænse mellem virksomhedens datacentre og cloud udbydere, udpegning af, hvad en organisation, der kan fungere for sig selv, da “her”, og den sky, som “over there.”
Dette er ikke, hvad cloud begrebet egentlig betyder, eller har nogensinde virkelig betød. Din organisation kan være i stand til hosting sin egen cloud-native programmer, hvis det ejer eller endda leasing servere, der kører dem, om lokaler, der enten ejer eller lejer fra en colocation udbyder som Equinix eller Digital Realty. Hvad vi har kaldt “hybrid cloud”, som om det var en mærkelig, men levedygtigt alternativ, er nu en cloud-platform, hvis tjenester kan være en del, der ejes og er en del-udlejes fra en udbyder, såsom Amazon, Microsoft, Google eller IBM, uanset hvor de er placeret.
Også: Virksomhedens udviklere holder nå til cloud
Lad os prøve at sætte dette på en anden måde, ud fra, hvad der giver mening fra starten, før nogen omdefinerer dem til at betyde noget andet: En sky kan være enhver kombination af ressourcer, som ligger overalt på Jorden, hvis netværk-konnektivitet gør det muligt for dem at fungere i koncert som en enkelt samling af servere. En organisation kan eje og drive sin egen sky i sin helhed, selv om det typisk ikke. Kommercielle cloud udbydere (de tre største, som er Amazon AWS, Microsoft Azure, Google Cloud) tilbyder en organisation, ressourcer, kan det være nødvendigt at iscenesætte en af eller alle sine programmer i den plads, vi nu kalder public cloud. Nogle virksomheder, der ikke ejer eller driver nogen af sine egne it-ressourcer, vælger i stedet at lease disse ressourcer fra offentlige udbydere af cloud-tjenester helt.
Så når vi siger, at et program er “native”, at denne type af cloud, hvad, vi mener, er ikke kun, at det var konstrueret til installation der, men at den er bærbar i hele nogen del af det rum, som i dette tilfælde omfatter. Cloud masker sammen flere iscenesættelse områder for applikationer og deres ressourcer, herunder databaser, i et enkelt landskab. Cloud-native applikation opfatter dette landskab som sin egen. Mere vigtigt er, at det ikke behøver at grave dybere ind i, de infrastrukturer af servere og datacentre, hvor dele af landskabet bliver hostet.
Hvordan hjem til en cloud-native applikation er bygget
Sig for eksempel, at en virksomhed, der administrerer et VMware vSphere miljøet. Oprindeligt, vSphere var beregnet til at være vært for virtuelle maskiner (Fos), der opfører sig som fysiske servere, men de gengives som software. Nu, ved hjælp af en udvidelse produkt kaldet vSphere Cloud Fundament, det kan også være vært for og administrere den nye race af containertransport-applikationer, der er langt mere bærbare, og som eksisterer uden for VMs.
VMware administrerende DIREKTØR Pat Gelsinger forklarer VMware Afgørende Container Service til deltagerne VMworld 2018 i Las Vegas.
Scott Fulton
Som VMware annoncerede i November sidste år, sådan container-applikationer vil være i stand til at gøre brug af ressourcer som computerkraft, opbevaring og database service fra Amazon AWS. VMware har lavet en lignende pagt med Google Cloud til det foregående år. Som et resultat, en organisations hybrid cloud kan bestå af ressourcer samlet sammen fra den offentlige udbyder og sine egne datacentre. VSphere opfatter disse ressourcer, som en enkelt plads til at håndtere programmer.
Også: 8 trin til at blive en “cloud-native” enterprise
Så et program er designet til et sådant miljø, og måske inden for dette meget miljø, vil være “cloud-indfødte.” I modsætning til en server-baseret program, der er skrevet til en stand-alone Windows Server-eller Linux-miljø, den cloud-native version ville være i stand til indsættelse overalt i denne rummet på ethvert tidspunkt.
Denne form for aftale er ikke eksklusiv til vSphere. Hvis en organisation ikke havde sin egen OpenStack cloud-lokaler, det kunne integrere sin egen private ressourcer til en vis grad med AWS, Microsoft Azure, eller Google Cloud. (Om den gør det med enkelhed er et spørgsmål om åben debat, men i det mindste er åben.) En organisation med Microsofts Azure-Stakken kan bygge og installere programmer ved hjælp af Visual Studio (eller dens fremragende open source modstykke, VS-Kode) på sine egne servere i sine egne datacentre, og integrere de ressourcer, der er til rådighed fra den offentlige Azure cloud, som det er nødvendigt.
Og baseret på den information, vi har på hånden i dag, mener vi, at en virksomhed, der tilslutter sig AWS Forposter bør være i stand til at opbygge et program, der er gearet til Amazon EC2, og brug det til at AWS servere placeret på kundernes præmisser. Dette vil være en cloud-native applikation, men ikke nødvendigvis i den offentlige sky, medmindre og indtil de kunde flyttes det der, eller en del af det der, med vilje.
Hvorfor cloud fødselskirken pludselig betyder noget nu
At sammenligne native applikationer til vandrende applikationer
De fleste server-side software, der nogensinde er produceret (dvs, ikke de apps, der kører på en PC eller en telefon, der er “client-side”) blev udtænkt til at køre på en almindelig maskine-en boks med en processor, sin egen hukommelse, nogle lokale til opbevaring, og et PC-operativsystem. Når den ældre gruppe af software, der kører i skyen, en virtuel maskine (VM) er skabt til det, som i sig selv er en form for program. En VM foregiver at være en konventionel maskine til skyld af ansøgningen, der ofte ikke kender forskellen. Men VM er transportabel og let at overskue. Hvis det skulle blive beskadiget, er et andet eksempel på, at det kan blive klonet fra et tidligere billede for at indtage sin plads (“instantieres”).
Også: Hvorfor native apps er ikke virkelig dømt, for nu TechRepublic
En cloud-native applikation behøver ikke at lade som om. Hvis det ikke køre i en VM, som mange gør, så det er i stand til at blive bevidst om cloud-platform, så kører det, som giver det mere kontrol over den måde, som det er lykkedes og distribueret gennem et netværk.
Dette giver anledning til to skoler, som begge er lige gyldige lokaler til cloud-native metoder:
På sidste, kan programmet være meget opmærksom på sine omgivelser. Som gæst i en virtuel maskine, et program ved aldrig rigtig, oplysninger om den sande natur af den infrastruktur, der understøtter det. Som et resultat, kan det ikke lære, hvordan man kan forbedre sin egen præstation. Nu, ved hjælp af komponenter, der tjener som eksterne agenter inde i beholdere (et fremtrædende eksempel er NGINX Plus) en del af et program, der kører, kan erhverve live data om visse aspekter, nogle af dem ganske vist esoterisk, af dets konfiguration og ydeevne. Med, at data, i det mindste teoretisk, ansøgningen kunne træffe visse afgørelser om dets konfiguration og videre distribution, iscenesætte nogle af sine egne funktioner og dermed udvikler sig til at passer til skiftende formål og situationer.Til sidst, programmet behøver ikke at vide en pinsemandag om sine omgivelser. Der er en mere vocal-skolen i de seneste måneder, at billethajer fordele for udviklere at opbygge deres programmer, mens du udelukkende fokuserer på brug af programmet og de interesser brugeren, mens forvaltningen af den underliggende hardware til miljøet, og fordelingen af software til orchestrator (oftest i disse dage, Kubernetes). Disse er de fortalere for såkaldt serverless arkitektur. Den første time-sharing systemer, de siger, der indvindes oplysninger om edb-drift fra funktioner i programmet, og at indvinding kan være lige så relevante og nødvendige i dag.
Har du brug for microservices at være virkelig cloud-indfødte?
I dag, den sidstnævnte skole er langt den mest højrøstede, men dens kerne filosofi har endnu ikke grundigt gel. I hjertet af serverless value proposition, er det budskab, som abstraktioner gratis udviklere til at tænke og arbejde helt i realm af de problemer, som de prøver at løse. Dette går imod forestillingen om, at en organisations IT-infrastruktur er i centrum for sin virksomhed, og sætter tempoet for sin forretningsmodel. Ikke længere er alt dette “strategisk alignment” mellem forretning og teknologi vingerne af den organisation, der er nødvendige.
Også: 8 måder at gøre sikker på, at du virkelig har brug for microservices
Men fra der, advokater går på at argumentere for nedbrydning af monolitisk programmer til fordel for en microservices-baseret model, hvor de enkelte komponenter hånd i hånd mod fælles mål. Der fastsætter, hvad disse fælles mål, er for det kræver netop den type af strategiske tilpasning, der serverless fortalere siger, at de bøger, således at interessenterne kan få sammen på den samme side.
Nogle fortalere har også gået på rekord støtte et koncept de kalder “cloud-native DevOps”, som vil bringe den DevOps (udviklere + operationer fagfolk) bevægelse med bevægelse hen mod både serverless og microservices arkitekturer. Det største problem med denne hele ideen er, at der ikke er bevis overhovedet at Ops del af denne bevægelse har underskrevet på denne idé. Hvis udviklere, som serverless fortalere, der er beskrevet i dem, “befriet” for at forfølge deres egne ideer og på deres egne tidsplaner, så en sådan adskillelse ville gå mod begrebet koalition med Ops, hvis ansvarsområde omfatter indstilling af tidsplaner, og sørge for at udviklere er opmærksomme på deres infrastruktur.
Udviklingen af cloud-hjemmehørende i den virkelige verden
Lad os stoppe med at tale om alle disse ting i det abstrakte, og tage en mere praktisk at se på, hvad dette egentlig betyder, i forbindelse med historien om en af de mest almindelige klasser af server-side program:
Et content management system (CMS) er et forholdsvis avanceret database-manager, der er forklædt, i det mindste delvist, som et tekstbehandlingsprogram. Oprindeligt er det gemt, og gjorde Web-sider som statiske dokumenter. Men som forbrugere er nødvendigt Web til at være mere funktionel end arkivalier, CMS-arkitektur blev centreret omkring to forarbejdning motorer:
En, der hentes elementer af indhold fra en database og samlet dem i HTML-komponenter, på et punkt kaldet content delivery program,og en Anden som gjorde, administratorer og redaktører til at skabe de centrale komponenter eller deres prototyper, samt skabe styles, som disse komponenter vil følge, kaldet content management program.
Modeller af monolitisk arkitektur
Den første ægte CMS-systemer automatisk generering af Web-sider, der er baseret på elementer i det arkiv, der var ved at blive løbende opdateret eller udskiftet, og ændret. “Portaler” for sådanne systemer-for eksempel, Vignette — blev installeret på Pc ‘ erne af folk opgave som brugere og administratorer. Som et resultat, når systemet som helhed var træg eller anæmisk, dets brugere var de første til at lide, og fastsættelse af disse lidelser nødvendigt for brugerne at beskæftige sig direkte med IT-afdelingen, i hånd-afholde møder, hvor det blev aldrig klart, hvis hånd var førende, hvis.
Også: Cloud computing: Fem vigtige forretningsmæssige tendenser til at se ud for
Set i bakspejlet, og optimering af disse første CMS-systemer, såvel som “knowledge management systemer” de inspireret, er blevet kaldt monolitisk. Når et program, der bor udelukkende på en PC, dens udviklere kan sikre, at alle brikkerne passer sammen ordentligt, før ansøgningen er fordelt. I et netværksbaseret system, lageret er bag en server, og i mellem server og klienter, man møder en masse af middleware. Så stykkerne ikke altid passer meget godt.
Med en monolitisk applikation, der finder innovation sted i meget meget planlagt, koordineret trin. Et eksempel på en velkoordineret produkt plan er Kentico, et CMS for markedsføring og e-handel. Først kom på scenen i 2004, Kentico hurtigt vedtaget og vedligeholdes en større version kadence på omkring en version per år. Dette har været at Kentico er stor kredit, som sin kundebase, der opfattes dette som symptomatisk for systemets kontinuitet. Som en blogger skrev i slutningen af 2017, “Hver ny udgivelse er værd at tale om. Jeg kan sige, at ikke bare fordi jeg er en Kentico entusiast, men virkelig fordi hver større udgivelse af Kentico tendens til at tilføje noget, som samfundet kræver.”
Historien om frigivelse strategi
I den æra af client/server-arkitektur, timing af større udgivelser var blevet en kunstart i sig selv. Som veteran analytiker Kurt Bittner og konsulent Ian Spence rådede i 2006 for deres bog Managing Iterativ Udvikling af Software-Projekter, udvikleren af et program, bør kortlægge dens udgivelse kadence i de tidlige stadier af dets virksomhed planlægning, blandt andre grunde til at minimere risikoen ved at sprede ud evolution over tid. Bittner og Spence skrev:
Antallet af udviklingstendenser (større udgaver), der kræves, er normalt dikteret af økonomiske problemer, at afbalancere den hastighed, hvormed virksomheden kan absorbere ny kapacitet i forhold til behovet for nye muligheder. . . Hver større udgivelse giver en klar afslutning-peger i retning af, hvor alle værker, der ofte mangler, hvis den udvikling, der er planlagt som en uspecificeret del af en serie af løbende iterationer.
Hvis udgivelser er planlagt alt for ofte, de advarede om, udviklere kunne køre risikoen for at indføre så meget nyt overhead så snart, at brugerne ikke ville være i stand til at værdsætte værdien af disse funktioner tilføjet til deres egne organisationer. Release planlægning, på denne periode i historien, var en fint beregnede affære, da det blev klart, at de fleste alle, at motorerne af disse programmer-som det er i hvert fald tilfældet med en CMS — er kernen i deres virksomheder.
Den økonomiske risiko for nedetid, og visheder af kontinuitet spørgsmål, er for store til, at enhver organisation til at foretage, medmindre og indtil den potentielle værdi af de kommende funktioner-uanset hvor længe de har måske ventet i kulissen — opvejer dem. (Mind mig til at fortælle dig engang om, hvor mange år man udgiver ventede, indtil den følte sig sikker nok til at gøre overgangen til et nyt system, der gjorde det til en fed sin første afsnit.) Dette er grunden til, at Spence og Bittner advaret om, at planlægningen af release-cyklusser bør være omhyggeligt timet til behov i erhvervslivet.
Også: Hvad er DevOps? En executive guide
Hvad disse forfattere formodes, var imidlertid, at hver forekomst af et CMS kan tilpasses til de unikke behov i dens eksklusive kunde — der er ikke, hvordan markedet endte med at arbejde.
For et væld af årsager, herunder et salg af dets moderselskab og en massiv omdøbning og relanceringen af det produkt, forskellen mellem Vignet version 7 til version 8 af dens efterfølger produkt, Open Text, var omkring syv år. Men i løbet af denne tid, et overraskende antal af sine kunder holdt fast-ikke med glæde med alle midler, og i nogle tilfælde virkede det som om, under tvang. Når store forlag havde forpligtet sig til at så mange som syv store udgivelser, nogle mente, at der var ingen måde at vedtage en alternativ platform. Som denne 2011 AdWeek historie med titlen “De Problemer med Back-Ends” fortalte, at udgivere var opgive deres brand-navn CMS suites, at opbygge deres egne platforme i stedet omkring open source Drupal ramme. . . og opdage succes.
I nogle tilfælde, en indsats for at bevare stabiliteten ældre Vignet tilfælde gjort springet til version 8 alt for stor en risiko. Som Regeringen Teknologi, der er rapporteret i 2012, Georgien Teknologi Myndighed, der er kendetegnet flugten som en “kraft til at passe.”
Angreb af den hovedløse hybrid
På omkring dette tidspunkt, fremkomsten af Web-arkitektur og starten af HTML5 rettet monolit problem med indførelsen af de såkaldte “Good design.” Her, portaler er erstattet med browser-baseret frontends at kommunikere med servere på bagenden ved hjælp af API-kald. Vi kunne bruge meget om, hvordan denne metode ændret front-end arkitektur. Hvad vi ville gå glip af, er, hvad der skete på den bageste ende: system ikke længere brug for to (eller flere) motorer til at behandle input fra to (eller flere) grupper af brugeren. I stedet, godkendelse og rettigheder tjenester kan validere, filter, og ruten API opkald til den rette handling. Hvad mere er, ved hjælp af en avanceret reverse proxy som NGINX, disse API opkald håndterer kan være multiplexede og fordeles blandt server noder, så CMS ‘ er bedre til at reagere på varierende arbejdspres.
Også: Tre måder DevOps vil være mere fintunet i 2019
En ny og spændende CMS-arkitektur opstod på dette tidspunkt. Kaldet “hovedløs design” (ganske risikabelt moniker, hvis du spørger mig) det fjernet portalen helt, præsenterer i stedet en enkelt motor, der ikke har standard interface mellem sig selv og sin kontrol-programmer. Dette ville udviklere at opbygge nogen form for front-end, de skal bruge, over Internettet eller andre steder, og fortsætte udviklingen spor til deres forreste ende uafhængigt af back-end. På denne måde, tænkes, funktioner, der har at gøre med administration og produktivitet kunne gennemføres i et hurtigere tempo, uden at vente på den næste større version af CMS’ repository, eller hvad hovedløse arkitekter kalder “indhold hub.”
Inde i British Museum i London
Scott Fulton
Endelig cloud-native model fremstår
Endnu flytter til en hovedløs model er ikke en problemfri overgang, men en anden mosebog. Da vi har konstateret, at det næste evolutionære spring fremad er over en temmelig stor bugt alligevel, organisationer, er at stille spørgsmålstegn ved den relative værdi af at flytte deres eksisterende CMS metoder og aktiver i en hovedløs model og iscenesættelse, at modellen på en cloud-platform, i forhold til at helt at omskrive deres model ved hjælp af en cloud-native ramme.
Sidstnævnte vej ville give organisationer frihed til at eksperimentere med serverlessness, der synes at tilpasse tæt nok med headlessness. Og ved at vedtage microservices, organisationer kunne også gå videre med et andet begreb, der har vundet betydelig trækkraft: continuous integration og kontinuerlig levering (CI/CD). Under sådanne systemer, organisationer, har timet deres udgivelse kadencer til at være så meget som er 2.500 gange hurtigere (ja, de er nuller, ikke en % – grænse, der blev misforstår) end virksomheder, der ifølge den klassiske Bittner og Spence metode, der er markeret med forbedringer i produktivitet, rentabilitet, og endda glæde i deres arbejde.
I et forsøg på at løse disse nye spørgsmål, nye virksomheder, herunder Contentful er at producere, hvad de beskriver som “composable moduler” — komponenter, der kan samles som bygger på en cloud-platform. Tænk på disse moduler som præ-blandet, afmålte ingredienser for en organisation til at bygge sin egen cloud-native CMS — eller snarere et system for forvaltningen af sine publikationer, der erstatter det CMS, som vi kender det.
En for nylig offentliggjort case study [PDF], som beskriver, hvordan British Museum hyret et software udviklings firma til at samle Contentful moduler i en enkelt enhed, at alle Museets udgivelse divisioner kunne bruge, hver på sin egen måde-som om hver arm, herunder webcasts og print, havde sit eget CMS. Den Contentful system viser vejen mod en ny metode til at samle og udvikler applikationer, der bygger i høj grad på de behov, brugerne på det tidspunkt, og gennemført på en hensigtsmæssig mode snarere end en forsigtig en.
Også: Seks trin til at DevOps succes, analyseret
Reconnoiter
Dette er, hvordan cloud-native applikation model er at ændre den diskussion, og er begyndt at ændre de data, som center:
Automatisere udsendelsen af funktioner og komponenter, uanset hvor triviel eller hvor omfattende de er, fjerner risikoen for faktorer, der traditionelt er involveret i gennemførelsen version opdateringer.Med disse risici ikke længere i billedet, organisationer, er fri til at tænke fremad-til at tage ansvar for, hvad de ønsker, at deres information management-systemer til at være, og ville ønske, de ville opføre sig.Nu, kan organisationer har råd til at ansætte lille hold af udviklere til at yde bidrag og ændringer til store projekter, der giver dem alle de fordele af “rullende deres egne” programmer suites uden at investere i et komplet genopfindelse af hjulet hver gang.Med en cloud-platform udvidet på tværs af offentlige og private lokaler, organisationer har frihed til at lease eller eje så meget eller så lidt af deres eget data center aktiver, som de kan styre på det tidspunkt, og for at udvide hele deres applikationer miljø på tværs af både plateauer.Ja, ja, organisationer kan prøve serverless, microservices, og disse vidunderlige nye begreber, der gjorde Netflix dynamisk organisation, det er blevet. Men sky er i sig selv allerede en fremmed landskab for de fleste virksomheder, og begreber som microservices kan lige så godt være andre ikke-jordiske intelligenser set ukendt sprog. Tænkes, levering pipeline-model indført af CI/CD kan give disse virksomheder en bred køje, de har brug for at prøve nye ting i deres eget tempo, iterere hurtigt, men i små bidder.
Relaterede historier:
Kampen mellem kant og cloud
Hvad er den bedste cloud storage for dig?
Top cloud-udbydere 2018: Hvordan AWS, Microsoft, Google, IBM, Oracle, Alibaba stak upEverything du behøver at vide om cloud, forklarede
Få mere at vide-Fra CBS Interaktive Netværk
Hvorfor beholder orkestrering er afgørende for cloud-native apps (TechRepublic)
CNAB: Docker og Microsoft ‘ s Cloud Oprindelige Program Bundt
8 trin til at blive en “cloud-native” enterprise
Andre steder
7 Løfter, og Potentielle Faldgruber i forbindelse med Vedtagelsen af en Sky Native Tilgang til DevOps af Scott M. Fulton, III, Den Nye Stak
Gør DevOps Cloud Native Måde, Scott M. Fulton, III, Den Nye Stak
Microservices Gøre Indhug: Udskiftning af CMS Monolit af Scott M. Fulton, III, CMSWire
Relaterede Emner:
Thought Leadership
Digital Transformation
Datacentre
CXO
Innovation
Opbevaring
0