Simplificering.
Det er et ord, der går igen, når man taler med Rod Johnson, CEO og grundlægger af SpringSource.
Måske er det hans australske opvækst, der giver ham en down-to-earth tilgang til livet. En livsindstilling der ikke levner plads til bureaukratiske procedurer og opsvulmede ineffektive teknologier.
Ting skal være enkle og effektive.
Det var blandt andet det, der drev ham til at skrive bøgerne Expert One-on-One J2EE Design and Development og J2EE without EJB. Sammen med den første bog publicerede han open source-kode, der illustrerede koncepter, som skulle gøre enterprise Java-udvikling nemmere.
Bøgerne var ikke skrevet på en teoretisk baggrund, men bundede i Rod Johnsons egne, ofte smertefulde erfaringer fra store J2EE-projekter, som han havde deltaget i siden slutningen af 1990'erne.
Læsere og udviklere verden over kunne lide, hvad de læste i bogen. Og koden, som Rod Johnson gjorde frit tilgængelig for alle interesserede, blev downloadet i stor stil.
Interessen og tilbagemeldingerne på open source-koden var så stor, at koden blev grundlaget for Spring-frameworket, som i dag anvendes i mange store organisationer.
Det har givet Rod Johnson, der nu er bosiddende i Californien, en betegnelse som manden, der reddede Java-platformen fra at ende som en stor, kompleks og uinteressant teknologiplatform.
Rod Johnson anvender ikke den slags betegnelser. Han foretrækker at tale om at simplificere udviklernes arbejde på Java-platformen.
Da Spring-frameworkets succes tog fart, snakkede Rod Johnson om at gøre Java-udvikling mere simpelt. Nu er det udvikling og udrulning af applikationer til produktionsmiljø, der skal være effektiv og simpel.
Teknisk samarbejde før salg til VMware
Her kommer salget af hans hjertensbarn SpringSource til VMware ind i billedet. Salget kom som en overraskelse for nogle brancheiagttagere, men ifølge Rod Johnson er det nærmest en naturlig udvikling.
"Vi har haft et teknisk samarbejde med VMware gennem et stykke tid. Vi arbejder sammen med VMware om deres vSphere platform. Det er en meget, meget interessant teknologi for cloud deployment. VMware har nogle meget værdifulde infrastruktur-aktiver, der kan bruges til at flytte applikationer til skyen. Så det er en meget naturlig integration," siger Rod Johnson.
Traditionelt datacenter forsvinder ikke i skyen
Selvom der i forbindelse med salget af SpringSource til VMware blev talt meget om cloud computing, lægger Rod Johnson vægt på, at det er det langsigtede perspektiv. På den korte bane handler det om udvikling og udrulning i mere traditionelt driftscentermiljø.
"Jeg vil gerne understrege, at selvom vi ser cloud computing som det næste store opbrud i it, så er det ikke kun cloud, vi er interesserede i. Vi ved, at den store majoritet af brugere fortsat vil gøre brug af traditionel applikationsudrulning. Derfor understøtter vi den traditionelle datacentermodel med SpringSource middleware. Så mens vi er begejstret for potentialet i cloud computing, glemmer vi ikke den daglige normale forretning," siger Rod Johnson.
Vejen mod en sammenhængende applikationscyklus
Den daglige normale forretning er siden etableringen af SpringSource i 2005 blevet udvidet fra at have fokuseret på udvikling til nu at dække hele livscyklussen fra udvikling over udrulning til produktion; eller
Build-Run-Manage, som SpringSource kalder det.
I starten af i år kom Manage-delen for alvor på plads, da SpringSource købte open surce-selskabet Hyperic, der specialiserede sig i drifts- og overvågningsløsninger.
Rod Johnson erkender, at Build-Run-Manage i dag er stærkest på Build-siden, men mener, at SpringSource kan levere den fulde end-to-end version i dag.
"Med SpringSource Tool Suit, Spring framework, Grails og Spring Roo til udrulning på tc server eller dm server og nu også potentiel cloud-udrulning ved hjælp af Cloud Foundry, synes jeg, at vi allerede demonstrerer end-to-end visionen. Nogle af delene er meget modne; Spring er meget moden, SpringSource Tool Suite er moden. Nogle er mindre modne, Cloud Foundry er stadig i tidlig beta," siger Rod Johnson.
Pæne tegninger er ikke bedre end kode
SpringSources Build-Run-Manage-filosofi kunne måske minde om Application Lifecycle Management (ALM) ,som blandt andre IBM via deres Rational-produkter taler om, ligesom Microsoft, Borland og andre spillere er inde på det område.
For Rod Johnson er det en forkert sammenligning.
"Application Lifecycle er nok et misbrugt ord. Vi er ikke på vej ind i det traditionelle ALM-markede. Vi sørger for løsninger, der hænger godt sammen, men du kan potentielt godt anvende forskellige værktøjer i eksempelvis udvikling. Vi gør ikke tingene som Rational Rose og den slags værktøjer, da vi er skeptiske over for den modeldrevne tilgang til udvikling," forklarer Rod Johnson og uddyber:
"Modeldrevet udvikling er baseret på den fejlagtige antagelse, at programmering er en forfærdelig ting, og det er noget, du skal undgå; det er bedre at tegne pæne diagrammer end at skrive kode. Det har vi aldrig troet på i SpringSource."
Open source-livscyklus - ikke Microsoft-monopolvejen
Noget andet, som Rod Johnson og kollegaerne i SpringSource heller ikke tror på, er, at kontrol af applikations-livscyklussen opnås ved at en leverandør står for alle værktøjer.
"Over tid forventer jeg at se en integration af de forskellige ellementer i livscyklussen som den operationelle udrulning, kildekode kontrol, integrationstest og så videre. Så processen kommer til at blive mere automatisk. Vi vil arbejde på sofistikerede workflows, så man kan udrulle applikationer og eventuelt rulle dem tilbage, hvis der er problemer med den netop udrullede version," siger Rod Johnson, der understreger, at processen skal være simpel for udvikleren.
"Vi mener, at den kan og skal være mere simpel. Hvis du ser historisk på Java, så er der fordele ved at se mere holistisk på tingene. På Javamarkedet havde vi en masse konkurrerende leverandører uden et holistisk syn på applicationslivscyklussen.
En måde at opnå et holistisk syn er at gå Microsoft-vejen og monopolisere et område. Men de seneste år har vi lært fra open source, at det er muligt at få en sammenhængende oplevelse uden et monopol. Hos SpringSource bygger vi på open source-komponenter, men vi sælger sammenhængen og den måde vi knytter komponenterne sammen," siger Rod Johnson.
Open source giver magt til udviklerne
Men risikerer den enkelte leverandør så ikke at miste kontrollen?
"Du mister noget kontrol. Vi har et stærkt lederskab indenfor Spring og Grails og vores værktøjsstrategi bygger på Eclipse. Vi kontrollerer servicedistributionen, management-teknologien og udrulning til cloud. Så vi føler, at vi har en del kontrol, men vi behøver ikke at binde kunderne til en teknologi."
Netop open sources fleksibilitet er vigtig, hvis softwarebranchen fremover skal udvikle sig, mener Rod Johnson.
"Open source har i stor udstrækning givet magten tilbage til udviklerne. Hvis der er en teknologi eller en platform som er utilfredsstillende, så er der en stor sandsynlighed for, at der er nogen, der har udviklet et alternativ," siger Rod Johnson.
Problemet med gammeldags J2EE
Det var netop open source i form af Spring frameworket og Hibernate, der var med til at redde J2EE, som ifølge Rod Johnson var på vej ind i en kompleksitetsmæssig blindgyde.
"Jeg brugte EJB (Enterprise Java Beans, red.) i stor stil fra 2000 til 2004. Det var ikke en særlig tilfredsstillende oplevelse. Det primære problem med EJB'er er den massive kompleksitet. Der er et antal implementeringsproblemer med EJB 1 og 2, hvilket betød, at teknologien ikke var særlig brugbar. Der var en række fundamentale fejl i konceptet bag teknologien. Selv EJB3, som har lånt nogle features fra Spring og fjernet noget af kompleksiteten, har jeg ærligt talt svært ved at forstå formålet med," siger Rod Johnson.
"Det eneste alternativ tilbage i 2000 var at bygge et framework for at skjule eller eliminere noget af kompleksiteten. Open source har beriget udviklingen enormt. Det giver en række muligheder for at reducere kompleksitet eller udstille fejlbehæftet teknologi," mener Rod Johnson.
A developer's got to do, what a developer's got to do
Vejen for open source ind i de store organisationer var dog ikke enkel.
Her sad metodeafdelinger og udstak retningslinjer, der ofte fulgte det officielle J2EE-dogme om, at EJB'er var den rigtige Enterprise-Java.
"Tilegnelsen af open source i enterprise java-markedet foregik ret ukontrolleret. Det var vanskeligt; hvis du skulle anvende EJB'er med entity beans og alting, så var du dømt til at fejle. Så virkeligheden var stort set, at udviklerne blev nødt til at anvende Spring og Hibernate, fordi det var den eneste måde, de kunne udføre deres job.
Så det blev et rent akademisk spørgsmål om, hvorvidt det var officielt godkendt eller ej. På det tidspunkt var platformen så død, at det var den eneste vej frem. Dogmet om at J2EE var den eneste vej frem, forhindrede ikke udviklere i at gøre, hvad de måtte gøre," vurderer Rod Johnson.
I dag er Spring frameworket selv blevet en udviklingsstandard i mange af de store organisationer, som er blandt SpringSources kunder.
Er der ikke en fare for, at den standardisering forhindrer andre open source-alternativer i at blive brugt til at løse problemer og dermed hæmme udviklingen?
"Der kan være en fare, nu da open source bliver brugt og i nogle tilfælde er ophøjet til corporate standard. Det er godt for Red Hat og SpringSource - det er fint med os - men for de mindre open source projekter, kan det være et problem. På den ene side er det godt for de store virksomheder at tænke strategisk om open source, på den anden side, vil det være en skam, hvis det fører til en bureaukratisk fastlåsthed," mener Rod Johnson.
Han er dog optimistisk og stoler på udviklernes dømmekraft.
"Open source har bemyndiget og bekræftet udviklerne, så de er mere villige til at træffe deres egne valg, de er mere kritiske over for teknologierne. Det er ikke kun et spørgsmål om corporate standarder."
VMware og Springsource: Kultursammenstød?
SpringSource har fra starten været baseret på open source, mens VMware har en mere leverandør-ejet tilgang til softwareudvikling, selvom virtualiseringsgiganten er begyndt at åbne mere op for kildekoden.
Er der ikke en risiko for et kultursammenstød, når de to virksomheder skal slås sammen?
"Nej. De fleste open source forretningsmodeller er i forvejen hybride modeller. Tag eksempelvis vores tc server. Den er baseret på Tomcat, så udvikling og udrulning er præcis det samme som ved Tomcat, men tc server inkluderer kode som kun er tilgængelig for vores abonnenter. Eksempelvis management-features og konsol-funktionerne.
Vores model er en hybrid model. Vi er baseret på open source, men vi har kode over og ved siden af open source, som vi sælger til vores kunder. Vmware er meget bevidste om, at de vil ødelægge SpringSource, hvis open source-miljøet ikke længere har tiltro til os. Jeg tror, at vores engagement i open source vil sprede sig til VMware og de vil lave flere open source-bidrag," svarer Rod Johnson.
Kodegenerering for folk der elsker at kode
Rod Johnson giver tre foredrag på JAOO-konferencen i næste måned. Hårdt presset vælger han at anbefale en af sine præsentationer frem for de to andre.
"Det er svært at vælge en fremfor de andre, men Extreme Java Productivity with Spring Roo and Spring 3.0 vil nok være interessant, da det er om teknologier som mange endnu ikke har set."
Java ROO: Forenklet Java
Hvad er Spring Roo?
"Det giver nogle af de samme fordele som Ruby on Rails har for Ruby og Grails giver til Java-platformen. Der er dog nogle udviklere som ikke har valget om at anvende Groovy (programmeringssproget i Grails, red.) eller de foretrækker bare Java. Det er den slags udviklere som Spring Roo er rettet imod.
Det er kodegenerering som det er i Ruby on Rails, hvor der genereres kode ud fra den kode, du selv har skrevet.
Det er ikke modelbaseret kodegenerering, hvor man går ud fra, at udviklere hader at skrive kode, hvilket er en fejltagelse.
Den bedste måde at beskrive det på er, at det er kodegenerering for folk som kan lide at kode. Med Spring Roo skriver du Java-kode, men det er en hurtigere og mere effektiv måde. Jeg er spændt på at høre hvad danske udviklere mener om det."
