There was a time when programmers would write big programs. And those big programs – probably written in COBOL – would get information, display information, update information, and produce a printed file showing what was done to the file and the final result.
And quite often, another team in the organization would like a similar program written for them. And the programmer would disappear for a week or so, do his magic (and it was usually a man in those days), and come back with a new application that he had written for this other team. And everyone went home happy.
The truth was that most of the functions for the two applications were pretty similar, and so the programmer would look at his old program and copy the bits that he needed for the new program and re-use them. And that idea gets us quite a long way towards describing microservices. The big difference is that, nowadays, the first application would be broken down into discrete components called microservices. And the new program (and every future program that needed to) would re-use the microservice that already existed.
Obviously, each microservice needs to be network connected so that it can be called from elsewhere. It’s modular in structure. And it should work in a continuous delivery software environment. What that means is that a change to a small part of the application requires the rebuilding and redeploying of only one (or a small number of services).
The microservice architectural style can be thought of as a way of building applications as suites of services. Each service is independently deployable and scalable, and each service provides a firm module boundary, which means that different services can be written in different programming languages, can use different data storage technologies, and can be managed by different teams. Each service runs in its own process and communicates using lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable using fully-automated deployment machinery.
You can see the benefits from my old COBOL programmer model, but what other benefits are there from using microservices. Firstly, because microservices are designed to act independently, they are naturally consistent with agile (DevOps) principles. Secondly, it’s very easy to change from one microservice to a new, better one, without affecting the whole application. Each service is changed, tested, and then deployed when it’s proven to be working. This makes developing new applications so much faster. And this leads to the third benefit of improved application quality. The fourth benefit comes in terms of scalability.
If you fancy having a go at creating microservices, what do you need to bear in mind? Firstly, each microservice performs only one job. And it needs to be very good at that job. Secondly, all communication between microservices should be carried out using REST APIs and message brokers. All communication from service to service must be through the service API or must use an explicit communication pattern. Microservices can be continuously integrated and continuously delivered. That results in some microservices being updated more frequently than others. Lastly, to make the application resilient, each microservice can be scaled as much as is needed. Not all microservices need to be scaled by the same amount.
What can possibly go wrong? One answer is that you make your microservices are too small (these are sometimes called nanoservices) that you use more time etc connecting the parts together than you gain from using the microservices.
If this all sounds a bit ‘cloud-y’, you can run microservices on mainframes. There’s a Redbook called “How Walmart Became Cloud Services Provider with IBM CICS”. This highlights the role of microservices in z/OS CICS. In one part it says:
“Microservices architecture is becoming the standard approach for developing, deploying, and managing applications and application components. Small teams work independently and use their technology of choice to create services that are accessed by easily consumed application programming interfaces (APIs). CICS provides the multi-language run time for such teams on a robust, secure, highly scalable z Systems platform. The resulting microservices are stand-alone pieces of code, each with a finite function that can be accessed by anyone on the team and independently deployed. The APIs can call other services or be used alone. It is all about the service that is faster, cheaper, and more flexible than traditional IT provided”.
So, microservices are for the mainframe. They do engage in the API economy, and they are often associated with things like z/OS Connect EE (which provides a framework that enables z/OS-based programs and data to participate fully in the new API economy for mobile and cloud applications) and API Connect (an API management solution that enables automated API creation, simple discovery of assets, self-service access for developers, and built-in security and governance).
Where else will you have come across the idea of microservices? You’ll hear the word Kubernetes. If you’re unfamiliar with it, it’s an open-source container-orchestration system for automating application deployment, scaling, and management. Originally it was designed by Google, and is now maintained by the Cloud Native Computing Foundation. The other name that pops up is Netflix. They developed a microservice framework to support their internal applications, and then open-sourced different parts of that framework. In fact, the tools were later re-implemented as Spring-based tools under the umbrella of the Spring Cloud project. One thing to note is that the Spring Cloud ecosystem uses only Java-based technologies, whereas Kubernetes is a polyglot runtime platform.
To summarize, the main benefits for microservices are:
- Their small size enables developers to be most productive.
- It’s easy to comprehend and test each service.
- You can correctly handle failure of any dependent service.
- They reduce impact of correlated failures.
There are negatives to using microservices. The issues that are usually highlighted are around network latency, message formats, load balancing and fault tolerance. There can also be issues with increased network traffic that can result in slower than expected performance.
I can guarantee that you’ll be hearing a lot more about them on mainframes and elsewhere.
