Last two articles from that series on Microservices:
There are multiple patterns for deployment. Monolith applications are usually deployed in their entirety to multiple hosts, but that does not have to be the case for Microservices.
The Mutliple Services per Host pattern is exactly what it sounds like, you deploy an instance of multiple services to the same host / vm. Whether they be in the same container / web server or running as separate processes. Some benefits is that you can share resources of the underlying server / host. Deployment can be fast and easy. Some draw backs are that you are coupling services together by their resources. One service could hog all the resources, starving the other services.
An alternative pattern is One Service per Host. Each deployed service instance has it’s own host / server and set of resources. There are two flavours of this, Service Instance per VM & Service Instance per container. (And deploying items to the cloud in serverless offerings gives us another flavour with Azure WebApps or AWS Beanstalk or FaaS). Service Instance per VM uses VM images to package up the VM which is then instantiated as many times as you need. Packaging your services into VMs gives you a reusable template that you can deploy over and over, which can also take advantage of other modern cloud benefits such as load balancing and auto scaling. Deploying becomes reliable. Downsides are that you have the overhead of an entire VM per service instance, including the OS. That’s where per container patterns can help, as they package a smaller footprint that can be deployed with fewer resources. Some downsides to Containers are the newness of the technology. It’s rapidily becoming more mature, but they’ve only been around for a couple of years. If you don’t use a managed container service, you are also responsible for the container infrastructure and underlying OS / VM.
When refactoring a monolith application to Microservices, it’s best to break off pieces of the application into services gradually, rather than rewriting the entire application at once. You can shrink the functionality in the monolith by running Microservices along side, shifting more and more features to services until the monolith disappears, or becomes one of many Microservices.
When you have a monolith and Microservices you will need both a router (to route incoming traffic to the appropriate code) and some glue code to get both working together.
An initial split of your Monolith can naturally happen between the different layers, specifically the presentation and the business & data access layers.
When you begin to break things up further, start small, and start with the low hanging fruit to get more familiar with Microservices and it’s quirks. Modules and functionality that change frequency are also good candidates for breaking off early, as it frees you from having to build and deploy the whole app for the frequent changes.
That’s the end of the Microservices article series. I feel like I got a good glimpse into the elements that a Microservices architecture encompass. I wish that I had a code base to work with / tutor to help guide me through a real world example, but I feel more confident in having discussions about this architecture type. I think a lot of the projects I have at work right now are a bit too small to consider converting (although, we do have semblances of Microservices in some sites). Glad I read through them all.