This webinar by Volodymyr Gladchenko (GlobalLogic) was delivered at Java TechTalk on June 15, 2021.

1. TechTalk "Spring boot made life easier with
Kubernetes and Microservices"

2. Popularity of the Microservices
DDD
Introduction to Kubernetes
Introduction to Spring
Typical architecture
Sample project

3. POPULARITY OF
MICROSERVICES
Main idea

5. Pros and Cons of Microservices
◦ Testing can be very complex
◦ Rapid provision of new versions
◦ Robust monitoring
◦ Dev team became partially devops
team in regarding owned microservice
◦ Resilience
◦ Scalability
◦ Ability to use diverse tools and
Languages
◦ Faster time to market
◦ More granular maintenance
◦ Operation costs improvement

6. Compromises
Business wants soft be created
cheap, fast and with the good
quality, but reality check that
only 2 of that requirements is
possible to accomplish.

9. Not a perfect solution for all cases
Every software architecture out there has its drawbacks, and MSA is not an exception. Much of it relates to the hassle of getting
used to new ways of doing things. Tasks like testing, deployment, and monitoring are a tad more complex to perform on MSA
systems than on monolithic applications. To put this in perspective, the Amazon web application calls 100 to 150 services to get
data used for building a web page, Hailo has 160 different services, Netflix has in excess of 600 services.
Furthermore, the benefits of decoupling may be overwhelmingly convincing; but it also means duplication of efforts, mitigating
fault tolerance and network latency, and handling a bunch of issues that were a lot more implicit in monoliths. None of this is
rocket science, but compared to a monolithic application, there is an added layer of complexity.
Partitioning an application into microservices isn’t only a science; it is very much an art. And although, rewriting a microservice
using newer, more efficient technology later isn’t prohibitive; refactoring the boundary of a microservice (when you find a good
reason to, as may happen sometime later thanks to the focus on evolutionary design), say by having to move a responsibility
between services, is difficult because of the loose coupling of services.

10. DDD
Domain Driven Design

11. DDD definition
◦ Domain-Driven Design is an approach to software development that centers the development on programming a domain model that has a
rich understanding of the processes and rules of a domain. The name comes from a 2003 book by Eric Evans that describes the approach
through a catalog of patterns. Since then a community of practitioners have further developed the ideas, spawning various other books and
training courses. The approach is particularly suited to complex domains, where a lot of often-messy logic needs to be organized.

12. Classic way
Requirements
A company provides IT Body Leasing. They
have some Employees, and a lot of Freelancers
as Subcontractors. Currently, they use Excel
sheets to manage their Customers, Freelancers,
Timesheets and so on. The Excel solution does
not scale well. It is not multi-user ready and does
not provide security and audit logs. So they
decided to build a new web-based solution. Here
are the core requirements:
•A searchable catalog of Freelancer must be
provided
•The new solution must allow to store the
different Communication Channels available to
contact a Freelancer
•A searchable catalog of Projects must be
provided
•A searchable catalog of Customers must be
provided
•The Timesheets for the Freelancers under
contract must be maintained
Based on these requirements the development
team decided to model everything using UML to
get a big picture of the new solution. Now let’s
see what they did.

13. Define sub domains
Ok, let’s look at the requirements.
We could think that there is a “Body
Leasing” Domain, and that is
completely right. But if we look
deeper into the Domain, we see
something that is called
“Subdomain”. The following
Subdomains might be possible:
 Identity and Access Management
Subdomain
 Freelancer Management
Subdomain
 Customer Management
Subdomain
 Project Management Subdomain

14. DDD way
Okay, what happened here? There are now Bounded
Contexts for every identified Subdomain. The Bounded
Contexts are isolated, they know nothing of each other.
They are only glued together by a set of common types, like
UserId, ProjectId and CustomerId. In DDD this set of
common types is called a “Shared Kernel”. We can also see
what is part of the "Core domain" and what is not. If a
bounded context is part of the problem we are trying to
solve and cannot be replaced by another system, it is part
of the "Core domain". If it can be replaced by another
system, it is a "Generic Subdomain". The "Identity and
access management" context is a "Generic Subdomain", as
it could be replaced by an existing IAM solution, such as
Active Directory or something else.
We applied a set of tactical and strategical patterns to the
model. These patterns help us to build a better model,
improve fault tolerance and also to increase maintainability.
Within each Bounded Context there are Aggregates and
Value Objects. Aggregates are object hierarchies, but only
the root of the hierarchy is accessible from outside of the
Aggregate. Aggregates take care of business invariants.
Every access to the object tree must go thru the Aggregate
and not over one element within. This greatly increases
encapsulation.
Aggregates and Entites are things with an unique id in our
model. Value Objects are not things, they are values or
measures, like a UserId. Value Objects are designed to be
immutable, they cannot change their state. Every state
changing method returns a new instance of the value
Object. This helps us to eliminate unwanted side effects.

15. DDD
Define services corresponding to Domain-
Driven Design (DDD) subdomains. DDD refers
to the application’s problem space - the
business - as the domain. A domain is consists
of multiple subdomains. Each subdomain
corresponds to a different part of the business.
Subdomains can be classified as follows:
•Core - key differentiator for the business and
the most valuable part of the application
•Supporting - related to what the business does
but not a differentiator. These can be
implemented in-house or outsourced.
•Generic - not specific to the business and are
ideally implemented using off the shelf software

16. Business
capabilities
Define services corresponding to
business capabilities. A business
capability is a concept from
business architecture modeling. It
is something that a business does
in order to generate value. A
business capability often
corresponds to a business object,
e.g.
Business capabilities are often
organized into a multi-level
hierarchy. For example, an
enterprise application might have
top-level categories such
as Product/Service
development, Product/Service
delivery, Demand generation, etc.

17. KUBERNETES
Quick intro into kubernetes

18. Kubernetes +
Docker
microservices
Actual microservice are actual
console applications that
hosting inside a containers.
Communication between
services is typically done by
REST API, but can use any tcp
and even udp connections.

21. SPRING
Quick intro into spring

22. Spring intro
◦ Spring Framework is a Java platform that provides comprehensive infrastructure support for developing Java
applications. Spring handles the infrastructure so you can focus on your application.
◦ The Spring Framework Inversion of Control (IoC) component addresses this concern by providing a formalized
means of composing disparate components into a fully working application ready for use. The Spring Framework
codifies formalized design patterns as first-class objects that you can integrate into your own application(s).

23. Modules
Spring Framework consists of
features organized into about
20 modules. These modules are
grouped into Core Container,
Data Access/Integration, Web,
AOP (Aspect Oriented
Programming), Instrumentation,
and Test, as shown in the
following diagram.

24. Core Modules
◦ The Core Container consists of the Core, Beans, Context, and Expression Language
modules.
◦ The Core and Beans modules provide the fundamental parts of the framework, including the IoC and
Dependency Injection features. The BeanFactory is a sophisticated implementation of the factory pattern.
It removes the need for programmatic singletons and allows you to decouple the configuration and
specification of dependencies from your actual program logic.
◦ The Context module builds on the solid base provided by the Core and Beans modules: it is a means to
access objects in a framework-style manner that is similar to a JNDI registry. The Context module inherits
its features from the Beans module and adds support for internationalization (using, for example, resource
bundles), event-propagation, resource-loading, and the transparent creation of contexts by, for example, a
servlet container. The Context module also supports Java EE features such as EJB, JMX ,and basic
remoting. The ApplicationContext interface is the focal point of the Context module.
◦ The Expression Language module provides a powerful expression language for querying and manipulating an object
graph at runtime. It is an extension of the unified expression language (unified EL) as specified in the JSP 2.1
specification. The language supports setting and getting property values, property assignment, method invocation,
accessing the context of arrays, collections and indexers, logical and arithmetic operators, named variables, and
retrieval of objects by name from Spring's IoC container. It also supports list projection and selection as well as
common list aggregations.

25. Data Access
Modules
◦ The Data Access/Integration layer consists of the JDBC, ORM, OXM, JMS and
Transaction modules.
◦ The JDBC module provides a JDBC-abstraction layer that removes the need to
do tedious JDBC coding and parsing of database-vendor specific error codes.
◦ The ORM module provides integration layers for popular object-relational
mapping APIs, including JPA, JDO, Hibernate, and iBatis. Using the ORM
package you can use all of these O/R-mapping frameworks in combination with
all of the other features Spring offers, such as the simple declarative transaction
management feature mentioned previously.
◦ The OXM module provides an abstraction layer that supports Object/XML
mapping implementations for JAXB, Castor, XMLBeans, JiBX and XStream.
◦ The Java Messaging Service (JMS) module contains features for producing and
consuming messages.
◦ The Transaction module supports programmatic and declarative transaction
management for classes that implement special interfaces and for all your
POJOs (plain old Java objects).

26. Web Modules
◦ The Web layer consists of the Web, Web-Servlet, Web-Struts, and Web-Portlet
modules.
◦ Spring's Web module provides basic web-oriented integration features such as
multipart file-upload functionality and the initialization of the IoC container using
servlet listeners and a web-oriented application context. It also contains the web-
related parts of Spring's remoting support.
◦ The Web-Servlet module contains Spring's model-view-controller (MVC)
implementation for web applications. Spring's MVC framework provides a clean
separation between domain model code and web forms, and integrates with all the
other features of the Spring Framework.
◦ The Web-Struts module contains the support classes for integrating a classic
Struts web tier within a Spring application. Note that this support is now
deprecated as of Spring 3.0. Consider migrating your application to Struts 2.0 and
its Spring integration or to a Spring MVC solution.
◦ The Web-Portlet module provides the MVC implementation to be used in a portlet
environment and mirrors the functionality of Web-Servlet module.

27. AOP and
Instrumentation
Modules
◦ Spring's AOP module provides an AOP Alliance-compliant aspect-oriented programming
implementation allowing you to define, for example, method-interceptors and pointcuts to cleanly
decouple code that implements functionality that should be separated. Using source-level
metadata functionality, you can also incorporate behavioral information into your code, in a
manner similar to that of .NET attributes.
◦ The separate Aspects module provides integration with AspectJ.
◦ The Instrumentation module provides class instrumentation support and classloader
implementations to be used in certain application servers.

28. Usage scenarios

29. TYPICAL ARCHITECTURES
Usual cases of the systems

30. •Decomposition patterns
• Decompose by business capability
• Decompose by subdomain
•The Database per Service pattern describes how each
service has its own database in order to ensure loose
coupling.
•The API Gateway pattern defines how clients access the
services in a microservice architecture.
•The Client-side Discovery and Server-side
Discovery patterns are used to route requests for a client to
an available service instance in a microservice architecture.
•The Messaging and Remote Procedure Invocation patterns
are two different ways that services can communicate.
•The Single Service per Host and Multiple Services per
Host patterns are two different deployment strategies.
•Cross-cutting concerns patterns: Microservice chassis
pattern and Externalized configuration
•Testing patterns: Service Component Test and Service
Integration Contract Test
•Circuit Breaker
•Access Token
•Observability patterns:
• Log aggregation
• Application metrics
• Audit logging
• Distributed tracing
• Exception tracking
• Health check API
• Log deployments and changes
•UI patterns:
• Server-side page fragment composition
• Client-side UI composition

31. SAMPLE PROJECT
Spring boot + docker and minikube

32. THANK YOU !