"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
Create a service from CF marketplace: cf create-service shared-vm p-redis MY-CACHE
Scale an app: scale
©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 to the smaller footprint of every constituent service) Scaling per service / per tier Smaller development teams leading to faster getting-up-to- speed (smaller codebase) Microservices promote stateless app design letting you persist any state in a reliable external (e.g. caching) service Essentially, microservices force you to re-think and change (theoretically, for the better) the way you build and deliver software
©WebAgeSolutions.com 23 Microservices Cons Performance overhead (crossing boundaries is expensive and may be x1000 slower than in-process communication!) Considerable operational overhead with more distinct moving parts that require highly orchestrated deployment and distributed monitoring To deal with that, you need to adopt DevOps best practices (automation / scripting) for app packaging, deployment, and monitoring E.g. (Pivotal) Cloud Foundry provides buildpacks for provisioning dependencies and consistent path for building code archives (droplets); for monitoring you can leverage its Loggagregator capability
©WebAgeSolutions.com 24 Anti-Pattern: Nanoservices At an extreme end of the service granularity spectrum, a microservice's overhead (e.g. its maintenance) may start outweighing its practical usefulness This is considered an anti-pattern appropriately named nanoservice
©WebAgeSolutions.com 25 Microservices Inter-Connectivity Following the inter-connectivity approaches adopted in SOA, microservices prefer to use technology- agnostic protocols HTTP has become the transport of choice for microservice inter-connectivity The overall consensus is to use, where appropriate, the RESTful style of interactions with the emphasis on the statelessness of the communication channels Asynchronous communication is carried out in a number of ways: Using lightweight messaging systems, e.g. RabbitMQ, leveraging wire-level protocols, e.g. AMQP, for interoperability Non-blocking (not RPC-like) remote calls, including AJAX, WebSockets, and other modalities that facilitate reactive programming design pattern ©WebAgeSolutions.com 26 Data Exchange Interoperability Considerations Microservices may be written in different languages (e.g. Java, C#, Python, Go, Ruby, JavaScript, etc.) and in a variety of systems and frameworks (e.g. Spring Boot, Node.js, etc.) To ensure efficient data exchange between microservices inter-connected within complex distributed systems, the following technological approaches are used: Wire-level protocols (AMQP mentioned above) with data encoding / decoding implemented in the respective client Interoperable data interchange formats, such as: • Google's protocol buffers • Apache Avro • JSON • XML (on a lesser scale nowadays)
©WebAgeSolutions.com 27 Micro Front-ends (a.k.a. MicroUI) Micro front-ends is a relatively new term that extends the concept of microservices to the front-end tier of you app [https://micro-frontends.org/] Front-end components of web apps run in client browsers and leverage modern JavaScript run-times for building dynamic, data-driven apps (sometimes referred to as 'Single Page Apps') that are composed of a suite of features The current trend for building feature-rich apps is to combine the front-end components (MicroUI fragments) with MSA apps at the back-end MicroUI helps with the following: Breaking up the front-end monolith components Organized your development into small, per-feature Dev teams, where such teams own their feature(s) end-to-end (from UI to business logic to persistence layer) It might help to think of MicroUI as next generation (NG) portals
©WebAgeSolutions.com 28 The Twelve-Factor App Methodology The twelve-factor app methodology [http://12factor.net] helps build robust on-premise and cloud-native apps The contributors to this methodology had been gathering those insights when working on the Heroku PaaS platform before sharing it with the world The twelve-factor methodology can be applied to apps written in any programming language Some of the twelve-factor app principles are listed in the next slide
©WebAgeSolutions.com 29 The Select Twelve Factors III. Config Store config in the environment VI. Processes Execute the app as one or more stateless processes VII. Port binding Export services via port binding IX. Disposability Maximize robustness with fast startup and graceful shutdown X. Dev/prod parity Keep development, staging, and production as similar as possible XI. Logs Treat logs as event streams
©WebAgeSolutions.com 30