Digital Strategy: Making sense of Microservices

In the course of my work, I’ve often encountered developers in corporate environments bemoaning the lack of a microservices architecture and the infrastructure to deliver microservices. You’ll see people pulling their hair out because core business logic is built into front end components rather than in a smart API layer supporting a microservices-based architecture. Or organisations running old monolithic systems that are neither scalable nor reliable, as if one component of the system fails, the whole thing comes down like a house of cards. There is little doubt that most of the developers in your IT unit will think that developing on a microservices-based architecture is cool and a good thing to do. After all some really great companies like Twitter, Netflix and Amazon moved from a more monolithic design to an architecture based on microservices. But they may not be able to coherently describe why this investment and development effort is necessary for you.

If you hear your people talking about building on an agile framework, what they mean is that they would like to continuously deliver the most important business features to you as their customer. This sounds great, right? But the ‘DevOps’ culture or continuous deployment practices that this requires may not be possible or at least extremely difficult within the context of your existing technical architecture. I’ve noticed that there tends to be a common problem that architects or senior engineers fail to adequately communicate to the IT and Business management why an investment in such an architectural solution is necessary, despite the fact that it is all too often these stakeholders who hold the purse strings that would make such a transformation possible. This is frustrating as having the correct architecture can be a real rocketship in moving your business from a traditional IT services model to a model that supports the integration of business and IT processes that is necessary for product leadership in the digital age. In this short article, I want to simply articulate why a microservices based architecture is so important.

Most of the corporate applications we build are based on a server-side infrastructure which may be hosted in your own data centre or in the cloud. The customer facing applications we build must be accessible via internet browsers or mobile applications. In some cases, your IT system may even have an API that you want to be available to third parties. If you’re asking what an API is, you can just think of it as a programming interface that allows software applications to communicate with one another. Such services communicate with each other using standard internet protocols like HTTP/HTTPS adhering to architectural standards like REST while others are following event-based approaches by utilising message brokers like Kafka, RabbitMQ etc. Now the key point here is that each service is independent and has its own datastore. Because the microservices are isolated, it is easy for a specialist or engineer to have a clear view and understanding of one particular area such as customer receipts without any knowledge of another area such as customer payments.

Now you might reasonably ask why your techies did not start with delivering an architecture based on microservices. It may be due to historical reasons or due to the fact that it is often faster and easier to simply build a business application as a monolith. However, as you start to scale, the advantages of a model based on microservices become more clear. The rise of containerisation has created an environment that now suits microservices, whereas in the past having a single server for each small task wouldn't really have been a feasible option. 

But when starting out with a microservices architecture, one of the key challenges that teams come up with is how to split the application into the multiple services that such an architecture demands. You could do this by simply defining it based on functional services or use cases, by business capabilities or by subdomains in something known as Domain Driven Design. This is a proven method that eases communication through the use of ubiquitous language and focuses on the core aspects of the business known as the domain. A ubiquitous language is just a fancy way of saying a glossary of terms that are clear in that we can all be sure that we are talking about the same thing in a complex environment. This might seem obvious but ensuring that all stakeholders in both business and IT are working in a common language is key to Domain Driven Design. Needless to say, designing the subdomains requires a strong functional understanding of the business, the associated organisation units and jobs to be done. 

Once this process is completed, you would theoretically have a model where each of the new microservices are self-contained in that they deliver a single business capability. If one service is not available for whatever technical reason, then it does not cause a problem for other services that are currently running successfully. The microservices can communicate with one another on a stateless server via a standard known as REST. This all sounds great, right? However, not so fast. The microservices can communicate with each other but how do you keep the data consistent over multiple independent services each with their own datastore? 

A concept called Event Driven Architecture was proposed to address this. For example, you may have a banking platform where the customer wants to execute an order but you will have to question if he/she has the available funds. Let’s say our microservice called OrderService receives the order. This microservice can then create an order in a pending state and an event called OrderCreated is sent. Another microservice called CustomerService receives the event and checks the available balance. It then publishes either a CreditApproved or CreditDeclined event. This event is then returned to the OrderService microservice which changes the state of the order to either approved or declined. Kudos to Chris Richardson for his work in elaborating this area.   

It’s important to note that microservices are also technology agnostic which means that the services can be built in different programming languages that contribute to the platform. A key advantage is that your developers need only be proficient in their own microservices rather than the whole as is often the case with a monolithic architecture. So if you're moving forward with your digitalisation programme, take a step back and talk to your development team about how you might implement a microservices based architecture to support the growth of your business and digital strategy going forward. Having the right technical setup will support you in attracting the right technical talent and motivate the team - working on clean code on a great architecture makes the job so much more fun.

---------------------------------------------------------------------------------------------------------------

Based in Prague with offices in Brno and Tbilisi, Blocshop is a community {family/ group/collection} of top software engineers building best in class solutions. We are proud of our mantra "keeping our commitments since 2012" as it emphasizes our company-wide focus on meeting our objectives. We are a boutique business who care deeply about staying on top of technology trends and leveraging that expertise to maintain lasting relationships with our colleagues and clients.