CURRENTS
Instead, align the teams around
the business capability. Microservices are isolated, so you can
scale them as you require. For
some, you could bring up several
identical services and distribute
the load accordingly. For others,
you might scale one or two
instances vertically, keeping
an eye on high availability.
A microservice should be, as
the name suggests, small, but also
stateless-although this isn't a
hard requirement. Additional benefits exist when one team owns the
entire stack and each microservice
is independent of the others.
For example, if you have new
hires, they can quickly understand
how the microservice works. It also
doesn't matter what language it's
written in. Want to give new hires
who know Java* a side project? Let
them write it in Java. Need a particular microservice to be highly
performant? Write it in Assembler
or C. All you have to do is agree on
the interfaces so each team knows
how to talk to the others. It's a
good idea to version the APIs you
expose, too, to allow for changes
down the road.
Above all, make the communication explicit. (Those of you
who have dabbled with functional
programming will be familiar with
these ideas: no side effects.) These
microservices often communicate
with RESTful JSON, but it isn't the
only option. It must be lightweight
so you don't spend all of your time
chatting and little time processing.
Mainframe
and CICS as Host
To host these services you
want something that's reliable,
understands many languages,
can talk RESTful JSON and
already has tooling for DevOpsstyle deployment of resources in
this environment. This sounds
like IBM z/OS* and CICS*. You
can build and deploy resources
quickly and dynamically with a
pipeline utilizing tools such as the
z/OS Provisioning Toolkit
The z/OS Provisioning Toolkit is a simple command line utility
for the rapid provisioning of z/OS development environments,
including CICS. It's available at no charge of z/OS V2 clients.
Learn more about the toolkit, download it and get started at
developer.ibm.com/mainframe/products/zospt.
CICS Build Toolkit, DFHDPLOY
and UrbanCode* Deploy. CICS
even supports versioned APIs and
manages workloads.
But this brings us back to the
issue of provisioning the microservices themselves. It quickly
becomes apparent that you want
a technology to host several
of these in an isolated manner
and make them easy to update.
Container technology came about
as a way to solve this problem, by
allowing you to define an image
(i.e., a view of what you want
the microservice to look like)
and then deploy it as a container
(just an instance of an image),
abstracting away many of the
usual issues of deployment. Making this process fast changes the
game and can allow new ways
of working.
Using the z/OS
Provisioning Toolkit
Enter the z/OS Provisioning Toolkit (ibm.co/2kpm8Xj). It's useful
for systems beyond CICS, but, as
an example, can be used to bring
up a new CICS region in two
minutes. This helps in quickly
deploying microservices, but it's
also useful for application development. Each developer could
have her own CICS region, in use
only for as long as required. If
the developer makes a mistake,
it doesn't matter. Starting over
again only takes a few minutes.
This technology revolves
around images. An image is a
specific definition of a layer of
your system-back to the cake
analogy. The beauty of this
approach is that you can create
a new image by stacking together
existing images.
For example, you could start
from an existing image defining
a CICS Transaction Server VS 5.3
region with Liberty. You can say
"add to this, a web application
archive (WAR) file, to create a
16 // MARCH/APRIL 2017 ibmsystemsmag.com
pg 14-17.indd 4
2/7/17 1:09 PM

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page.
If you would like to try to load the digital publication without using Flash Player detection, please click here.