This is Part 3 of the humor-inspired saga on the journey from monoliths to microservices, to serverless, and now incorporating AI agents. If you haven’t read Part 1: Mono’s Journey from Monolith to Microservices and Part 2: Mikro’s Serverless Saga, please do so first.
The question arises frequently in engineering discussions: “Should we break up our monolith into microservices?” The answer is often surprising: “Probably not” or “It depends”. This isn’t because microservices are bad—they’re not. It’s because the industry has finally moved past the religious wars where you were either team microservices or team monolith, with no middle ground. The reality in 2025 is far more nuanced.
This is part 2 of a humor-inspired take on Monoliths to microservices that I wrote a few years back: https://blogs.justenougharchitecture.com/monos-journey-from-monolith-to-microservices/. If you did not read that, please do so first.
Mikro was serving his consumers as always. He consistently met his promises (SLAs), and his life was good. Suddenly, he felt a stab and excruciating pain. “Damnit, what was that?” he said. To Mikro’s horror, he found himself being sliced and diced into smaller and smaller pieces. “But I thought I was already micro enough!” he wailed as functions were extracted from his very being.
So this is a mix of a couple of howtos. First, we have a simple Spring Boot app that retrieves some data from a MongoDB database that has authentication enabled to access it. Next, we will see how to store secrets in a Vault implementation and then programmatically access it (in our case the user ID and password to access the database).
There are multiple strategies you could use to introduce new service versions to an existing product. In this article I will go over how you can implement Canary deployments using Istio in a k82 cluster. The same approach can be used to implement Blue/Green deployments too.
Most serious applications (and distributed microservices style architectures) will require to provide a log aggregation & analysis feature to its dev & operations teams. Reviewing log entires from 10s or 100s of server instances is not something to take lightly. Whether you choose to use a commercial product or an open source offering – that does not matter; just make sure you have one available.
Recently I have been deploying applications using AWS Beanstalk. You can definitely configure CloudWatch Logs to send log streams over to AWS ElasticSearch service. Log messages can be routed to a Lambda function which would break the log messages into individual attributes suitable for indexing. I wanted to try a slightly different route where I depend less on CloudWatch Logs and more on open source tools. Enter filebeat on Beanstalk.
Notes on getting Docker Swarm cluster running on two Raspberry Pi 3 devices. We will then deploy a simple nodejs app container on the new cluster.
Updated one of my previous Spring Boot sample service to run within a Docker container – https://github.com/thomasma/quote-service-docker. You can run it locally w/o Docker as a regular Spring Boot app and next run it inside a Docker container. Make sure that you have Docker setup correctly and tested prior to running this app.
It is hard not to be affected by the constant chatter on Microservices Architecture and Container technology. Both are leading the discussions nowadays and they combine to provide new ways to Architect distributed systems and provide agility in delivering business value. While they do bring in big benefits when implemented successfully, the path to success for most enterprises (other than startups/product/tech firms) is going to be difficult and having a level of measured caution would be good.
To discuss Serverless Architecture we need to understand how we got here. From using physical machines we moved to virtual machines (somewhere in between a few brave folks also used linux/solaris containers). The current trend is container technologies such as Docker or CoreOS RKT which allow even more efficient use of resources. Regardless of which you use, we are often required to plan our application infrastructure needs upfront and permanently keep the “servers” running.