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.
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
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
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
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
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
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)
+
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
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.
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…
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.
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
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…
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…
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.
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...
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]
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.