Microservices - one of the current buzz words running around. Microservices instead of a monolith.

And yes, Microservices have its advantages: Decoupling simple services, isolating databases. Each service can be built in another language or another framework by another team in another place. Each service can easily be replaced by a completely new one that fulfils the contract. We actually did all of the above and those benefits are quite nice.

Testing Monolith

There is already a load of articles about the hidden costs of Microservices. Microservices have to resilient, the must be able to handle network outage, missing data base or message queueing system on start-up and during runtime. This is actually not that easy as it turns out. You can't have foreign keys in data bases of other services so you would need something like CQRS to handle it.

You now have dependencies to an HTTP interface. When they change without notice, you won't get a compiler error but strange behaviors at runtime. So you better have versioned interfaces and need to support at least two at a time which also is not that easy if you want to move forward. Actually, you can never really trust those interfaces which leads to a testing monolith. You will probably have unit tests, component/service tests. But you would need a system integration test that covers your system end-to-end because integration can be hard.

On-Premise

But there is another issue when you want to deploy it on some customer system. I know most people who are using Microservices in the wild have some nice Website, hosting there own cloud infrastructure or using AWS or CloudFoundry e.g. You could probably put every component in its own Docker container or directly push your Spring Boot application with one command to the cloud.

And now, there is on-premise. You might ask yourself why on earth would you want to do that? Everything is built on cloud infrastructure nowadays, right? But when you develop professional services, there are a lot of customers that do not want to host there applications and - more importantly - their data abroad on some foreign big companies servers. This is about data security. Most parts of their critical server infrastructure is part of separate network segments that might not even have internet access.

So if you want to sell your products and solutions, you need address that.

Especially, when you are targeting cloud operations as well, you might already have designed your products as microservices which is good because you can plug-in new parts or replace parts in specific customer solutions.

Deployment Monolith

But how will you ship, deploy, operate your microservices when you don't have internet access? You might only have a crappy Windows-based VPN connection and you have to address legal issues when shipping your proprietary software.

When you put you artifacts in Docker containers, you would need to provide appropriate 3rd party licence information. That includes not only your application, but everything within it, especially the Linux OS. This is almost impossible to do.

So, no Docker. Ok, no problem, you would just deploy your artifacts on CloudFoundry... except that there is no CloudFoundry on the target system. And its way to heavy-weight to install it for a small deployment.

You could use Ansible to install e.g. the message queuing system and your application components but wait, because of the network situation, you cannot have your workstation as the control machine.

You may at least use Consul to handle you configuration.

So you probably end up, writing ugly unmaintainable shell scripts that set-up the initial infrastructure, starting your services and provide them with configuration.

This is the infamous deployment monolith.

Summary

There is no technology that I know of that helps you dealing with all those problems in an on-premise scenario. So if you plan to build an application from scratch and it is only meant to be used in on-premise scenarios as described, you probably shouldn't go for a microservice architecture. At least, it shows some other flaw in that paradigm that might be addressed by good frameworks/tools in the future.