Microservices and Standards; Request / Response

Standards are key to implementing a Microservice Architecture.  In this article, I want to focus on the Request and Response types.   A request usually enters a gateway into a microservice architecture system.  That request is processed and a response is generated.  Then, another request is generated from the second microservice which processes and generates a second response. This process goes on for several, sometimes hundreds of microservices until finally a response leaves the system.  To correlate the various requests and responses with a unique transaction all requests/responses must share a transaction ID.  In addition to a transaction, it is also important to identify the originating client that made the originating request.  Therefore, having a base request/response type shared among all microservices will help ensure that the processing of these requests and responses can be standardized across the system.

Rubens Gomes

Transitioning to a Microservices Architecture - Part 2

Microservices and the Development Organization

Microservice architecture is based on the principles of modular systems that comply with the domain-driven design paradigm.  That is, the architecture is broken into sub-domains with delegated specialized responsibilities that are delineated from other modules by what is called a boundary context.  Therefore, in order to have specialized knowledge that is best able to address the concerns of these sub-domains, it is best to have a development organization that has teams of experts in the particular sub-domain. The team becomes the owner of microservices in that sub-domain.  This type of development organization is key to implementing a microservices architecture.

As stated in Conway's Law:

"O]rganizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations."

The implications of Conway's Law are fundamental to the successful implementation of microservices architecture.  Because a microservice is a module with a responsibility within a domain therefore with a clear boundary context, having teams that become delegated to work on that specific sub-domains will tend to facilitate the implementation of microservices.

Again, what I am trying to say is that in order to achieve the best results from a Microservice Architecture it is imperative that an organization is broken down into sub-domain knowledge expertise.  The Microservice Architecture goes hand in hand with Conway's Law.  That is, by breaking organizations into sub-domains, you force those organizations to create applications that more uniquely resemble the microservices of those sub-domains.  The communication within those expertise groups becomes very cohesive, unique, and very focused on the intents/requirements of those sub-domains.  This will help create a Microservice architecture. 

In fact, one way to force an organization to move to a Microservice Architecture is to use the reverse (or also known inverse) Conway's Law pattern, which basically states that by breaking an organization into groups of sub-domain experts you end up creating a Microservice Architecture.

Rubens Gomes

Why I Like Microservices

In order to explain some of my reasons why I like the microservices architecture style, I write and compare monoliths vs microservices based on practical real-life experiences of working with software development for more than 30 years in both small and large companies.

Monolith Development Environment Setup

The setup of a developer environment is one of the most important steps a developer must take when starting a job.  It entails not only the configuration of tools (e.g., IDEs, text editors), networking access, familiarity with databases, and source control, but most of all having an environment that facilitates the development and maintenance of the application.  And this is right off the bat one of the issues I have with monolith systems.  Monoliths are usually very complex to set up.  I have a few real-life examples of spending over a week just to get my development set up for a single monolith application.  It is sometimes licensed to use platforms like J2EE, all the libraries being used, the build itself that involves several components, and the database which is usually much larger.  Having the tests set up and running. Learning about the entire business domain. Everything in a monolith is orders of magnitude more complex than in microservices.

In one job it took me over two weeks to set up my development environment for one of the main monolith applications in that department. The monolith was a J2EE backend server implemented using IBM WebSphere.  It not only required installation of IBM WebSphere locally but lots of various configurations for the various components (database, interface to other systems, access to multiple libraries.) The build was very complex as there were different components being built with different property configuration files.

Monolith Long Meetings and Long Releases

I remember while being a senior architect at a very large enterprise when I used to attend weekly meetings with project managers, the QA manager, and the department manager to discuss the various features that were being implemented for the next release. The wall had all these different features and where each feature was in the development lifecycle phase.  As the timeline for the next release approached we had discussions on what was ready, and what was still in QA testing, and when we would think we could start planning a deployment date.  Everything took longer: development, testing, interaction with various teams, orchestrating the different projects, synchronizing the different features being developed in parallel, contacting the Operations teams to set up time for deployment, and on and on. This is to me one of the great drawbacks of monolith systems, the time it takes to get something in production. It usually encompasses so many steps that can take months just to get a single release in production.

Since there were various features, trying to get all of them in a single release was not always possible, we broke different projects into separate branches.  And those branches would move in parallel. At the same time, developers were cranking code, issues would arise in production therefore requesting hot fix branches to be created.  As if that was not enough we had all the operational issues to deal with.  When to deploy, who was going to deploy, at what time, and so on?

Microservice Development Environment Setup

On the other hand, a microservice typically has smaller databases, fewer libraries, a much less complex business sub-domain component, fewer tests, and of course much fewer lines of code to deal with. I have seen real-life experiences of a contractor joining a team in the morning, and in the afternoon having a development set up to work on a specific or few microservices.  And not only that being able to start coding on the first day!

From my previous experiences with monoliths, once we had converted it to microservices, things became so much easier.  Setting up a development environment in Eclipse or IntelliJIDEA only took a matter of minutes.  All I had to do was to clone the microservice project locally and import it to Eclipse as a Maven project.  Then, running builds was simply executing CLI commands or pressing a button in DevOps Microsoft Azure.  Bottom line from the IDE I was ready to start modifying the code in a matter of minutes.

Why Is It Easier to Work with Microservices?

First, microservices are very small applications that are focused on doing one thing and doing it well.  Therefore, there is no longer all of the monolith's different technologies, components, databases, and libraries to deal with.  Furthermore, the build of microservices becomes much simpler and faster since it does not depend on the various component libraries found in monoliths.  Since microservices are focused on a specific sub-domain the learning curve is much faster. Our brains are more capable of dealing with one smaller problem at a time; versus in a monolith that deals with everything at once.

Getting things up and running, writing a test, writing a feature, being focused, delivering features, fixing bugs everything is SO MUCH faster and easier when you are working on microservices compared to monoliths.  In a microservice, we can become very focused on a small area of the business, and we can ensure that features are delivered faster to production.  That's because testing is easier, and faster.  And builds and deployments are not only easier but much faster.  I have seen cases where a PR was approved in the morning, and the code was in production on the same day.  Also, tracking issues in logs with microservices is simpler because we can set up queries on specific applications.  And that means easier troubleshooting!

Rubens Gomes

Transitioning to a Microservices Architecture - Part 1

I had the opportunity to play a technical lead role in the implementation of  American Airlines Ticketing department microservices architecture from 2016-2023.  The AA Ticketing department is responsible for the booking and payment processing of over 700K airline tickets daily.  The company's IT department started its IT transformation around 2017, and the ticketing team was one of the first to have microservices in production. 

The transitioning to Microservices involves significant changes not only to the technical architecture, and continuous implementation/delivery but a social and cultural organizational change.  In a microservice architecture, the teams become more independent and self-organized around a specific piece of the domain.  That team maintains the expertise not only on a specific business sub-domain but is also responsible for its development, deployment, and production support.

In addition to the team organization structural changes, a transition to microservices requires fundamental components that must be in place for its successful implementation.  I would like to elaborate on some of these components next, and why they are essential in a microservices architecture.

Please see my next edition of "Transitioning to Microservices Architecture - Part 2" coming up.  I have so much to talk about this topic since I spent significant time seeing from the ground-up in a real and practical large microservices architecture implementation in a very large enterprise.  

Rubens Gomes