From Monolith to Microservices - Chapter 1

I got some free time to invest in learning about Kubernetes, I will talk about the courses you can find at kubernetes.io/training. Let's get started with introduction-to-Kubernetes.

Learning Objectives:

• Explain what a monolith is.
• Discuss the monolith's challenges in the cloud.
• Explain the concept of microservices.
• Discuss microservices advantages in the cloud.
• Describe the transformation path from a monolith to microservices.

What is a Monolith?

A Monolith describes a single-tiered software application in which the user interface and data access code are combined into a single program from single platform. It is self-contained and independent from other computing applications.

The training describes the monolith as a single system that must satisfy compute, memory, storage and network requirements.

Challenges in the cloud

Like I said before, to keep a Monolith maintained it takes a lot of effort. Since the entire monolith application runs as a single process, the scaling of individual features of the monolith is almost impossible. It internally supports a hard-coded number of connections and operations. However, scaling the entire application can be achieved by manually deploying a new instance of the monolith on another server, typically behind a load balancing appliance - another pricey solution.

Downtime's are inevitable and maintenance windows have to be planned well in advance as disruptions in service are expected to impact clients. An highly available active/passive configuration is the way to go, which in itself brings again challenges to setup for example a Zero Down-time Deployment. Take for example a CMS like Sitecore, where you have one Content Management instance to manage your content and several Content Delivery instances that have to always be available for the customer to visit. The Content Delivery instances are relying on the single Content Management instance. A deployment with new features might break the CD instances which are not deployed yet, which might make the Zero down-time Deployment obsolete.

As summary you can say that monolithic applications are very hard to maintain and get pricey if your business grows.

What is a Microservice?

I am citing the training about microservices:

"Pebbles, as opposed to the 1000-ton boulder, are much easier to handle. They are carved out of the monolith, separated from one another, becoming distributed components each described by a set of specific characteristics. Once weighed all together, the pebbles make up the weight of the entire boulder. These pebbles represent loosely coupled microservices, each performing a specific business function."

Advantages in the cloud

Microservices can be deployed individually on separate servers provisioned with fewer resources. The architecture is aligned with event-driven architecture and service-oriented architecture. Communication will be done over API access by the services. While we gain great flexibility, the distributed nature of microservices adds complexity to the architecture.

While this might be true, the great benefit of using microservices are seamless upgrades and patching processes. The biggest benefit is the simple scalability of the services which have more overhead, without scaling every component no matter the scale in a monolithic application.

Transformation path from a monolith to microservices

Refactoring is a big part of the transition to a microservice approach. In the training they talk about two approaches to refactoring of an decades old monolithic size multi-process application.

The "Big Bang" refactoring focuses all efforts with the refactoring of the monolith, postponing the development and implementation of any new features, even breaking the monolith can be the case.

An incremental refactoring approach guarantees that new features are developed and implemented as modern microservices which can communicate with the monolith through API's.

Once the refactoring is done there are several challenges in front of you. Chances are that different libraries and runtime environments may conflict with one another causing errors and failures. Luckily, containers came along, that are providing an encapsulation of lightweight runtime environments.

You can read some success stories at kubernetes.io/case-studies/

That is it my friends, thanks for reading.

(most parts of this write up is very similar to the training I mentioned, I recommend you to also do the training as it is free and good)