Don’t build microservices for the sake of building on a new architecture Industry leaders and analyst predict 2015 will be the year of microservices. Provided they are right, I want to make a plea to CIOs and developers: Please build microservices that serve the business. Don’t build microservices for the sake of building on a new architecture. If you do, you will end up with a bigger architecture problem than you probably have now. Let me explain. First, a primer: Microservices really comprise a loosely defined software development architecture. Although the definition of “microservices” varies, there are a few common elements: Small, single-purpose programming Automated deployments Endpoint intelligence Decentralized control of language I believe an architecture that promotes automated deployments and the decentralization control of a specific programming language moves us all in the right direction. With this kind of architecture in place, we can deploy products, rather than just projects. For example, if we developed a new solution to sell vouchers online, following a products approach would mean the sale and print functionality would be developed and deployed in separate products. This would allow us to make changes and deploy a new print engine without having to deploy any other functionality. This small architecture change will probably solve more than half of deployment bugs and problems. Furthermore, if we develop products using a container technology like Docker, we can automate the deployment of the products and further reduce deployment problems. The approach also would permit us to develop each product in a different language, thus benefiting from language specific advantages or resource expertise. The selected programming language would coexist in harmony. For example, Node.js could be used for the sale product, while Python could be used for the print product. My major concern with microservices is the idea of small programs and superintelligent endpoints. Why does a single-purpose program have to be small? Yes, you might want it to be as simple as possible and consequently as small as possible, but beware of creating an army of programs that no one will be able to maintain or understand their relationships. We should think simple and elegant — not small. I recently read an article that claimed microservices should not be more than 100 lines of code. This statement is ridiculous! Microservices should be as small as possible while taking into consideration the complexities of maintaining and reusing a group of small programs. Architects: If you decide to build multiple microservices, make sure the architecture is documented correctly or you will end up with an unmaintainable army of programs. Again, small should never trump elegant — size should be a consequence of great programming, not a goal. Also beware of the superintelligent endpoint and ultradumb pipeline. Never forget the concept of reusability. Why create a dumb pipeline to write the sales data, while replicating the complex sales business logic to all endpoints? This doesn’t make sense. There is always some business logic that needs to be centralized in order to achieve optimum maintainability and business process governance. Microservices architecture is a move in the right direction. No doubt it will be the driver for faster developments of customer-facing applications and modernization of legacy applications. This architecture also will allow a faster proliferation of future IoT devices. However, microservices implemented incorrectly have the potential to create an unmaintainable architecture that will cause more problems and delays to the business than what they were suppose to fix. Let’s always remember the “service” in microservices and ensure they truly serve the business, not just engineering goals. Software Development