Skip to content

Micro-services – a year after

July 25, 2019

Wow, I feel like I am wandering into this huge field with landmines right now. This discussion has many, many topics and I will only focus on some of them.

Our experience

MICROSERVICE STRATEGY is kinda like something everyone in Tech has heard of and everyone wants to do, right? And we have now experienced some of the pain that comes when you split up the monolithic software:

  • Overhead when setting up the pipelines
    • Our Teamcity, Octopus and F5s must be configured correctly
  • MANY dependencies to keep track of
    • A client is suddenly not able to spin up locally without 20 other services
  • MANY variables when deploying to different environments
    • Since a service has lots of dependencies, those dependency endpoints are currently defined in each services’ web.config, and those values differ dependant upon which environment deploy to

Our deployment server has currently defined 153 different deployment of services, and they keep rising.

Did we forget the database?

I believe that we are doing the right thing, breaking up those monoliths.

However there is something missing in our current strategy. Although the number of services are still rising, the number of databases is not. Our company has had a long-lasting policy with 1 database pr customer.

It is said that microservices (or whatever you want to call it) are bounded contexts, and they should own their own storage. Still, none of the services created the last years (except SAAM) has gotten their own storage.

Now I am not saying that every service should have their own storage, but it makes sense on a larger level, the application domains.

From a infrastructure perspective, this makes life less flexible. Let’s say you want to move an application to another datacenter. In our scenario you cannot do that, because the database the application uses is also used by many other applications. It’s also insanely more easier and flexible to deal with backup/restore, data retention.

And from a developer point of view, those who want to have more control of the database, and introduce version control and continuous database delivery: it is much easier to start with a smaller database than with the WHOLE thingy.

We already have a ConnectionString service that handles mutliple customer databases, and when I asked all tech-employees in my company a year ago what was our best improvement, this was it. Still, there hasn’t been any initiatives on the database-split approach from the product teams. I guess it’s hard to get priority on such tasks when competing with other features that gives more direct value to the customers.


Service DiscoveryBilderesultat for consul sidecar

While the overhead of defining endpoints for each web.config in every service is getting larger, this certainly slows down the progress on improving our environments. It is clearly not a good idea having to know every endpoint (hostname/ip and port) out there, and it was certainly not a good idea of just having backend services as IPs only (you have to remember that was ServiceA-Prod and was ServiceA-Pilot).

I think some kind of service register and service discovery solution is needed and I believe it’s ok to start with the downstream services, the backend and not the clients. We also have to keep in mind that our company is an enterprise with different datacenters, multiple acquisitions and different hosting solutions, so a discovery solution must be really flexible. One scenario could be introducing Consul (or a similar sidecar concept) on our VMs. Consul will also work with Kubernetes and container solutions (when that time comes).

This concept will totally eliminate all those variable plumbings in Octopus, because when you want to call a service, all you gotta do is to call the local proxy with the name of the service. (like http://localhost:9999/ServiceA). All hosts will have a proxy and they are all in sync all then time. And the proxy is isolated to 1 environment so you don’t have to worry about calling ServiceA-Production or ServiceA-Pilot.

With this approach we can start small with getting our proxies installed on the hosts, and then start calling 1 service. After stabilizing we can start industrializing it more and more.


From → .Net

Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: