NDC i Oslo er alltid et av årets høydepunkter som utvikler i Norge. I år er intet unntak. Programmet er innholdsrikt og variert, og som alltid er det vanskelig å velge hva man skal gå på. Under er korte sammendrag av sesjonene vi valgte oss ut. Vi kommer garantert til å se en del flere som video når de blir lagt ut senere.

Versions Are Evil - Sebastien Lambla

Versjonering blir brukt for endringskontroll. Målet er å ikke bryte eksisterende klienter. Flere versjoner muliggjør endring av klient og server hver for seg. Versjonen er også et godt utgangspunkt for dokumentasjon og kan brukes for kommunisere endringer med andre utviklere.

Hvordan kan vi få fordelene ved versjonering uten å faktisk lage nye versjoner?

En vanlig versjoneringsstrategi er å slenge på en versjonsslug som en del av API-adressen eller domenet. Dermed får klientene flere URI-er å forholde seg til. Det er krevende å vedlikeholde flere versjoner av API-et samtidig, så dersom man bruker en gammel versjon av API-et, vær forberedt på endring. Eksempel fra Github som er på versjon 3 av sitt API, klienter mot de to tidligere versjonene fungere ikke lenger. Dersom de ikke blir oppdatert, vil de aldri igjen funke. Dermed har en sterk kobling mellom klienten og API-et den konsumerer.

Løsningen er å bruke versjonering sjeldnere, men å endre API-et på en kontrollert måte. Noen enkle (på papiret) teknikker kan brukes:

  • Bakoverkompatabilitet: en nyere versjon av systemet skal fortsatt fungere med input generert av en eldre versjon av systemet.
  • Framoverkompatabilitet: en eldre versjon av systemet forstår input fra en nyere versjon av systemet ved å ignorere det den ikke forstår.
  • Don’t Validate Schemas: Valider kun det systemet trenger for å gjennomføre sin businesslogikk.

Ikke bryt APIet kun av kosmetiske grunner. Dårlige navn er ofte mindre kostbart enn brytende endringer.

Selv om man lager levende API-er, trenger man en måte å fjerne gammel kode på en kontrollert måte. Dersom man bare legger til, fører det til for store og tunge kodebaser. Et eksempel fra nettleserverdenen er å telle hvor ofte de forskjellige versjonene av HTML-standarden blir brukt. Dette kan samles opp sentralt, og etter en stund får man god data på bruksmønstrene . Etter hvert som eldre versjoner faller i popularitet, blir det til slutt veldig billig å slette bitene som ikke lenger brukes. Dette kan videreføres til alle API-er, så lenge man lager telemetri. Telemetri er uansett en god idè, så enklere migrering er en bonus.

Konklusjon

Versjonering må brukes varsomt og gjennomtenkt. Det løser en del problemer, men kommer med en kostnad. Flere teknikker kan benyttes for å utsette versjonering så lenge som mulig.

The Sane Way to Build Cloud Infrastructure - Paul Stack

For en gangs skyld en Ops-rettet talk som ikke dreide seg om containerteknologi!

Snowflake Servers

De fleste produksjonsservere har fram til nå blitt behandlet som snøflak. Alle er forskjellige og får forskjellig behandling, inkludert sin helt egen identitet. Jo mere tid man har sunket ned i hver enkelt server, jo verre er det å bli kvitt den. Produksjonsservere får sine egne navn og mange systemadministratorer trykker dem tett til sine bryst som om serveren var hans eget barn: Han har jo tross alt installert og tatt vare på boksen for hånd og sørget for årevis med oppetid på serveren! Dette må vi slutte med. Langtlevende servere med sin egen identitet fører til klare forskjeller mellom forskjellige miljø. Databaseserveren i test blir aldri lik den som er i produksjon, den lange oppetiden fører til sikkerhetshull, mens oppdateringer og patcher fort kan føre til ustabilitet og uforutsette feil.

Phoenix servers

Alternativet til det unike snøflaket er Fugl Føniks: en fugl som står opp fra sin egen aske helt identisk med slik den var før den døde. Ved å fokusere på imutabel infrastruktur og configuration management verktøy som Ansible, Chef eller Puppet kan vi skreddersy roller serverne våre skal ha, som sikrer repetitiv oppførsel for hver gang en eller flere servere spinnes opp. En servers særegne identitet blir borte - klonene regjerer.

Terraform

Verktøyet Terraform fra HashiCorp lar utviklere selv designe skymiljø med serverinstanser og nettverk, alt ved hjelp av kode. Infrastruktur i kodeform betyr blant annet mulighet for kildekodekontroll: serveroppsettet ditt kan nå befinne seg i Git, vegg i vegg med applikasjonskoden din. Med infrastruktur som kode kan også utviklere bruke mange av mønstrene de kjenner fra tradisjonell systemutvikling når de beskriver miljøene sine. Med Terraform sikrer man liket på tvers av miljøet: blir en instans tuklet med eller forrandret, vil Terraform gripe inn og reversere endringene til en kjent normalform.

Tips og triks ved bruk av Configuration Management

  • Respekter prosessen! Ikke gjør manuelle endringer på kjørende miljø!
  • Ikke la infrastrukturen begrense applikasjonen din!
  • Har du konfigurert miljøet ditt slik at du på en demo kan ta ned flere instanser av applikasjonen din, er miljøet designet godt.
  • Bruk gode abstraksjoner! Amazon og Azure har forskjeller på detaljenivå men gjør i bunn og grunn den samme jobben. Abstraher ut grunnfunksjonaliteten!

Konklusjon

Ved bruk av skytjenester vil for mye manuell behandling av kjøremiljøet og hver enkelt server til slutt koste organisasjonen utrolig dyrt. Automatiser oppsettet så langt det lar seg gjøre, skap gjenbrukbare konfigurasjoner som gjør at tap av instanser blir forventet. Ha som mål at instanser skal dø ofte.

Building ASP.NET Core Kestrel - David Fowler and Damian Edwards

or how to do .Net really, really fast but make your head really, really hurt.

ASP.Net har funnet Web Framework Benchmarks og bestemt seg for ikke lenger å ligge i bunnsjiktet. Det betydde hardkjerne ytelsesoptimalisering i .Net koden.

God ytelse i .Net handler mye om å unngå GC-er (Garbage Collections). Det er to måter å gjøre dette på:

  1. Ha veldig grunn og enkel minnegraf slik at GC går veldig raskt når den faktisk skjer
  2. Alloker minnet du trenger og gjenbruk det underveis slik at minnetrykket blir konstant under prosessens levetid. Dermed trenges færre GC-er

For ASP.Net-teamet betydde dette:

  • Håndter ditt eget minne (MemoryPool). Ikke kopier eller lag data unødig, how dare you use memcpy?
  • Gjenbruk kjente strenger, string kan være dyrt. Strenger er tross alt bare bytes med en enkoding.
  • Bruk data som kommer inn så fort som mulig.

Når det du måler ofte blir ferdig på et mikrosekund, teller hvert eneste nanosekund. Da betyr også konstantleddet i algoritmer mye, ikke bare asymptotisk kompleksitet.

Bruk av MemoryPool

Egen minnehåndtering

Egen awaiter for å effektivisere lesing

Egen awaiter

Gjenbruk strenger

Ved å unngå å representere strenger som strenger, kan man benytte CPU-en på en mer effektiv måte. Dette gjør koden mye mer komplisert, så her må man vurdere kost-nytte. For ASP.Net-teamet var det verdt det siden antallet forespørsler er så høyt.

Gjenbruk strenger

Vektorisering for moro og profitt:

Vektorisering

Galskapen gir bedre standardavvik og er faktisk verdt det for store n (sammen med andre mikrooptimaliseringer):

Vektorisering

Konklusjon

Når man optimalisering for ytelse, ofrer man ofte lesbarheten til koden. Dermed er det viktig å ha et ytelsesmål i tankene før man begynner, slik at kodekvaliteten ikke lider unødig. De mer avanserte ytelsestriksene krever god kunnskap til både språk, rammeverk og maskinvaren koden skal kjøres på. Profiler i et så produksjonslikt miljø som mulig slik at resultatene blir realistiske.

5 000 000 forespørsler pr sekund er målet til ASP.Net, men de er nok ikke fornøyd med det så lenge andre fremdeles er raskere.