This video discusses three related paths that can be taken to modernize applications to cloud native. It is often difficult to understand where to begin when modernizing a traditionally developed application to one that embraces a cloud native approach and modern cloud technologies. Let’s examine application modernization by looking at three transformational paths each with its own area of focus. The first path relates to Infrastructure and will be covered in detail in this module. This path involves migrating apps to Cloud to take advantage of cloud native technologies that embrace immutable infrastructure. This approach relies on Container images that have pre-built layers that include the operating system and application runtime. The second modernization path involves refactoring monolithic application architectures with tightly-coupled, interdependent functions into multiple stateless, single purpose microservices that are loosely coupled. The patterns, techniques, and activities from this path (around refactoring into microservices) will be fully covered in module 3. The third path centers around the automation of CI/CD processes to enable agility to deliver applications quickly and reliably while supporting the goals of DevSecOps. This includes treating “Infrastructure as Code” as well as integrating security tooling and tests against requirements and policies into delivery pipelines. Module 4 of this course is devoted to this pattern and details methods and technologies used within CI/CD processes to achieve maximum agility and automation. If we look at how applications use infrastructure, we can see a distinct evolution where applications are becoming decoupled from hardware architectures and operating systems. Traditionally, applications would run on physical servers sometimes called “bare metal”. In this case, application code is often tightly coupled to the hardware architecture, proprietary infrastructure, specific operating system, and its runtime. This can inhibit moving to cloud… Limiting the application's ability to move off proprietary environments, which are likely brittle to infrastructure changes. Resource planning and scaling is complex as application responsiveness to resource changes are unclear. Configurations often need to be “updated in place” or “tweaked,” leading to configuration “drifts” adding to deployment uncertainty. Over time, Virtual Machines (VMs) improved application infrastructure flexibility as hardware access became indirect. This allowed operators to… Move to better hardware, provision infrastructure resources more easily, and create versioned packages to improve maintainability and failover. However, complexity in resource planning for scaling remained and the flexibility to move to any hardware or provider was still limited by hypervisor availability. A cloud native approach favors Linux-style Containers and commoditized container technologies to solve most of these problems. Containers allow applications to be built “on top of” fixed image layers that include only the base OS and necessary code needed to run. Container technology effectively achieves immutable infrastructure decoupling the application from its runtime stack and operating system. The technology frees operators to reliably deploy to cloud native platforms anywhere using the same configurations with no “drift”. It also provides owners maximum flexibility in choosing a cloud provider using any deployment model (public, private or hybrid). Many companies today still have applications architected monolithically where all functions are coupled and built together as a single, interconnected unit. Monoliths have many drawbacks. They are large and complicated, making them difficult to change, add new features, or adopt new technologies. Their large sizes also make them slower to move around networks, start or restart on failure…and also inhibit scaling with unclear resource requirements. Reliability is impacted as even simple bug fixes cause the entire application to be updated in every deployment. Over time, a Service-Oriented Architecture (SOA) became popular, which reduced complexity by organizing code by type of service. SOA grouped code logically by the service they either provided or consumed; for example, web, database, user-profiles, billing, and logging. It also leveraged frameworks which helped services share “state” and enabled interservice communication over localized service buses. SOA solved many problems by reducing complexity, simplifying change management, and resource determination and improving deployment. However, SOA apps are not fully optimized for Cloud and their frameworks are complex and difficult to configure and maintain with any agility. Enter microservice architecture... Microservice architecture is the modern approach for cloud native and is a natural evolution of SOA. It involves composing your application from fine-grained, single-purpose services which can be independently managed and scaled. Microservices are small and effectively “stateless" so they are fast to startup and easily scale. Each microservice can be developed and built independently, meaning DevOps teams can rapidly integrate new functions into applications and release them to meet the demands of business. In addition, since microservices operate independently of each other, when problems occur, they are easier to diagnose and fix and they do not affect other parts of the overall application. The good news for owners of existing applications is that many can be refactored into microservices. In fact, cloud providers often have tools that can help analyze existing application packages, their APIs, and structure to make recommendations and even start the refactoring process. Monoliths were often built in a linear fashion, sometimes called “waterfall”, as each phase would pass or fall to the next phase, eventually producing a release that could be delivered. Unfortunately, this process leads to siloed organizations with strict roles within each phase of the development lifecycle, often with limited communication and knowledge sharing. Although quality applications could be produced, the process itself leads to long release cycles, slowing the ability to fix, improve or introduce new features with any speed. Adopting agile methodology across the development lifecycle, as discussed earlier, can bring overall improvements. However, a cloud native approach also incorporates DevSecOps which breaks down walls between teams and roles, endorsing regular communication, cross-education, and continual knowledge sharing. The approach strives to push “Ops left” within the Software Development Lifecycle by treating “Infrastructure as Code” (IaC) and integrating security across fully automated CI/CD pipelines. It also institutes Agile methodology and practices from the day 1 in innovating around ideas to drive features and change. You should now be familiar with: The three transformation paths to modernization, How to advantage infrastructure using containers, Improving application architecture using microservices, and How agile plus cloud native optimizes delivery
