Embed Size (px)
Citation preview
Cloud Native Computing
CloudNative.guide
The Future of EnterpriseSoftware Development
Net�ix – Exemplar blueprint for CloudNative Computing
The uber poster child of migrating legacyapplications and IT systems to a modular, highfrequency agile ‘Cloud Native’ approach is Net�ix.
Not only do they share their bestpractices via blogs, they also share thesoftware they’ve created to make itpossible via open source. You too canBuild Code Like Net�ix, literally.
In this video the chief architect behindthis digital transformation, AdrianCockcroft, shares his experiences of theNet�ix journey to the Cloud.
In a VentureBeat article the authorenvisions ‘the future of enterprise tech’.
They describe how pioneeringorganizations like Net�ix are entirelyembracing a Cloud paradigm for theirbusiness, moving away from thetraditional approach of owning andoperating your own data centrepopulated by the likes of EMC, Oracleand VMware.
Instead they are moving to ‘web scale IT’via on demand rental of containers,commodity hardware and NoSQLdatabases, but critically it’s not justabout swapping out the infrastructurecomponents. By further embracingsoftware architecture principles likeMicroservices and high frequencyContinuous Deployment practices anorganization can go fully Cloud Native.
Cloud Migration BestPracticesFirst we can examine their transitionfrom their legacy IT estate to the Cloud.
In this blog they focus on the migrationof the core Net�ix billing systems fromtheir own data centre to AWS, and fromOracle to a Cassandra / MySQLcombination, emphasizing in particularthe scale and complexity of thisdatabase migration part of the CloudMigration journey.
This initial quote from the Net�ix blogsets the scene accordingly:
Net�ix – Exemplar blueprint for Cloud Native Computing
Net�ix – Exemplar blueprint for CloudNative Computing
On January 4, 2016, right beforeNet�ix expanded itself into 130new countries, Net�ix Billinginfrastructure became 100%AWS cloud-native.
They also reference a previous blog alsodescribing this overall AWS journey,again quickly making the most incisivepoint – this time describing the primaryin�ection point in CIO decision makingthat this shift represents, a move to‘Web Scale IT‘:
That is when we realized that wehad to move away from verticallyscaled single points of failure,like relational databases in ourdatacenter, towards highlyreliable, horizontally scalable,distributed systems in the cloud.
Migrating Mission-critical Systems
They then go on to explain theirexperiences of a complex migration ofhighly sensitive, operational customersystems from their own data centre toAWS.
As you might imagine the core customerbilling systems are the backbone of adigital delivery business like Net�ix,handling everything from billingtransactions through reporting feeds forSOX compliance, and face a ‘change thetyre while the car is still moving’challenge of keeping front-facingsystems available and consistent toensure unbroken service for a globallyexpanding audience, while conducting abackground process of migratingterabytes of data from on-site enterprisedatabases into the AWS service.
Net�ix – Exemplar blueprint for Cloud Native Computing
Net�ix – Exemplar blueprint for CloudNative Computing
We had billions of rows of data,constantly changing and composedof all the historical data sinceNet�ix’s inception in 1997. It wasgrowing every single minute in ourlarge shared database on Oracle.To move all this data over to AWS,we needed to �rst transport andsynchronize the data in real time,into a double digit Terabyte RDBMSin cloud. Being a SOX system added anotherlayer of complexity, since all themigration and tooling needed toadhere to our SOX processes. Net�ix was launching in many newcountries and marching towardsbeing global soon. Billing migration needed to happenwithout adversely impacting otherteams that were busy with theirown migration and global launchmilestones.”
The scope of data migration and thereal-time requirements highlight thechallenging nature of Cloud Migrations,and how it goes far beyond a simple liftand shift of an application from oneoperating environment to another.
DatabaseModernizationThe backbone of the challenge was howmuch code and data was interactingwith Oracle, and so their goal was to‘disintegrate’ that dependency into aservices based architecture.
“Moving a database needs its ownstrategic planning:
Net�ix – Exemplar blueprint for Cloud Native Computing
Net�ix – Exemplar blueprint for CloudNative Computing
Database movement needs to beplanned out while keeping the end goalin sight, or else it can go very wrong.There are many decisions to be made,from storage prediction to absorbing atleast a year’s worth of growth in datathat translates into number of instancesneeded, licensing costs for bothproduction and test environments,using RDS services vs. managing largerEC2 instances, ensuring that databasearchitecture can address scalability,availability and reliability of data.Creating disaster recovery plan,planning minimal migration downtimepossible and the list goes on. As part ofthis migration, we decided to migratefrom licenced Oracle to open sourceMYSQL database running on Net�ixmanaged EC2 instances.”
Overall this transformation scope andexercise included:
1. APIs and Integrations – The legacybilling systems ran via batch jobupdates, integrating messagingupdates from services such as giftcards, and billing APIs are alsofundamental to customerwork�ows such as signups,cancellations or address changes.
2. Globalization – Some of the APIsneeded to be multi-region andhighly available, so data was splitinto multiple Cassandra datastores. A data migration tool waswritten that transformed memberbilling attributes spread acrossmany tables in oracle into a muchsmaller Cassandra structure.
3. ACID – Payment processing neededACID transaction, and so wasmigrated to MySQL. Net�ix workedwith the AWS team to develop amulti-region, scalable architecturefor their MySQL master with DRBDcopy and multiple read replicasavailable in di�erent regions, withtoolingn and alerts for MySQLinstances to ensure monitoring andrecovery as needed.
Net�ix – Exemplar blueprint for Cloud Native Computing
Net�ix – Exemplar blueprint for CloudNative Computing
4. Data / Code Purging – To optimizehow much data needed migrated,the team conducted a review withbusiness teams to identify whatdata was still actually live, and fromthat review purged manyunnecessary and obsolete datasets. As part of this housekeepingobsolete code was also identi�edand removed.
A headline challenge was the real-timeaspect, ‘changing the tyre of the movingcar’, migrating data to MySQL that isconstantly changing. This was achievedthrough Oracle GoldenGate, whichcould replicate their tables acrossheterogeneous databases, along withongoing incremental changes. It took aheavy testing period of two months tocomplete the migration via thisapproach.
Downtime SwitchoverDowntime was needed for this scale ofdata migration, and to mitigate impactfor users Net�ix employed an approachof ‘decoupling user facing �ows toshield customer experience fromdowntimes or other migration impacts’.
All of their tooling was built aroundability to migrate a country at a timeand funnel tra�c as needed. Theyworked with ecommerce andmembership services to changeintegration in user work�ows to anasynchronous model, building retrycapabilities to rerun failed processingand repeat as needed.
An absolute requirement was SOXCompliance, and for this Net�ix madeuse of components available in theirOSS open source suite.
“Our Cloud deployment tool Spinnakerwas enhanced to capture details ofdeployment and pipe events to Chronosand our Big Data Platform forauditability. We needed to enhanceCassandra client for authentication andauditable actions. We wrote new alertsusing Atlas that would help us inmonitoring our applications and data inthe Cloud.”
Building HA, GloballyDistributed CloudApplications with AWS
Net�ix – Exemplar blueprint for Cloud Native Computing
Net�ix – Exemplar blueprint for CloudNative Computing
Net�ix provides a detailed, repeatablebest practice case study forimplementing AWS Cloud services, at anextremely large scale, and so is an idealbaseline candidate for any enterpriseorganization considering the same typesof scale challenges, especially with anemphasis on HA – High Availability.
Two Net�ix presentations: GloballyDistributed Cloud Applications, andFrom Clouds to Roots provide a broadand deep review of their overall globalarchitecture approach, in terms ofexploiting AWS with the largest andmost demanding of of capacity andgrowth requirements, such as hostingtens of thousands of virtual serverinstances to operate the Net�ix service,auto-scaling by 3k/day.
This goes into a granular level of detailof how they monitor performance, andthen additionally in they focusspeci�cally on High AvailabilityArchitecture, providing a broad anddeep blueprint for this scenariorequirements.
Migration is only the �rst step of thejourney. Net�ix has achieved theirmassive global growth because they areinnovating continuously, meaning thatthey must be continually updating andchanging their digital business systems.
This introduces the role of ContinuousDeployment best practices, and howone of their modules ‘Spinnaker‘ iscentral to this.
In this blog Global Continuous DeliveryWith Spinnaker they explain how itaddresses this scope of the codedevelopment lifecycle, across globalteams, and forms the backbone of theirDevOps ‘toolchain’, integrating withother tools such as Git, Nebula, Jenkinsand Bakery.
As they describe:
Net�ix – Exemplar blueprint for Cloud Native Computing
Net�ix – Exemplar blueprint for CloudNative Computing
Spinnaker is an open sourcemulti-cloud Continuous Deliveryplatform for releasing softwarechanges with high velocity andcon�dence. Spinnaker isdesigned with pluggability inmind; the platform aims to makeit easy to extend and enhancecloud deployment models.
Their own quoted inspirations includeJez Humble’s blog and book onContinuous Delivery, as well as expertssuch as Martin Fowler and workingideals such as ‘Blue GreenDeployments‘.
Moving from AsgardTheir history leading up to theconception and deployment ofSpinnaker is helpful reading too;previously they utilized a tool called‘Asgard’, and in Moving from Asgard:,describe the limitations they reachedusing that type of tool, and how insteadthey sought a new tool that couldachieve:
“enable repeatable automateddeployments captured as �exiblepipelines and con�gurable pipelinestages provide a global view across all theenvironments that an applicationpasses through in its deploymentpipeline o�er programmatic con�gurationand execution via a consistent andreliable API be easy to con�gure, maintain, andextend”
These requirements formed intoSpinnaker and the deployment practicesthey describe, which you can repeatthrough the Github Download.
MicroservicesThe third Cloud Native foundationcomponent is a microservices softwarearchitecture and again there are awealth of resources to learn from.
Net�ix – Exemplar blueprint for Cloud Native Computing
Net�ix – Exemplar blueprint for CloudNative Computing
In the past, architects tried to designevery aspect of a software. Applicationswere supposed to work like perfectmachines. The microservices approachto software development is moreorganic. Instead of trying to controlevery aspect of a complex system,architects try to set up rules to make afunctioning organism. DevOps toolsplay an important role in thisecosystem. These tools help multipleteams work with each other seamlessly.The process results in healthy, �exibleand scalable software.
Net�ix OSS is a great place for anyDevOps team to get an idea of thevariety of tools that Net�ix uses to runits massive microservice-basedapplications.
Matias De Santi of Wolox describes howmicroservices can make use of AWSservices like their API Gateway andRisingStack o�ers this article DeployingNode.js Microservices to AWS usingDocker.
Build and Delivery Tools: Net�ixhas a collection of Gradle pluginscalled Nebula that helpsdevelopment teams createrepeatable builds. It helps savetime during development. TheAminator tool packages AMIs forAWS. Spinnaker is Net�ix’scontinuous delivery platform thatmakes its complex microservicesdeployment possible. Common Runtime Services andLibraries: Eureka is Net�ix’s servicediscovery tool. The applicationRibbon helps with servicecommunications. Hystrix helpsisolate latency and fault toleranceat runtime. Data Persistence: Net�ix’s EVCacheand Dynomite are importantinnovations that help microservicesuse Memcached and Redis at scale.
Net�ix – Exemplar blueprint for Cloud Native Computing
Net�ix – Exemplar blueprint for CloudNative Computing
Insight, Reliability, andPerformance: Net�ix has developeda lot of tools to collect metrics andautomatically address problems.But Chaos Monkey and SimianArmy are its most famous reliabilitytools. These tools help Net�ix testinstances with random failures. Theabove discussion touches only ahandful of options. The Net�ix OSSpage has a list of all the availableopen source tools that can helpDevOps practices.
This 2016 AWS Summit presentationprovides a comprehensive overviewincluding the broader context of how it�ts within this DevOps framework. Theirwhite paper provides a detailed reviewand this presentation dives more intothe technical details and o�ers anumber of implementation patterns:
Anyone can implement a microservicesarchitecture on AWS with a simpleElastic Load Balancer, a few EC2instances and a datastore like AmazonRDS or DynamoDB. The EC2 instancescan be used for deployingmicroservices. However, depending onthe size of the service, this can be anexpensive choice. Here some otherAmazon tools that can help withmicroservices:
AWS Elastic Beanstalk – Thisorchestration service makesmicroservices deployment easier. Amazon Elastic Container Service(ECS) – Containers have becomepart of the microservices culture.Amazon’s ECS helps makesscheduling of containers more�exible. Amazon API Gateway and AWSLambda – Serverless computing isgaining popularity. By combiningAmazon API Gateway and AWSLambda, it’s possible to create amicroservices application thatwouldn’t require any form ofinfrastructure management fromthe development team.
Net�ix – Exemplar blueprint for Cloud Native Computing
Werner Vogels : The Enterprise Journey toServerless Microservices
In the AWS Summit 2019 keynotepresentation, from 19:45, Dr. WernerVogels describes the evolution ofenterprise IT towards Cloud Nativecomputing.
Referencing Amazon.com and AWScustomer examples, CTO Werner Vogelsexplains the shift from monolithenterprise software to a Serverless andMicroservices model, walking throughhow to build such an architecture onAWS services.
AWS – The Era ofCloud BuildersSetting the scene Werner states AWS setout to achieve for IT what Amazon.comachieved for e-commerce, to be entirelycustomer-driven where the customersare entirely in control of the productroadmap and economic cost model.
They have massively disrupted thetraditional vendor supply chain, nowo�ering over 165 di�erent Cloudservices across DevOps, Blockchain, MLand more.
The Cloud has transformed how IT isdelivered and costed, citing S3 GlacierDeep Archive storage as an exampleand that it is now generally available,describing a use case such as a hospitalstoring MRI and cat scan images, thathave a regulatory requirement to keepthem for 30 years.
No cost e�ective storage options wereavailable but now the Cloud hascommoditized this resource to such anextent they can easily make use of nearin�nite levels of storage for a fraction ofthe previous costs.
Overall the evolution is one frommoving from traditional vendormonolith applications, where you adaptyour business model to theirfunctionality, to one of an era of CloudBuilders – The ability to plug and play anumber of di�erent Cloud services, theright tool for each job, together into thesolution you need.
Werner Vogels : The Enterprise Journey to Serverless Microservices
Werner Vogels : The Enterprise Journey toServerless Microservices
Monolith toMicroservices: Lessonslearned fromAmazon.comAt Amazon.com they faced the samescaling challenges as their enterprisecustomers, and to address them theyadopted a number of practices nowknown as DevOps and Microservices.
He describes S3 as one of their ownexamples, evolving it from eight simpleMicroservices to now over 235distributed Microservices.
From 31:15 he explains the essentialdynamics of re-engineering monolithsoftware to Microservices, highlightingthat each Microservice has very di�erentscaling and reliability requirements.
Therefore to most e�ectively design asuitable Microservices architecture thebest approach is to undertake afunctional decomposition, like in theircase to identify di�erent services suchas a customer login and an addressbook service.
One is used infrequently while the otheris accessed repeatedly, and so thewhole component needs to scale to thelevel of just one small service. Similarlythe whole component has access toboth the credential store and also theaddress book store, a violation ofsecurity policies.
Therefore the re-engineering process isone of decomposing down to a level ofthe smallest possible building blocks foreach service and then have them scaleindependently, so that a service likelogin can utilize all the resource it needswithout impact on the whole site.
Containers andMicroservices
Werner Vogels : The Enterprise Journey to Serverless Microservices
Werner Vogels : The Enterprise Journey toServerless Microservices
From 35:25 Verner states that containersare an essential technology forimplementing Microservices.
Highlighting McDonalds as one exampleof an enterprise customer using thisapproach, he describes how they built anew home delivery service using ECS tobuild a microservices application. Theuse of an API architecture enabled themto integrate with partners like Uber Eats.
From 37:00 Werner walks through thedecision process to design yourMicroservices container environment –You can choose between ECS or ECS forKubernetes at the orchestration level,and at the compute level you canmanage your own clusters on EC2 oruse Fargate, which turns it into aServerless container service, eliminatingthe need to manage infrastructure at all.
Learn more: Building Microservices withContainers
ServerlessMicroservices
From 41:00 Werner describes theadoption of these products asa continuing abstraction of softwaredevelopment, a journey movingupwards from IaaS instances throughcontainers to Lambda, the AWSServerless layer.
He highlights that the Cloud �rstcustomers of today who are starting outto build an entirely new service are nowdoing so on Serverless, as they can becompletely freed from the hassles ofmanaging the underlying infrastructureand can instead immediately just focuson adding value and building newbusiness logic.
At 42:30 he references a case study ofHomeAway, an Expedia sharingeconomy venture for vacation homes.
Werner describes how they’ve built itentirely at the Serverless layer, makinguse of other AWS services like DynamoDB, Kinesis and S3 to enable uploadingand processing of six million images amonth.
Werner Vogels : The Enterprise Journey to Serverless Microservices
Werner Vogels : The Enterprise Journey toServerless Microservices
He adds that the adoption of Serverlessis being driven by tech startups yes, butalso they are seeing large enterprisesbeing equally quick to embrace thetrend, given it greatly increasesdeveloper productivity. He cites anothervery powerful example of Capital One,who entirely migrated billions ofmainframe transactions to a Serverlessapproach.
From 56:00 Werner makes the key pointthat Serverless isn’t just about Lambda,that is the developer tool that stitchestogether multiple AWS services like S3and DynamoDB, but many of theservices can be considered Serverless,because fundamentally they require nomanagement of underlying serverinfrastructure.
Learn more: Accelerate Adoption ofMicroservices with Serverless
Serverless ApplicationModel
Werner touches on AWS ‘SAM’,the Serverless Application Model (AWSSAM, previously known as ProjectFlourish) extends AWS CloudFormationto provide a simpli�ed way of de�ningthe Amazon API Gateway APIs, AWSLambda functions, and AmazonDynamoDB tables needed by yourserverless application.
As the developer guide describes:
“A serverless application is acombination of Lambda functions, eventsources, and other resources that worktogether to perform tasks. Note that aserverless application is more than justa Lambda function—it can includeadditional resources such as APIs,databases, and event source mappings.”
and that
Werner Vogels : The Enterprise Journey to Serverless Microservices
Werner Vogels : The Enterprise Journey toServerless Microservices
“AWS SAM is an extension for the AWSCloudFormation template language thatlets you de�ne serverless applicationsat a higher level. It abstracts awaycommon tasks such as function rolecreation, which makes it easier to writetemplates. AWS SAM is supporteddirectly by AWS CloudFormation, andincludes additional functionalitythrough the AWS CLI and AWS SAM CLI.”
ContinuousDeployment PracticesFrom 44:40 Werner talks through theheart of building a Microservicesapplication on AWS.
The keynote challenge is servicediscovery and communication – Howdoes each microservice �nd oneanother and manage their dataexchanges?
For this AWS launched App Mesh. Thisgives a complete view of the distributedsystem, handles reliability andcommunication between services, andprovides insights into the loads andpaths these communications generate.
At 58:45 Werner describes how theMicroservices approach is seeingdevelopment teams moving from asingle to multiple software deploymentlifecycles, achieved throughautonomous teams that can reactindividually to changing customerneeds. Rather than multiple teams alltrying to move one monolith softwarebuild through a very infrequentdeployment process now they are allcontinuously deploying at a highfrequency rate.
He describes how AWS o�ers acomplete toolchain for enabling thislifecycle,including CodeCommit, CodeBuild and CodeDwith X-Ray and CloudWatch formonitoring. X-Ray provides a debuggingvisualization of all the components in aMicroservices environment, acrosscontainers and Serverless,
Popular development tools can be usedfor building Serverless microserviceapplications, including AWS Cloud9,AWS Toolkits forPycharm, IntelliJ and Visual Studio.
Werner Vogels : The Enterprise Journey to Serverless Microservices
Werner Vogels : The Enterprise Journey toServerless Microservices
Learn more: Advanced ContinuousDelivery Best Practices
Continuous SecurityFrom 1:04:24 Werner focuses in onsecurity. He says most if not all of thedata breaches that occur today are dueto older systems and security practicesassociated with them, that are no longerappropriate for today’s modern world.
In line with the microservices teammodel seeing each individual team takewhole responsibility for the operation aswell as development of their services, sosecurity needs to become part of thistoo, rather than being a separate team.“Security is everyone’s job”.
This is achieved through security beingan integral part of the ContinuousDevelopment pipeline, both in terms ofsecuring of the development pipeline,as well as the security of the software itproduces, achieved through pipelineaccess controls and hardened buildservers, and through artifact validationand static code analysis. Alarms andchecks need to occur when for examplenew libraries are added into the build,to ensure that they are approved andsecure.
As much as possible all of this checkingshould be automated, using AWS toolssuch as Inspector and CloudTrail.
Similarly Werner says that nowadaysencryption shouldn’t just be selectivelyapplied to some data but be entirelyubiquitous throughout the applicationenvironment.
Learn more: Continuous Compliancewith AWS Management Tools
Werner Vogels : The Enterprise Journey to Serverless Microservices
Werner Vogels : The Enterprise Journey toServerless Microservices
Aurora – A DatabaseDesigned for theCloudFrom 1:15:00 Werner moves on toexploring the role of the underlyingdatabases. He relates how there hasbeen a big shift away from thetraditional enterprise vendors to opensource, primarily to escape theprohibitive costing models they employ.
However they too are not especiallydesigned for the Cloud, and so thepractice of ‘sharding‘ can be used here,but even then this approach faces manyscaling issues, given it was an approachdeveloped in the 90s.
So AWS has built Aurora, their ownrelational database re-engineered to beCloud Native, a scaled out distributedarchitecture based on a shared storagemodel using SSDs that is database-aware. It delivers high performance andavailability with up to 15 low-latencyread replicas, point-in-time recovery,continuous backup to Amazon S3, andreplication across three AvailabilityZones.
Aurora has been the fastest growingservice in the history of AWS.
At 1:23:00 Werner concludes this sectionby relating it back to a Microservicesarchitecture, highlighting that theunique design-per-microserviceapproach means that it may not be arelational database that service needs –Perhaps it is best served by a graphdatabase for example.
Depending on the requirements of thatparticular service it could use a numberof possible AWS options, such asDynamoDB, DocumentDB, ElasticCache, Neptu
Werner Vogels : The Enterprise Journey to Serverless Microservices
Werner Vogels : The Enterprise Journey toServerless Microservices
Learn more: Migrate from LegacyDatabases to Aurora with AppAssociates
Data analyticsFrom 1:25:00 Werner concludes hissession through a review of AWS dataanalytics capabilities.
He begins with the critical insight that ITitself is no longer a competitivedi�erentiation, as there is ubiquitousaccess to all the same tools foreveryone, so it is now it is the kind ofdata that you have and how smartly youuse it that de�nes your advantage.
Furthermore where data warehousesused to be a heavy, slow and expensivetechnology to set up and use, now theCloud has made them lightweight, agileand on demand. Redshift, the AWS datawarehouse product, can be spun up andused only for a couple of hours.
Data warehousing may be thought of asan old-style world but wrapping upWerner makes the point it is actuallyintegral to every modern and cuttingedge application and business model.
Using Fortnite as an example hehighlights that they have a massiveanalytics engine underpinning thegame, enabling core components likeservice health, game usage to improveplayability and tournaments.
Werner describes data analytics ashaving three main pillars: Historicalreporting, real-time status andforecasting, where the data can providethe foundation for machine learning tobetter predict the future, leading on tothe follow on presentation on AWS’s AIservices.
Learn more: AWS re:Invent 2018: ChrisDyl, Director of Platform at Epic Games
Werner Vogels : The Enterprise Journey to Serverless Microservices
