Is it needed to migrate from monolithic to micro service architecture?
Micro Services are the new architecture, that software engineers are fascinated about today. Promoted and explored by tech giants, using new technologies such as docker, this architecture get easier approachable by a wide range of businesses, that do noy necessarily originate from the technology branch.
monolithic architecture
The monolithic architecture, is not something, that people intended to do. It is more like a stamp that the promoters of micro services use, to make classic architectures look old and inefficient.
Typically they are meant to be old mainframe systems or the all to widely used three tier architecture (frontend, backend, database).
The good point of the monolithic architecture is, it is simple. There is one application to build and to deploy. All the features are included to this one application.
These monolithic apps are usually build using one technology. Like Java or C# are very common for building large enterprise applications in a monolithic style. PHP, Ruby, python and node.js are more likely to be used to build the backend application server in a three tier architecture.
There are two main disadvantages to these kind of architectures. It is difficult to measure what functionality uses how much resources individually. By doing better measurement, you can be able to offer a more fair pricing to your clients or simply get savings from not over-sizing your system.
The second disadvantage are difficult to predict and identify latencies and spikes in workloads. Lets say your app has 10 servers. and one has to run a cron job. The web proxy still give requests via round robin to the servers While 9 out of 10 requests are fast, the 10th request will hit the server that is busy occupied with an other large task. causing a bad user experience. “but just sometimes”. It is very hard to find the reason for such issues.
micro service architecture
When talking about these architectures it is almost always spoken about the design of the backend. With the word micro service, there is meant to have a backend that consist of many smaller services.
Each service can be deployed and updated individually. That can make each deployment easier.
In a micro service architecture, the different services can be implemented using different technologies. While is php service is good to implement some database operations. A service made with node.js is better suited to have many client connections connected, such as via web-sockets. A service made using golang is very good. to do very general tasks like a proxy server that does some data normalization.
While this is an advantage of using the right best suitable technology for the job at hand, you can also see, that it can cost quite a lot to hire the expert for each of thr technologies. While I am certainly able to build applications using Java and C#, my personal strengths are definitely somewhere else and it is likely that I am not able to utilize on the strengths of the technology.
When having a micro service architecture, it is very good visible to see what service require more resources. When there is a functionality like cron jobs or some data migration (import exports) an additional service can be create, so that the performance, lets say for the web service, is not compromised.
When we have requests and commands coming from different systems, such as from third party services or (again) from users of our app, we can measure very detailed how each kind of tasks that our system performs require different resources, like RAM, storage, CPU or networking. According to the measurements we can add specific resources to those services, not over sizing other resources for that service. This can result in lots of savings.
orchestration using docker
Today micro services are mostly managed and operated using the software docker. Each service get packaged into a reusable image. and as more resources are needed more servers with that services image can be creates.
Docker is a lightweight virtualization solution. That can run applications in a virtual server, with very little overhead compared to running a software native on the host system.
As the virtualization is nice, the real power comes when installing docker on many servers. Then there is a solution called swarm or kubernetes. With kubernetes, you can add many servers into a cluster network, then define what services need to run, and kubernetes will automatically use one of the physic servers to run the service. Kubernetes also has network routing build in. With that, you can just say, that of the web services you need 5, and kubernetes will choose 5 servers in its.cluster to run the service and automatically route network requests via round robin or other strategies to those servers.
With kubernetes it is easy (relatively) to manage many kinds of services that all together are part of your app.
moving from monythic to microservice
Moving your architecture from monolithic to a micro service architecture be done gradually. A first step can be to host your app within a docker cluster environment. Within your monolithic application you can add feature flags. So that features such as
- listening for web request
- listening for pub sub messages
- third party api,
- cron jobs
can be deactivates. Then in your docker swarm or kubernetes configuration, you can set up multiple services, all using the same image, but fulfilling different tasks. With the help of kubernetes build-in routing or a web proxy like nginx, you can then route the workloads to the right service.
This is how you can gain many advantages of the micro service architecture from your single codebase monolithic app.
Should I migrate my architecture to micro services?
I believe small to medium sized business outside of the tech industry have very seldom the need to build there own micro service infrastructure.
For a tech company or any company that already has an IT department and that is already managing servers and there own network applications can profit well, and be prepared for the future.
With the path I have shown above, to migrate a large application into a container environment the barrier get very low, and there is quite some value to gain.
That said, please be aware, that I work personally every day with docker but can not compare it to a vm and computing resource management such as openStack. From previous experiences setting up micro services as processes across multiple servers, I believe that the use of virtualization containers with docker is very effective. For small business however, hosting options are a bit more pricy compared to managed VMs. But in future with a more wide adoption of container environments, these price gap should close.