Using Microservices on z Systems With CICS Improves Flexibility and Reliability
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.
comments powered by