Ericsson Technology Review: Cloud-native application design in the telecom domain Cloud-native application design is set to become common practice

Ericsson Technology Review: Cloud-native application design in the telecom domain Cloud-native application design is set to become common practice
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
✱ 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
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
✱ 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
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
✱ 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
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
✱ 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
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
✱ 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.
ISSN 0014-0171 284 23-3329 | Uen © Ericsson AB 2019 Ericsson SE-164 83 Stockholm, Sweden Phone: +46 10 719 0000

Ericsson Technology Review: Cloud-native application design in the telecom domain Cloud-native application design is set to become common practice

Ericsson Technology Review: Cloud-native application design in the telecom domain Cloud-native application design is set to become common practice

Recommandé

Contenu connexe

Présentations pour vous(20)

Similaire à Ericsson Technology Review: Cloud-native application design in the telecom domain Cloud-native application design is set to become common practice(20)

Plus de Ericsson(12)

Dernier(20)

Ericsson Technology Review: Cloud-native application design in the telecom domain Cloud-native application design is set to become common practice