Nul
Voor een belangrijke toepassing zoals industrial control system (ICS), een content management systeem (CMS), of een ziekenhuis management systeem (HMS) te worden “cloud-native,” met de volledige levenscyclus moet bestaan op een cloud-platform. Het is ontwikkeld of samengesteld daar, het is in scène gezet en getest er, het is er ingezet, debugged er, en voortdurend bijgewerkt. Het is niet “geïnstalleerd” op een server in een datacenter als een soort permanente verblijfsvergunning. En het is niet omgezet in een virtuele machine image gewoon om het draagbaar op verschillende servers. Het is ontworpen voor de cloud, die niet alleen mandaten fundamentele wijzigingen in de architectuur, maar van de gehele IT-economie die het ondersteunt.
Ook: IT-banen: de Aanpak van het dreigende digitale vaardigheden kloof
Een manier om de evolutie van de server-side applicaties is het terugkeren naar de cursus geweest en het nemen voorafgaand aan het PC-tijdperk, toen x86-processors geduwd mainframes en minicomputers uit van het datacenter. Een cloud-native applicatie is gemaakt voor de systemen die door de host, in plaats van te worden omgezet of geënsceneerd in een virtuele omgeving die verbergt de aard van de cloud.
De terugkeer van time-sharing
“Op onze huidige systeem ongeveer 35 gebruikers kan het een goede gelijktijdige service, elk met de illusie dat hij heeft volledige controle over de machine. Elke gebruiker zit op een teletype typemachine, types uit zijn programma, en houdt het invoeren van correcties tot zijn programma werkt eindelijk. Dit maakt het zowel handig en prettig gebruik van de computer.”
-John G. Kemeny en Thomas E. Kurtz
De Dartmouth Time-sharing Systeem, April 1967
Sinds de opkomst van de computer, de software is geschikt voor de machines aangewezen om het te draaien. Dat mag niemand verbazen. Dartmouth John Kemeny en Thomas Kurtz in wezen uitgevonden moderne computing door de ontwikkeling van een taal bedoeld om te weerstaan trial-and-error programmering: BASIC. De eerste echte cloud computing-platforms, en de meest succesvolle van dergelijke platforms van vandaag, zijn de directe afstammelingen van hun werk. Hun principe was dat de programma ‘ s die kunnen het beste gebruik maken van de machine, moet worden gekoesterd en ontwikkeld in de machines, in plaats van hash van te voren op papier en afzonderlijk samengesteld.
“De overwinning van de Deugd en Adel over de Onwetendheid” van Giovanni Tiepolo, ca. 1745. Van het Norton Simon Museum.
Gesteld via Creative Commons CC0 1.0
Platforms als diensten
“Cloud-native” computing is dit hetzelfde principe, uitgebreid en omvat cloud-platforms. Als we eerlijk zijn (nu zou een goed moment zijn), dan moeten we erkennen dat “de cloud” is een enkele machine, althans vanuit het perspectief van de toepassingen die worden uitgevoerd. Het is niet echt een mistige of andere wereldse omgeving, maar een cluster van processoren gekoppeld door high-speed netwerken die toevallig te span de planeet. De talen ontworpen voor engineering cloud-native applicaties op dit enorme klasse van de machine, het zijn rechtstreekse afstammelingen van de Dartmouth BASIC.
Ook: het Gebruik van de cloud als platform voor digitale transformatie
Eerst en vooral, cloud geboorte wordt het probleem van waar een organisatie ook kiest gastheer zijn toepassingen, een eeuwig open vraag. Applicaties in de Cloud platforms zijn ontworpen voor draagbaarheid. Een cloud-infrastructuur vandaag de dag vaak voorzien van een applicatie-platform zoals Cloud Foundry (stewarded door Centrale), Apprenda, of Red Hat OpenShift.
Binnenkort de uitspraak “cloud-native” kan vallen in onbruik geraakt, zoals de tag op de jaren 1990 en vroege jaren 2000 TV-programma dat lezen, “Gefilmd in high definition!”
Making sense van alle abstracties
Sinds de komst van C++ en high-level programmeertalen, het ontwerp van de software werd gescheiden van die van de onderliggende hardware door één of meer lagen van abstractie. Programmeurs — nu bekend als ontwikkelaars, meestal hebben nooit rekening houden met de architectuur van de hardware of de infrastructuur ondersteunen.
Ook: Linux nu domineert Azure
“De cloud” (dat is veel te laat om het te hernoemen) is een machine, zij het dat zich uitstrekt van de planeet. Sommige van de eerste cloud-diensten, met inbegrip van de originele “Windows Azure” terug in 2008, werden opgericht als een middel van enscenering van nieuwe software, ontworpen met de bedoeling van het lopen. Ondanks wat de oorspronkelijke huisstijl impliciet, software waarvan het de bedoeling is om te worden gedistribueerd en niet gecentraliseerd — met andere woorden, te worden uitgevoerd via het Web in plaats van een PC als server fungeert, — op zijn eigen ontwerp.
De Docker revolutie van 2013 is ingeschakeld drie ideale situaties tegelijkertijd:
Docker ontkoppelde toepassingen van de servers waarop ze liep, door het vervaardigen van een standaard-klasse van draagbare, software-gebaseerde container.Het werd een self-service implementatie mechanisme dat maakte het mogelijk voor ontwikkelaars om letterlijk op te bouwen lokaal, dan handelen globaal — om het podium een gedistribueerde toepassing op een enkele computer, en duw het naar de cloud in een eenvoudige, geautomatiseerde manier.Het veranderde voor eeuwig de architectuur van de server-based applicatie, het maken van ten minste één stijl van programmeren, misschien wel meer, die speciaal geschikt zijn voor implementatie in de cloud: de cloud-native applicatie.
Is dit dezelfde “cloud” hebben we het over gehad hebben?
Voordat we vooruit met die zin, laten we afwikkeling van de kwestie van wat wij denken dat “de cloud” is vandaag de dag. Wij die dekking van technologie voor een leven hebben de neiging om te tekenen van een harde grens tussen datacenters en cloud service providers, de aanwijzing van wat een organisatie kan eigen en werken voor zichzelf als “hier” en de cloud “daar.”
Dit is niet wat de cloud concept eigenlijk betekent, of heeft ooit echt betekende. Uw organisatie staat van hosting zijn eigen cloud-native applicaties, als het bezit van of zelfs leasing de servers die ze uitvoeren op het terrein dat het ofwel in eigendom of lease van een colocatie provider zoals Equinix of Digital Realty. Wat we hebben is het aanroepen van de “hybride cloud”, alsof het een vreemd, maar levensvatbaar alternatief is, is nu een cloud-platform van wier diensten kan worden deel-eigendom en gehuurd van een service provider, zoals Amazon, Microsoft, Google, IBM, waar deze diensten zijn gevestigd.
Ook: Enterprise-ontwikkelaars te bereiken voor de cloud
Laten we proberen om dit op een andere manier, in termen die zin te maken vanaf het begin, voordat iemand herdefinieert ze betekenen iets anders: Een wolk kan elke combinatie van middelen, overal op Aarde, waarvan de netwerk connectiviteit stelt hen in staat om te functioneren in concert als een enkele vergadering van de servers. Een organisatie kan bezitten en exploiteren van een eigen cloud in zijn geheel, hoewel het meestal niet. Commerciële cloud service providers (de drie grootste van die Amazon AWS, Microsoft Azure, Google Cloud) bieden een organisatie de middelen die het mogelijk moeten stadium enige of alle toepassingen in de ruimte die we nu noemen de publieke cloud. Sommige bedrijven niet in het bezit of het bedienen van haar eigen it-middelen in plaats daarvan kiest voor het leasen van deze middelen uit de public cloud service providers volledig.
Dus wanneer we zeggen dat een toepassing is “native” om deze vorm van cloud, wat we bedoelen is niet alleen dat het werd gebouwd voor de implementatie, maar dat draagbaar is in elk deel van de ruimte die deze cloud omvat. De cloud steken samen meerdere kleedruimtes voor toepassingen en hun bronnen, met inbegrip van databases, in een enkel landschap. De cloud-native applicatie ziet dit landschap als zijn eigen. Belangrijker nog, is het niet hebben om dieper te graven in de infrastructuur van de servers of datacenters waar delen van het landschap worden gehost.
Hoe het huis voor een cloud-native applicatie is gebouwd
Zeg bijvoorbeeld dat een onderneming beheert een VMware vSphere-omgeving. Oorspronkelijk, vSphere, het was de bedoeling om het hosten van virtuele machines (vm ‘ s) die zich gedragen als fysieke servers, maar weergegeven als software. Nu, door middel van een uitbreiding van het product genoemd vSphere Cloud Stichting, het kan ook hosten en beheren van de nieuwe soort van container-toepassingen, die zijn veel meer draagbaar en die zich buiten het VMs.
VMware-CEO Pat Gelsinger, legt VMware Centrale Container Service aan de deelnemers van VMworld 2018 in Las Vegas.
Scott Fulton
Als VMware kondigde in November vorig dergelijke container-toepassingen zullen in staat zijn om gebruik te maken van middelen zoals computing power, storage, database diensten van Amazon AWS. VMware gemaakt van een soortgelijk pact met Google Cloud het voorgaande jaar. Als een resultaat, een organisatie hybride cloud kan bestaan uit middelen verzameld van de publieke dienstverlener en zijn eigen data centers. VSphere ziet deze middelen als een enkele ruimte om applicaties te beheren.
Ook: de 8 stappen om een ‘cloud-native’ enterprise
Dus een applicatie die ontworpen is voor een dergelijke omgeving, en misschien wel in deze omgeving, zou worden “cloud-native.” In tegenstelling tot een server-based applicatie geschreven voor een stand-alone Windows Server of Linux-omgeving, de cloud-native versie staat zou zijn om de implementatie overal in deze ruimte op elk moment.
Deze constructie is niet exclusief voor vSphere. Als een organisatie haar eigen OpenStack cloud, on-premise, het kan integreren in haar eigen middelen in zekere mate met AWS, Microsoft Azure, of Google Cloud. (Of doet dat met eenvoud is het een kwestie van een open debat, maar er is in ieder geval open.) Een organisatie met Microsoft ‘ s Azure toren kan bouwen en implementeren van applicaties met behulp van Visual Studio (of de uitstekende open source tegenhanger, VS-Code) op haar eigen servers in haar eigen datacenters, en de integratie van de middelen die beschikbaar zijn in de openbare Azure cloud als dat nodig is.
En op basis van de informatie die wij hebben aan de hand vandaag, we geloven dat een onderneming die zich inschrijft voor AWS Buitenposten moeten in staat zijn van het bouwen van een applicatie die gericht is op Amazon EC2, en het implementeren van het AWS-servers gesitueerd op de locatie van de klant. Dit zal een cloud-native applicatie, maar niet noodzakelijk in het publieke cloud, tenzij en totdat de klant beweegt, of een deel daarvan, opzettelijk.
Waarom cloud geboorte plotseling zaken nu
Het vergelijken van native applicaties voor de participatie van migranten toepassingen
De meeste server-side software ooit gemaakt (d.w.z. niet de apps die draaien op een PC of op een telefoon, die een “client-side”) werd ontwikkeld om te worden uitgevoerd op een conventionele machine — een doos met een processor, haar eigen geheugen, sommige lokale opslag, en een PC-besturingssysteem. Wanneer dat oudere klasse van de software in de cloud draait, een virtuele machine (VM) is gemaakt, is zelf ook een soort programma ‘ s. Een VM doet zich voor als een conventionele machine omwille van de applicatie, die vaak niet weten wat het verschil is. Maar de VM is draagbaar en eenvoudig te beheren. Moet het beschadigd is, een ander exemplaar van het kunnen worden gekloond uit een eerdere beeld voor in de plaats (“gemaakt”).
Ook: Waarom native apps zijn niet echt ten dode opgeschreven, voor nu TechRepublic
Een cloud-native toepassing hoeft niet te doen alsof. Als het doet draaien in een VM, zoals velen dat doen, dan is het in staat is om bewust te worden van de cloud-platform dat wordt uitgevoerd, waardoor het meer controle over de manier waarop het wordt beheerd en verspreid over een netwerk.
Dit geeft aanleiding tot twee scholen, beide zijn even geldig terrein voor cloud-native methoden:
Eindelijk, de toepassing kan worden terdege bewust van haar omgeving. Als een gast van een virtuele machine, een toepassing weet nooit echt de details van de ware aard van de infrastructuur ondersteunen. Als een resultaat, het niet weten hoe het verbeteren van de eigen prestaties. Nu, bij wijze van componenten die als externe agenten in containers (een prominent voorbeeld wordt NGINX Plus) een component van een draaiende toepassing kan verkrijgen live gegevens over bepaalde aspecten, sommige van hen weliswaar esoterische, van de configuratie en prestaties. Met die gegevens, althans in theorie, de toepassing kan bepaalde beslissingen nemen over de configuratie en de verdere distributie, het orkestreren van een aantal van haar eigen functies en, daarmee, de ontwikkeling zelf te passen aan veranderende doelen en situaties.Eindelijk, de toepassing hoeft niet te weten van een tweede over de omgeving. Er is een meer vocale school van denken die in de afgelopen maanden dat touts de voordelen van ontwikkelaars aan de bouw van hun applicaties en uitsluitend gericht op de behoeften van het programma en de belangen van de gebruiker, terwijl het beheer van de onderliggende hardware voor het milieu, en de distributie van de software aan de orchestrator (vaak deze dagen, Kubernetes). Dit zijn de voorstanders van het zogenaamde serverloze architectuur. De eerste time-sharing systemen, zeggen ze, geabstraheerd van de gegevens van de computer van de werking van de functies van het programma, en dat abstractie kan net zo geldig en noodzakelijk is.
Heeft u behoefte aan microservices echt cloud-moedertaal?
Vandaag, de laatste school van gedachte is, by far, de meest vocale, hoewel de kern van de filosofie is nog niet grondig gel. In het hart van de serverloze waarde propositie is de boodschap die abstracties gratis ontwikkelaars om te denken en te werk in zijn geheel in het rijk van de problemen die ze proberen op te lossen. Dit gaat in tegen het idee dat een organisatie haar IT-infrastructuur is in het hart van de business, en zet de toon voor haar business model. Niet langer is dit alles “strategic alignment” tussen de business en technologie vleugels van de organisatie noodzakelijk.
Ook: 8 manieren om te zorgen dat je echt nodig hebt microservices
Maar, advocaten gaan pleiten in het voordeel van de afbraak van de monolithische applicaties in het voordeel van een microservices-gebaseerd model, waarbij de afzonderlijke componenten samensmelten in de richting van gemeenschappelijke doelstellingen. Het opgeven van wat die gemeenschappelijke doelstellingen zijn, vereist precies het type van strategische uitlijning die serverloze voorstanders zeggen dat ze schuwen, zodat belanghebbenden kunnen bij elkaar op dezelfde pagina.
Sommige advocaten zijn ook weg op de plaat, zoals het ondersteunen van een concept noemen ze “cloud-native DevOps,” die zou uitlijnen van de DevOps (ontwikkelaars + operations professionals) beweging met het bewegen in de richting van zowel de serverloze en microservices architecturen. Het belangrijkste probleem met dit idee is het feit dat er geen enkel bewijs dat de Ops deel van die beweging heeft ondertekend op dit idee. Als de ontwikkelaars zijn, als serverloze advocaten beschreef ze, “bevrijd” om hun eigen ideeën en hun eigen tijdschema, dan is zo ‘ n scheiding zou gaan tegen de notie van een coalitie met Ops, waarvan de verantwoordelijkheden omvatten het instellen van de dienstregeling, en ervoor te zorgen dat ontwikkelaars zijn zich bewust van hun infrastructuur.
De stap naar cloud-native in de echte wereld
Laten we stoppen met praten over al deze dingen in het abstracte, en een meer praktische kijk op wat dit eigenlijk betekent, in de context van de geschiedenis van één van de meest voorkomende klassen van server-side applicatie:
Een content management systeem (CMS) is een vrij geavanceerde database manager vermomd, ten minste gedeeltelijk, als in een tekstverwerker. Oorspronkelijk opgeslagen en weergegeven Webpagina ‘ s als statische documenten. Maar als de consument nodig het Web om meer functioneel dan de archivering, de CMS architectuur werd gecentreerd rond twee verwerking motoren:
Een die opgehaald elementen van de inhoud van een archief en gemonteerd in HTML-componenten, op een gegeven moment riep de content delivery; en een Ander, die ingeschakeld beheerders en redacteuren te maken van de kern-componenten of hun prototypes, evenals het maken van de stijlen die deze componenten zouden volgen, de zogenaamde content management applicatie.
Modellen van monolithische architectuur
De eerste echte CMS systemen geautomatiseerd de generatie van Web pagina ‘ s, gebaseerd op elementen in de gegevensopslagruimte die werden voortdurend bijgewerkt, vervangen en gewijzigd. De “portalen” voor dergelijke systemen-bijvoorbeeld Vignet — werden geïnstalleerd op de Pc ‘ s van de mensen die belast is als de gebruikers en beheerders. Als gevolg hiervan, wanneer het systeem als geheel was traag of bloedarmoede, de gebruikers was de eerste om te lijden, en het oplossen van deze aandoeningen vereist gebruikers om rechtstreeks te maken met de IT-afdeling, in de hand houden sessies waar was het niet duidelijk in wiens hand het leiden van wier.
Ook: Cloud computing: de Vijf belangrijkste zakelijke trends om naar uit te kijken
In retrospect, de architectuur van de eerste CMS systemen, alsmede de “knowledge management “systemen” hebben geïnspireerd, heeft geroepen monolithische. Wanneer een toepassing die zich volledig op een PC, de ontwikkelaars ervoor kan zorgen dat alle stukjes in elkaar passen goed voordat u de toepassing die wordt gedistribueerd. In een netwerksysteem, het archief is achter een server, en in-tussen de server en de clients, stuit men op veel van middleware. Dus de stukken niet altijd past erg goed.
Met een monolithische toepassing, innovatie vindt plaats in een zeer sterk gepland, gecoördineerd stappen. Een voorbeeld van een goed gecoördineerde product plan is kentico solution, een CMS voor marketing en e-commerce. Eerst verscheen op het toneel in 2004, kentico solution snel aangenomen en behouden van een major release cadans van ongeveer één versie per jaar. Dit is om kentico solution is geweldig krediet, als de klanten ervaren dit als een embleem van het systeem van de continuïteit. Als een blogger schreef eind 2017, “Elke nieuwe release is de moeite waard te praten over. Ik kan zeggen dat niet alleen, want ik ben een kentico solution liefhebber, maar echt omdat elke grote release van kentico solution heeft de neiging om iets toe te voegen die gemeenschap is veeleisend.”
De geschiedenis van de release-strategie
In het tijdperk van de client/server-architectuur, de timing van grote releases tot een vorm van kunst op zichzelf. Als veteraan analist Kurt Bittner en adviseur Ian Spence geadviseerd in 2006 voor hun boek het Beheer van Iteratieve Software Ontwikkeling Projecten, de ontwikkelaar van een applicatie moet in kaart brengen van de release van de cadans in de vroege stadia van de planning, onder andere vanwege het risico te minimaliseren door de verspreiding evolutie in de tijd. Bittner en Spence schreef:
Het aantal evoluties (grote releases) vereist is meestal ingegeven door zakelijke wensen, de afweging van de mate waarin de business kan absorberen nieuwe mogelijkheden tegen de behoefte aan nieuwe mogelijkheden. . . Elke grote release biedt een duidelijk eind-punt in de richting die iedereen werkt, dat vaak ontbreekt als de ontwikkeling is gepland als een ongedifferentieerde serie van voortdurende herhalingen.
Als releases gepland te vaak, zij gewaarschuwd, kunnen ontwikkelaars het risico van de invoering van zo veel nieuwe overhead zo snel dat gebruikers zou het niet kunnen waarderen van de waarde van deze functies toegevoegd aan hun eigen organisaties. Release planning, in deze periode in de geschiedenis, was een fijn berekend affaire, want het was duidelijk voor iedereen dat de motoren van deze toepassingen — als laatste is zeker het geval met een CMS-zijn de kern van hun bedrijven.
De economische risico ‘ s van mogelijke downtime, en de zekerheden van de continuïteit van de problemen zijn te groot voor een organisatie te verbinden, tenzij en totdat de potentiële waarde van toekomstige functies-hoe lang zij hebben gewacht in de vleugels — opweegt tegen hen. (Herinner me om te vertellen dat je ergens over hoeveel jaar een uitgever wachtte tot hij voelde zich zelfverzekerd genoeg om de overstap te maken naar een nieuw systeem dat ingeschakeld te vet zijn de eerste alinea ‘ s.) Dit is de reden waarom Spence en Bittner gewaarschuwd dat de planning van de release cycles moet zorgvuldig worden gepland om de behoeften van de business.
Ook: Wat is DevOps? Een executive gids
Wat deze auteurs vermoeden was echter dat elk exemplaar van een CMS kan worden afgestemd op de unieke behoeften van haar exclusieve klant-en dat is niet hoe de markt terecht.
Voor een overvloed van redenen, waaronder een verkoop van haar moedermaatschappij en een enorme hernoemen en herlancering van het product, de kloof tussen Vignet versie 7 en versie 8 van zijn opvolger product, Open Text, ongeveer zeven jaar. Maar in die tijd, een verrassend groot aantal van haar klanten strak gehouden-niet gelukkig met alle middelen, en in sommige gevallen, zo leek het, onder dwang. Zodra de grote uitgevers hadden zich maar liefst zeven grote releases, sommigen geloofden dat er geen manier was om het toepassen van een alternatief platform. Als dit 2011 AdWeek verhaal met de titel “De Problemen met de Back-Ends” geboekstaafd, uitgevers waren het verlaten van hun merk-naam CMS suites, het bouwen van hun eigen platforms in plaats rond de open source Drupal framework. . . en het ontdekken van succes.
In sommige gevallen is het streven naar het behoud van de stabiliteit oudere Vignet gevallen de sprong naar versie 8 veel te grote risico ‘ s. Als de Overheid Technologie gemeld in 2012, het Georgia Technologie Instantie gekenmerkt wordt de exodus als een “kracht.”
Aanval van de onthoofde hybride
Op ongeveer deze tijd, de opkomst van Web architectuur en het begin van HTML5 gericht de monoliet probleem met de introductie van de zogenaamde “Goede ontwerp.” Hier, portals worden vervangen door een browser-based front-ends, dat communiceren met servers op de back-end door middel van API-aanroepen. We konden doorbrengen boekdelen over hoe deze methodiek gewijzigd front-end architectuur. Wat we missen is wat er gebeurde op de back-end: Het systeem niet meer nodig om twee (of meer) motoren voor het verwerken van de input van twee (of meer) categorieën van de gebruiker. In plaats daarvan, de authenticiteit en de rechten van de diensten kan valideren -, filter-en route-API calls naar de juiste handler. Wat is meer, met behulp van een geavanceerde reverse proxy zoals NGINX, deze API call handlers kunnen worden gemultiplexed en verdeeld over de server nodes, zodat de CMS beter in te spelen op wisselende werkdruk.
Ook: Drie manieren DevOps zal meer afgestemd in 2019
Een nieuwe en intrigerende CMS architectuur is ontstaan op dit punt. De naam “headless design” (nogal een riskante naam, als je het mij vraagt) het elimineren van de portal in totaal presenteren in plaats van een enkele motor die niet standaard interface tussen het zelf en de controle programma ‘ s. Dit zou gratis ontwikkelaars bouwen een soort van front-end nodig, via het Web of elders, en gaan met de ontwikkeling track voor hun front-end onafhankelijk van de back-end. Op deze manier denkbaar, heeft dat te maken met de beheersbaarheid en productiviteit kan worden geïmplementeerd in een sneller tempo, zonder te wachten op de volgende grote release van het CMS-gegevensopslagruimte, of wat headless architecten noemen de “content hub.”
In het British Museum in Londen
Scott Fulton
Tot slot, de cloud-native model naar voren
Nog verhuizen naar een onthoofde model is niet een naadloze overgang, maar een uittocht. Aangezien we hebben vastgesteld dat de volgende evolutionaire sprong voorwaarts is over een vrij grote golf toch zijn organisaties bevragen over de relatieve waarde van het verplaatsen van hun bestaande CMS-methoden en activa in een onthoofde model en staging dat model op een cloud-platform, vergeleken met het volledig herschrijven van hun model met behulp van een cloud-native kader.
De laatste weg zou geven organisaties de vrijheid om te experimenteren met serverlessness, die nauw af te stemmen genoeg met headlessness. En door het aannemen van microservices, kunnen organisaties er ook vooruit met een ander concept dat is het verkrijgen van aanzienlijke trekkracht: continuous integration en continuous delivery (CI/CD). Onder dergelijke systemen, organisaties hebben tijdelijk hun release cadensen zoveel 2500 keer sneller (ja, die zijn nullen, niet een % teken dat was verkeerd gelezen) dan bedrijven na de klassieke Bittner en Spence methodologie, met duidelijke verbeteringen in de productiviteit, winstgevendheid, en zelfs plezier in hun werk.
In een poging om deze nieuwe vragen, nieuwe bedrijven, waaronder Contentful produceren wat zij omschrijven als “samen te stellen modules” — componenten die kunnen worden gemonteerd, zoals het bouwen van een cloud-platform. Denk dat van deze modules als pre-gemengd, pre-gemeten ingrediënten voor een organisatie in staat om een eigen cloud-native CMS — of liever, een systeem voor het beheer van de publicaties die vervangt de CMS zoals wij die kennen.
Een onlangs gepubliceerde case-studie [PDF] wordt beschreven hoe Het British Museum voor de huur van een software development bedrijf te monteren Contentful de modules in een enkele entiteit die van het Museum is het publiceren van divisies zou kunnen gebruiken, ieder op zijn eigen manier-alsof elke arm, met inbegrip van webcasts en afdrukken, had een eigen CMS. De Contentful systeem wijst de weg naar een nieuwe methode van montage en veranderende toepassingen, grotendeels gebaseerd op de behoeften van de gebruikers op het moment, en geïmplementeerd in een opportuun mode in plaats van een voorzichtig.
Ook: Zes stappen naar een DevOps succes, geanalyseerd
Reconnoiter
Dit is hoe de cloud-native app-model is het veranderen van de discussie, en is begonnen met het wijzigen van de data center:
Het automatiseren van de implementatie van de functies en onderdelen, ongeacht hoe triviaal of hoe uitgebreid ook, elimineert de risico factoren van oudsher betrokken bij de implementatie van versie updates.Met deze risico ‘ s niet meer in beeld, organisaties zijn vrij om te denken verder vooruit — om de leiding te nemen van wat ze willen dat hun informatie management systemen te worden en willen ze zich zouden gedragen.Nu, organisaties kunnen het zich veroorloven om de huren van kleine teams van ontwikkelaars om bijdragen te maken en wijzigingen aan grote projecten, waardoor ze alle voordelen van “rolling hun eigen” toepassingen suites, zonder te investeren in een complete heruitvinding van het wiel elke keer.Met een cloud-platform uitgebreid in de publieke en private gebouwen, organisaties hebben de vrijheid om te leasen of eigen zo veel of zo weinig van hun eigen datacenter activa als ze kunt beheren en uit te breiden hun hele toepassingen milieu in beide plateaus.Ja, ja, organisaties uit kunnen proberen serverloze, microservices, en deze prachtige nieuwe concepten die gemaakt Netflix de dynamische organisatie geworden. Maar de cloud op zich is al een buitenaards landschap voor de meeste bedrijven, en concepten als microservices kan net zo goed een andere wereld intelligenties spreken in onbekende talen. Denkbaar is, de levering pipeline model geïntroduceerd door CI/CD, geven deze bedrijven de grote boog die ze nodig hebben om nieuwe dingen te proberen op hun eigen tempo, itereren snel, maar in kleine hapjes.
Verwante artikelen:
De strijd tussen de rand en de cloud
Wat is de beste opslag in de cloud voor u?
Top cloud aanbieders van 2018: Hoe AWS, Microsoft, Google, IBM, Oracle, Alibaba stapel upEverything u moet weten over de cloud, uitgelegd
Lees meer — Van de CBS-Interactief Netwerk
Waarom container orkestratie is van cruciaal belang om cloud-native apps (TechRepublic)
CNAB: Docker en Microsoft ‘ s Cloud Native Applicatie Bundel
8 stappen om een ‘cloud-native’ enterprise
Elders
7 Beloften, en de Mogelijke Valkuilen bij het Aannemen van een Cloud Native Benadering van DevOps door Scott M. Fulton, III, Het Nieuwe Stapel
Het doen van DevOps de Cloud Native Weg door Scott M. Fulton, III, Het Nieuwe Stapel
Microservices Maken Doorgedrongen: het Vervangen van de CMS Monoliet door Scott M. Fulton, III, CMSWire
Verwante Onderwerpen:
Thought Leadership
Digitale Transformatie
Datacenters
CXO
Innovatie
Opslag
0