September 28, 2020
TABLE OF CONTENTS
Many legacy systems in the business world tend to be Monolithic design in nature. A monolithic application is one where it, and it alone, handles all the business needs. Many industries have this architecture in place for their most core applications. This is an easy trap to fall into, too. When projects are young, and the business scope is small, it is easy to create a basic application that handles a limited number of business needs. Turnaround times can be rapid, and updates are quick.
Over time, however, these quick updates for the primary business applications will begin to be completed slower as complexity increases. More features will mean more time devoted to finding a place to make them fit into the application’s overall ecosystem. The team of dedicated developers goes from turning out new features in half a day to taking a day and, eventually, a few days to bring it all together. Deployment times for each of these features will also tend to trend longer as the added complexity may require the application to go offline longer and tie up additional resources. The business has now fallen into this monolithic trap.
At this point, the team starts looking for optimization opportunities. If they can only fit in an overhaul to one part of the system, it will be all right. These will become massive undertakings, with reworkings to the system and ensuring one overhaul will not break other aspects of the application. At the end of the day, some progress will be made, but it still won’t be like the early days. Eventually, more large application overhauls will be needed and will equate to wanted features being delayed. This leads to increased costs and potential losses in revenue.
There is a way out of this trap. Rather than having a single project with huge dependencies that must be accounted for each small change, it’s better to consider breaking it into smaller and more manageable chunks. Each part is responsible for itself and providing an access window to other parts that need the information this part manages. The goal here is to have many smaller independent and specialized parts so that if one part must go offline for maintenance, the rest of the application can stay up and remain productive.
Microservices has been around for fifteen years and is a variant Service-Oriented architecture. What sets Microservices apart is its focus on creating small and lightweight applications specializing in one specific task. These applications provide an API (Application Programming Interface) endpoint to other applications in the business ecosystem that need to utilize it. Some specialized examples would be services dedicated to handling email, authentication, inventory, and invoicing systems.
The benefit of going with Microservices is that businesses upgrade a small part at a time to this new ecosystem; they no longer must worry about interdependence problems or long downtimes while updates are applied to the monolithic application. This enables businesses to take a small aspect of their application offline for maintenance, while the rest of the application stays online and working. Development teams also benefit in the long run as they can focus on a smaller application for updates. Teams can implement updates for the system in the same way, just like when the application was new and small.
The best way to transform a monolithic application to Microservices would be to find parts that can be easily compartmentalized first from the monolith. These chunks could be an email service or authentication service, which are typically small and simple. After that, a more critical look at the actual business needs and its workflow can be considered for points to target. The benefits will become more apparent as the system is broken down into smaller/more manageable parts, and the application moves toward Microservices. Application downtime will start to reduce, with new features added more rapidly.
Microsoft and .Net provide a strong offering in the Microservices space. Out of the box .Net and its toolchain provide rapid creation of WebAPIs and services that can be deployed for any platform. Microsoft has committed .Net Core to being platform agnostic and is supported on Linux, Mac, as well as Windows machines.
WebAPIs, by default, provide all responses back as JSON objects (or XML with a quick settings tweak) and are easily consumed by other applications within your network. Once you are up and running on the front end, make the most of the rest of .Net. Get hooked up into your database of choice, implement your business logic, and prepare outgoing files, such as CSV or Microsoft Office. Later consumption will become a trivial task.
Breaking down your old monolithic application into individual and manageable parts will become a much simpler process. Microsoft’s open-source commitment and work with third parties includes additional tools to make Microservices’ deployment and management easier with Docker and Kubernetes support.
It’s simple to get started with monolithic applications. Many software development platforms make monolithic applications seem natural. As a result, many companies are burdened with the unseen application and development costs. With careful planning, the monolithic trap can be filled with the more robust offering of Microservices. When done right, moving to Microservices will keep applications online, increase productivity, and keep maintenance downtimes to a minimum.
Senior Engineering Consultant
Meet our Experts
Senior Engineering Consultant
Patrick Lamm is a Senior Engineering Consultant specializing in the Microsoft .Net Stack at Levvel. He has maintained and improved various small to medium-sized codebases, including a codebase for an organization generating over $200M in annual revenue. Patrick is enthusiastic about history, cooking, experimenting with new ideas in .Net, and above all, spending time with his wife and two sons. Patrick earned a B.A. in Computer Science from UNC Charlotte.
You're doing big things, and big things come with big challenges. We're here to help.