Advertisement

More Related Content

Slideshows for you(20)

Similar to App Mod 03: Monoliths to microservices with java ee and spring boot(20)

Advertisement

More from Judy Breedlove(20)

Advertisement

App Mod 03: Monoliths to microservices with java ee and spring boot

  1. MONOLITHS TO MICROSERVICES: APP TRANSFORMATION Hands-on Technical Workshop
  2. PART 3: MONOLITHS TO MICROSERVICES WITH JAVA EE AND SPRING BOOT
  3. MONOLITHS TO MICROSERVICES: APP TRANSFORMATION HANDS-ON LAB3 WHY MONOLITH TO MICROSERVICES Break things down (organizations, teams, IT systems, etc) down into smaller pieces for greater parallelization and autonomy and focus on reducing time to value.
  4. MONOLITHS TO MICROSERVICES: APP TRANSFORMATION HANDS-ON LAB4 REDUCING TIME TO VALUE Month 0 Month 3 Week 1 Week 2 Week 3 Week 4 Week 5 Week 6 Week 7 Week 8 Week 9 Week 10 Week 11 Monolith Lifecycle Fast Moving Monolith Microservices Optimizing for Speed
  5. MONOLITHS TO MICROSERVICES: APP TRANSFORMATION HANDS-ON LAB66 THE BIGGER PICTURE: THE PATH TO CLOUD-NATIVE APPS A DIGITAL DARWINISM SELF-SERVICE ON-DEMAND INFRA RE-ORG TO DEVOPS AUTOMATION CONTINUOUS DELIVERY ADVANCED DEPLOYMEN T TECHNIQUES MICROSERVICE S FAST MONOLITH
  6. MONOLITHS TO MICROSERVICES: APP TRANSFORMATION HANDS-ON LAB7 ● In this lab, you will begin to ‘strangle’ the coolstore monolith by implementing its services as external microservices, split along business boundaries ● Once implemented, traffic destined to the original monolith’s services will be redirected (via OpenShift software-defined routing) to the new services STRANGLING THE MONOLITH Node.js Web WildFly Swarm Inventory Vert.x Cart Runtime Service Runtime Service Vert.x Orders Spring Boot Catalog JBoss EAP HTML Javascript Web CartCatalogInventory Promo Ratings Orders Data Access
  7. MONOLITHS TO MICROSERVICES: APP TRANSFORMATION HANDS-ON LAB
  8. MONOLITHS TO MICROSERVICES: APP TRANSFORMATION HANDS-ON LAB TOMCAT SIMPLICITY JAVASCRIPT FLEXIBILITY SERVLET APPS REACTIVE SYSTEMS JAVA MICROSERVICES ENTERPRISE JAVA
  9. MONOLITHS TO MICROSERVICES: APP TRANSFORMATION HANDS-ON LAB RHOAR PRODUCT ARCHITECTURE RHOAR RUNTIMES (Container images, Maven Artifacts, Serverless) MICROPROFIL E / JAVA EE OPENSHIFT SERVICES REACTIVE (vert.x) JAVASCRIPT SERVLET APPS OpenShift.io (Developer SaaS) Generators IDE etc. Management APM Metrics Service Discovery Config. Logging Health Check Load Balancing CI/CDSSOMessaging IMDG API Mgmt OPENWHISK SERVICE MESH Istio Pilot Istio Mixer Istio Auth Envoy Proxy Envoy Proxy Envoy Proxy Envoy Proxy Service Catalog == Future
  10. LAB: MONOLITHS TO MICROSERVICES WITH JAVA EE AND SPRING BOOT
  11. GOAL FOR LAB In this lab you will learn: ● How Red Hat OpenShift and Red Hat OpenShift Application Runtimes (RHOAR) help jumpstart app modernization ● Benefits and challenges of microservices ● How to transform existing monolithic applications to microservices using strangler pattern and 12-factor app patterns. ● Use modern app dev frameworks like WildFly Swarm and Spring Boot to implement microservice applications on OpenShift
  12. CURRENT STATE - THE MONOLITH OpenShift coolstore-dev Coolstore monolith Coolstore database (dev) Coolstore Binary coolstore-prod Coolstore monolith Coolstore database (prod) Pipeline Promotion Debugger mvn package
  13. LAB: MONOLITHS TO MICROSERVICES WITH JAVA EE AND SPRING BOOT SCENARIO 4 TRANSFORMING AN EXISTING MONOLITH (PART 1) SCENARIO 5 TRANSFORMING AN EXISTING MONOLITH (PART 2) +
  14. WRAP-UP AND DISCUSSION
  15. RESULT OF LAB In this lab you learned how to: ● Implement a Java EE microservice using WildFly Swarm ● Implement a Java EE microservice using Spring Boot ● Develop container-based testing ● Add microservice concerns like Health checks, externalized configuration and circuit breaking ● Use the strangler pattern to slowly migrate functionality from monolith to microservices
  16. DESIRED RESULT OF LAB OpenShift coolstore-prod Coolstore monolith Coolstore database (prod) inventory Inventory microservice Inventory database catalog Catalog microservice Catalog database UI
  17. THANK YOU plus.google.com/+RedHat linkedin.com/company/red-hat youtube.com/user/RedHatVideos facebook.com/redhatinc twitter.com/RedHatNews

Editor's Notes

  1. So why move toward Microservice…? Fundamentally to break things down (organizations, teams, IT systems, etc) down into smaller pieces for greater parallelization and autonomy and focus on reducing time to value.
  2. So -- It’s all about speed! Ultimately, time to value is the most precious commodity in today’s marketplace. The grandfather of K8s, Google has cited metrics showing they increased: Engineers Complexity And their overall IT spend… for 1 important payoff: Time to market. This chart depicts typical throughput when optimizing for speed: Notice the red line, the Monolith Lifecycle which increases steadily through time representing common legacy workloads and the effort associated between release cycles. The blue represents the fast moving monolith techniques... Lastly, green represents MicroServices architectures which are often implemented in sprints…
  3. It’s important to remember that this is a journey, not necessary a race…. There are both cultural (people) and technology elements Most organizations start small, establish a baseline success and increment forward One of the things we’d like you to take back to your respective organizations is that Red Hat can help you on this journey Both from a cultural and technological perspective On the technology side, we offer A lot of what we’re showcasing today: (OpenShift, Ansible, certified MW images, application runtimes, RH Application Migration Toolkit, and many more technologies outside of today scope) On the people and cultural side, we offer a partnership with our customers -- side by side mentoring via our consulting organization vast trusted partner ecosystem and unique DevOps-centric co-location experiences where experienced engineers and scum coaches walk our customers through tailored projects utilizing all elements of modern app/dev approaches/methodologies.
  4. In this lab, you will begin to ‘strangle’ the coolstore monolith by implementing its services as external microservices, split along business boundaries Once implemented, traffic destined to the original monolith’s services will be redirected (via OpenShift software-defined routing) to the new services
  5. Red Hat® OpenShift Application Runtimes helps organizations leverage a cloud native model and simplify continuous delivery of applications and services on Red Hat® OpenShift platform. Built on proven open source technologies, Red Hat® OpenShift Application Runtimes also provides development teams multiple modernization options to enable a smooth transition to the cloud for existing applications. Simply put, RHOAR offers developers flexibility and choices to build the right application with the right runtime, framework, language, and architectural style…
  6. Specifically, Red Hat® OpenShift Application Runtimes reduces the complexity of developing cloud-native applications by integrating OpenShift capabilities with polyglot programming models including capabilities for service discovery, external configurations, and circuit breakers/fault tolerance. Red Hat® OpenShift Application Runtimes also includes a number of developer-centric techniques/efficiencies, such as creating: APIs interoperating with a database or implementing health check patterns All of this is designed to speed up application development... Due to its integration with Red Hat® OpenShift Container Platform, Red Hat® OpenShift Application Runtimes provides developers with a self-service platform for provisioning, building, and deploying applications and their components. It integrates with CI/CD tools like Git, Maven, and Jenkins. It also provides intuitive tooling to securely streamline Kubernetes workflows Additionally, it enables application load-balancing and auto-scaling capabilities with policy-based control and automation. We’ll create a WildFly Swarm and SpringBoot microservice in the next 2 labs…
  7. This represents the RHOAR architecture. Some of the Cloud Native support, delivered in RHOAR that you’ll experiment with in the next lab scenarios includes: Health Checks Externalized Config Client-side discovery / load balancing Circuit Breaking / Bulkheading Logging / Monitoring / Tracing / Metrics Secure deployments with Keycloak MicroProfile API Documentation *** Notice the Envoy Proxy, which is leveraged as part of the Istio service mesh. You will learn all about this in the final scenario. For now, you can think of it as a “side car” container which can be deployed with your microservices. Envoy adds resilience and observability to your services and it does so in a way that's transparent to your service implementation.
  8. Next up is WildFly Swarm which is targeted at Java-based microservices applications, but as you may have guessed from the name it also brings in a number of Java EE components from the WildFly ecosystem. This means that if you’re a Java EE developer you can continue to re-use your knowledge as you start to migrate existing applications to benefit from microservices. We say that WildFly Swarm brings just enough of the app server you used in the past to build lightweight and efficiently-packaged java applications, which contain only the bits you need to run as an executable JAR file, or uber-jar, on a container platform like OpenShift. For example, the diagram above shows a small microservice needing only support for RESTful communication using the JAX-RS standard from the Java EE world, so with WildFly Swarm you can build a WildFly Swarm uber-jar containing your service’s business logic along with only that JAX-RS component, and run it using java -jar. So you get a minimal execution footprint and minimal attack surface for those security-minded developers out there. Microservice apps generally need only a small subset of functionality as compared to a traditional monolithic enterprise app, and so last year several vendors including Red Hat collaborated to produce a new specification that that defines such a subset...
  9. Fractions support explicit and implicit configuration In many cases you won’t need to configure anything Or configuration can be externalized Fractions can be detected or explicitly declared The most simple case is a <war> project, with just the maven plugin All of Java EE is supported in upstream WildFly Swarm JPA, JAX-RS, EJB, JMS, CDI, … Successfully ran Java EE 7 samples [blog] Successfully ran JBoss EAP 7 Quickstarts [blog]
  10. Companies love standardization, as it gives them choice of implementation AND essentially free QA resources as the spec is developed and used across the industry through different implementations. The Microprofile spec is geared toward Java microservices applications, and there are a number of implementations available today. WildFly Swarm is Red Hat’s implementation of this spec, and as you can see includes some functions from the Java EE world like JAX-RS and CDI, but also includes typical functions you’d find in a microservice like health checks, fault tolerance for building resilient apps, externalized configuration support and support for securing microservices through JWT token propogation. If you want to learn more or get involved in the evolution of tis spec, visit microprofile.io.
Advertisement