anders lisdorf bloghoved

Mønstre i skydannelsen i de danske IT afdelinger

Af 1

Cloud er stadig en ting, som polariserer og forvirrer rigtigt mange. Med god grund. Det er forvirrende. Der er masser af forskellige farverige komponenter, og hvis man vover sig til nogle af leverandørernes konferencer, vil man blive blæst væk af information. Amazon Web Services (AWS) har som regel en 2-3 timer lang key note, som er en tour de force i termer, man ikke anede fandtes, og produkter, man slet ikke anede, man havde brug for.
Alt det fjolleri gør jo, at fornuftige mennesker med rette kan læne sig tilbage og nikke uforstående overfor dette nymodens nonsens og logge ind på deres 3270 skærmbillede, hvor alt er meget mere logisk. Selv når man graver sig ned og finder nogle af de mere solide løsninger, så kan det være svært at se, hvordan det kan passe ind i en almindelig dansk IT hverdag.

For efterhånden mange år siden, da NoSQL-databaser vandt frem, stod jeg selv med en lignende udfordring. Jeg kunne jo godt se, at det her var smart og ville løse nogle udfordringer, men hvem var det lige, jeg skulle snakke med for at få interesse for det? En DBA ville være et naturligt sted at starte, men hvis man ser på mange af de eksisterende NoSQL-løsninger, er det noget, som en DBA vil grine ad. Det er omtrent lige så forståeligt som fuglekvidder for et bøgetræ.

Men var det så måske webudviklerne? De er jo tit lidt mindre bundet af etablerede ideer og løsninger. Men for dem var det lidt for infrastrukturagtigt at skulle sidde og konfigurere sharding og master og slavenoder.
Hvad så med infrastrukturfolkene? De ville helst ikke bekymre sige om logikken bag, hvad de her ting skal gøre. NoSQL er simpelthen noget, som sætter sig imellem alle stole, der findes i et traditionelt dansk firma med en IT-afdeling. Det er ikke rigtigt DB eller applikation eller infrastruktur. Det er lidt af det hele.

Det er det samme med cloud. Men nu har jeg fundet ud af problemet. Det er, fordi vi angriber det helt forkert. Når Amazon, Azure og Google highlighter features, taler de til et specifikt publikum: dem, der bruger det, dvs. start ups og seje firmaer med alle de moderne udviklertyper. Og de bruger det alle på en meget bestemt måde, der adskiller sig fra de fleste firmaer. Det, som det hele handler om, er, at der er forskellige cloudmønstre eller patterns, som man kalder det efter den amerikanske arkitekt Christopher Alexander. Det er kritisk at forstå forskellen i mønstre for at se, hvordan cloud kan være en fordel for et firma.

Mønstre i IT

i starten af halvfjerserne udgav Christopher Alexander og medarbejdere et trebindsværk om arkitektur og byplanlægning. Bind to, “A Pattern Language”, kom til at spille en stor rolle for systemudvikling og teknologiindustrien generelt. I denne bog udviklede Alexander og medarbejdere en måde at tænke på om bygning af regioner, byer og huse ud fra gentagelige mønstre. Ideen var, at disse mønstre havde vist sig brugbare i flere tilfælde og derfor kunne bruges til lignende problemer igen. Det er her, hvor simpliciteten og genialiteten kommer ind, for et mønster består grundlæggende blot af følgende: en kontekst, i hvilken mønstret bliver relevant, et problem, der gentager sig i denne kontekst, og en løsning, der er den optimale måde at få problemet til at gå væk på. Mønstre kan være på mange forskellige niveauer. Hos Alexander startede det på regions- og byudiklingsniveau og sluttede med, hvordan man designede rum i en bygning.

"Design Patterns" af den såkaldte "gang of four” har påvirket software udvikling i årtier, og “Enterprise Integration Patterns” har ligeledes drevet udviklingen for integrationsløsninger. På samme måde, som disse bøger tænker ud fra mønstre indenfor et felt, er det også muligt at gøre det indenfor cloud. Og jo tak: O’Reilly har været der, så der findes en “Cloud Architecture Patterns”, men lige præcis denne bog udstiller hele problemet med cloud patterns. Den behandler nemlig kun patterns indenfor cloudnative applikationer, og så er vi jo tilbage, hvor vi startede: Hvis man ikke arbejder for et sejt startup med Millenials, som snakker om deres investeringer i Bitcoins og forskellige marijuanarelaterede firmaer, så er der ikke rigtigt noget at komme efter.

Cloud strategy patterns

Derfor har jeg udviklet nogle forskellige patterns for, hvordan firmaer kan tilgå cloud. De er på et højere niveau - omtrent ligesom Alexanders byudviklingsmønstre. I det følgende vil jeg kort gennemgå de vigtigste mønstre for at skitsere diversiteten. I senere blogs vil jeg dykke mere ned i de enkelte og vise, hvornår man skal bruge dem, og hvad man bør gøre. De er udviklet gennem mine egne erfaringer med at udvikle og designe løsninger til 4 af de 5 store cloudplatforme i indland og udland. Meget går nemlig igen imellem dem.

Cloud Native er for en ny organisation eller forretningsenhed uden nogen eksisterende IT-løsninger, der gerne vil bygge software hurtigt og omkostningseffektivt. De vil ikke bruge tid og penge på at opbygge en stor infrastruktur og operationsenhed. Problemet er at udvikle nye løsninger så hurtigt som muligt for at komme først på markedet. For at gøre det bygges løsningerne på en cloudplatform, og alt sker her. De, som har gavn af dette mønster, har typisk ingen eller meget lidt eksisterende on-premise løsninger. Hvis du ikke er en hurtigt voksende startup i et kompetitivt marked, er der stor chance for, at dette mønster ikke giver mening for dig.

Lift and shift er en for organisation med en stor eksisterende investering i standardsoftware fra softwareleverandører som Microsoft, Oracle og IBM. Lift and shift vil gerne reducere infrastruktur og operationsomkostninger og/eller øge modstandsdygtighed og skalerbarhed af deres infrastruktur. Problemeter, hvordan man kan reducere omkostninger og overhead i provisionering og vedligeholdelse af eksisterende services og samtidig øge driftssikkerheden. Løsningen er at vælge en cloudleverandør, der er kompatibel med legacy software og etablere en netværksstruktur, der svarer til og er forbundet med eksisterende on-premise. Flyt alle højt standardiserede elementer som VM og databaser. Her skal man være opmærksom på, at Google absolut ikke er en god kandidat, da det er decideret ulovligt at køre Oraclesoftware på Googles infrastruktur grundet deres retsager med Oracle omkring Java. AWS har også et anstrengt forhold til Oracle, men det virker, mens kun IBM kører IBM-ting. Derfor handler det meget om at identificere sit eksisterende miljø. Mange almindelige danske virksomheder vil kunne bruge dette mønster.

Gradvis ændring er for en organisation, der har mange år i markedet med en væsentlig eksisterende investering i on-premiseteknologi, og den vil modernisere sin IT-portefølje for at drage nytte af de nye muligheder, cloud giver. Det grundlæggende problem, som addresseres i dette mønster, er, hvordan man selektivt bruger cloud, hvor det giver maximal værdi for minimal investering og risiko. Ud fra det kan man bygge mere og mere på og etablere en gradvis modernisering af IT-porteføljen. Løsningen er her at etablere et cloudprogram, som bygger business cases både for modernisering og migrering af eksisterende løsninger, men som også inddrages i nyudvikling. Dette udgør en portefølje, som styres ud fra parametre, der giver mening for firmaet. Cloud handler meget om at få føling med og tillid til teknologien, så derfor bør der fokuseres på lavt hængende frugter, og mission critical applikationer skal undgås. Dette er også et mønster, som mange danske virksomheder vil kunne have brug for.

Der findes også andre interssante mønstre, som jeg har identificeret, men som det fører for vidt at komme ind på her:

Cloud first – for dem, som mener det alvorligt.
Off load – for købmændende, der kan finde det lidt billigere.
Balkanisering – for dem, som opdager nye forretningsenheder i deres firma i nyhederne.
Anarki – live fast die young…
Eksperimentel – for de forsigtige, som er lidt bange, men også lidt fascinerede

Ved at kigge lidt mere fokuseret på, hvilket problem man forsøger at løse og at ignorere salgstalerne fra cloudleverandørerne er det faktisk muligt at få skabt nogle rigtigt gode løsninger, der kan bringe stor forretningsværdi og besparelser, hvis man gør det rigtigt.

Kommentarer (1)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Ivan Skytte Jørgensen

En udfordring er at finde ud af hvad man skal betale. Alm. virtuelle maskiner og båndbredde er normalt nemme nok at regne på, men når man kigger på de ekstra services som udbyderne har, så er det knap så nemt:
- load balancer: x kroner per y requests. Øhm. Er det med eller uden TSL? Hvad med http 1.1 persistent connections? Hvis en client er fejlkonfigureret og bombarderer os med requests, løber regningen så løbsk? Hvormange requests har vi egentlig normalt?
- Den der block storage lyder smart. Men hvad koster et snapshot? Ahah, det koster x per y GB faktisk plads, så duplikeret data tæller ikke med. Hvordan udregner jeg det? Nå, det kan man ikke, så vi skal blot tro på udbyderen.
- En fin database-som-service. Hvad er det helt præcist jeg betaler for?
- Shared filesystem lyder dejligt. Men sparer jeg faktisk noget i forhold til at selv konfigurere det?

Log ind eller Opret konto for at kommentere
Tip redaktionen