Cloud-native application design is set to become standard practice in the telecom industry in the near future due to the major efficiency gains it can provide, particularly in terms of speeding up software upgrades and releases. At Ericsson, we have been actively exploring the potential of cloud-native computing in the telecom industry since we joined the Cloud Native Computing Foundation (CNCF) a few years ago. This Ericsson Technology Review article explains the opportunities that CNCF technology has enabled, as well as unveiling key aspects of our application development framework, which is designed to help navigate the transition to a cloud-native approach. It also discusses the challenges that the large-scale reuse of open-source technology can raise, along with key strategies for how to mitigate them.

1. Cloud
native
Culture
OrganizationArchitecture
Automation
ERICSSON
TECHNOLOGY
CLOUD-NATIVE
APPLICATION
DESIGN
C H A R T I N G T H E F U T U R E O F I N N O V A T I O N | # 0 5 ∙ 2 0 1 9

2. ✱ CLOUD-NATIVE APPLICATION DESIGN
2 ERICSSON TECHNOLOGY REVIEW ✱ JUNE 5, 2019
Cloud-native application design is set to become common practice in the
telecom industry in the next few years due to the major efficiency gains that
it can provide, particularly in terms of speeding up software upgrades and
releases.
HENRIK SAAVEDRA
PERSSON,
HOSSEIN KASSAEI
The cloud-native paradigm is driving the
transformation of virtual network functions
into cloud-native applications (CNAs) that
can be commercialized and offered according
to either as-a-service (aaS) or as-a-product
(aaP) models. In either case, the goal is to
provide a seamless and secure deployment,
monitoring and operations experience by
applying a very high degree of automation.
■ Toeasethetransitiontothecloud-nativeapproach,
Ericssonhascreatedanapplicationdevelopment
frameworkthatprovidesasetofarchitecture
principles,designrulesandbestpracticesthatguide
thefundamentaldesigndecisionsforallofourCNAs.
Ourframeworkleveragesweb-scaletechnology
fromtheCloudNativeComputingFoundation
(CNCF)andotheropen-sourceprojectswhile
takingintoconsiderationtheparticularchallenges
ofproduction-gradetelecomapplications.
TheCNCFisanopen-sourcesoftwarefoundation
whosestatedpurposeistomakecloud-native
computing‘universalandsustainable.’Itfosters
collaborationbetweentheindustry’stopdevelopers,
endusers,andvendors,servingasthevendor-neutral
homeformanyofthefastest-growingprojectson
GitHub,includingKubernetes,Prometheusand
Envoy.CNCFtechnologyhasplayedanimportant
roleinoureffortstodevelopandrefineourapproach
toCNAdesign.
IN THE TELECOM DOMAIN
Cloud-native
application
design

3. CLOUD-NATIVE APPLICATION DESIGN ✱
JUNE 5, 2019 ✱ ERICSSON TECHNOLOGY REVIEW 3
Figure1illustratesthefourpillarsofthe
cloud-nativeparadigm.Ourframeworkaddresses
threeofthem:automation,architectureandculture.
Automationisanintegralpartoftheframework,
whichtakesaCI/CD(ContinuousIntegration,
ContinuousDelivery)approachtoapplication
developmentanddelivery.Architecturally,
theframeworkprovidesthesoftwareassets/
componentsthatenableapplicationstofulfillkey
designprinciples[1].Culturally,itpromotes
collaborationwiththeopen-sourcecommunity,
asusingandcontributingtotherelevantopen-
sourcesoftwareprojects(typicallywithinCNCF)
isattheheartofourimplementationstrategy.
Ourapplicationdevelopmentframework
Ourframeworkestablishesasetofprinciplesfor
telecomapplicationsbasedonmicroservices,
containersandstate-optimizeddesign.Itprovidesa
setofbestpractices,designrulesandguidelineson
Terms and abbreviations
AAP – As-a-Product | AAS – As-a-Service | ACID – Atomicity, Consistency, Isolation, and Durability |
CAP – Consistency, Availability and Partition Tolerance | CAT – Configuration Assessment Tool |
CI/CD&D – Continuous Integration, Continuous Delivery and Deployment | CIS – The Center for
Internet Security | CNA – Cloud-native Application | CNCF – Cloud Native Computing Foundation |
DR – Design Rule | ETSI – European Telecommunications Standards Institute | MSA – Microservice
Architecture | NIST – National Institute of Standards and Technology | UI – User Interface
Figure 1 The four pillars of the cloud-native paradigm
Cloud
native
Culture
OrganizationArchitecture
Automation

4. ✱ CLOUD-NATIVE APPLICATION DESIGN
4 ERICSSON TECHNOLOGY REVIEW ✱ JUNE 5, 2019
howtobuildCNAsbasedonmicroservicearchitecture
(MSA),aswellasguidanceonhowtodeploy,monitor
andoperatethembasedonDevOpsprinciples.
Withthesupportofourframework,itispossible
tobuildtelecomapplicationsthatuseCNCF
technologythroughahighlymodulararchitecture
andclearseparationofconcerns.Theframework
helpsusdrivealignmentacrossallEricssonCNAs,
ensuringthatweaddresskeyconcernsinacommon,
genericway.Theconsistentlife-cyclemanagement,
operationandmaintenancethatresultfromthis
approachenhancethecustomerexperience.
Figure2providesahigh-levelpictureofwhatthe
frameworkoffers.
Designingcloud-nativeapplications
EricssonCNAsarebuiltasasetoflooselycoupled
(micro)serviceswithwell-defined,boundedcontexts
andindividuallifecycles.Eachmicroserviceis
packagedanddeliveredasoneormorecontainers,
independentfromothermicroservices,andprovides
well-definedandversion-controlledapplication
programminginterfacesexposedoverthenetwork.
Toachievefullportabilityacrossvarious
infrastructures,CNAsrelyonKubernetesasthe
choiceofcontainerorchestrationplatformandcan
bedeployedonanycertifiedKubernetes
distribution[2]withaminimumversionadheringto
thecompany’ssecurityandstabilityrequirements.
AllEricssonCNAsarefullyverifiedonEricsson
Kubernetesdistribution.OurCNAsrelyon
Kubernetesfortheautomaticplacement,auto-
scaling,upgradeandauto-healingofindividual
services.OntopofmakinguseofKubernetes,we
alsocontributefeaturesbacktoKubernetesthat
makeitabetterfitfortelco-gradedeployments.IPv6
isjustoneexampleofanimportantareawithinthe
telecomdomainthathasnotyetreceivedenough
attentionwithinthecommunity.
Observability,securityandpersistence
ObservabilityisaprerequisiteforseamlessCNA
monitoringandoperations.TheCNCFlandscape[3]
includesseveralverygoodcandidatestohelpcollect,
Figure 2 Key components of Ericsson’s application development framework
Application-specific services
1
3
4
2
Application development & onboarding environment
Any hardware
Data
services
Security
services
Network
services
Management
services
Monitoring
services
Application
& service
management
Kubernetes-
based reference
container platform
Management
stack
Generic
services
Cloud
platform
Management &
orchestration
functionality for
services and
applications
Common (platform
type/generic)
services for reuse
across applications
Application &
service
development and
onboarding
environment, tools,
DRs and interface
to CI/CD
4
3
1
2
Any Kubernetes cloud platform

5. CLOUD-NATIVE APPLICATION DESIGN ✱
JUNE 5, 2019 ✱ ERICSSON TECHNOLOGY REVIEW 5
storeandvisualizelogs,metrics,tracesandother
datapoints,suchasPrometheus,Fluentd,Elastic
Stack,JaegerandGrafana.
Securityisavitalcomponentofcloud-native
development.Ontopofadheringtothebest
practicesandguidelinesprovidedbyprominent
organizationssuchasCIS(TheCenterforInternet
Security)andNIST(theNationalInstituteof
StandardsandTechnology),open-sourcesoftware
projectssuchasKeycloakandHashiCorpVaultcan
helpCNAsdealwithstorageandprovisioning,as
wellasthehandlingofidentities,certificatesandkeys.
Tobreakdownandimplementbusinesslogic
usingstatelessmicroservices,CNAstypicallyneed
torelyonstatefulbackingservicestostoretheirdata.
Thetypeofstatefulbackingservicethatisrequired
dependsonvariousfactors,suchasthetypeand
formatofthedata(suchasstructuredor
unstructured),theamountofdata,theintensity
ofreadandwriteoperations,CAPandACID
properties,andsoon.Amultitudeofopen-source
projectsaimstoaddresstheseneeds,including
databasetechnologiessuchasPostgreSQL,MariaDB,
Couchbase,Redis,MongoDB,Cassandra,MySQL
andHadoop.
ThedesignphilosophybehindEricssonCNAsis
tousepolyglotpersistence[4]whiletakinginto
accountthetotalfootprintandavoidingtechnology
sprawl.Achievingthelatterrequirestheidentification
ofthemostimportantpropertiesthatenable
classificationofdatabaseenginetypesintodistinct
groupsandadoptingaslightlyopinionatedapproach
inselectingoneorafewchoicesineachgroup.
ContinuousIntegration,ContinuousDelivery
andDeployment
Ourframeworkprovidestools,interfacesanddesign
rulesthatenablemicroservicestobenefitfromafully
automatedContinuousIntegration,Continuous
DeliveryandDeployment(CI/CD&D)pipeline,as
illustratedinFigure3.Thepipelineistriggeredfrom
themomentcodeiscommittedandtakesthenew
“candidaterelease”throughthefullcycleofbuild,
verification,packagingandrelease.Thedeployment
Figure 3 Fully automated CI/CD&D
Ericsson Customer
2
1
3
4
56
Software distribution
Continuous
releases
Continuous
integration
Software
upgrades
Acceptance
tests
Data collection
Feedback
0
Automated
software
distribution
Automated
acceptance
test
Automated
software
deployment
Automated data
collection and
analysis
Network CI
for ”systems
of systems”
Automated
release
machinery

6. ✱ CLOUD-NATIVE APPLICATION DESIGN
6 ERICSSON TECHNOLOGY REVIEW ✱ JUNE 5, 2019
phasewillbesomewhatdifferentforaaSandaaP
models.Togetthefullbenefitfromcloudnativeinan
aaPapproach,theend-to-endpipelineshouldbe
fullyautomated,connectingEricssonwiththe
customertoallowcontinuousfeedbackfromlive
deploymentstodevelopmentteams.
Softwarereuseandopen-sourceprojects
Whilethegoaloflarge-scalesoftwarereuseand
utilizationofopen-sourceprojectsexistedwell
beforetheemergenceofthecloud-nativeparadigm
andMSA,itismuchmorelikelytobeachievednow.
Thisisbecausecontainertechnologyisolatesthe
differentservicesfromeachothertoaveryhigh
degree.Insteadofbeingexposedtoallthe
dependenciesofeachservice,theexposureislimited
totheinterfaceneededbytheuseroftheservice.
Strictbackward-compatibilityoftheexposed
interfacesisrequiredtoachieveloosecouplingand
makeitpossibleforeachservicetoevolve
independently.Atthesametime,semantic
versioningontheinterfacescreatesacommonway
tocommunicatetheevolutionoftheinterfaces.
TheCNCFprovidesanewstartingpointwhen
lookingforreuseopportunitiesfromacloud-native
andMSAperspective.Itaddsvaluebycreatinga
structure,choosingrelevantopen-sourceprojects,
andensuringoverallqualityandcommunity
acceptance.Italsoprovidesacomprehensivemapof
potentialrealizationsfordifferentareas.
Keyarchitecturalaspectstoconsider
Makingtherightselectionbetweenthevarious
CNCFandotheropen-sourceprojectsthatare
availablerequiresaclearviewofthecontextandthe
kindofusecasesaselectedservicemustsupport.
Havingaclearlydefinedarchitecture–withset
goals,principles,designrulesandguidelines–is
moreimportantthaneverbeforeinthissituation
becauseithelpstodeterminethedifferentservice
andfunctionalneeds.
Followingthisapproach,itispossibleto
disconnectthedefinitionofwhichusecasesaretobe
providedforwithinaparticulararea(andwhat
additionalprincipleswouldapply)fromaparticular
realization.Thebenefitofthisisthatthearchitecture
itselfisnotcompromisedorinfluencedbytheneed
tosupportparticularusecases(ornot).Forexample,
inthecaseofservicemesh,thisapproachmakesit
possibletoidentifythecorefunctionalusecasesthat
wouldaddvaluetothearchitectureforCNAs,
withoutbeinginfluencedbyrealizationslikeIstio
andLinkerd.
Usingidentifiedusecaseswhenconsidering
differentpotentialrealizationsbothwithinand
outsideofCNCFenablesadirectcomparisonwhen
lookingatthecompliancetotheseusecases.This
approachallowsforreevaluationofprevious
selectionsforwhateverreason.Fromanarchitecture
evolutionperspective,itisequallyimportantto
updateidentifiedusecasesassoonasnewneeds
arise,whichmayinturnleadtoanewrealization
selection.
Separationofconcerns
Separationofconcernsisanimportantarchitectural
principlethatincreasesthepossibilitytoreuse
CNCFandotheropen-sourceprojectsevenforvery
domain-specificusecases.Inthiscontext,
separationofconcernsmeansthattheinternal
representationofthedatashouldbeseparatedfrom
externalrepresentation.Thisapproachmakesit
possibletoapplycloud-nativeapproachesinareas
thatweredrivenbypurelyproprietary
implementationsinthepast.
Demonstratingtheadditionalbenefitandthe
potentiallyricherfeaturesetofferedbythese
projectsprovidesanopportunitytoinfluenceand
evolveexpectationswithinthetelecomdomain.
TheongoingevolutionofONAP(theOpenNetwork
AutomationPlatform)andsupportforhighvolume
streamdatacollectionisoneexampleofthis.
EXPOSUREISLIMITEDTO
THEINTERFACENEEDEDBY
THEUSEROFTHESERVICE

7. CLOUD-NATIVE APPLICATION DESIGN ✱
JUNE 5, 2019 ✱ ERICSSON TECHNOLOGY REVIEW 7
Itisrareforout-of-the-boxsolutionsfromCNCF
andotheropen-sourceprojectstobesufficientto
meettheneedsofmanytelecom-specificusecases
relatedto3GPP,ETSIandothertelecom-defined
interfaces.Thereis,however,anobviousbenefitto
minimizingin-housedevelopmentoftheadditions
bybuildingthemasmodularservicesontopofan
availableopen-sourceproject,whenoneexistsinthe
relevantarea.Realizationsthatarerelativelygeneric
andprovidebackward-compatibleandversion-
controlledinterfacesarepreferredbecausethey
makeitpossibletobuildextensionsinafuture-proof
way.
Anexampleofthisapproachwouldbetochoose
Prometheusastheperformancemanagement
infrastructureanduseitsinterfacestoconsume
metricsandbuildadditionalsupporttoexpose
3GPP-compliantmetricreportfiles.
Thequestionofmaturity
Anotherimportantfactortoconsiderwhenselecting
anopen-sourceprojectismaturity.Thiscanbe
measuredintermsofthesizeoftheproject’s
communityandthenumberofreleasesithasthat
includebackward-compatiblechanges.Selectinga
matureprojectthatisfullycompliantwiththeuse
casesyouhaveinmindwouldmakeitpossibleto
takeapassiveroleintheproject,simplyusingthe
releasesastheybecomeavailableandfocusingon
buildinginternalcompetence.Choosingaless
matureprojectthatisnotfullycompliantwithyour
usecaseswouldrequireyoutoadoptanactiverolein
thecommunitytoinfluencebothhowbackward-
compatibilityismanagedandthedirectionoffeature
evolutioninthefuture.
Ineithercase,itshouldbenotedthatusingopen-
sourcesoftwareisnotfree–itisimportanttobuild
upinternalknowledgerelatedtothesoftware,
especiallyaroundtheneededusecases.Itisnotan
optiontobedependentonthecommunityforall
support-relatedquestions,particularlywhentaking
onanactiverole.
Beawarethat,duringtheprojectselection
process,itwilltypicallyonlybepossibletogeta
snapshotviewofhowtheprojecthandlesthecritical
issuesofbackward-compatibilityonexposed
interfacesandsemanticversioning.Whileaproject
withalongerhistoryshouldbeabletoprovidea
betterpicture,itstillmightnotbeabletooffera
completeone.Kafkaisanexampleofarelatively
matureprojectinwhichchangesthatbroke
backward-compatibility(accordingtoourdefinition)
wereannouncedasaminorupdateintherelease,
ratherthanamajorrelease.
Weighingintegrationpotential
againstbest-of-breed
Inseveralcases,open-sourceprojectshavebeen
createdwithaverydifferentcontextinmindthan
theoneinwhichtheyarelaterusedwithinadefined
architecture–particularlyintermsofdeployment
footprintandcharacteristicsaspects.Forexample,a
projectmaydecidetouseoneortwospecificdata
storesforpersistentdata,which,giventhebigger
pictureoftheCNAarchitecture,maynotbenatural
fits.
SometimesachoicelikethisismadewithanaaS
contextinmind,whereaserviceisdeployedonce
andreusedbyeveryone,asopposedtoanaaP
context,whereaCNAtypicallyneedstobemore
self-containedandprovideitsowninstancesofall
services.OneexampleofthisisHarbor,aproject
thathasanopinionatedselectionofbothdatastore
andingress.Inmanycases,thesesortsofissuescan
beaddressedbyconfigurationorinfluencingthe
project,butsometimestheyleadtoadifferent
selectionofrealization.
Aseachopen-sourceprojectistypically
independent,functionalityoverlapiscommon,
ITISIMPORTANTTOBUILD
UPINTERNALKNOWLEDGE
RELATEDTOTHESOFTWARE,
ESPECIALLYAROUNDTHE
NEEDEDUSECASES

8. ✱ CLOUD-NATIVE APPLICATION DESIGN
8 ERICSSON TECHNOLOGY REVIEW ✱ JUNE 5, 2019
andtherecansometimesbecontradictingviews
abouthowparticularproblemsshouldbesolved.
Whileeachprojectcantypicallyprovidevalue
withinthescopeitwasdesignedfor,thebroader
architecturalperspectiverequirestheprovisionof
end-to-endvaluewithoutcompromisingdefined
goalsandprinciples.Akeyaspectofthisisfiguring
outhowdifferentprojectscanbeintegratedand
usedincombinationtoprovidegreatervalue.
Inlightofthis,itisimportanttokeepinmindthat
eventhoughaspecificopen-sourceprojectmaybe
consideredbest-of-breed,itmightnotfitwellintothe
fullend-to-endvaluethatthelargerarchitecture
intendstoprovide.Inthiscase,itmightmakemore
sensetoselectalesscapableprojectthatisabetterfit
withtheoverallarchitecturalgoals.
Forexample,existingbest-of-breedprojects
wouldnotbetherightchoicetobuildacohesive,fully
integratedvisualizationsolutiontoprovideahigh-
levelviewofmicroservicesandtheirhealthstatus,
metrics,logs,distributedtracesandotherartifacts
neededformonitoringinaDevOpsteam.Bundling
best-of-breedstandaloneuserinterfaces(UIs)such
asGrafanaformetrics,Kibanaforlogs,aJaegerUI
fortracesandKubernetesUIforworkload
monitoringwouldresultinverypoorusabilityanda
sub-optimalexperienceforOpsteams.
Sharedresponsibilityforsecurity
Certainaspectsofsecurityareexpectedtobe
coveredbyopen-sourceprojects,whileothers
remainthefullresponsibilityofthedevelopment
organization.Forinstance,whenitcomesto
securingcommunication,thereistypicallyan
alignedapproachwithinboththeenterpriseand
telecomdomain.ThisiscenteredaroundTLSand
OAuth2,especiallylookingattheevolutionof3GPP,
whichismovingtoweb-scaletechnologyprotocols
likeHTTP/2.Whenthislevelofsecurityisnot
providedbytheopen-sourceproject,itistypically
seenasavalidevolutionoftheproject.Insome
scenarios,though,duetotimingorconflictbetween
freeandcommercialversionsoftheproject,the
mitigationistodeployaproxyinfrontoftheservice
toaddresssecurityaspects–albeitatthecostof
introducingadditionallatency.
Themodelforusingopen-sourcesoftwareisto
bringinthesourcecode–evenifpre-baked
containerimagesareprovidedbysomeprojects–
andbuildcontainerimages,includingtheselection
ofthebaseoperatingsystemimage.Becauseofthis,
securityhardeningmustbefullycontrolledbythe
team.TherearestandardtestingtoolssuchasCIS-
CAT(theCISconfigurationassessmenttool)that
helpteamsevaluatethequalityofthehardeningthey
haveperformed.Suchreportscanalsobeusedto
assurecustomersoftheoverallsecuritycompliance.
Keyorganizationalandculturalaspects
toconsider
Speedisthedrivingforceinthecloud-native
paradigm,whichmeansthatthegoalistostreamline
theworkprocessasmuchaspossible.Everytaskthat
cannotbeautomatedorcutoutinhibitsthe
organization’sabilitytobenefitfromthecloud-native
approach.Movingtothecloud-nativeparadigmand
makinguseofMSAisthereforemuchmorethanjust
atechnologicalchangeinhowsoftwareisbuilt.A
numberofimportantorganizationalandcultural
changesmusttakeplacetoachievethebenefits.
Acloud-nativedevelopmentorganizationisoften
structuredaroundarchitectureandprocesses.
Whentheneedtocreateaservicehasbeen
identified,asmallteamformstotakefull
responsibilityandaccountabilityforthatservice
acrossallstagesofthesoftwarelifecycle,according
toDevOpsprinciples.Thisstructurestandsinstark
contrasttothetraditionalone,inwhichbiggerteams
typicallyworkonlargersoftwareprojectsalongside
teamswithdedicatedresponsibilityforhorizontal
taskssuchasreleaseandcompliancehandling.
DIFFERENTPROJECTS
CANBEINTEGRATEDANDUSED
INCOMBINATIONTOPROVIDE
GREATERVALUE

9. CLOUD-NATIVE APPLICATION DESIGN ✱
JUNE 5, 2019 ✱ ERICSSON TECHNOLOGY REVIEW 9
Movingfromamoretraditionalsoftwarerelease
cycleofeverythreetosixmonthstomuchmore
frequentreleasesrequiresbothahigherlevelof
automationoftheprocessandareductioninthe
numberofactivities/tasksneededaspartofa
release.Inshort,anythingthatcanbeautomated
mustbeautomated,andafewtasks,suchastrade
compliance,thatcannotbeautomatedmustbe
simplified.
Buildingtrustandacceptance
Developersdonothavefullcontrolwhentheywork
withopen-sourcecode.Thiscanleadtotrustissues,
particularlyinorganizationsthathaveahistoryof
workingwithproprietaryimplementations.Even
whenthereisabuy-infromdevelopersonthe
decisiontouseopen-sourcecode,itisoften
necessarytobuildtrustandacceptancewithinthe
organizationforthefactthatopen-sourcecodecan
doasgoodajoboffulfillingrequirementsascode
thatisdevelopedin-house.
Thebestwaytobackupthedecisiontouseopen-
sourcecodeistodemonstratethatthereisasolid
selectionprocessinplacealongwithclearmapping
ofarchitectureusecases.Fromabusinesspointof
view,itisimportanttoemphasizethatthecostof
developingcommoditizedsoftwareissimplynot
justifiable:selectingopen-sourcesoftwarethat
meetsthecriteriatoasufficientdegreeispreferable
tocreatingsimilarsoftwarefromscratch.
Regardlessofwhetheraserviceisbasedonopen-
sourcecodeoraproprietaryimplementation,the
teamstructureandtheresponsibilitymustbethe
same.Constantvalidationoftheopen-source
projectiscrucialforearlydetectionofanypotential
issuesrelatingtobackward-compatibility.
In-housetalentiscrucialtothesuccessfuluseof
open-sourcecode.Internalcompetencebuildingis
asimportantforopen-sourcebasedworkasitisfor
proprietaryimplementations,bothfor
troubleshootingpurposesandtounderstand
evolutionneeds.
Conclusion
Cloud-nativeapplicationdesignwillsoonbecome
thetelecomdomain’snewstandardforthe
developmentofvirtualnetworkfunctions.Ericsson
iswellpreparedforthistransition,thankstoour
applicationdevelopmentframework,whichuses
cloud-nativeprinciples,microservicearchitecture
andseveralkeyenablingtechnologiessuchas
containersandKubernetes.
Tofullybenefitfromthecloud-nativeparadigm,
speedcannotbecompromised.Technologicaland
architecturalchangesarenotenough–transitioning
towardthecloud-nativeparadigmrequiresmajor
organizationalandculturalchangesaswell.
Achievingthenecessaryspeedrequiressmaller
teamsetupswithfullDevOpsresponsibilityand
(full)automationofanystepthatisrequiredaspart
ofthesoftwareCI/CD&Dandreleaseprocess.One
ofthemainorganizationalchallengesistogetthe
developerstoletgooffullcontrolandtrusttheuse
ofopensourceinareaswherein-housedevelopment
hasbeenusedinthepast.
TOFULLYBENEFIT
FROMTHECLOUD-NATIVE
PARADIGM,SPEEDCANNOT
BECOMPROMISED

10. ✱ CLOUD-NATIVE APPLICATION DESIGN
10 ERICSSON TECHNOLOGY REVIEW ✱ JUNE 5, 2019
Further reading
❭ CNCF, Sustaining and integrating open source technologies, available at: https://www.cncf.io/
References
1. Ericsson, Cloud-native applications, available at: https://www.ericsson.com/en/digital-services/trending/
cloud-native
2. CNCF, Certified Kubernetes, available at: https://www.cncf.io/certification/software-conformance/
3. GitHub, CNCF landscape, available at: https://github.com/cncf/landscape
4. Martinfowler.com, PolyglotPersistence, November 16, 2011, available at: https://martinfowler.com/bliki/
PolyglotPersistence.html
Henrik Saavedra
Persson
◆ is an expert at Business
Area Digital Services, where
he drives the common
cloud-native architecture
for the business area’s
virtual network functions
and applications in his role
as chief architect of the
application development
framework. He joined
Ericsson in 2004 and
has worked in R&D with
architecture for both
applications and platform
products. Saavedra Persson
holds an M.Sc. in software
engineering from Blekinge
Institute of Technology in
Sweden.
Hossein Kassaei
◆ is a technology specialist
in cloud computing and
MSA within Business Area
Digital Services, where he
has worked on common
platforms and application
architectures for the past
five years. He joined Ericsson
in 2010 and has worked in
various roles within R&D
from developer, to software
designer, to architect and
DevOps lead. He holds an
M.Sc. in computer science
from Concordia University in
Montreal, Canada.
theauthors
Theauthorswould
liketothank
MarioAngelic
forhiscontribution
tothisarticle.

11. ISSN 0014-0171
284 23-3329 | Uen
© Ericsson AB 2019
Ericsson
SE-164 83 Stockholm, Sweden
Phone: +46 10 719 0000