Transcription
Re-architecting to cloud native:an evolutionary approachto increasing developerproductivity at scale
Table of ContentsWhy move to a cloud-native architecture? . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3What is a cloud-native architecture? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4Migrating to cloud native. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7Microservices architecture principles and practices . . . . . . . . . . . . . . . . . . . .11Reference architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12Containerize production services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13Create effective CI/CD pipelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14Focus on security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17Getting started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22Further reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23Footnotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24
3Why move to a cloud-native architecture?Many companies build their custom software services using monolithic architectures. Thisapproach has advantages: monolithic systems are relatively simple to design and deploy - atleast, at first. However, it can become hard to maintain developer productivity anddeployment velocity as applications grow more complex, leading to systems that areexpensive and time-consuming to change and risky to deploy. This paper shows how tore-architect your applications to a cloud-native paradigm that allows you to acceleratedelivery of new features even as you grow your teams, while also improving software qualityand achieving higher levels of stability and availability.As services — and the teams responsible for them — grow, they tend to become morecomplex and harder to evolve and to operate. Testing and deployment become more painful,adding new features becomes harder, and maintaining reliability and availability can be astruggle.Research by Google’s DORA team shows that it is possible to achieve high levels of softwaredelivery throughput and service stability and availability across organizations of all sizesand domains. High-performing teams are able to deploy multiple times per day, get changesout to production in less than a day, restore service in less than an hour, and achieve changefail rates of 0-15%1.Furthermore, high performers are able to achieve higher levels of developer productivity,measured in terms of deployments per developer per day, even as they increase the size ofLow PerformersDeploy/Day/DevMed Performers2.521.510.5Deploy/Day/Dev010more frequent:Deployment Frequency (log10(freq)): Higher is more frequent:High Performers3Figure 1: The impact of a team’ssoftware delivery performanceon its ability to scale developerproductivity, from the 2015 Stateof DevOps Report 2.32.5100Number of Developers1000Low PerformersMed PerformersHigh Performers
4their teams. This is shown in Figure 1.The rest of this paper shows how to migrate your applications to a modern cloud-nativeparadigm to help achieve these outcomes. By implementing the technical practicesdescribed in this paper, you can reach the following goals: Increased developer productivity, even as you increase your team sizes. Faster time-to-market: add new features and fix defects more quickly. Higher availability: increase the uptime of your software, reduce the rate ofdeployment failures, and reduce time-to-restore in the event of incidents. Improved security: reduce the attack surface area of your applications, and make iteasier to detect and respond rapidly to attacks and newly discovered vulnerabilities. Better scalability: cloud-native platforms and applications make it easy to scalehorizontally where necessary - and to scale down too. Reduce costs: a streamlined software delivery process reduces the costs of deliveringnew features, and effective use of cloud platforms substantially reduces the operatingcosts of your services.What is a cloud-native architecture?Monolithic applications must be built, tested, and deployed as a single unit. Often, theoperating system, middleware, and language stack for the application are customized orcustom-configured for each application. The build, test, and deployment scripts andprocesses are typically also unique to each application. This is simple and effective forgreenfield applications, but as they grow, it becomes harder to change, test, deploy, andoperate such systems.Furthermore, as systems grow, so does the size and complexity of the teams that build, test,deploy, and operate the service. A common, but flawed approach, is to split teams out byfunction, leading to hand-offs between teams that tend to drive up lead times and batch sizes
5and lead to significant amounts of rework. DORA’s research shows high-performing teamsare twice as likely to be developing and delivering software in a single, cross-functional team.Symptoms of this problem include: Long, frequently broken build processes Infrequent integration and test cycles Increased effort required to support the build and test processes Loss of developer productivity Painful deployment processes that must be performed out of hours, requiring scheduleddowntime Significant effort in managing the configuration of test and production environmentsIn the cloud-native paradigm, in contrast 3: Complex systems are decomposed into services that can be independently tested anddeployed on a containerized runtime (a microservices or service-oriented architecture); Applications use standard platform-provided services, such as database managementsystems (DBMS), blob storage, messaging, CDN, and SSL termination; A standardized cloud platform takes care of many operational concerns, such asdeployment, autoscaling, configuration, secrets management, monitoring, and alerting.These services can be accessed on-demand by application development teams; Standardized operating system, middleware, and language-specific stacks are providedto application developers, and the maintenance and patching of these stacks are doneout-of-band by either the platform provider or a separate team; A single cross-functional team can be responsible for the entire software deliverylifecycle of each service.
6This paradigm provides many benefits: Faster delivery: Since services are now small and loosely coupled, the teams associatedwith those services can work autonomously. This increases developer productivity anddevelopment velocity. Reliable releases: Developers can rapidly build, test, and deploy new and existingservices on production-like test environments. Deployment to production is also asimple, atomic activity. This substantially speeds up the software delivery process andreduces the risk of deployments. Lower costs: The cost and complexity of test and production environments issubstantially reduced because shared, standardized services are provided by theplatform, and because applications run on shared physical infrastructure. Better security: Vendors are now responsible for keeping shared services, such asDBMS and messaging infrastructure up-to-date, patched, and compliant. It’s also mucheasier to keep applications patched and up-to-date because there is a standard way todeploy and manage applications. Higher availability: Availability and reliability of applications is increased because of thereduced complexity of the operational environment, the ease of making configurationchanges, and the ability to handle autoscaling and autohealing at the platform level. Simpler, cheaper compliance: Most information security controls can be implemented atthe platform layer, making it significantly cheaper and easier to implement anddemonstrate compliance. Many cloud providers maintain compliance with riskmanagement frameworks such as SOC2 and FedRAMP, meaning applications deployedon top of them only have to demonstrate compliance with residual controls notimplemented at the platform layer.However, there are some trade-offs associated with the cloud-native model: All applications are now distributed systems, which means they make significantnumbers of remote calls as part of their operation. This means thinking carefully abouthow to handle network failures and performance issues, and how to debug problems inproduction. Developers must use the standardised operating system, middleware, and applicationstacks provided by the platform. This makes local development harder.
7 Architects need to adopt an event-driven approach to systems design, includingembracing eventual consistency.Migrating to cloud nativeMany organizations have adopted a “lift-and-shift” approach to moving services to thecloud. In this approach, only minor changes are required to systems, and the cloud isbasically treated as a traditional datacenter, albeit one that provides substantially betterAPIs, services, and management tooling compared with traditional datacenters. However,lift-and-shift by itself provides none of the benefits of the cloud-native paradigm describedabove.Many organizations stall at lift-and-shift because of the expense and complexity of movingtheir applications to a cloud-native architecture, which requires rethinking everything fromapplication architecture to production operations and indeed the entire software deliverylifecycle. This fear is rational: many large organizations have been burned by failed multiyear, “big bang” replatforming efforts.The solution is to take an incremental, iterative, and evolutionary approach tore-architecting your systems to cloud native, enabling teams to learn how to workeffectively in this new paradigm while continuing to deliver new functionality: an approachthat we call “move-and-improve”.A key pattern in evolutionary architecture is known as the strangler fig application 4 . Ratherthan completely rewriting systems from scratch, write new features in a modern, cloudnative style, but have them talk to the original monolithic application for existingfunctionality. Gradually shift existing functionality over time as necessary for theconceptual integrity of the new services, as shown in Figure 2.
uleNewmoduleNewmoduleFigure 2: Using the strangler fig pattern to incrementally re-architect your monolithic applicationHere are three important guidelines for successfully re-architecting:First, start by delivering new functionality fast rather than reproducing existingfunctionality. The key metric is how quickly you can start delivering new functionality usingnew services, so that you can quickly learn and communicate good practice gained fromactually working within this paradigm. Cut scope aggressively with the goal of deliveringsomething to real users in weeks, not months.Second, design for cloud native. This means using the cloud platform’s native services forDBMS, messaging, CDN, networking, blob storage and so forth, and using standardizedplatform-provided application stacks wherever possible. Services should be containerized,making use of the serverless paradigm wherever possible, and the build, test, and deployprocess should be fully automated. Have all applications use platform-provided sharedservices for logging, monitoring, and alerting. (It is worth noting that this kind of platform
9architecture can be usefully deployed for any multi-tenant application platform, including abare-metal on-premises environment.)A high-level picture of a cloud-native platform is shown in Figure 3, below.InternetManaged serviceAPI serviceManaged service broker(DB, storage, identity, httpstermination etc.) serviceprovider / 3rd partyContainer schedulerservice providerresponsibility deployments,app & svc mgmt, routing, authservice providerresponsibilityservice providerresponsibilityDynamic routingservice providerresponsibilityManaged service(DB, storage, identity, httpstermination etc.) serviceprovider / 3rd partyManaged service(DB, storage, identity, httpstermination etc.) serviceprovider / 3rd partyApplicationApplicationApplicationcustomer responsibilitycustomer responsibilitycustomer responsibilityApplication StackApplication StackApplication Stackservice provider or customerservice provider or customerservice provider or customerContainer heat layerHeat base imageservice provider responsibility hardened, includes intrustion detection, threat and vunerability detectionInfrastructure layerservice provider responsibility IaaS managed using infrastructure-as-code paradigmFigure 3: High-level anatomy of a cloud platformFinally, design for autonomous, loosely-coupled teams who can test and deploy their ownservices. Our research shows that the most important architectural outcomes are whethersoftware delivery teams can answer “yes” to these six questions:
10 We can make large-scale changes to the design of our system without the permission ofsomebody outside the team; We can make large-scale changes to the design of our system without depending onother teams to make changes in their systems or creating significant work for otherteams; We can complete our work without communicating and coordinating with people outsidethe team; We can deploy and release our product or service on demand, regardless of otherservices it depends upon; We can do most of our testing on demand, without requiring an integrated testenvironment; We can perform deployments during normal business hours with negligible downtime.Our research shows that the extent to which teams agreed with these statementsstrongly predicted high software performance: the ability to deliver reliable, highlyavailable services multiple times per day. This, in turn, is what enables high-performingteams to increase developer productivity (measured in terms of number of deploymentsper developer per day) even as the number of teams increases.Check on a regular basis whether teams are working towards these goals, and prioritizeachieving them. This usually involves re-thinking both organizational and enterprisearchitecture.In particular, organizing teams so that all the various roles needed to build, test, and deploysoftware, including product managers, are working together and using modern productmanagement practices to build and evolve the services they are working on is crucial. Thisneed not involve changes to organizational structure. Simply having those people worktogether as a team on a day-to-day basis (sharing a physical space where possible) ratherthan having developers, testers, and release teams operating independently can make a bigdifference to productivity.
11Microservices architecture principlesand practicesWhen adopting a microservices or service-oriented architecture, there are some importantprinciples and practices you must ensure you follow. It’s best to be very strict aboutfollowing these from the beginning, as it is more expensive to retrofit them later on. Every service should have its own database schema. Whether you’re using a relationaldatabase or a nosql solution, each service should have its own schema that no otherservice accesses. When multiple services talk to the same schema, over time theservices become tightly coupled together at the database layer. These dependenciesprevent services from being independently tested and deployed, making them harder tochange and more risky to deploy. Services should only communicate through their public APIs over the network. Allservices should expose their behavior through public APIs, and services should only talkto each other through these APIs. There should be no “back door” access, or servicestalking directly to other services’ databases. This avoids services becoming tightlycoupled, and ensures inter-service communication uses well-documented and supportedAPIs. Services are responsible for backwards compatibility for their clients. The teambuilding and operating a service is responsible for making sure that updates to theservice don’t break its consumers. This means planning for API versioning and testingfor backwards compatibility, so that when you release new versions, you don’t breakexisting customers. Teams can validate this using canary releasing. It also meansmaking sure deployments do not introduce downtime, using techniques such as blue/green deployments or staged roll-outs. Create a standard way to run services on development workstations. Developers needto be able to stand up any subset of production services on development workstationson demand using a single command. It should also be possible to run stub versions ofservices on demand — make sure you use emulated versions of cloud services thatmany cloud providers supply to help you. The goal is to make it easy for developers totest and debug services locally. Invest in production monitoring and observability. Many problems in production,including performance problems, are emergent and caused by interactions between
12multiple services. Our research shows it’s important to have a solution in place thatreports on the overall health of systems (for example, are my systems functioning? domy systems have sufficient resources available?) and that teams have access to toolsand data that helps them trace, understand, and diagnose infrastructure problems inproduction environments, including interactions between services. Set service-level objectives (SLOs) for your services and perform disaster recoverytests regularly. Setting SLOs for your services sets expectations on how it will performand helps you plan how your system should behave if a service goes down (a keyconsideration when building resilient distributed systems.) Test how your productionsystem behaves in real life using techniques such as controlled failure injection as partof your disaster recovery testing plan — DORA’s research shows that organizations thatconduct disaster recovery tests using methods like this are more likely to have higherlevels of service availability. The earlier you get started with this the better, so you cannormalize this kind of vital activity.This is a lot to think about, which is why it’s important to pilot this kind of work with a teamthat has the capacity and capability to experiment with implementing these ideas. Therewill be successes and failures — it’s important to take lessons from these teams andleverage them as you spread the new architectural paradigm out through your organization.Our research shows that companies that succeed use proofs-of-concept and provideopportunities for teams to share learnings, for example by creating communities ofpractice. Provide time, space, and resources for people from multiple teams to meetregularly and exchange ideas. Everybody will also need to learn new skills andtechnologies. Invest in the growth of your people by giving them budget for buying books,taking training courses, and attending conferences. Provide infrastructure and time forpeople to spread institutional knowledge and good practice through company mailing lists,knowledge bases, and in-person meetups.Reference architectureIn this section, we’ll describe a reference architecture based on four broad guidelines: Use containers for production services Use a container scheduler such as Cloud Run or Kubernetes for orchestration Create effective CI/CD pipelines Focus on security
13Containerize production servicesThe foundation of a containerized cloud application is a container management andorchestration service. While many different services have been created, one is clearlydominant today: Kubernetes. According to Gartner, “Kubernetes has emerged as the defacto standard for container orchestration, with a vibrant community and support frommost of the leading commercial vendors.” Figure 4 summarizes the logical structure of aKubernetes cluster.Figure 4: A Kubernetes cluster runs workloads, with each pod comprising one or more containers.Kubernetes defines an abstraction called a pod. Each pod often includes just onecontainer, like pods A and B in Figure 4, although a pod can contain more than one, as inpod C. Each Kubernetes service runs a cluster containing some number of nodes, each ofwhich is typically a virtual machine (VM). Figure 4 shows only four VMs, but a real clustermight easily contain a hundred or more. When a pod is deployed on a Kubernetes cluster,the service determines which VMs that pod’s containers should run in. Because containersspecify the resources they need, Kubernetes can make intelligent choices about whichpods are assigned to each VM.Part of a pod’s deployment information is an indication of how many instances — replicas— of the pod should run. The Kubernetes service then creates that many instances of the
14pod’s containers and assigns them to VMs. In Figure 3, for example, pod A’s deploymentrequested three replicas, as did pod C’s deployment. Pod B’s deployment, however,requested four replicas, and so this example cluster contains four running instances ofcontainer 2. And as the figure suggests, a pod with more than one container, such as podC, will always have its containers assigned to the same node.Kubernetes also provides other services, including: Monitoring running pods, so if a container fails, the service will start a new instance.This makes sure that all the replicas requested in a pod’s deployment remain available. Load balancing traffic, spreading requests made to each pod intelligently across acontainer’s replicas. Automated zero-downtime rollout of new containers, with new instances graduallyreplacing existing instances until a new version is fully deployed. Automated scaling, with a cluster autonomously adding or deleting VMs based ondemand.Create effective CI/CD pipelinesSome of the benefits of refactoring a monolithic application, such as lower costs, flowdirectly from running on Kubernetes. But, one of the most important benefits — the abilityto update your application more frequently — is only possible if you change how you buildand release software. Getting this benefit requires you to create effective CI/CD pipelinesin your organization.Continuous integration relies on automated build and test workflows that provide fastfeedback to developers. It requires every member of a team working on the same code (forexample, the code for a single service) to regularly integrate their work into a sharedmainline or trunk. This integration should happen at least daily per developer, with eachintegration verified by a build process that includes automated tests. Continuous deliveryaims at making deployment of this integrated code quick and low risk, largely by
15automating the build, test, and deployment process so that activities such as performance,security, and exploratory testing can be performed continuously. Put simply, CI helpsdevelopers detect integration issues quickly, while CD makes deployment reliable androutine.To make this clearer, it’s useful to look at a concrete example. Figure 4 shows how aCI/CD pipeline might look using Google tools for containers running on GoogleKubernetes Engine.Detect newcommit andtrigger a buildCommit andpush changesCloud CodeGitHubRun tests andpush imageCloud BuildDetect scannedimageContainerRegistryDeploy to GKECloud BuildFigure 5: A CI/CD pipeline has several steps, from writing code to deploying a new container.GoogleKubernetesEngine
16It’s useful to think of the process in two chunks: Local Development: The goal here is to speed up an inner development loop and providedevelopers with tooling to get fast feedback on the impact of local code changes. Thisincludes support for linting, auto-complete for YAML, and faster local builds. Remote Development: When a pull request (PR) is submitted, the remote developmentloop kicks off. The goal here is to drastically reduce the time it takes to validate and testthe PR via CI and perform other activities like vulnerability scanning and binary signing,while driving release approvals in an automated fashion.Here is how Google Cloud tools can help during this process:Local development: Making developers productive with local application development isessential. This local development entails building applications that can be deployed to localand remote clusters. Prior to committing changes to a source control management systemlike GitHub, having a fast local development loop can ensure developers get to test anddeploy their changes to a local cluster.Google Cloud as a result provides Cloud Code. Cloud Code comes with extensions to IDEs,such as Visual Studio Code and Intellij to let developers rapidly iterate, debug, and run codeon Kubernetes. Under the covers Cloud Code uses popular tools, such as Skaffold, Jib, andKubectl to enable developers to get continuous feedback on code in real time.Continuous integration: With the new Cloud Build GitHub App, teams can trigger builds ondifferent repo events - pull requests, branch, or tag events right from within GitHub. CloudBuild is a fully serverless platform and scales up and down in response to load with norequirement to pre-provision servers or pay in advance for extra capacity. Builds triggeredvia the GitHub App automatically post status back to GitHub. The feedback is integrateddirectly into the GitHub developer workflow, reducing context switching.Artifact Management: Container Registry is a single place for your team to manage Dockerimages, perform vulnerability scanning, and decide who can access what with fine-grainedaccess control. The integration of vulnerability scanning with Cloud Build lets developersidentify security threats as soon as Cloud Build creates an image and stores it in theContainer Registry.
17Continuous delivery: Cloud Build uses build steps to let you define specific steps to beperformed as a part of build, test, and deploy. For example, once a new container has beencreated and pushed to Container Registry, a later build step can deploy that container toGoogle Kubernetes Engine (GKE) or Cloud Run - along with the related configuration andpolicy. You can also deploy to other cloud providers in case you are pursuing a multi-cloudstrategy. Finally, if you are someone looking to pursue GitOps-style continuous delivery,Cloud Build lets you describe your deployments declaratively using files (for example,Kubernetes manifests) stored in a Git repository.Deploying code isn’t the end of the story, however. Organizations also need to manage thatcode while it executes. To do this, GCP provides operations teams with tools, such as CloudMonitoring, and Cloud Logging.Using Google’s CI/CD tools certainly isn’t required with GKE — you’re free to use alternativetoolchains if you wish. Examples include leveraging Jenkins for CI/CD or Artifactory forartifact management.If you’re like most organizations with VM-based cloud applications, you probably don’t havea well-oiled CI/CD system today. Putting one in place is an essential part of getting benefitsfrom your re-architected application, but it takes work. The technologies needed to createyour pipelines are available, due in part to the maturity of Kubernetes. But the humanchanges can be substantial. The people on your delivery teams must become crossfunctional, including development, testing, and operations skills. Shifting culture takestime, so be prepared to devote effort to changing the knowledge and behaviors of yourpeople as they move to a CI/CD world.Focus on securityRe-architecting monolithic applications to a cloud-native paradigm is a big change.Unsurprisingly, doing this introduces new security challenges that you’ll need to address.Two of the most important are: Securing access between containers Ensuring a secure software supply chain
18The first of these challenges stems from an obvious fact: breaking your application up intocontainerized services (and perhaps microservices) requires some way for those servicesto communicate. And even though they’re all potentially running on the same Kubernetescluster, you still need to worry about controlling access between them. After all, you mightbe sharing that Kubernetes cluster with other applications, and you can’t leave yourcontainers open to these other apps.Controlling access to a container requires authenticating its callers, then determining whatrequests these other containers are authorized to make. It’s typical today to solve thisproblem (and several others) by using a service mesh. A leading example of this is Istio, anopen source project created by Google, IBM, and others. Figure 7 shows where Istio fits ina Kubernetes cluster.Figure 7: In a Kubernetes cluster with Istio, all traffic between containers goes through this service mesh.
19As the figure shows, the Istio proxy intercepts all traffic between containers in yourapplication. This lets the service mesh provide several useful services without any changesto your application code. These services include: Security, with both service-to-service authentication using TLS and end-userauthentication Traffic management, letting you control how requests are routed amon
re-architecting your systems to cloud native, enabling teams to learn how to work effectively in this new paradigm while continuing to deliver new functionality: an approach that we call “move-and-
