Using Microservices on IBM Z With CICS Improves Flexibility and Reliability
One of the goals of a microservices architecture is to help with DevOps.
By Chris Poole03/01/2017
By now, we’re all familiar with the DevOps process: better join your development and operations teams so you can catch bugs earlier and ultimately be more agile in an increasingly competitive market. But it’s an end goal.
We talk of continuous delivery, testing and deployment, but it’s difficult to accomplish when a monolithic application is owned by several teams across the organization. Furthermore, what if some parts of the application need horizontal scaling while others could benefit from vertical scaling? One fact holds true: Development, test and deployment speed decrease as complexity and size of the application increase.
These problems are often due to the interrelated nature of the app. It consists of many cogs in the machine, all tightly meshed together. What if we could decouple some of them to allow them to spin independently? One of the goals of a microservices architecture is to help with DevOps.
Why don’t we split this application into smaller pieces, each talking to the others via some communication method? That might sound like a service oriented architecture (SOA), but often this architecture isn’t fine-grained enough, and could be reduced to form a service oriented around a business deliverable. A smaller deliverable enables you to adopt the DevOps promise of delivering new functionality more quickly than before.
Layers of Service
Let’s stop and think about cake layers for a moment—layers of sponge separated by jam and cream—except let’s call these layers presentation, business logic and data access. Though not as mouthwatering, it’s a common architectural pattern and more recognizable as the kind of stack you might often see.
A microservice architecture is an architectural pattern that lends itself to providing fast deployment of new services. Thinking about the cake, a microservice is a vertically cut slice. It has all of the layers it needs to do something valuable. How large is this slice? How wide does it need to be? As wide as necessary but as narrow as possible, oriented around a particular business function.
Microservices are loosely coupled SOAs with bounded contexts. One application can consist of many services, each its own process, each owning the complete stack it needs to perform a valuable business function, with a lightweight communication method to chat with one another. Each should be independently deployable so that one small team (or individual) can own an entire microservice and deploy updates as required.
Taking an online retailer as an example, you might see that it consists of an order processing system, a fulfillment system and a tracking system. Each of these has different business capabilities and its own requirements. Because they don’t all need access to the same data, and they might require different levels of security and compliance to run, split them up. Don’t give one team ownership of all front-end systems, another team all back-end systems, etc. 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 DevOps-style 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 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 new image.” This latter image will be the custom microservice, with the Java code you’ve been developing, in the WAR file. To create an instance of this image (i.e., to provision an instance of this service), create a container. The z/OS Provisioning Toolkit can construct this container, based on the image you specify, automatically assigning ports and application identifiers as necessary, pulling in a base definition appropriate for your workplace’s environment.
You can find further instructions on using the z/OS Provisioning Toolkit on developerWorks* (ibm.co/2jBWuxO), but in short, after a small amount of configuration particular to your workplace, you can run a command like zospt run cics_53_liberty from UNIX* System Services, and bring up an entire CICS Transaction Server V5.3 region, along with CICS Liberty, in just a few minutes. The toolkit can be downloaded at no charge.
The microservice architectural pattern can help your teams deliver with greater agility by allowing a team to own the whole stack of a particular business function.
CICS on the mainframe is an ideal host, given its support of multiple languages and renowned reliability. The z/OS Provisioning Toolkit allows you to quickly provision a CICS region (along with CICS Liberty or anything else you configure) for development, testing or deployment of a microservice.
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.
Chris Poole is an IBM Master Inventor working on the CICS Development team.
Sponsored Content3 Unknown Risks in Your Resiliency Armor
Post a Comment
Note: Comments are moderated and will not appear until approvedcomments powered by Disqus