"Web Age Speaks!" Webinar Series

Designing and Implementing -Native Applications in Pivotal 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

©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, , 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, )  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 [--recent]

 Create a service from CF marketplace: cf create-service shared-vm p-redis MY-CACHE

 Scale an app: scale -i [-m ]

©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: • '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 PaaS platform before sharing it with the world  The twelve-factor methodology can be applied to apps written in any  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