There is no doubt that the pace of business change is not slowing. With this business rate of change comes the need for business applications to change at great speed. What may be less visible is the direct relationship between the speed of application change and the need for new application architectures.
First, we need to understand the difference between the client-server applications of the last thirty years and the microservices architectures that have been developing for the last five or ten years. Client-server gets its name from having two applications. The client is on the device in front of the user. The client application generally handles the user interface elements. It is what makes most of the application responsive. The server is in a data center, and it handles business logic and data. The server also handles any function that requires coordination between multiple clients. The same pair of client and server applications might handle a hundred different business processes. In addition, the version of the client application is tightly coupled to the version of the server. A new feature usually requires coordinated updates to both the client application and the server application. This locking together of software in multiple locations restricts the ability to update the application. The client side is most troubling, as it requires updates to many end user computers, and those computers are frequently offline. Typically, a client-server application is updated a few times per year. Lead times for changes might be months.
In contrast, web applications generally don’t have an install on the client; everything happens on the server. All the clients need is a compatible web browser. Simply moving to a web application often means changes are simplified. Only the server requires updating, and all users will always get the latest application version. Servers are online all the time and there are fewer of them, so updates are more controllable. A basic web application can be updated multiple times per month, and changes might take only days to go from idea to implementation. Both client-server and basic web applications still have large pieces of software that provide all of the application functionality. Both generally handle multiple business processes and require updating of the entire application. It is this all-or-nothing update methodology that becomes a restriction. It isn’t practical to update an entire web application more than a few times per week. The amount of testing required for each change becomes the limiting factor. Failing to test adequately leads to the entire application being unavailable.
The next required step, to enable faster application changes, is to allow smaller units to update. The logical solution is to break the application into the smallest units possible. The smaller the unit, the easier it is to update. As a result of this objective, the large monolithic web application is rapidly broken into many smaller units. Each unit needs to perform one basic function and interact with the other units. The units are microservices. Each microservice has a defined set of inputs and a defined set of outputs. The microservice processes the input to produce the defined outputs. How it does this is not important to the other microservices. For example, the input might be a product stock code and store number. The output might be the amount of stock on hand at that store and the date of the next delivery of that item to the store. This microservice might be used by the storefront application to display stock and delivery time to customers who are ordering product. The same microservice might be used by the staff in the store as part of their inventory management screens. Only one part of a business process is served by this microservice. However, the microservice can be used by multiple processes because it has well-defined inputs and outputs. If the business moves to just-in-time stocking, the microservice might be rewritten. It could return the amount of stock at a local warehouse rather than on hand in the store. This application change would be far simpler to roll out, and roll back, than updating the entire application.
Each microservice can treat every other microservice as a black box. Provided the microservice processes the inputs to produce the outputs, it does not matter how the processing is done. This way, each microservice can be updated independently and as frequently as required. The only way for software development to keep pace with the rate of business change is by keeping each piece of software small. The small units link together to make a larger application.