Monoloithic :
En monolithic application har en enkelt code base med flere moduler. Modulerne er udelt i application layer, bussiness logic laver og data acces layer.
Fordele :
- Simpelt at udvikle
- Simplet at teste, kan fx end to end testest ved brug af selenium
- Simplet at deploy. En package sal copires til serveren
- Simple ats cale horizontalt ved at sinne flere copier op bag en loadbalancer
- Continous deplyment er svært
Ulemper:
- Stor codebase gør det complikeret at forstå, især for nye tilkomende udviklere
- Scaling
- Overloaded IDE, stor kodebase kan gør en IDE lagsom, og kan sænke byg tiden drastisk
- Svært at skrifte teknologier, sprog eller framework. Couplingen er tæt og derfor svært at ændre på.
- Deployment kan være tidkrævende, data hele applicationen skal deployes hver gang
- Stor database forbrug
- Tæt coupling. Hvis en feature går i stykker falder hele programmet til jorden
Microservice
En microservices arkitektur er baseret på en samling af små selvstændige tjenester. Hver tjenste er selvstædning.
Fordele :
- Opdelingen af en application ind i små services gør det hurtigere at deploye og nemmere at forstå og opretholde.
- Hver services bliver udviklet uafhængig af andre services og udviklere kan derfor hurtigere blive ‘eksperter’ på denne services og evt. frameworks der bliver brugt.
- Gør det nemmere at indføre nye teknologier og eller skifte programmeringssprog på enkelte services.
- Gør continous deployment nemmere og hurtigere.
- Gør det muligt at scare hver services uafhængigt, hvis en service bliver brugt mere end de andre kan denne service blive tildelt flere resourcer.
Ulemper:
- Opdelingen af database kan kræve flere database opdateringer hvis en enkelt entitet bliver opdateret. Som bla. Persons adresse hvis andre services bruger denne infomation.
- Kan være komplekse af teste.
- Kan være problematisk at implementere ændringer der strækker sig over flere servies.
- Latency , microservices kan være langsommere hvis communication mellem services ikke er planlagt godt.
- Versioning, opdatering af en service må ikke ødelægge andre services der er afhænging af denne. Derfor kærver det god planlægning og design for at sikre sig dette ikke sker.