Switching from monolithic web apps to microservices
Anyone working as a Chief Technology Officer (CTO), or Product Owner of a web application will be only too aware of what a challenge those roles can be. You can be facing a whole host of technical issues as well as demands coming from the business.
It can be hard to implement the desired changes when you are dealing with a growing backlog, demanding customers and over-ambitious roadmaps set by people who don’t understand software development.
Because of this, unlocking value in existing applications is highly desirable for CTOs, and one of the most effective way of doing so is to make the switch from monolithic architecture to microservices. It’s not a straightforward task, but the benefits can be huge.
Challenges around monolithic web applications
A monolithic web application is built as a single, self-contained unit, which can be a great way for a small team of developers to get an application to market. It comprises all the features, functions, and modules of the application in one codebase and the entire application is developed, tested, and deployed as a single unit. Monolithic web applications are characterised by tight coupling, lack of modularity and often follow a Model, View, Controller pattern, with layers to handle UI, business logic and data access.
Trending
Unfortunately, monoliths are associated with a number of challenges, particularly as the application grows and scales:
Expensive and inefficient server scaling – if you need to scale your monolith to support more users or more requests, the answer is typically to scale vertically – i.e. provision a more powerful server. This is an expensive way to scale and has an upper ceiling. To make matters worse, you must scale your hardware to meet the needs of the most demanding element of your application. Horizontal scaling may not be possible with monoliths as they are often stateful, holding data in memory.
Bugs can crash the entire system – due to the tight coupling of the various modules in a monolithic application, a crash in one part of the application can bring down the entire server.
Deploys can cause downtime – because any change to a module or function requires the rebuilding and redeployment of the entire application, deploys can result in downtime and require testing of all areas of the application.
Development resource can be hard to manage – perhaps one of the biggest challenges with monoliths is the human element. Making changes in an application often requires changes to all three layers of the MVC pattern, which means new developers need to understand everything to be able to make changes. And it’s almost impossible to find developers who excel at the various skillsets that are required.
The result is that you either have to coordinate tightly coupled work between specialist developers or expect your developers to be great at each discipline. Since it is mission-critical that your business logic and data access layers are rock solid, this can often result in a team of engineers who are great at logic and data structures, but don’t enjoy wrangling with the peculiarities of the UI. Ultimately, it’s often the user interface that suffers – which is where your end users see the value in your product.
The role of microservices
These deficiencies are behind the rise of microservices, a software architecture that structures an application as a collection of small, independent, and loosely coupled services. Each service is responsible for a specific business capability, and it communicates with other services using lightweight protocols such as HTTP. Microservices are designed to be scalable, resilient, and fault-tolerant, and can serve multiple frontend UI applications via a stateless REST API.
There are many benefits to such an approach:
Easier and cheaper server scaling – one of the most significant benefits of microservices is their scalability. You can employ horizontal scaling targeted at the specific areas of the application that need it. For example, if a chat service is experiencing a high traffic load, you can spin up another server to handle more requests and add more redundancy. When the traffic dies down, you can scale the hardware in, meaning you only pay for the resources you use.
Increased resilience – microservices are designed to be resilient; since each module is independent, failure in one module does not affect the entire application. For example, if your chat service fails, your users are likely able to continue using the rest of your application.
More agile and flexible development – microservices allow for greater flexibility in development and deployment. Developers can work on individual services or UI applications independently, enabling them to work independently and to their strengths.
Technology diversity – monolithic web applications are typically built using a single technology stack. This can limit the flexibility and innovation of the development team. In contrast, microservices can take a polyglot approach, allowing developers to choose the best tool for the job.
Ease of maintenance – monolithic web applications can be challenging to maintain as the codebase grows. In contrast, microservices are smaller and more manageable, making maintenance and updates more straightforward and resulting in less technical debt.
Making the switch
Swapping to a microservices architecture can be transformative, but refactoring an entire application can seem like a daunting task. A common solution is something called the Strangler pattern; creating a facade API which passes requests through to the old system and incrementally replace each service.
Any CTO should consider how microservices will communicate with each other. A key characteristic of microservices is that they should be loosely coupled. If you are not careful, you can end up building your microservices in such a way that they are highly dependent on each other, which basically results in a distributed monolith.
The right people are also essential. Some of the common challenges associated with refactoring an application into microservices lie in upskilling existing team members or finding new talent to implement the changes. So, it is vital to hire the right people, or partner with specialists, to ensure a smooth transition.
The shift from monolithic web applications to a microservice architecture is fuelled by the need for more scalable, flexible, and resilient applications that can meet the demands of modern-day users. It’s a shift that is set to continue, as enterprises seek to extract maximum value from their web applications.
