This is the UKOUG Tech 18 Conference Edition of the Microservices in a Monolith World. It is an abridged and slightly updated version of a presentation.
PHOTO of audience
Ask questions …
Who is developing microservices
Who is using WLS
Who is stuck in monolith hell
~approx. 1 minute per slide
Organizer for the London Oracle Dev Meetup
API Platform book out
QUESTION: anyone want to share some names of things that we’d associate with Microservices?
Microservices typically get linked directly to specific tech - Containers like Docker, container mgmt like Kubernetes
Design paradigm to facilitate goals...
Descrete independent deployable pieces – allowing greater rate of change
Reduce/prevent = different components impacting each other – bulkheads etc
Smart endpoints, dumb pipes
Point to clarify the difference between the concepts and the common tech
The boundary getting blurred we conflat tech with architect - with CNCF ratifying specific solutions and Cloud Native getting tied up with microservice model
Small descrete independent deployable pieces – allowing greater rate of change
https://martinfowler.com/articles/microservices.html
These are all thought leaders
Note the absence of tech, or at most used as illustration
http://microservices.io/patterns/microservices.html – Chris Richardson
Monolith – scaleout by cloning entire stack or scale up by just giving more resources
Highlight how each component is isolated or NOT
Notice the common rail between the components
Based on Martin Fowler
I think we’ve established that microservices are ideas over tech. So why adopt those ideas, what are the risks
If we’re doing microservices for reasons other than the benefits – how do you know you’re being effective, and not creating a distributed monolith
We need to evaluate, measure and understand if we’re getting things right
Why take on the challenge of Microservices?
Microservices are quicker – yes at scale, otherwise NO.
Microservices require the understanding and deployment of more building blocks UNLESS you use PaaS that takes that away. If you need small solution with a few features and small user base
Microservices are easier –in small scale solutions its not – more parts to deal with unless your have a PaaS. Real benefit is when solutions get larger or the microservice premium is worth paying
Tax examples additional docker containers
CORs becomes necessary
Microservices are hard - https://hackernoon.com/microservices-are-hard-an-invaluable-guide-to-microservices-2d06bd7bcf5d
Trade off of the micro app likely to attenuate down to a monolith
Benefits – simpler transition
We’re at an Oracle sponsored event – so lets look at WLS
But many of the following principles have comparable solutions with WebSphere, Wildfly aka JBoss AS
Issues of investment
Open sources vs closed source – often a proxy argument for how support is realized
Manage questions of license -- Don’t think open source == no license – Sonatype blog at length on this trap
Manage number of verndors
WLS in docker – cwertified but not really a microservice story
Does jump start development
Benefit in CI/CD as now can spin new environments for each test cycle
Environment build consistency and simplification
Cloud portability for monoliths
https://blogs.oracle.com/weblogicserver/oracle-weblogic-server-1221-running-on-docker-containers
https://docs.oracle.com/middleware/1213/wls/NOTES/whatsnew.htm#NOTES405
WLS documentation does actually talk about partition as a ‘micro container’
Also design goal of driving up execution density
WebLogic 12.2.1 also introduced idea of Partitions – QoS controls
Classic microservice benefits – access, partitioning of resources
Core processes JNDI, JMS still there as a central service but config isolated
New discrete – separated resources – partitions can not SEE each others content
Oracle Diagram – shows the separation OF RESOURCES
Each micro app – has its own partition – therefore slice of memory, threads etc
One gotcha – multi-partitioning with WLS impacts licensing
WLS partitioning also a multi tenancy model
Messaging is central to the microservice idea of dumb pipes, smart endpoints aka choreography vs orchestration
Talk to larger diagram – simplicity of listening and deciding on each msg – yes comes with an overhead
Async comms lends itself to scaling as race conditions on event consumption is easier than service discovery and registration
You have to assume sooner or later in a microservices environment that something will be built using a different tech
This means wire level protocol and interface – contract – which JMS does not have
Kafka + Apache Avro, remember AMQP mentioned previously
Transition strategy – abandon queues – everything is a topic – Kafka has JMS API
Then replace JMS API as each service gets revisited
Kafka uses HDFS which is where it wins out of typical underpinning of DB – comes at the price of HDFS complexity
The size of microservices is a long running question – 1 view is If you cant build & test on your laptop – its too big
Talk about bounded context diagram
Design your code using bounded contexts – this will help with the 2 pizza sizing as well
Microservices.io map of patterns – therse patterns are not tech specific
Diagram highlighted those that need extra effort vs those that cant be done in a WLS;J2EE environment
Spring & Springboot – your friend – abstracts common services – therefore can graft on to a container
Springboot gives you an app svr – that local use, configure to then later work with target – portability, sizing reinforced
Reconfiguring Springboot for WLS does require some understanding of both Spring and WLS
https://spring.io/blog/2013/08/06/spring-boot-simplifying-spring-for-everyone
https://spring.io/blog/2014/03/07/deploying-spring-boot-applications
http://undertow.io/ - Jboss non blocking IO server
https://netty.io/ Async (reactive) app framework/server
Microservices don’t come without cost & can be difficult – so need to take on for the right reasons
Make the right choices and you set yourself on a journey to transition without too much pain. A less disruptive transition may be more palatable
Microservices is a design style NOT tech – so design microservices even if you have to run on a monolithic platform