Programmering

10 programvareutviklingsspådommer for 2018

Siddhartha Agarwal er visepresident, produktadministrasjon og strategi for Oracle Cloud Platform.

Utviklere bør være brennende av spenning over mulighetene framover i 2018, med produkter og verktøy rundt teknologier som blockchain, chatbots, serverløse funksjoner og maskinlæring som blir modne nok til virkelige prosjekter. Samtidig vil mange utviklere være bekymret for å holde presset mot å levere kode og funksjonalitet raskere uten å gå på bekostning av sikkerhet eller ytelse. Men det er også gode nyheter på den fronten.

For utviklere vil 2018 bli definert av denne spenningen mellom å gripe transformative nye muligheter mens de takler presset for å gjøre mer, med høyere kvalitet. Nedenfor er 10 spådommer relatert til hvordan disse styrkene vil spille seg ut i året som kommer.

1. B2B-transaksjoner som utnytter blockchain, går i produksjon

Bedrifter har begynt å forstå sikkerheten, påliteligheten og effektiviteten som kan oppnås ved transaksjoner med blockchain. Utviklere vil implementere mange blockchain-brukstilfeller på tvers av finansielle tjenester og produksjonskjeder i det kommende året. Blockchain er en teknologi som muliggjør effektive, sikre, uforanderlige, pålitelige transaksjoner blant organisasjoner som kanskje ikke helt stoler på hverandre, og eliminerer mellomledd.

Vurder et selskap som bestiller produkter fra en offshore-produsent. Disse produktene sendes via et rederi, kommer gjennom toll, gjennom et annet rederi og til slutt til kjøperen. I dag skjer bekreftelse og forsoning av hvert trinn for det meste via e-post og regneark, med mange mennesker og prosesser involvert. Blockchain eliminerer manuelle prosesser og forsoning ved uigenkallelig å registrere oppdateringer til blockchain-hovedboken når et minimum antall parter sier "Ja, denne delen av transaksjonen skjedde."

Blockchain-skytjenester vil gi skalerbarhet, spenst, sikkerhet og forhåndsbygde integrasjoner med bedriftssystemer, noe som gjør det mye enklere for utviklere å fokusere på forretningsbruk, i motsetning til underliggende implementering av hyperledger-stoff.

2. Chatbots har rutinemessige ekte samtaler med kunder og ansatte

Folk blir lei av å trenge flere mobilapper for å gjøre den samme jobben - som tre forskjellige flyselskapsapper med forskjellige måter å sjekke inn og få boardingkort på. En bedre måte er å tilby den samme funksjonaliteten, men via den mest populære appen på telefonen din - meldinger. Meldinger har tre attraktive elementer som er konsistente på tvers av mediet: øyeblikkelig, uttrykksfull og samtaler - ingen trening er nødvendig. Takket være fremskritt innen kunstig intelligens og naturlig språkbehandling, vil folk bruke Facebook Messenger, Slack, WeChat, WhatsApp eller en stemmeassistent som Amazon Alexa eller Google Home, for å stille spørsmål og få svar fra intelligente roboter.

Utviklere som bruker nye intelligente skytjenester for bot-bygging, kan raskt lage roboter som forstår kundens intensjon, opprettholder samtalestatus og reagerer intelligent samtidig som det er enkelt å integrere med back-end-systemer. Tenk deg å ta et bilde av en kjole du så i en film og sende meldinger til bildet til favorittbutikkens bot, som bruker bildegjenkjenning og AI for å anbefale lignende kjoler. Ansatte kan også være store mottakere av roboter for oppgaver som å spørre hvor mange feriedager de har igjen, arkivere en helpdesk-billett eller bestille en ny bærbar PC, der systemet til og med vet hvilke bærbare datamaskiner den ansatte er berettiget til og kan tilby statusoppdateringer på bestilling. Gitt at det er mye mer tilgivende å eksperimentere med din egen medarbeiderbase, kan utviklere først utnytte sine bot-building koteletter for å bygge og teste medarbeidervendte bots.

3. Knappen forsvinner: AI blir app-grensesnittet

AI blir brukergrensesnittet, noe som betyr at den synkrone modellen for forespørselsrespons for bruk av apper og tjenester forsvinner gradvis. Smarttelefoner er fortsatt "lav IQ", fordi du må hente dem, starte et program, be om noe som skal gjøres, og til slutt få svar. I en ny generasjon intelligente apper, vil appen starte interaksjoner via push-varsler. La oss ta dette et skritt videre der en app, bot eller en virtuell personlig assistent som bruker kunstig intelligens, vet hva de skal gjøre når, hvorfor, hvor og hvordan. Og bare gjør det. To eksempler:

  • Utgiftsgodkjenningsappen ser på mønsteret ditt for godkjenning av utgiftsrapporter, begynner å godkjenne 99 prosent av utgiftsrapportene automatisk og gjør bare oppmerksom på den sjeldne rapporten som krever oppmerksomhet.
  • Analytics-appen forstår de underliggende dataene, spørsmålene som er stilt så langt av bedriftsbrukeren, spørsmål som er stilt av det samme datasettet av andre brukere i selskapet, og gir hver dag en ny innsikt som analytikeren kanskje ikke hadde tenkt på. Når organisasjoner samler inn mer data, kan AI hjelpe oss med å lære hvilke spørsmål vi skal stille med dataene.

Utviklere må finne ut hvilke data som er veldig viktige for deres forretningsapplikasjon, hvordan de kan se og lære av transaksjoner, hvilke forretningsbeslutninger som mest vil ha nytte av denne typen proaktiv AI, og begynne å eksperimentere. Innebygd AI kan forutsi hva du trenger, levere informasjon og funksjonalitet via riktig medium til rett tid, inkludert før du trenger det, og automatisere mange oppgaver du gjør manuelt i dag.

4. Maskinlæring tar i bruk praktiske, domenespesifikke bruksområder

Maskinlæring beveger seg fra området obskure datavitenskap til vanlig applikasjonsutvikling, både på grunn av den tilgjengelige tilgjengeligheten av forhåndsbygde moduler på populære plattformer, og fordi den er så nyttig når man arbeider med analyse på tvers av store, historiske datasett. Med maskinlæring kommer den mest verdifulle innsikten med kontekst - hva du har gjort før, hvilke spørsmål du har stilt, hva andre mennesker gjør, hva som er vanlig versus avvikende aktivitet.

Men for å være effektiv, må maskinlæring innstilles og trenes i et domenespesifikt miljø som inkluderer både datasett den vil analysere og spørsmålene den vil svare på. For eksempel vil maskinlæringsapplikasjoner designet for å identifisere avvikende brukeratferd for en sikkerhetsanalytiker være veldig forskjellige fra maskinlæringsapplikasjoner designet for å optimalisere fabrikkrobotoperasjoner, som kan være veldig forskjellige fra de som er designet for å gjøre avhengighetskartlegging av en mikrotjenestebasert applikasjon.

Utviklere må bli mer kunnskapsrike om domenespesifikke brukstilfeller for å forstå hvilke data de skal samle inn, hvilke typer maskinlæringsalgoritmer som skal brukes, og hvilke spørsmål de skal stille. Utviklere må også vurdere om domenespesifikke SaaS eller pakkede applikasjoner passer godt for et gitt prosjekt, gitt at det kreves store mengder opplæringsdata.

Ved hjelp av maskinlæring kan utviklere bygge intelligente applikasjoner for å generere anbefalinger, forutsi resultater eller ta automatiserte beslutninger.

5. DevOps beveger seg mot NoOps

Vi er alle enige om at devops er kritisk viktig for å hjelpe utviklere med å bygge nye applikasjoner og funksjoner raskt, samtidig som de opprettholder høye nivåer av kvalitet og ytelse. Problemet med devops er at utviklere trenger å bruke 60 prosent av tiden sin på opsiden av ligningen, og dermed kutte inn i tiden som er viet til utvikling. Utviklere må integrere ulike verktøy for kontinuerlig integrering og kontinuerlig levering (CICD), opprettholde disse integrasjonene og kontinuerlig oppdatere CI / CD-verktøykjeden når nye teknologier slippes. Alle gjør CI, men ikke for mange mennesker gjør CD. Utviklere vil insistere på skytjenester for å hjelpe pendelen til å svinge tilbake til utviklingssiden i 2018. Det vil kreve mer automatisering for ekte CICD.

Docker gir deg emballasje, bærbarhet og muligheten til å gjøre smidige distribusjoner. Du trenger CD for å være en del av denne Docker-livssyklusen. For eksempel, hvis du bruker containere, så snart du foretar en kodeendring til Git, bør standard artefakt bygget være et Docker-bilde med den nye versjonen av koden. Videre skal bildet automatisk skyves inn i et Docker-register, og en container distribueres fra bildet til et dev-testmiljø. Etter QA-testing og distribusjon i produksjon, skal orkestrering, sikkerhet og skalering av containere tas vare på for deg. Bedriftsledere legger press på utviklere for å levere nye innovasjoner raskere; devops-modellen må frigjøre mer tid for utviklere å gjøre det mulig.

6. Open source som en tjeneste akselererer forbruket av open source-innovasjon

Open source-modellen er fortsatt en av de beste motorene for innovasjon, men å implementere og vedlikeholde den innovasjonen er ofte for komplisert. For eksempel:

  • Du vil ha en streaming data / event management platform, så du henvender deg til Kafka. Når du begynner å utnytte Kafka i stor skala, må du sette opp flere Kafka-noder og laste balanse store Kafka-klynger, oppdatere disse klyngene når nye utgivelser av Kafka kommer ut, og deretter integrere denne tjenesten med resten av miljøet ditt.
  • Du vil ha Kubernetes for orkestrering av containere. I stedet for å ta vare på oppgraderinger, sikkerhetskopier, gjenoppretting og oppdateringer for Kubernetes-klyngen, bør plattformen gjøre alt dette for deg. Kubernetes sendes hver sjette uke, så plattformen skal ha rullende distribusjoner og selvhelbredelse.
  • Du vil ha Cassandra for NoSQL-databaser. Du bør ønske at sikkerhetskopiering (trinnvis eller full etter planen), oppdatering, klynging, skalering og høy tilgjengelighet av Cassandra-klyngen skal administreres av plattformen.

Utviklere vil i økende grad se etter skytjenester for å levere all den høyhastighetsinnovasjonen fra åpen kildekode, mens de tar vare på drifts- og ledelsesaspekter av disse teknologiene.

7. Serverløse arkitekturer går stort i produksjon

Appellen til serverløse arkitekturer er tydelig: Når det er krav om at koden min skal kjøres basert på en bestemt hendelse, blir infrastrukturen instantiert, koden min distribueres og kjøres, og jeg belastes bare for den tiden koden min kjører. La oss si at du vil lage en reisebestillingsfunksjon for å bestille / kansellere flyreiser, hotell og leiebiler. Hver av disse handlingene kan bygges som en serverløs funksjon skrevet på forskjellige språk som Java, Ruby, JavaScript og Python. Det er ingen applikasjonsserver som kjører med koden min på; i stedet blir funksjonene instantiert og utført på infrastruktur bare når det er nødvendig.

For utviklere skaper nye serverløse funksjoner for å utføre komplekse transaksjoner nye utfordringer: å beskrive hvordan disse funksjonene skal lenkes sammen, feilsøke distribuerte transaksjoner og bestemme hvordan en feil i en kjede skal skape kompenserende transaksjoner for å avbryte upassende endringer. Se etter skytjenester og åpen kildekodeverktøy, som FN-prosjektet, for å blomstre ved å hjelpe utviklere med å enkelt administrere programmering, sammensetning, feilsøking og livssyklusadministrasjon av serverløse funksjoner, og til å distribuere og teste dem på en bærbar eller lokal server. eller hvilken som helst sky. Nøkkelen kommer til å være å velge en serverløs plattform som gir maksimal bærbarhet.

8. Det eneste spørsmålet om containere blir "Hvorfor ikke?"

Beholdere blir standard for dev / testarbeid og vanlig for produksjonsapplikasjoner. Forvent fortsatte forbedringer i sikkerhet, håndterbarhet, orkestrering, overvåking og feilsøking, drevet av innovasjoner med åpen kildekode og industristandarder. Beholdere er byggesteinene for mange av trendene som driver moderne utvikling, inkludert mikrotjenestearkitekturer, skyinnfødte apper, serverløse funksjoner og devops.

Beholdere gir ikke mening overalt - for eksempel når du trenger en mer forskriftsmessig skyplattform, for eksempel en integrasjon PaaS eller en mobil PaaS - men disse skytjenestene på høyere nivå vil selv kjøre på containere, og vil være unntakene som viser at regel.

I tillegg vil programvarelisensieringsmodeller for kommersiell programvare av høy verdi, måtte omfatte spredningen av adopsjon av containere. Prismodeller for programvare må støtte "slå på" og "slå av" lisensiering ettersom containere blir instantiert, oppskalert og nedskalert.

9. Programvare og systemer blir selvhelbredende, selvjusterende og selvadministrerende

Utviklere og produksjonsdriftsteam drukner inn data fra logger, overvåking av ytelse / nett / app / database og overvåking av brukeropplevelse og konfigurasjon. I tillegg blir disse forskjellige typene data lagt ut, så du må ta med mange mennesker inn i et rom for å feilsøke problemer. Så er det spørsmålet om kunnskapsoverføring: Utviklere bruker mye tid på å fortelle produksjonsinnsatsene for applikasjonene, hvilke terskler de skal sette, hvilke servertopologier de skal overvåke for en transaksjon, og så videre.