"Web Age Speaks!" Webinar Series Designing and Implementing Cloud-Native Applications in Pivotal Cloud Foundry Introduction Mikhail Vladimirov Director, Curriculum Architecture [email protected] Web Age Solutions Providing a broad spectrum of regular and customized training classes in programming, system administration and architecture to our clients across the world for over ten years ©WebAgeSolutions.com 2 Agenda Cloud Foundry Intro Moving to the Cloud The Twelve-Factor App Methodology ©WebAgeSolutions.com 3 Designing and Implementing Cloud- Native Applications in Pivotal Cloud Foundry What is Cloud Foundry What is Cloud Foundry Cloud Foundry (CF) is an open source Platform-as-a- Service (PaaS) The source code is under an Apache License 2.0 It runs on every major private and public IaaS cloud hiding the underlying cloud platform's specifics behind its uniform middleware which can be viewed as a portable standard CF supports and promotes modern cloud application design and development principles as outlined in https://12factor.net/ Originally developed by VMware (around 2009) and then transferred to Pivotal Software ©WebAgeSolutions.com 5 Traditional On-Premise vs IaaS vs CF ©WebAgeSolutions.com 6 Why Would I Need (if at all) Cloud Foundry? Cloud Foundry is ideal for anyone interested in removing the cost and complexity of configuring infrastructure for their apps You install CF and configure it to run in one or more regions (for HA) of the IaaS platform of your choice CF PaaS provides infrastructure that helps manage (configure, deploy, scale, and upgrade) distributed systems in the IaaS cloud While that's the typical value proposition of any PaaS platform, CF, however, does this in a portable way CF uses a container-based architecture that promotes the use of microservices based on the twelve-factor app principles ©WebAgeSolutions.com 7 What is Being IaaS-Independent? CF offers you a uniform way of running your apps that isolates your from most of the cloud platform-specific details and the cloud provider API CF uses the Cloud Provider Interface (CPI), which allows it to be deployed on every major IaaS platform: AWS, Azure, GCP, OpenStack, VMware’s vSphere, etc. This feature, essentially, helps you avoid cloud vendor lock-in scenarios You are not required to re-write your applications if you move from one platform to another Your apps are essentially decoupled from the underlying IaaS platform The lift-and-shift type of migration (from one cloud to another) becomes a reality ©WebAgeSolutions.com 8 The Immutable Infrastructure Principle VMs and containers are viewed as temporary, ephemeral entities Any updates to a guest app are not done in-place, rather a new VM / container instance is spun off and the applications are re-deployed there This consideration has a major impact on your application design, e.g. your application should not create any local files as those will be eventually lost The above operational arrangement is referred to as the Immutable Infrastructure principle ©WebAgeSolutions.com 9 What is Pivotal Cloud Foundry Pivotal Cloud Foundry (PCF) is a certified (through the CF Foundation Certification Program) commercial CF software distribution vendor PCF is positioned as an enterprise flavor of CF On top of and in addition to core CF platform capabilities, PCF provides a number of commercial value-adds, including: apigee (API gateway) Application Manager (UI) Autoscale Bundled software: MySQL, Redis, RabbitMQ, Jenkins, etc. Spring Boot integration Spring Cloud Services Service marketplace SSO Extension ©WebAgeSolutions.com 10 Organizations and Spaces CF uses organizations and spaces as a way to organize compute resources deployed in the CF cloud and logically partition users' work Spaces are created within an organization You must have at least one organization set up and one space within it Organizations and spaces may or may not be aligned with your real organizational structure, for example, You may set up CF organizations such as Marketing, Sales, Emerging Markets, etc. You may have DEV, UAT, PROD, OTHER, APPLES- AND-ORANGES, etc. spaces Organizations and spaces offer strong resource isolation ©WebAgeSolutions.com 11 Buildpacks Buildpacks provide the build framework and runtime support for your apps You can think of them as a collection of assembly, build, and deployment lifecycle scripts that are executed consequently when your app is staged in CF CF includes a set of system buildpacks for common languages and frameworks, including: Go Java (Spring) .Net Core Node.js PHP Ruby (Rails, Sinatra) Python NGINX ©WebAgeSolutions.com 12 Common IaaS Admin Tasks Transparently Handled by CF Provision a VM per some specs (RAM, vCPUs) Configure Firewall Configure Load Balancer ©WebAgeSolutions.com 13 CF CLI Cloud Foundry offers users Command Line Interface (CF CLI) represented by the cf tool CF CLI provides complete programmatic control over the PCF cloud The types of commands you can issue are subject to your role (e.g. admin, space manager, etc.) ©WebAgeSolutions.com 14 CF CLI Examples Deploy an app in CF, in most cases, is done with just one command: cf push my_app -m 64M -k 128M -p ./myApp.zip View app’s logs: cf logs <APP-NAME> [--recent] Create a service from CF marketplace: cf create-service shared-vm p-redis MY-CACHE Scale an app: scale <APP_NAME> -i <INST_NUM> [-m <NEW_MEM>] ©WebAgeSolutions.com 15 Designing and Implementing Cloud- Native Applications in Pivotal Cloud Foundry Moving to the Cloud Lift and Shift, eh … In many cloud migration projects, the straightforward lift and shift strategy may not work Application re-architecture may be required (this activity may happen before moving to the cloud, or once already there) You may be required: To align your app's security with the security capabilities of the target cloud To account for performance and cloud latency issues Once you have successfully moved your app to a cloud vendor platform and made it what is now referred to as the cloud-native app, the lift-and-shift scenario may still not be fully possible should you wish (again!) to move your app to another cloud platform ©WebAgeSolutions.com 17 Architecture Modernization Moving to the cloud is often being accompanied by Architecture Modernization efforts that involve re- designing existing applications using the microservice-based architectural style (MSA) In essence, MSA drives adoption of the distributed system architecture for your app In many ways, MSA is the same old-fashioned SOA with added critical dimensions like using containers for service deployment, adopting RESTful style web services, MicroUI, etc. Using app containers, among many other things, aids in DevOps operational agility and app runtime benefits, including ease of scalability (you can scale service at the tier level: front-end or middle tier) ©WebAgeSolutions.com 18 Monolithic Applications Monolithic application architecture is prevalent in High-performance/mission critical real-time systems Systems built around intricate transaction semantics When tight coupling and/or monolithic integration is required (due to security considerations, high cost of cross- process interactions, etc.) Monolithic applications (monoliths) are typically packaged and deployed as a single archive (e.g. Java WAR or EAR file) The good ol' SOA did not have the technical depth to contain the proliferation and expansion of monoliths ©WebAgeSolutions.com 19 Disadvantages of Monolithic Applications Large code base / deployment footprint High process memory requirements follow Tight coupling of system components, which make it difficult to Develop Test Evolve High resistance to change Difficult to scale, especially doing it in an elastic way (using cloud autoscaling services) ©WebAgeSolutions.com 20 Disadvantages of Monolithic Applications Typically having to bundle all tiers (front-end, middleware (business logic), data access layer) into one artifact (EAR, WAR archive files, etc.) You often end up with a stateful app design Lack of anti-corruption boundaries within layers or across the whole app E.g. a rogue thread in one Java app may bring down the whole JVM that may host multiple services as the JVM does not offer sufficient process isolation On the development front, monoliths can pose problems to source control management by creating code changes contention points requiring constant code merges causing developer frustration Developers may also be overwhelmed by being exposed to a large code base; it becomes cumbersome to implement agile development practices As a rule, monoliths are not cloud-native in nature and therefore not suitable for cloud deployment ©WebAgeSolutions.com 21 Dealing with Monoliths Some of the monoliths' woes can be addressed by: Layered architecture Separation of sub-system responsibilities in well-defined cross-cutting concerns by means of orthogonal design / AOP Reducing coupling between system components through design-by-contract, CDI, etc. A radical step is a deep app design overhaul and adopting a distributed architecture for your app using MSA MSA is often viewed as an integral part of architecture modernization and cloud migration initiatives ©WebAgeSolutions.com 22 MSA Benefits Overall, the microservices-based architecture forms vectors for breaking up monoliths MSA benefits: Change cycles for different services can be more easily decoupled Deployment cycles and developer velocity are faster (due