2. scope
Let’s talk about …
• Microservices :
• Microservices … what makes them different ?
• Microservice Architectures
• What is Docker?
• Containers are in .
• How to use Docker for microservices.
• A Step Further :
• Business Application: Outdated Web Services.
• Demo of a Java Microservice running in a Docker container, providing status updates
on a Bitcoin Node block height.
3. about me
Lana Kalashnyk
BAAS Computer Science minor Business Administration
AS in Computer Science emphasis on Networking
Cisco CCNA I-IV, Red Hat JAX-RS, NetSuite, CODE WPF, Oracle
Java training
Houston Java User Group, Houston .Net User Group, Texas
DevOps User Group, PuppetConf Test Pilot
Fan of back end engineering, cloud technologies, innovation and
running.
www.wcgp.co
Twitter: lana_vk
4. THE RISE OF THE MICROSERVICES
When
did
Microservices
became
a
thing?
Not
a
new
Idea,
but
a
rela:vely
new
trend
in
So=ware
Architectures
for
smaller
companies.
Men:oned
in
2011
Yegge
Memo
to
Google
about
the
way
Amazon
largely
runs
their
company
as
microservices
communica:ng
exclusively
over
APIs.
hJps://plus.google.com/+RipRowan/posts/
eVeouesvaVX
5. COMPANY CULTURE MATTERS
“Any
organiza:on
that
designs
a
system
(defined
broadly)
will
produce
a
design
whose
structure
is
a
copy
of
the
organiza:on's
communica:on
structure.”
–
Melvin
Conway,
1967
6. WHAT IS A MICROSERVICE ?
Microservices
is
a
so=ware
architecture
style
in
which
complex
applica:ons
are
composed
of
small,
independent
processes.
These
processes
communicate
with
each
other
using
language-‐agnos:c
APIs.
These
services
are
small,
highly
decoupled
and
focus
on
doing
a
small
task.
Facilitate
a
modular
approach
to
system-‐building.
The
service
is
autonomous;
it
is
full-‐stack
and
has
control
of
all
the
components
–
UI,
middleware,
persistence,
transac:on.
“A
perfect
JavaEE
microservice
is
single
ECB
component
within
a
WAR
deployed
on
a
single
server”
7. BENEFITS OF USING MICROSERVICES
A
Well
wriJen
Microservice
operates
on
a
single
resource.
Allows
to
focus
on
building
a
product
rather
than
a
project.
(each
service
is
developed
independently,
not
a
refactor
of
a
monolith)
Independently
deployable.
Smart
endpoints.
RESTFUL
protocols
or
Message
queues
can
be
used
for
non-‐blocking
communica:on.
Doesn’t
have
to
be
all
in
one
technology
Infrastructure
Automa:on
:
making
releases
boring
.
Fault
isola:on
:
Helps
with
fixing
the
issue,
rather
than
deploying
a
patch
.
8. PITFALLS OF USING MICROSERVICES
Crea:ng
so-‐called
Nanoservices
.
Services
that
are
too
granular,
their
maintenance
and
implementa:on
are
counterproduc:ve.
Lack
of
Tooling.
Transi:oning
to
a
microservice
architecture
implies
investment
into
management
and
monitoring
tools.
Failure
to
do
so
will
surely
result
in
a
poor
system.
Change
Management,
Transac:ons
and
Data
Integrity
can
be
tricky
12. APPROACH TO ENGINEERING : THE TWELVE FACTORS
I. Codebase
One codebase tracked in revision control, many deploys
II. Dependencies
Explicitly declare and isolate dependencies
III. Config
Store config in the environment
IV. Backing Services
Treat backing services as attached resources
V. Build, release, run
Strictly separate build and run stages
VI. Processes
Execute the app as one or more stateless processes
VII. Port binding
Export services via port binding
VIII. Concurrency
Scale out via the process model
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
XII. Admin processes
Run admin/management tasks as one-off processes
13.
14. WHAT ARE CONTAINERS ?
Containers
are
a
solu:on
to
the
problem
of
how
to
get
so=ware
to
run
reliably
when
moved
from
one
compu:ng
environment
to
another.
Put
simply,
a
container
consists
of
an
en:re
run:me
environment:
an
applica:on,
plus
all
its
dependencies,
libraries
and
other
binaries,
and
configura:on
files
needed
to
run
it,
bundled
into
one
package.
“By
containerizing
the
applica:on
plalorm
and
its
dependencies,
differences
in
OS
distribu:ons
and
underlying
infrastructure
are
abstracted
away.”
–Paul
Rubens
CIO
15. WHY DO WE NEED THEM?
Immutable
Servers
–
BIG
WIN
Immutable
containers
mean
that
they
will
never
be
changed.
A
new
version
of
an
applica:on
is
deployed
in
a
new
container
No
More
Magical
Servers.
You
deploy
in
the
environment
you
build
the
product
for…
all
the
:me.
Isola:on.
Applica:ons
are
isolated
by
the
container
boundaries.
Smarter
use
of
resources
when
compared
to
separate
VMs.
Con:nuous
Integra:on
and
Delivery
.
16. WHAT IS DOCKER?
Docker
is
an
open
plalorm
for
building,
shipping
and
running
distributed
applica:ons.
It
gives
programmers,
development
teams
and
opera:ons
engineers
the
common
toolbox
they
need
to
take
advantage
of
the
distributed
and
networked
nature
of
modern
applica:ons.
Docker
consists
of:
The
Docker
Engine
-‐
container
virtualiza:on
technology
combined
with
a
work
flow
for
building
and
containerizing
applica:ons.
Docker
Hub
-‐
SaaS
service
for
sharing
and
managing
your
applica:on
stacks.
18. DEPLOYING MICROSERVICES ON DOCKER
Microservice
and
any
necessary
so=ware
is
“baked”
into
a
Docker
Image.
The
Image
is
created
based
on
a
Docker
file.
All
necessary
set
up
is
specified
here.
Docker
Images
are
stored
in
Docker
Registry
Mul:-‐container
applica:ons
can
be
defined
using
Docker
compose.
Containers
can
be
deployed
as
a
Cluster
using
Docker
SWARM.
19. TRANSITION FROM .NET WEB SERVICES ON IIS
In
a
recent
project
we
replaced
outdated
.Net
Web
Services
running
on
an
IIS
Service
with
Java
Microservice
deployed
on
Docker
in
a
Wildfly
AS
.
Good
candidate
due
to
few
dependencies.
Already
separated
by
product
in
separate
web
services
Needed
to
dras:cally
cut
costs
Low
risk
project
since
doesn’t
provide
cri:cal
data
writes
Other
applica:ons
in
the
eco
system
were
already
Java
based
22. WORK IN PROGRESS
Commipng
to
a
microservice
architecture
beyond
a
small
project
is
a
much
bigger
undertaking.
Define
architecture
paJerns
for
cross
technology
interac:ons
Define
scaling
mechanisms
Define
state
monitoring
Or
deploy
on
AWS
or
Google
to
leverage
their
pre-‐built
tools
23. Example
The
following
solu:on
imitates
the
previous
architecture.
It
consists
of
:
Virtual
Machine
:
Complex
Web
Applica:on
(
Bitcoin
Node)
Docker
Container
:
Java
Microservice
polling
the
Bitcoin
Node
Simple
ReactJS
Web
Page
displaying
the
results.
24. PRE REQUISITES
Install
a
Bitcoin
Node
I
used
AWS
EC2
t2.medium
instance
w/
100
GiB
volume.
Configure
the
Security
group
to
allow
traffic
to
our
node
from
other
bitcoin
nodes
and
our
applica:on.
25. CONFIGURE THE BITCOIN NODE
Install
the
bitcoin
node
so=ware
on
your
provisioned
server.
Configure
the
node
to
accept
JSON-‐RPC
requests
from
our
IP
only.
sudo
vi
.bitcoin/bitcoin.conf
Start
the
bitcoin
daemon.
Now
you
can
manage
it
using
bitcoin-‐cli
commands
sudo
bitcoind
–daemon
sudo
bitcoin-‐cli
ge:nfo
26. WRITING A JAVA MICROSERVICE
Install
Maven,
Git,
NetBeans
(or
an
IDE
of
your
choice)
Only
work
on
a
single
resource
Here
a
Bitcoin
Node
Make
the
end
points
RESTFUL
(PUT,
POST,
GET)
Use
JSON
to
package
objects.
Report
Errors
Log
29. WILDFY SWARM
Add
Wildfly
Swarm
Dependency
&
Plugin
to
package
the
service
into
a
container
in
your
pom
file
<dependency>
<groupId>org.wildfly.swarm</groupId>
<ar:factId>wildfly-‐swarm-‐jaxrs-‐weld</ar:factId>
<version>1.0.0.Alpha5-‐SNAPSHOT</version>
</dependency>
<dependency>
<groupId>org.projectlombok</groupId>
<ar:factId>lombok</ar:factId>
<version>1.16.2</version>
</dependency>
…
<!-‐-‐
***
Swarm
Plugin
***
-‐-‐>
<!-‐-‐
Specify
the
main
class
in
your
app
-‐-‐>
<!-‐-‐
Executu:on
phase
and
goal
-‐-‐>
<plugin>
<groupId>org.wildfly.swarm</groupId>
<ar:factId>wildfly-‐swarm-‐plugin</ar:factId>
<configura:on>
<mainClass>com.mius.javajaxrsmicroservice.JaxRSServriceSwarmMain</mainClass>
</configura:on>
<execu:ons>
<execu:on>
<phase>package</phase>
<goals>
<goal>package</goal>
</goals>
</execu:on>
</execu:ons>
</plugin>
30. COULD STOP HERE..
Build
the
Service
and
package
it
into
a
Swarm
Container
mvn
clean
package
Jar
file
is
fully
executable…
Execute
using
“java
–jar
JavaMSDocker-‐swarm.jar”
but
then
we
wouldn’t
get
to
talk
about
Docker.
32. CREATE A DOCKER FILE
Create
a
file
name
“Dockerfile”
Specify
the
base
image
FROM
java:openjdk-‐8-‐jdk
Copy
over
your
files
into
the
container
ADD
target/JavaMSDocker-‐swarm.jar
/opt/JavaMSDocker-‐swarm.jar
Open
port
8080
for
our
Service
EXPOSE
8080
Configure
the
container
to
run
as
an
executable
ENTRYPOINT
["java",
"-‐jar",
"/opt/JavaMSDocker-‐swarm.jar"]
33. DOCKER COMPOSE
Define
all
services
to
be
ran
together
in
a
.yml
file
Create
a
file
name
“docker-‐compose.yml”
wildflyswarm:
//
define
service
name
build:
.
//
path
to
the
Dockerfile
ports:
-‐
"8080:8080"
//
ports
to
expose
HOST:CONTAINER
34. CREATE YOUR DOCKER IMAGE
Run
the
following
commands
:
docker-‐compose
build
docker
run
–p
8080:8080
javamsdocker_wildflyswarm
Or
docker-‐compose
up
36. REACT PAGE TO DISPLAY THE DATA
For
simplicity
uses
simple
jquery
to
GET
the
bitcoin
node
status
from
the
java
microservice
Uses
virtual
DOM
JSX
transforms
in
browser
