Empowering Business & Developers with Microservice Architecture: Part-I Introduction

As business, we create the room to showcase the products and value them in all the aspects. We’re the one who put the idea to create own world.

As developers, we’re the builder of new era, creating the ideas and putting logics in the form of code that helps business to transform their idea in the shape of a Software products. On the one hand we help to simplified complex problems for business and on another aspect, we craft various patterns & practices to layout the plan and to resolve these complex problems.

From above both business and developers are two different sides of a same coin. I am trying to cover both aspects with respect to microservices architecture. In this first part, I am starting with the introduction of microservice architecture.

From the early days of having tiers and layers being represented interchangeably and mostly being same, we have come a long way to the world of Microservices. As a software developer I am not able to shake off the contentment I had just to see my code neatly stacked across the three layers lovingly referred as Presentation layer, Business layer and the Database layer. The application architecture we are talking about is referred as Monolithic architecture. Depending on the level of our prowess with OOPs we would employ classes, interfaces and shared libraries to keep the code manageable.

There wasn't anything wrong with the approach. However, there wasn't humongous amount of internet traffic or expectation of lightning speed responses to deal with either. So, after employing best of patterns and spending days of refactoring it was becoming apparent that it wasn't enough to handle the enterprise applications. Before we move on to Microservices let's see what are the challenges with Monolithic architecture.

Monolithic Architecture Limitations

I will try to list them here in the sequence of importance as a developer (in my experience):

1. System Failure - irrespective of problem in the smallest part of the application, the whole system could fail.
2. Code Complexity - despite the best of efforts while employing all best coding practices the code base could grow up to be huge and complex. Any new person coming in might have a learning curve which is not entirely suitable to the immediate response needs.
3. Expensive Changes - with the growing code base and inter-module dependency it is only a matter of time that making changes becomes painstakingly slow to code and even more so when deploying or testing.
4. Technology Adoption - above points coupled with lack of possibility to adapt new technology results in only even higher turnaround time which is not suitable in order to changing market demands resulting in a slower response to market needs.
5. Scalability - could only be achieved at the whole application level and not just a component/part of it. This mean - that you will be investing for the sections of the application which don't need it or won't benefit from it. Cost overhead.
6. Continuous Deployment/Integration - will become more challenging with every growth in application size/functionality, eventually becoming impossible to be deployed frequently. Even a small change no matter whether it is a type or conditional change can trigger build and run multiple tests. However, a defined rules or set-of-boundaries can only manage the CI/CD.

Monolithic Architecture Benefits

1. Design - makes it easier to develop the application at least in the initial stages, clear cut component boundaries with separation of concerns makes the development easier and focused. But this can also be considered - testing becomes harder as the system grows.
2. In some extent, it provides ease of debugging, testing and can easy to troubleshoot. In most of the cases, developer can be less concern for deployment being a single unit of deployment.
3. Simple to Test - by virtue of the whole application at one place the testing was simpler with not too many scenarios involving communication across boundaries. It is important to note here that testing is simple but not inexpensive - since the entire application is to be tested. However, testing depends on the complexity of the application. But testing of monolith application is always consume less resources in comparison to distributed application.
4. Faster Communication - with all components residing and operating with in a process [mostly].
5. Easy Monitoring - both health and state is easier and doesn't impact design and investment much. Do keep this in mind as monitoring would be a practice that must be practiced from the beginning when dealing with Microservices.

Microservices

The term microservices was used for the first time in mid-2011 at a workshop on software architects. In March 2012, James Lewis presented some of his ideas about microservices. By the end of 2013, various groups from the IT industry started having discussions about microservices, and by 2014, they had become popular enough to be considered a serious contender for large enterprises.

In 2014, James Lewis and Martin Fowler came together and provided a few real-world examples as well as presenting microservices (reference- https://martinfowler.com/microservices/ ) as follows:

The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and are independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and may use different data storage technologies.

Microservices Attributes

In view point of a developer, microservices attributes are the set of practices and discipline along with these attribute-based development, that creates a true Microservice architecture. Let's see what are the core attributes are:

1. Single/Isolated Functionality - don't try to achieve too much with in a single Microservice. Instead, design it for one reason only and do that well. This means that the design should try and avoid any dependency on any other part of the functionality. This part is extremely important in my opinion as it lays the basis for the rest of the attributes. This would require a separate discussion altogether. We will cover it in another discussion.
2. Isolated Data & State - each service owns its data and its state. It does not share ownership for the same with any other application or its part.
3. Independent Deployment - is a cumulative effect of both the points above. This also helps you with the continuous deployment as well.
4. Technology Adoption - is easier with first two points taken care of. Since it would not have an impact on any of the existing modules. The beauty here lies in the fact that you could have two different versions of a Microservice in two different technologies. Extremely beneficial
5. Consistency and Resiliency - has to be impeccable. If you can't rely on a service to return with in a speculated period or rely on it to be always available, then the whole purpose of it is lost.

As developer, the transitioning of the monolithic application is not just another fad or forced change. This is a natural and gradual transition in the way we develop application while responding over time to the change in sheer size of the applications or the volume of traffic these applications are meant to handle.

Closing

In this first part, I tried to cover very basic and introductory level aspect of microservices in view of a developer. In the upcoming series, I will cover more advance topics.

*Cover image credits: Medical abstract vector created by Starline