Yodle helps small businesses succeed in online marketing. We make it easy to grow and manage profitable customer relationships; it is success simplified.

I would like to say it’s something that has a very clear description. If you can say "it does x, y and z" in a simple sentence then perfect. If you need a full paragraph describing countless features then it’s probably not a microservice. It should be small. It should be re-buildable in a handful of days.

That being said, we are not so picky because the way our PaaS is set up. We are decomposing a monolith into the same estate; we have some what I call macro-services: traditional SOA services that do 30, 40, 50 different things. I don’t think that is where we want to be in the long term, but it’s okay now, as long as you have sufficient testing and monitoring around those services so you can release them in a decoupled manner.

There are three things that we are primarily talking about. One is about shared data resources. We had a large PostgreSQL database. Prior to being dockerized microservices, everything was in Tomcat containers where we may have had perhaps 40 or 50 JVM’s hitting this database using connection pools. There might have been tons of services in one container there were sharing one connection pool.

You could go to a minimum idle of zero but that is a questionable place to be for performance considerations. We switched to something called pgbouncer, which is a PostgreSQL library that acts as an external connection pool. We ran one of per slave host and all of the microservices are making connections to that, so essentially taking the connection pool and taking it out of the JVM.

We had to build tooling to make it easier for the systems engineers to produce databases as quickly as they could to satisfy the needs of the developers. MongoDB databases with dedicated per service user accounts. PostgreSQL databases with per service user accounts tied to single schemas.

There will be lots of bumps along the way on your path to micro-services and that is OK and to be expected. You will need to iterate multiple times in expected and unexpected ways. Testing is one example. When you bring in micro services, especially if you are decomposing a monolith, you start getting into this situation where you are going to be changing your testing methodologies.

You need to ensure that your testing infrastructure can evolve with you. This is where having a way to express your dependencies, whether that be just something that your test engineers know, whether that is integrating into your CD pipeline, becomes important to you. So what we did was, we built a canary testing process that would allow developers to express dependencies and smoke tests in the application in the container on an endpoint named "tests". When a service gets deployed, before the service is available to route general traffic, the framework will ping the service to determine the tests, run them, validate them and finally decide: "okay, you are in place, you are good". Now the rest of the ecosystem can work. This could have been done just by expressing it in a file. Whatever you wanted to do and your test infrastructure has to work with that. This gives a way for developers to express dependencies and we can ensure that we are not breaking the ecosystem as we evolve.